更新集群、工作程序节点和集群组件

更新集群主节点的步骤

开始之前，请确保您拥有 “操作员”或 “管理员”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 客户端版本。

主节点更新完成后，可以更新工作程序节点，具体取决于您拥有的集群基础架构提供者的类型。

• 更新经典工作节点。
• 正在更新 VPC 工作节点。

先决条件

在更新经典基础架构工作程序节点之前，请查看必备步骤。

更新工作程序节点可能会导致应用程序和服务产生停机时间。 系统会对工作程序节点机器重新应用映像，并且如果数据未存储在 pod 外部，那么将删除数据。

• 对于最新的安全补丁和修订，请确保在工作程序节点可用后尽快将其更新为最新的补丁。 有关最新更新的更多信息，请查看 Red Hat OpenShift on IBM Cloud 版本信息。
• 访问 Red Hat OpenShift 集群。
• 更新主节点。 工作节点的版本不能高于您 Kubernetes 主节点上运行的API服务器版本。
• 在 Red Hat OpenShift 版本准备指南 中进行任何标记为 在主服务器之后更新 的更改。
• 如果要应用补丁更新，请查看 Red Hat OpenShift on IBM Cloud 版本信息。
• 建议增加更多工作节点，以确保您的集群在更新期间拥有足够的能力来重新调度工作负载。 有关更多信息，请参阅 将工作程序节点添加到经典集群 或 将工作程序节点添加到 VPC 集群。
• 请确保您拥有 “操作员”或 “管理员”IAM 平台访问角色。

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

设置配置映射以执行经典工作程序节点的滚动更新。

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. 创建配置映射，并定义工作程序节点的不可用性规则。 以下示例显示了四个检查：zonecheck.json、regioncheck.json、defaultcheck.json 和检查模板。 您可以使用这些示例检查来为特定区域（zonecheck.json ）、区域（regioncheck.json ）中的工作节点定义规则，或者为所有不符合您在配置映射（defaultcheck.json ）中定义的任何检查条件的工作节点定义规则。请使用检查模板来创建您自己的检查。 对于每个检查，要识别工作程序节点，必须选择在上一步中检索到的其中一个工作程序节点标签。

   对于每个检查项，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 nodes）的区域标签来识别它们，而 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 状态。 要除去重复项，请参阅故障诊断。

后续步骤：

• 对其他工作程序池重复更新过程。
• 通知在集群中工作的开发者将其 oc CLI 更新到 Kubernetes 主节点的版本。
• 如果 Kubernetes 仪表板未显示利用率图形，请删除 kube-dashboard pod。

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

首次设置配置映射后，接着就可以使用 IBM Cloud 控制台来更新工作程序节点。

要通过控制台更新工作程序节点，请执行以下操作：

1. 完成必备步骤和设置配置映射，以控制工作程序节点的更新方式。
2. 从 IBM Cloud 控制台 菜单，单击容器 > 集群。
3. 在集群页面中，单击您的集群。
4. 在 “工作节点”选项卡中，勾选要更新的每个工作节点的复选框。 在表标题行的上方显示有操作栏。
5. 在操作栏中，单击更新。

如果在集群中安装了 Portworx，那么必须在更新后的工作程序节点上重新启动 Portworx pod。 有关更多信息，请参阅 Portworx 限制。

先决条件

在更新 VPC 基础架构工作程序节点之前，请查看必备步骤。

更新工作程序节点可能会导致应用程序和服务产生停机时间。 系统会除去工作程序节点机器，并且如果数据未存储在 pod 外部，那么将删除数据。

• 对于最新的安全补丁和修订，请确保在工作程序节点可用后尽快将其更新为最新的补丁。 有关最新更新的更多信息，请查看 Red Hat OpenShift on IBM Cloud 版本信息。
• 访问 Red Hat OpenShift 集群。
• 更新主节点。 工作节点的版本不能高于您 Kubernetes 主节点上运行的API服务器版本。
• 在 Red Hat OpenShift 版本准备指南 中进行任何标记为 在主服务器之后更新 的更改。
• 如果要应用补丁更新，请查看 Red Hat OpenShift on IBM Cloud 版本信息。
• 请确保您拥有 “操作员”或 “管理员”IAM 平台访问角色。

管理 Fluentd 的自动更新

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

您可以通过以下方式来管理 Fluentd 组件的自动更新。 注意：要运行以下命令，您必须拥有该集群的 “管理员 IBM Cloud”IAM平台访问角色。

• 运行 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 生命周期。