OpenYurt v1.1.0: 新增 DaemonSet 的 OTA 和 Auto 升级策略

简介：在 OpenYurt v1.1.0 版本中，我们提供了 Auto 和 OTA 的升级策略。Auto 的升级策略重点解决由于节点 NotReady 而导致 DaemonSet升级阻塞的问题，OTA 的升级策略主要应对边缘侧用户需要自主控制升级时机的场景。以下对这两种策略做简要的介绍。

作者：昌蒲、侯雪城

边缘计算云原生平台、CNCF SandBox 项目 - OpenYurt[1]，近期发布了 v1.1.0 版本。

OpenYurt 作为边缘云原生领域的开源项目，采用云管边的云边一体化架构，致力于解决云原生落地边缘计算场景的痛点问题。针对边缘计算场景，重点提供了边缘自治、云边运维通道、资源及流量的单元化管理、设备管理等核心能力。所有功能对原生 Kubernetes 无侵入，全部采用 Addons 的形式安装部署。

版本解析

在 OpenYurt v1.1.0 版本中，我们提供了 Auto 和 OTA 的升级策略。Auto 的升级策略重点解决由于节点 NotReady 而导致 DaemonSet[3]升级阻塞的问题，OTA 的升级策略主要应对边缘侧用户需要自主控制升级时机的场景。以下对这两种策略做简要的介绍。

DaemonSet 的 Auto 升级策略

在云边一体化架构中，边缘节点通常借助公网与云上管控交互。一方面，由于公网的不稳定性通常会导致边缘节点处于 NotReady 的状态，另一方面一些边缘节点处于网络受限的环境内，业务部署之后会断开公网连接。而原生 DaemonSet 滚动升级策略中，会因为节点的 NotReady 而导致老的 Pod 一直处于 Terminating 的状态，新的 Pod 无法创建，从而阻塞整个升级流程，导致集群中 Ready 节点上的 Pod 也无法继续升级。

为了解决上述问题，我们扩展了原生 DaemonSet 的升级模型[2]，在 Yurt-Controller-Manager 组件内新增自定义控制器 daemonPodUpdater-controller，提供了 Auto 的升级策略。该策略支持跳过 NotReady 节点上 Pod 的升级，待节点 Ready 之后，会自动触发 Pod 的更新。

如果需要使用 DaemonSet 的 Auto 升级策略，需要将原生的升级策略设置为 OnDelete，便于让 daemonPodUpdater-controller 接管 DaemonSet 的升级。同时，需要增加 annotations apps.openyurt.io/update-strategy: auto 来标名使用 Auto 的升级策略。此外，还可以通过设置 apps.openyurt.io/max-unavailable 的 annotations 来支持升级配置过程中 Pod 最大不可用数。具体的升级策略配置文件示例如下。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  # ···
  annotations:
    apps.openyurt.io/update-strategy: auto
    # 该注解用于滚动更新时设置最大不可用 pod 数量，仅在 auto 模式下起作用。
    # 该注解支持的配置值与原生 DaemonSet 配置中 maxUnavailable 相同，默认值为10%。
    apps.openyurt.io/max-unavailable: 30%
  # ···
spec:
  # ···
  # 使用 auto模型的另一个前提条件是将 updateStrategy 设置为 OnDelete。
  updateStrategy:
    type: OnDelete
  # ···

DaemonSet 的 OTA 升级策略

边缘侧业务所处的环境复杂多样，通过云上做统一升级的方式很难满足所有的业务升级场景。在一些边缘计算场景中，当业务有新版本发布时，用户期望能够自行决定升级的时机。例如，位于汽车上的边缘业务，当汽车正在行驶的过程中，是不能触发业务升级的，如果从云端做统一的升级，会导致业务服务中断，甚至引发交通事故。

为此，我们提供了 OTA 的升级策略，支持云端发布新版本，边缘侧用户自动决定升级时机。该策略由 daemonPodUpdater-controller 和 YurtHub 组件配和实现。在 daemonPodUpdater-controller 中，检测到 DaemonSet 有新版本发布时，会在 DaemonSet 所管理的 Pod 中新增 PodNeedUpgrade 的 condition 来表明此 Pod 有新版本发布，可以升级。在 YurtHub 中提供 Pod 升级相关的 API，边缘侧的用户通过自行调用 YurtHub 提供的 API 来完成业务 Pod 升级。

如果需要使用 OTA 的升级策略，需要将原生的升级策略设置为 OnDelete，同时增加 annotations apps.openyurt.io/update-strategy: ota 来标明使用 OTA 的升级策略没，具体的升级策略配置文件示例如下：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  # ···
  annotations:
    apps.openyurt.io/update-strategy: ota
  # ···
spec:
  # ···
  # 使用ota 升级模型的另一个前提条件是将 updateStrategy 设置为 OnDelete。
  updateStrategy:
    type: OnDelete
  # ···

此外，用户需要自行调用 YurtHub 的 API 来自行发现和升级 Pod，API 设计如下：

1. GET /pods：

通过该接口可以获取到边缘节点上全部 pods 列表信息，通过 pod 的 PodNeedUpgrade 状态判断是否有新版本可升级。

2. POST /openyurt.io/v1/namespaces/{ns}/pods/{podname}/upgrade：

通过该接口用户可以指定升级某个 DaemonSet Pod。路径参数 ns 与 podname 分别代表 Pod 的命名空间以及名称。

其它改动

你可以通过 Github release[4]页面，来查看更多的改动以及它们的作者与提交记录。

社区参与

非常欢迎你通过 Github/Slack/钉钉等方式加入我们来参与 OpenYurt 开源社区。你是否已经有一些希望与我们社区交流的内容呢？可以在我们的社区周会[6]上分享你的声音，或通过加入社区 Slack channel[5]参与讨论。

阿里云云栖社区