搜索

3.4. 执行 canary rollout 更新

download PDF

金丝雀更新是一种更新策略,其中 worker 节点更新以离散的、阶段阶段执行,而不是同时更新所有 worker 节点。这个策略在以下情况下很有用:

  • 您需要一个受控的 worker 节点更新推出,以确保任务关键型应用程序在整个更新过程中仍然可用,即使更新过程会导致应用程序失败。
  • 您需要更新一小部分 worker 节点,在一个时间段内评估集群和工作负载健康状况,然后更新剩余的节点。
  • 您可能希望将通常需要主机重新引导的 worker 节点更新放入较小的定义的维护窗口(不可能一次使用大型维护窗口来更新整个集群)。

在这些情况下,您可以创建多个自定义机器配置池 (MCP),以防止某些 worker 节点在更新集群时进行更新。在更新剩余的集群后,您可以在适当的时间批量更新这些 worker 节点。

3.4.1. 金丝雀更新策略示例

以下示例描述了一个金丝雀更新策略,其中有一个有 10% 的 100 个节点的集群,您有没有超过 4 小时的维护窗口,您知道排空并重启 worker 节点所需的时间不超过 8 分钟。

注意

以上值是仅限示例。排空节点所需的时间可能会因工作负载等因素而异。

定义自定义机器配置池

要将 worker 节点的更新组织到不同的独立阶段,您可以从定义以下 MCP 开始:

  • workerpool-canary,有 10 个节点
  • workerpool-A,有 30 个节点
  • workerpool-B,有 30 个节点
  • workerpool-C,有 30 个节点
更新 Canary worker 池

在第一个维护窗口中,您将暂停 workerpool-Aworkerpool-Bworkerpool-C 的 MCP,然后启动集群更新。这将更新在 OpenShift Container Platform 上运行的组件,以及作为取消暂停的 workerpool-canary MCP 一部分的 10 个节点。其他三个 MCP 不会更新,因为它们已暂停。

确定是否继续剩余的 worker 池更新

如果出于某种原因,您确定集群或工作负载健康受到 workerpool-canary 更新的负面影响,那么在分析完问题前,您会在保持足够容量的同时,对那个池中的所有节点进行 cordon 和 drain 操作。当一切按预期工作时,您可以在决定取消暂停前评估集群和工作负载健康状况,从而更新 workerpool-Aworkerpool-Bworkerpool-C 在每个额外的维护窗口中连续工作。

使用自定义 MCP 管理 worker 节点更新提供了灵活性,但它可能是一个耗时的过程,需要您执行多个命令。这种复杂性可能会导致错误可能会影响整个集群。建议您仔细考虑您的组织需求,并在开始之前仔细规划流程的实施。

重要

暂停机器配置池可防止 Machine Config Operator 在关联的节点上应用任何配置更改。暂停 MCP 还可以防止任何自动轮转的证书被推送到关联的节点,包括自动轮转 kube-apiserver-to-kubelet-signer CA 证书。

kube-apiserver-to-kubelet-signer CA 证书过期且 MCO 尝试自动更新证书时,MCO 无法将新轮转的证书推送到这些节点。这会导致多个 oc 命令失败,包括 oc debugoc logsoc execoc attach。如果在轮转证书时,如果 MCP 被暂停,则 OpenShift Container Platform Web 控制台的 Alerting UI 中收到警报。

在暂停 MCP 时应该非常小心,需要仔细考虑 kube-apiserver-to-kubelet-signer CA 证书过期的问题,且仅在短时间内暂停。

注意

不建议将 MCP 更新至不同的 OpenShift Container Platform 版本。例如,请勿将一个 MCP 从 4.y.10 更新至 4.y.11,另一个更新为 4.y.12。这个场景还没有被测试,可能会导致未定义的集群状态。

3.4.2. 关于 Canary rollout 更新过程和 MCP

在 OpenShift Container Platform 中,节点不会被单独考虑。相反,它们被分组到机器配置池中 (MCP)。默认情况下,OpenShift Container Platform 集群中的节点分组到两个 MCP 中:一个用于 control plane 节点,一个用于 worker 节点。OpenShift Container Platform 更新会同时影响所有 MCP。

在更新过程中,如果指定了最大数字,Machine Config Operator (MCO) 会排空并封锁 MCP 中的最多为 maxUnavailable 中指定的数量的节点。默认情况下,maxUnavailable 设置为 1。排空节点取消调度节点上的所有 pod,并将该节点标记为不可调度。

节点排空后,Machine Config Daemon 应用一个新的机器配置,其中包括更新操作系统 (OS)。更新操作系统需要主机重新引导。

使用自定义机器配置池

要防止特定节点被更新,您可以创建自定义 MCP。因为 MCO 不会在暂停的 MCP 中更新节点,所以您可以在启动集群更新前暂停包含您不想更新的节点的 MCP。

使用一个或多个自定义 MCP 可以让您更好地控制您更新 worker 节点的顺序。例如,在更新第一个 MCP 中的节点后,您可以验证应用程序兼容性,然后逐步将其余节点更新至新版本。

警告

对于 OpenShift Container Platform 中的所有机器配置池,maxUnavailable 的默认设置是 1。建议您不要更改这个值,且一次只更新一个 control plane 节点。对于 control plane 池,请不要将这个值改为 3

注意

为确保 control plane 的稳定性,不支持从 control plane 节点创建自定义 MCP。Machine Config Operator (MCO) 会忽略为 control plane 节点创建的任何自定义 MCP。

使用自定义机器配置池时的注意事项

根据工作负载部署拓扑,请仔细考虑您创建的 MCP 数以及每个 MCP 中的节点数。例如,如果必须将更新适合特定的维护窗口,您必须了解在给定窗口中可以更新多少个节点 OpenShift Container Platform。这个数字取决于您具体的集群和工作负载特性。

您还必须考虑集群中有多少额外容量,以确定自定义 MCP 的数量以及每个 MCP 中的节点数。当应用程序无法在更新的节点上按预期工作时,您可以对池中那些节点进行 cordon 和 drain 操作,这会将应用 pod 移到其他节点上。但是,您必须确定剩余的 MCP 中的可用节点是否可以为您的应用程序提供足够的服务质量 (QoS)。

注意

您可以将这个更新过程与所有记录的 OpenShift Container Platform 更新过程一起使用。但是,该过程不适用于使用 Ansible playbook 进行更新的 Red Hat Enterprise Linux (RHEL) 机器。

3.4.3. 关于执行 canary rollout 更新

下列步骤概述了金丝雀 rollout 更新过程的高级工作流:

  1. 根据 worker 池创建自定义机器配置池 (MCP)。

    注意

    您可以更改 MCP 中的 maxUnavailable 设置,以指定在任意给定时间可以更新的机器的百分比或数量。默认值为 1

    警告

    对于 OpenShift Container Platform 中的所有机器配置池,maxUnavailable 的默认设置是 1。建议您不要更改这个值,且一次只更新一个 control plane 节点。对于 control plane 池,请不要将这个值改为 3

  2. 将节点选择器添加到自定义 MCP。对于您不想与剩余的集群同时更新的每个节点,请向节点添加匹配的标签。该标签将节点与 MCP 相关联。

    重要

    不要从节点中删除默认 worker 标签。节点必须具有 role 标签才能在集群中正常工作。

  3. 在更新过程中暂停您不想更新的 MCP。
  4. 执行集群更新。更新过程更新没有暂停的 MCP,包括 control plane 节点。
  5. 在更新的节点上测试应用程序,以确保它们按预期工作。
  6. 取消暂停剩余的 MCP,等待池中的节点完成更新,并在这些节点上测试应用程序。重复此过程,直到所有 worker 节点都已更新。
  7. 可选:从更新的节点中删除自定义标签并删除自定义 MCP。

3.4.4. 创建机器配置池来执行 canary rollout 更新

要执行 Canary rollout 更新,您必须首先创建一个或多个自定义机器配置池 (MCP)。

流程

  1. 运行以下命令列出集群中的 worker 节点:

    $ oc get -l 'node-role.kubernetes.io/master!=' -o 'jsonpath={range .items[*]}{.metadata.name}{"\n"}{end}' nodes

    输出示例

    ci-ln-pwnll6b-f76d1-s8t9n-worker-a-s75z4
    ci-ln-pwnll6b-f76d1-s8t9n-worker-b-dglj2
    ci-ln-pwnll6b-f76d1-s8t9n-worker-c-lldbm

  2. 对于您要延迟的每个节点,运行以下命令为节点添加自定义标签:

    $ oc label node <node_name> node-role.kubernetes.io/<custom_label>=

    例如:

    $ oc label node ci-ln-0qv1yp2-f76d1-kl2tq-worker-a-j2ssz node-role.kubernetes.io/workerpool-canary=

    输出示例

    node/ci-ln-gtrwm8t-f76d1-spbl7-worker-a-xk76k labeled

  3. 创建新的 MCP:

    1. 创建 MCP YAML 文件:

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      metadata:
        name: workerpool-canary 1
      spec:
        machineConfigSelector:
          matchExpressions:
            - {
               key: machineconfiguration.openshift.io/role,
               operator: In,
               values: [worker,workerpool-canary] 2
              }
        nodeSelector:
          matchLabels:
            node-role.kubernetes.io/workerpool-canary: "" 3
      1
      为 MCP 指定名称。
      2
      指定 worker 和自定义 MCP 名称。
      3
      指定添加到此池中的自定义标签。
    2. 运行以下命令来创建 MachineConfigPool 对象:

      $ oc create -f <file_name>

      输出示例

      machineconfigpool.machineconfiguration.openshift.io/workerpool-canary created

  4. 运行以下命令,查看集群中的 MCP 列表及其当前状态:

    $ oc get machineconfigpool

    输出示例

    NAME              CONFIG                                                        UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
    master            rendered-master-b0bb90c4921860f2a5d8a2f8137c1867              True      False      False      3              3                   3                     0                      97m
    workerpool-canary rendered-workerpool-canary-87ba3dec1ad78cb6aecebf7fbb476a36   True      False      False      1              1                   1                     0                      2m42s
    worker            rendered-worker-87ba3dec1ad78cb6aecebf7fbb476a36              True      False      False      2              2                   2                     0                      97m

    创建新的机器配置池 workerpool-canary,机器计数中会显示您添加自定义标签的节点数量。worker MCP 机器数会减少相同的数字。更新机器数可能需要几分钟时间。在本例中,一个节点已从 worker MCP 移到 worker pool-canary MCP。

3.4.5. 暂停机器配置池

创建自定义机器配置池 (MCP) 后,您将暂停这些 MCP。暂停 MCP 可防止 Machine Config Operator (MCO) 更新与该 MCP 关联的节点。

流程

  1. 运行以下命令修补您要暂停的 MCP:

    $ oc patch mcp/<mcp_name> --patch '{"spec":{"paused":true}}' --type=merge

    例如:

    $  oc patch mcp/workerpool-canary --patch '{"spec":{"paused":true}}' --type=merge

    输出示例

    machineconfigpool.machineconfiguration.openshift.io/workerpool-canary patched

3.4.6. 执行集群更新

在机器配置池 (MCP) 进入就绪状态后,您可以执行集群更新。根据您的集群,请查看以下更新方法之一:

集群更新后,您可以一次开始取消暂停 MCP。

3.4.7. 取消暂停机器配置池

OpenShift Container Platform 更新完成后,一次取消暂停您的自定义机器配置池 (MCP)。取消暂停 MCP 允许 Machine Config Operator (MCO) 更新与该 MCP 关联的节点。

流程

  1. 对您要取消暂停的 MCP 进行补丁:

    $ oc patch mcp/<mcp_name> --patch '{"spec":{"paused":false}}' --type=merge

    例如:

    $  oc patch mcp/workerpool-canary --patch '{"spec":{"paused":false}}' --type=merge

    输出示例

    machineconfigpool.machineconfiguration.openshift.io/workerpool-canary patched

  2. 可选:使用以下选项之一检查更新的进度:

    1. Administration Cluster settings 从 web 控制台检查进度。
    2. 运行以下命令检查进度:

      $ oc get machineconfigpools
  3. 在更新的节点上测试您的应用,以确保它们按预期工作。
  4. 一次对任何其他暂停的 MCP 重复此过程。
注意

如果应用程序出现故障,如应用程序未在更新的节点上工作,您可以对池中的节点进行 cordon 和 drain 操作,这会将应用 pod 移到其他节点,以帮助维护应用程序的服务质量。第一个 MCP 不应大于过量容量。

3.4.8. 将节点移到原始机器配置池中

在自定义机器配置池(MCP)的节点上更新并验证应用程序后,删除添加到节点的自定义标签,将节点移回到其原始 MCP。

重要

节点必须具有角色才能在集群中正常工作。

流程

  1. 对于自定义 MCP 中的每个节点,运行以下命令来从节点中删除自定义标签:

    $ oc label node <node_name> node-role.kubernetes.io/<custom_label>-

    例如:

    $ oc label node ci-ln-0qv1yp2-f76d1-kl2tq-worker-a-j2ssz node-role.kubernetes.io/workerpool-canary-

    输出示例

    node/ci-ln-0qv1yp2-f76d1-kl2tq-worker-a-j2ssz labeled

    Machine Config Operator 将节点移回到原始 MCP,并将节点与 MCP 配置协调。

  2. 要确保节点已从自定义 MCP 中删除,请运行以下命令来查看集群中的 MCP 列表及其当前状态:

    $ oc get mcp

    输出示例

    NAME                CONFIG                                                   UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
    master              rendered-master-1203f157d053fd987c7cbd91e3fbc0ed         True      False      False      3              3                   3                     0                      61m
    workerpool-canary   rendered-mcp-noupdate-5ad4791166c468f3a35cd16e734c9028   True      False      False      0              0                   0                     0                      21m
    worker              rendered-worker-5ad4791166c468f3a35cd16e734c9028         True      False      False      3              3                   3                     0                      61m

    当节点从自定义 MCP 中删除并移回原始 MCP 时,可能需要几分钟时间来更新机器计数。在这个示例中,将一个节点从删除的 workerpool-canary MCP 移到 worker MCP。

  3. 可选:运行以下命令来删除自定义 MCP:

    $ oc delete mcp <mcp_name>
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.