更新集群主节点的步骤

开始之前，请确保您拥有 “操作员”或 “管理员”IAM平台访问角色。 如果您不确定自己的访问角色，请在 IBM Cloud 控制台中转至 “管理”→“访问（IAM）”→“用户”， 或咨询您的账户管理员。

如果证书颁发机构（CA）的证书轮换正在进行中，则主更新将被阻止，直到轮换完成为止。 开始之前，请先检查任何正在进行的轮换状态。

要更新 Red Hat OpenShift 的_主版本号_或_次_版本号：

1. 查看 Red Hat OpenShift on IBM Cloud 版本信息，并将任何更新标记为 在主节点之前更新。

2. 查看任何 Kubernetes 有用的警告，例如废弃声明。

3. 请检查集群中安装的附加组件和插件，以了解更新集群版本可能造成的任何影响。

   • 正在检查附加组件

     1. 列出集群中的附加组件。

        ibmcloud oc cluster addon ls --cluster CLUSTER
        

     2. 检查所安装的每个附加组件的受支持 Red Hat OpenShift 版本。

        ibmcloud oc addon-versions
        

     3. 如果必须更新附加组件以在要将集群更新到的 Red Hat OpenShift 版本中运行，请 更新附加组件。

   • 检查插件

     1. 在 Helm 目录中，找到已安装在集群中的插件。
     2. 从侧边菜单中，展开 源和 TAR 文件 部分。
     3. 下载并打开源代码。
     4. 请检查 README.md 或 RELEASENOTES.md 文件以获取受支持的版本。
     5. 如果必须更新插件才能在要更新集群的 Red Hat OpenShift 版本中运行，请遵循插件指示信息来更新插件。

4. 使用 IBM Cloud 控制台或运行 CLI ibmcloud oc cluster master update 命令来更新 API 服务器和关联的主节点组件。

5. 稍等几分钟，然后确认更新是否已完成。 在 IBM Cloud 集群仪表板上查看 API 服务器版本，或运行 ibmcloud oc cluster ls。

6. 安装与主节点中运行的 API 服务器版本相匹配的 oc cli 版本。 Kubernetes 不支持与服务器版本相差两个或更多版本（n ± 2）的 oc 客户端版本。 要刷新本地配置，请运行 ibmcloud oc cluster config -c CLUSTER_NAME_OR_ID，然后通过 oc version --client 进行验证。

主节点更新完成后，请更新您的工作节点。 具体方法取决于您的基础设施类型：

1. 更新经典工作节点 ——使用由 ConfigMap 和 worker update 命令控制的滚动更新。
2. 更新 VPC 工作节点 — VPC 裸机工作节点可通过 worker reload 进行就地更新；VPC VSI 工作节点必须使用 worker replace --update。 ConfigMap 的滚动更新流程目前尚不支持VPC工作节点。

先决条件

在更新经典基础设施的工作节点之前，请先完成以下先决条件步骤。

在工作节点更新过程中，工作节点机器将重新安装操作系统镜像，所有未 存储在持久化存储中的 数据都将被永久删除。 在开始之前，请确认所有需要保留的数据都已存储在工作节点之外。

如果您的集群中安装了 Portworx，则必须执行 在更新工作节点之前，请先更新您的 Portworx 配置。

在 CLI 中使用配置映射更新经典工作程序节点

使用 ConfigMap 对经典工作节点进行滚动更新。 通过 ConfigMap，您可以控制每个区域或区域内同时不可用的节点数量。 如果默认的 20% 不可用性规则对您的集群来说可以接受，则可以跳过步骤 3 和 4（创建 ConfigMap ），直接进入步骤 5，使用默认行为应用更新。

1. 完成必备步骤。

2. 列出可用的工作程序节点，并记录其专用 IP 地址。

   ibmcloud oc worker ls --cluster CLUSTER
   

3. 查看工作程序节点的标签。 可以在 CLI 输出的 Labels 部分找到工作程序节点标签。 每个标签都由 NodeSelectorKey 和 NodeSelectorValue 组成。

   oc describe node PRIVATE-WORKER-IP
   

   示例输出

   NAME:               10.184.58.3
   Roles:              <none>
   Labels:             arch=amd64
                   beta.kubernetes.io/arch=amd64
                   beta.kubernetes.io/os=linux
                   failure-domain.beta.kubernetes.io/region=us-south
                   failure-domain.beta.kubernetes.io/zone=dal12
                   ibm-cloud.kubernetes.io/encrypted-docker-data=true
                   ibm-cloud.kubernetes.io/iaas-provider=softlayer
                   ibm-cloud.kubernetes.io/machine-type=u3c.2x4.encrypted
                   kubernetes.io/hostname=10.123.45.3
                   privateVLAN=2299001
                   publicVLAN=2299012
   Annotations:        node.alpha.kubernetes.io/ttl=0
                   volumes.kubernetes.io/controller-managed-attach-detach=true
   CreationTimestamp:  Tue, 03 Apr 2022 15:26:17 -0400
   Taints:             <none>
   Unschedulable:      false
   

4. 创建配置映射，并定义工作程序节点的不可用性规则。 ConfigMap 最多支持 15 个命名检查。 每次检查都会根据标签锁定一组工作节点，并设定这些节点中同时不可用的最大比例。 以下示例展示了区域检查（zonecheck.json ）、区域检查（regioncheck.json ）、默认回退检查（defaultcheck.json ）以及自定义检查的模板。 对于每次检查，请从上一步中检索到的 worker 节点标签中选择一个，以标识目标节点。

   对于每个检查项，NodeSelectorKey 和 NodeSelectorValue 只能设置一个值。 如果要为多个区域、专区或其他工作程序节点标签设置规则，请创建新的检查。 在配置映射中最多可定义 15 个检查项。 如果添加更多检查，那么一次仅会重新装入 1 工作程序节点，直到更新所有请求的工作程序为止。

   示例

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: ibm-cluster-update-configuration
     namespace: kube-system
   data:
     drain_timeout_seconds: "120"
     zonecheck.json: |
       {
         "MaxUnavailablePercentage": 30,
         "NodeSelectorKey": "failure-domain.beta.kubernetes.io/zone",
         "NodeSelectorValue": "dal13"
       }
     regioncheck.json: |
       {
         "MaxUnavailablePercentage": 20,
         "NodeSelectorKey": "failure-domain.beta.kubernetes.io/region",
         "NodeSelectorValue": "us-south"
       }
     defaultcheck.json: |
       {
         "MaxUnavailablePercentage": 20
       }
     <check_name>: |
       {
         "MaxUnavailablePercentage": <value_in_percentage>,
         "NodeSelectorKey": "<node_selector_key>",
         "NodeSelectorValue": "<node_selector_value>"
       }
   

   drain_timeout_seconds

   可选：等待 排水完成的超时时间（以秒为单位）。 排空工作程序节点可安全地从工作程序节点中除去所有现有 pod，然后将这些 pod 重新安排到集群中的其他工作程序节点上。 接受的值为范围在 1 到 180 之间的整数。 缺省值为 30。

   zonecheck.json 和 regioncheck.json

   两个复选框，用于为一组工作节点定义规则，您可以通过指定的 NodeSelectorKey 和 NodeSelectorValue 来识别这些节点。 zonecheck.json 根据工作节点（worker node）的区域标签来识别这些节点，而 regioncheck.json 则使用在配置过程中添加到每个工作节点上的区域标签。 在此示例中，在更新期间，所有区域标签为 dal13 的工作节点中有30%，以及所有位于 us-south 的工作节点中有20%可能不可用。

   defaultcheck.json

   如果您未创建配置映射，或者映射配置有误，则将应用 Kubernetes 的默认设置。 缺省情况下，集群中只能有 20% 的工作程序节点同时不可用。 您可以通过向配置映射添加缺省检查来覆盖缺省值。 在此示例中，凡是在区域和区域检查（dal13 或 us-south ）中未被指定的每个工作节点，在更新期间都可能处于不可用状态。

   MaxUnavailablePercentage

   对于指定的标签键和值，允许不可用的最大节点数，指定为百分比。 工作程序节点在部署、重新装入或供应过程中会不可用。 如果排队的工作程序节点超过任何定义的最大不可用百分比，那么会阻止这些节点更新。

   NodeSelectorKey

   要为其设置规则的工作程序节点的标签键。 可以为 IBM 提供的缺省标签以及您创建的工作程序节点标签设置规则。 如果您想为属于某个工作节点池的工作节点添加一条规则，可以使用 ibm-cloud.kubernetes.io/machine-type 标签。

   NodeSelectorValue

   必须为定义的规则考虑工作程序节点的标签值。

5. 在集群中创建配置映射。

   oc apply -f <filepath/configmap.yaml>
   

6. 验证配置映射是否已创建。

   oc get configmap --namespace kube-system
   

7. 更新工作程序节点。

   ibmcloud oc worker update --cluster CLUSTER --worker WORKER-NODE-1-ID --worker WORKER-NODE-2-ID
   

8. 可选：验证由配置映射触发的事件以及发生的任何验证错误。 可以在 CLI 输出的 Events 部分中查看这些事件。

   oc describe -n kube-system cm ibm-cluster-update-configuration
   

9. 通过复查工作程序节点的 Kubernetes 版本，确认更新是否已完成。

   oc get nodes
   

10. 请确认没有重复的工作节点。 有时，较旧的集群会列出具有重复 NotReady 状态。 要除去重复项，请参阅故障诊断。

在控制台中更新经典工作程序节点

首次配置 ConfigMap 后，您可以通过 IBM Cloud 控制台更新工作节点。 该控制台会遵守您在《 ConfigMap 》中定义的不可用规则。

1. 完成 先决条件步骤，并 配置一个 ConfigMap 来控制工作节点的更新方式。
2. 从 IBM Cloud 控制台 菜单，单击容器 > 集群。
3. 在集群页面中，单击您的集群。
4. 在 “工作节点”选项卡中，选中要更新的每个工作节点的复选框。 在表标题行的上方显示有操作栏。
5. 在操作栏中，单击更新。

如果您的集群中安装了 Portworx，则必须在已更新的工作节点上重启 Portworx Pod。 如需了解更多信息，请参阅《 Portworx 限制 》。

先决条件

在更新 VPC 基础设施的工作节点之前，请先完成以下先决条件步骤。

对于 VPC VSI 工作节点，该工作节点将被删除并替换为一个新节点。 对于 VPC 裸机工作人员而言，节点将在原地重新加载。 在这两种情况下，未 存储在持久化存储中的 数据都会被永久删除。 在开始之前，请确认所有需要保留的数据都已存储在工作节点之外。

如果您已在集群中部署了 Portworx，请按照以下步骤 将VPC工作节点更新为使用 Portworx 卷，而不是按照本页上的步骤操作。

VPC 裸机工作节点重新加载期间的固件更新

当您重新加载 VPC 裸机工作节点时，IBM Cloud 基础设施会自动检查该服务器是否有待处理的固件更新，并在重新加载过程中将其应用。 无需采取任何额外操作即可触发固件更新。

在重新加载 VPC 裸机工作节点时，请注意以下事项：

重新加载时间延长

如果在重新加载过程中进行了固件更新，总重新加载时间可能会比通常的重新加载时间显著增加——增加30分钟或更长时间。 请据此规划您的维护窗口。

无法提前查看待处理的更新

在执行 reload 命令之前，无法得知某个工作节点是否正在等待固件更新。

数据丢失风险

与所有 VPC 裸机工作节点的重装操作一样，无论是否应用固件更新，重装过程中本地磁盘上的数据都会被删除。 在重新加载之前，请备份所有未存储在持久化存储中的数据。

因固件更新导致的重新加载失败

在某些情况下，固件更新可能会失败，导致工作节点进入 reload_failed 状态（Failed to reload worker ），状态详情为 The infrastructure firmware update has failed. (P4056)。 如果出现这种情况：

1. 请等待几分钟，然后再次运行 ibmcloud oc worker reload --cluster CLUSTER --worker WORKER-NODE-ID 来重新加载。
2. 如果尝试2至3次后错误仍未解决，请提交 IBM Cloud 支持工单。

准备工作

• 访问 Red Hat OpenShift 集群。
• 请确认需要保留的任何数据都已存储在工作节点之外的 持久化存储 中。 仅存储在工作节点上的数据将丢失且无法恢复。
• 请确保您拥有 “操作员”或 “管理员”IAM 平台访问角色。 如果您不确定自己的访问角色，请在 IBM Cloud 控制台中转至 “管理”→“访问（IAM）”→“用户”， 或咨询您的账户管理员。

更新风味

1. 列出可用的工作程序节点，并记录其专用 IP 地址。

   1. 列出集群中的可用工作程序池。

       ibmcloud oc worker-pool ls --cluster CLUSTER
       ```
   2. 列出工作程序池中的工作程序节点。 记下 **ID** 和 **Private IP**。
   ```sh {: pre}
       ibmcloud oc worker ls --cluster CLUSTER --worker-pool WORKER-POOL
       ```
   3. 获取工作程序节点的详细信息。 在输出中，记下区域以及经典集群的专用和公用 VLAN 标识或 VPC 集群的子网标识。
   ```sh {: pre}
       ibmcloud oc worker get --cluster CLUSTER --worker WORKER-ID
       ```
   

2. 列出专区中可用的类型模板。

   ibmcloud oc flavors --zone <zone>
   

3. 创建具有新机器类型的工作程序节点。

   1. 创建工作程序池，其中的工作程序节点数与要替换的节点数相同。
      • 经典集群：

        ibmcloud oc worker-pool create classic --name WORKER-POOL --cluster CLUSTER --flavor FLAVOR --size-per-zone NUMBER-OF-WORKERS-PER-ZONE
        

      • VPC 生成 2 集群:

        ibmcloud oc worker-pool create vpc-gen2 --name NAME --cluster CLUSTER --flavor FLAVOR --size-per-zone NUMBER-OF-WORKERS-PER-ZONE --label LABEL
        

   2. 验证工作程序池是否已创建。

       ibmcloud oc worker-pool ls --cluster CLUSTER
       ```
   3. 将专区添加到先前检索到的工作程序池。 添加专区时，工作程序池中定义的工作程序节点将在专区中供应，并考虑用于未来的工作负载安排。 如果要跨多个专区分布工作程序节点，请选择 [经典](/docs/openshift?topic=openshift-regions-and-zones#zones-mz) 或 [VPC](/docs/openshift?topic=openshift-regions-and-zones#zones-vpc) 多专区位置。
       * 经典集群：
           ```sh {: pre}
           ibmcloud oc zone add classic --zone ZONE --cluster CLUSTER --worker-pool WORKER-POOL --private-vlan PRIVATE-VLAN-ID --public-vlan PUBLIC-VLAN-ID
           ```
       * VPC 集群：
           ```sh {: pre}
           ibmcloud oc zone add vpc-gen2 --zone ZONE --cluster CLUSTER --worker-pool WORKER-POOL --subnet-id VPC-SUBNET-ID
           ```
   

4. 等待工作程序节点进行部署。 工作程序节点的状态更改为 Normal 时，说明部署完成。

   ibmcloud oc worker ls --cluster CLUSTER
   

5. 删除旧的工作进程池。 如果您要取消“Classic”裸机版本（按月计费），即使在当月月中取消，仍需支付当月的全额费用。 VPC 实例（包括裸机实例）按小时计费。

   1. 除去具有旧机器类型的工作程序池。 除去工作程序池将除去所有专区中该池中的所有工作程序节点。 此过程可能需要几分钟才能完成。

       ibmcloud oc worker-pool rm --worker-pool WORKER-POOL --cluster CLUSTER
       ```
   2. 验证工作程序池是否已除去。
   ```sh {: pre}
       ibmcloud oc worker-pool ls --cluster CLUSTER
       ```
   

6. 验证工作程序节点是否已从集群中除去。

   ibmcloud oc worker ls --cluster CLUSTER
   

7. 重复这些步骤以将其他工作程序池或独立工作程序节点更新为不同的类型模板。

管理 Fluentd 的自动更新

当您为集群中的某个源创建日志记录配置以转发至外部服务器时，集群中将创建一个 Fluentd 组件。 若要更改日志记录或过滤器配置，Fluentd 组件必须为最新版本。 缺省情况下，会启用组件的自动更新。

要运行以下命令，您必须拥有该集群的 “管理员 IBM Cloud”IAM平台访问角色。

您可以通过以下方式来管理 Fluentd 组件的自动更新。

• 运行 ibmcloud oc logging autoupdate get --cluster CLUSTER 命令，检查自动更新是否已启用。
• 通过运行 ibmcloud oc logging autoupdate disable 命令来禁用自动更新。
• 如果禁用了自动更新，但您需要对配置进行更改，那么有两个选项：
  • 启用 Fluentd pod 的自动更新。

      ibmcloud oc logging autoupdate enable --cluster CLUSTER
      ```
  * 使用包含 `--force-update` 选项的日志记录命令时，强制执行一次性更新。 您的 Pod 已更新至 Fluentd 组件的最新版本，但此后 Fluentd 将不会自动更新。
          示例命令
  
  ```sh {: pre}
      ibmcloud oc logging config update --cluster CLUSTER --id LOG-CONFIG-ID --type LOG-TYPE --force-update
      ```
  

管理 Ingress ALB 的自动更新

控制何时更新 Ingress 应用程序负载均衡器 (ALB) 组件。 有关使 ALB 保持最新的信息，请参阅 管理 Ingress ALB 生命周期。