执行金丝雀发布更新 - 执行集群更新 | 更新集群 | OpenShift Container Platform 4.17

示例 Canary 更新策略
关于 Canary 滚动更新流程和 MCP
关于执行 Canary 滚动更新
创建机器配置池以执行 Canary 滚动更新
管理工作池金丝雀的机器配置继承
暂停机器配置池
执行集群更新
取消暂停机器配置池
将节点移动到原始机器配置池

Canary 更新是一种更新策略，其中工作节点更新以离散的、顺序的阶段执行，而不是同时更新所有工作节点。此策略在以下情况下很有用：

您希望更可控地推出工作节点更新，以确保关键任务应用程序在整个更新过程中保持可用，即使更新过程导致应用程序失败。
您希望更新一小部分工作节点，在一段时间内评估集群和工作负载的健康状况，然后更新其余节点。
您希望将工作节点更新（通常需要主机重新引导）适应较小的已定义维护窗口，当无法使用较大的维护窗口一次更新整个集群时。

在这些情况下，您可以创建多个自定义机器配置池 (MCP) 以防止在更新集群时更新某些工作节点。在更新其余集群后，您可以适时分批更新这些工作节点。

示例 Canary 更新策略

以下示例描述了一种 Canary 更新策略，其中您有一个具有 100 个节点且冗余容量为 10% 的集群，您的维护窗口不得超过 4 小时，并且您知道排空和重新引导工作节点不超过 8 分钟。

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

定义自定义机器配置池

为了将工作节点更新组织到单独的阶段，您可以从定义以下 MCP 开始：

具有 10 个节点的workerpool-canary
具有 30 个节点的workerpool-A
具有 30 个节点的workerpool-B
具有 30 个节点的workerpool-C

更新 Canary 工作池

在您的第一个维护窗口期间，您暂停workerpool-A、workerpool-B 和workerpool-C 的 MCP，然后启动集群更新。这将更新在 OpenShift Container Platform 之上运行的组件以及属于未暂停的workerpool-canary MCP 的 10 个节点。其他三个 MCP 未更新，因为它们已暂停。

确定是否继续进行其余工作池更新

如果由于某种原因您确定集群或工作负载的健康状况受到workerpool-canary 更新的负面影响，那么您需要隔离并排空该池中的所有节点，同时仍然保持足够的容量，直到您诊断并解决问题为止。当一切按预期工作时，您在决定取消暂停并因此更新workerpool-A、workerpool-B 和workerpool-C 之前，会评估集群和工作负载的健康状况，并在每个额外的维护窗口中依次进行更新。

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

暂停机器配置池可防止机器配置操作员对相关节点应用任何配置更改。暂停 MCP 还可防止任何自动旋转的证书被推送到相关节点，包括kube-apiserver-to-kubelet-signer CA 证书的自动 CA 旋转。

如果在kube-apiserver-to-kubelet-signer CA 证书过期且 MCO 尝试自动续订证书时暂停 MCP，则 MCO 无法将新旋转的证书推送到这些节点。这会导致多个oc命令失败，包括oc debug、oc logs、oc exec 和oc attach。如果在旋转证书时暂停 MCP，您会在 OpenShift Container Platform Web 控制台的警报 UI 中收到警报。

暂停 MCP 应谨慎考虑kube-apiserver-to-kubelet-signer CA 证书过期时间，并且暂停时间应尽可能短。

不建议将 MCP 更新到不同的 OpenShift Container Platform 版本。例如，不要将一个 MCP 从 4.y.10 更新到 4.y.11，另一个更新到 4.y.12。此场景未经测试，可能会导致集群状态未定义。

关于金丝雀发布更新流程和 MCP

在 OpenShift Container Platform 中，节点不被单独考虑。相反，它们被分组到机器配置池 (MCP) 中。默认情况下，OpenShift Container Platform 集群中的节点被分组到两个 MCP 中：一个用于控制平面节点，另一个用于工作节点。OpenShift Container Platform 更新会同时影响所有 MCP。

在更新期间，机器配置操作符 (MCO) 会最多将 MCP 中的所有节点 drain 和 cordon 到指定的maxUnavailable 节点数，如果指定了最大数量。默认情况下，maxUnavailable 设置为1。drain 和 cordon 节点会取消调度节点上的所有 Pod 并将节点标记为不可调度。

节点 drain 后，机器配置守护程序会应用新的机器配置，其中可能包括更新操作系统 (OS)。更新操作系统需要主机重新启动。

使用自定义机器配置池

要阻止更新特定节点，您可以创建自定义 MCP。由于 MCO 不会更新已暂停的 MCP 中的节点，因此您可以在启动集群更新之前暂停包含不需要更新的节点的 MCP。

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

OpenShift Container Platform 中所有机器配置池的maxUnavailable 默认设置为1。建议不要更改此值，并一次更新一个控制平面节点。不要将控制平面池的此值更改为3。

为确保控制平面的稳定性，不支持从控制平面节点创建自定义 MCP。机器配置操作符 (MCO) 会忽略为控制平面节点创建的任何自定义 MCP。

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

根据您的工作负载部署拓扑，仔细考虑要创建的 MCP 数量以及每个 MCP 中的节点数量。例如，如果您必须将更新安排在特定的维护窗口内，则必须知道 OpenShift Container Platform 在给定窗口内可以更新多少个节点。此数字取决于您独特的集群和工作负载特性。

您还必须考虑集群中可用的额外容量，以确定自定义 MCP 的数量以及每个 MCP 中的节点数量。如果您的应用程序在新更新的节点上无法按预期工作，您可以 cordon 和 drain 该池中的节点，这会将应用程序 Pod 移动到其他节点。但是，您必须确定剩余 MCP 中的可用节点是否可以为您的应用程序提供足够的 QoS。

您可以将此更新流程与所有已记录的 OpenShift Container Platform 更新流程一起使用。但是，此流程不适用于使用 Ansible playbook 更新的 Red Hat Enterprise Linux (RHEL) 机器。

关于执行金丝雀发布更新

以下步骤概述了金丝雀发布更新流程的高级工作流程

基于工作程序池创建自定义机器配置池 (MCP)。

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

向自定义 MCP 添加节点选择器。对于您不想与集群其余部分同时更新的每个节点，请向节点添加匹配的标签。此标签将节点与 MCP 关联。

不要从节点中删除默认的工作程序标签。节点必须具有角色标签才能在集群中正常运行。
暂停您不想作为更新过程一部分进行更新的 MCP。
执行集群更新。更新过程会更新未暂停的 MCP，包括控制平面节点。
测试更新后的节点上的应用程序，以确保它们按预期工作。
取消暂停剩余的 MCP 之一，等待该池中的节点完成更新，然后测试这些节点上的应用程序。重复此过程，直到所有工作节点都更新完毕。
可选：从更新的节点中删除自定义标签并删除自定义 MCP。

创建机器配置池以执行金丝雀发布更新

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

步骤

通过运行以下命令列出集群中的工作节点

$ 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 已创建，您向其添加了自定义标签的节点数量显示在机器计数中。工作程序 MCP 机器计数减少了相同的数量。更新机器计数可能需要几分钟时间。在此示例中，一个节点从worker MCP 移动到workerpool-canary MCP。

管理工作程序池金丝雀的机器配置继承

您可以配置机器配置池 (MCP) 金丝雀以继承分配给现有 MCP 的任何MachineConfig。当您想要使用 MCP 金丝雀在一次更新现有 MCP 的节点时进行测试时，此配置非常有用。

先决条件

您已创建一个或多个 MCP。

步骤

按照以下两个步骤创建辅助 MCP

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

示例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-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
```

创建新的金丝雀 MCP 并添加来自您在前面步骤中创建的 MCP 的机器。以下示例创建了一个名为worker-perf-canary的 MCP，并添加了您先前创建的worker-perf MCP 中的机器。

运行以下命令为金丝雀工作节点worker-a添加标签

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

运行以下命令从原始 MCP 中移除金丝雀工作节点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

运行以下命令验证kdump服务是否在worker-a上启用。

$ 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. 运行以下命令从金丝雀 MCP 中移除worker-a
  $ oc label node worker-a node-role.kubernetes.io/worker-perf-canary-

暂停机器配置池

创建自定义机器配置池 (MCP) 后，暂停这些 MCP。暂停 MCP 可防止机器配置操作符 (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

执行集群更新

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

集群更新完成后，您可以开始一次暂停一个 MCP。

取消暂停机器配置池

OpenShift Container Platform 更新完成后，一次取消暂停一个自定义机器配置池 (MCP)。取消暂停 MCP 允许机器配置操作符 (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. 通过单击**管理** → **集群设置**来从 Web 控制台检查进度。
2. 运行以下命令检查进度
  $ oc get machineconfigpools
在更新的节点上测试您的应用程序，以确保它们按预期工作。
对任何其他已暂停的 MCP 重复此过程，一次一个。

如果发生故障（例如，您的应用程序在更新的节点上无法工作），您可以隔离并排出池中的节点，这会将应用程序 Pod 移动到其他节点，以帮助维护应用程序的服务质量。第一个 MCP 不应大于冗余容量。

将节点移动到原始机器配置池

在更新并验证自定义机器配置池 (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

机器配置操作符将节点移回原始 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>
```