3.4. 执行 canary rollout 更新

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-A、workerpool-B 和 workerpool-C 的 MCP，然后启动集群更新。这将更新在 OpenShift Container Platform 上运行的组件，以及作为取消暂停的 workerpool-canary MCP 一部分的 10 个节点。其他三个 MCP 不会更新，因为它们已暂停。

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

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

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

重要

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

当 kube-apiserver-to-kubelet-signer CA 证书过期且 MCO 尝试自动更新证书时，MCO 无法将新轮转的证书推送到这些节点。这会导致多个 oc 命令失败，包括 oc debug、oc logs、oc exec 和 oc 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 更新过程的高级工作流：

根据 worker 池创建自定义机器配置池 (MCP)。
注意
您可以更改 MCP 中的 maxUnavailable 设置，以指定在任意给定时间可以更新的机器的百分比或数量。默认值为 1。
警告
对于 OpenShift Container Platform 中的所有机器配置池，maxUnavailable 的默认设置是 1。建议您不要更改这个值，且一次只更新一个 control plane 节点。对于 control plane 池，请不要将这个值改为 3。
将节点选择器添加到自定义 MCP。对于您不想与剩余的集群同时更新的每个节点，请向节点添加匹配的标签。该标签将节点与 MCP 相关联。
重要
不要从节点中删除默认 worker 标签。节点必须具有 role 标签才能在集群中正常工作。
在更新过程中暂停您不想更新的 MCP。
执行集群更新。更新过程更新没有暂停的 MCP，包括 control plane 节点。
在更新的节点上测试应用程序，以确保它们按预期工作。
取消暂停剩余的 MCP，等待池中的节点完成更新，并在这些节点上测试应用程序。重复此过程，直到所有 worker 节点都已更新。
可选：从更新的节点中删除自定义标签并删除自定义 MCP。

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

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

流程

运行以下命令列出集群中的 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

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

$ 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

创建新的 MCP：

创建 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: 指定添加到此池中的自定义标签。

运行以下命令来创建 MachineConfigPool 对象：

$ oc create -f <file_name>

输出示例

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

运行以下命令，查看集群中的 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. 管理 worker 池 Canary 的机器配置继承

您可以配置机器配置池(MCP) Canary，以继承分配给现有 MCP 的任何 MachineConfig。当您要使用 MCP Canary 来测试现有 MCP 时，此配置很有用。

先决条件

您已创建了一个或多个 MCP。

流程

按照以下两个步骤所述，创建一个二级 MCP：

将以下配置文件保存为 machineConfigPool.yaml。

Example machineConfigPool YAML

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: worker-perf
spec:
  machineConfigSelector:
    matchExpressions:
      - {
         key: machineconfiguration.openshift.io/role,
         operator: In,
         values: [worker,worker-perf]
        }
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/worker-perf: ""
# ...

运行以下命令来创建新机器配置池：

$ oc create -f machineConfigPool.yaml

输出示例

machineconfigpool.machineconfiguration.openshift.io/worker-perf created

将一些机器添加到二级 MCP。以下示例将 worker 节点 worker-a、worker-b 和 worker-c 标记为 MCP worker-perf ：

$ oc label node worker-a node-role.kubernetes.io/worker-perf=''

$ oc label node worker-b node-role.kubernetes.io/worker-perf=''

$ oc label node worker-c node-role.kubernetes.io/worker-perf=''

为 MCP worker-perf 创建新的 MachineConfig，如以下两个步骤所述：

将以下 MachineConfig 示例保存为名为 new-machineconfig.yaml 的文件：

MachineConfig YAML 示例

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker-perf
  name: 06-kdump-enable-worker-perf
spec:
  config:
    ignition:
      version: 3.2.0
    systemd:
      units:
      - enabled: true
        name: kdump.service
  kernelArguments:
    - crashkernel=512M
# ...

运行以下命令来应用 MachineConfig ：
```
$ oc create -f new-machineconfig.yaml
```

创建新的 Canary MCP，并从您在上一步中创建的 MCP 添加机器。以下示例创建一个名为 worker-perf-canary 的 MCP，并添加您预先创建 worker-perf MCP 中的机器。

运行以下命令，标记 canary worker 节点 worker-a ：

$ oc label node worker-a node-role.kubernetes.io/worker-perf-canary=''

运行以下命令，从原始 MCP 中删除 Canary worker 节点 worker-a ：
```
$ oc label node worker-a node-role.kubernetes.io/worker-perf-
```

将以下文件保存为 machineConfigPool-Canary.yaml。

machineConfigPool-Canary.yaml 文件示例

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: worker-perf-canary
spec:
  machineConfigSelector:
    matchExpressions:
      - {
         key: machineconfiguration.openshift.io/role,
         operator: In,
         values: [worker,worker-perf,worker-perf-canary] 1
        }
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/worker-perf-canary: ""

1: 可选值。这个示例包括 worker-perf-canary 作为额外值。您可以使用此方法配置额外 MachineConfig 成员的值。

运行以下命令，创建新的 worker-perf-canary ：

$ oc create -f machineConfigPool-Canary.yaml

输出示例

machineconfigpool.machineconfiguration.openshift.io/worker-perf-canary created

检查 MachineConfig 是否继承在 worker-perf-canary 中。

运行以下命令验证没有 MCP 降级：

$ oc get mcp

输出示例

NAME                  CONFIG                                                          UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master                rendered-master-2bf1379b39e22bae858ea1a3ff54b2ac                True      False      False      3              3                   3                     0                      5d16h
worker                rendered-worker-b9576d51e030413cfab12eb5b9841f34                True      False      False      0              0                   0                     0                      5d16h
worker-perf          rendered-worker-perf-b98a1f62485fa702c4329d17d9364f6a          True      False      False      2              2                   2                     0                      56m
worker-perf-canary   rendered-worker-perf-canary-b98a1f62485fa702c4329d17d9364f6a   True      False      False      1              1                   1                     0                      44m

验证机器是否从 worker-perf 继承到 worker-perf-canary。

$ oc get nodes

输出示例

NAME       STATUS   ROLES                        AGE     VERSION
...
worker-a   Ready    worker,worker-perf-canary   5d15h   v1.27.13+e709aa5
worker-b   Ready    worker,worker-perf          5d15h   v1.27.13+e709aa5
worker-c   Ready    worker,worker-perf          5d15h   v1.27.13+e709aa5

运行以下命令，验证 worker-a 上是否启用了 kdump 服务：

$ systemctl status kdump.service

输出示例

NAME       STATUS   ROLES                        AGE     VERSION
...
kdump.service - Crash recovery kernel arming
     Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; preset: disabled)
     Active: active (exited) since Tue 2024-09-03 12:44:43 UTC; 10s ago
    Process: 4151139 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS)
   Main PID: 4151139 (code=exited, status=0/SUCCESS)

运行以下命令验证 MCP 是否已更新了 crashkernel ：
```
$ cat /proc/cmdline
```
输出应包含更新的 crashekernel 值，例如：
输出示例
```
crashkernel=512M
```

可选：如果对升级满意，您可以将 worker-a 返回到 worker-perf。
1. 运行以下命令，将 worker-a 返回到 worker-perf ：
```
$ oc label node worker-a node-role.kubernetes.io/worker-perf=''
```
2. 运行以下命令，从 canary MCP 中删除 worker-a ：
```
$ oc label node worker-a node-role.kubernetes.io/worker-perf-canary-
```

3.4.6. 暂停机器配置池

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

流程

运行以下命令修补您要暂停的 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.7. 执行集群更新

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

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

3.4.8. 取消暂停机器配置池

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

流程

对您要取消暂停的 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

可选：使用以下选项之一检查更新的进度：
1. 点 Administration Cluster settings 从 web 控制台检查进度。
2. 运行以下命令检查进度：
```
$ oc get machineconfigpools
```
在更新的节点上测试您的应用，以确保它们按预期工作。
一次对任何其他暂停的 MCP 重复此过程。

注意

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

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

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

重要

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

流程

对于自定义 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 配置协调。

要确保节点已从自定义 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。

可选：运行以下命令来删除自定义 MCP：
```
$ oc delete mcp <mcp_name>
```

3.4. 执行 canary rollout 更新

3.4.1. 金丝雀更新策略示例

定义自定义机器配置池

更新 Canary worker 池

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

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

使用自定义机器配置池

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

3.4.3. 关于执行 canary rollout 更新

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

3.4.5. 管理 worker 池 Canary 的机器配置继承

3.4.6. 暂停机器配置池

3.4.7. 执行集群更新

3.4.8. 取消暂停机器配置池

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

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Red Hat legal and privacy links

Red Hat legal and privacy links