使用 IBM Cloud CLI 检查版本更新是否可用

1. 登录到 IBM Cloud。 如果有联合账户，请将 --sso 选项包括在内。

   ibmcloud login [--sso]
   

2. 列出帐户中的 Satellite 集群。

   ibmcloud ks cluster ls --provider satellite
   

3. 列出要为其更新版本的集群中的工作程序节点。 在输出中，检查带有指示版本更新可用的消息的星号 *。

   ibmcloud ks worker ls -c <cluster_name_or_ID>
   

   示例输出

   ID                Primary IP       Flavor   State    Status   Zone     Version   
   sat-worker-<ID>   <IP_address>     upi      normal   Ready    zone-1   4.5.35_1534_openshift*   
   
   * To update to 4.5.37_1537_openshift version, run 'ibmcloud ks worker replace'. Review and make any required version changes before you update: 'https://ibm.biz/upworker'
   

从 IBM Cloud 控制台检查版本更新是否可用

1. 登录到 Satellite 控制台。
2. 单击要更新的主机所在的位置。
3. 单击主机选项卡。
4. 从主机列表中，单击要更新的主机的 集群 链接。 将打开 Red Hat OpenShift on IBM Cloud 集群详细信息的新选项卡。
5. 单击“工作节点”选项卡。
6. 在 “版本”栏中，检查是否有一个信息图标，点击该图标时会显示 Update available。 如果没有可用的更新，那么不存在任何图标。
7. 确定版本更新是主要更新，次要更新还是补丁更新。

一次向工作程序节点主机应用一个版本更新

1. 可选: 连接 和 分配 额外主机到服务集群，以在现有主机正在更新时处理计算容量。

2. 识别工作程序节点主机。 工作程序节点主机未在输出的 Cluster 列中列出 infrastructure，而是具有集群的名称。

3. 通过运行 ibmcloud ks worker update 命令来单独更新工作程序节点。

   ibmcloud ks worker update -c CLUSTER_NAME_OR_ID --worker WORKER_ID
   

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

   kubectl get nodes
   

   如果更新失败，那么必须 通过替换主机来应用版本更新。

使用 ConfigMap 将版本更新应用于工作程序节点主机

您可以使用 ConfigMap将更新推广到所有工作程序节点主机。 使用标签指定要更新的节点。 您还可以指定

1. 可选: 连接 和 分配 额外主机到服务集群，以在现有主机正在更新时处理计算容量。

2. 识别工作程序节点主机。 工作程序节点主机未列示为 Infrastructure。

3. 查看工作程序节点的标签。 可以在 CLI 输出的 Labels 部分找到工作程序节点标签。 每个标签都由 NodeSelectorKey 和 NodeSelectorValue 组成。 您可以使用这些标签来指定要更新的工作程序节点。

   kubectl get nodes -o yaml
   

   示例输出

   labels:
     arch: amd64
     beta.kubernetes.io/arch: amd64
     beta.kubernetes.io/instance-type: upi
     beta.kubernetes.io/os: linux
     failure-domain.beta.kubernetes.io/region: us-east
     failure-domain.beta.kubernetes.io/zone: us-east-2
     ibm-cloud.kubernetes.io/iaas-provider: upi
     ibm-cloud.kubernetes.io/internal-ip: 10.241.0.4
     ibm-cloud.kubernetes.io/machine-type: upi
     ibm-cloud.kubernetes.io/os: REDHAT_7_64
     ibm-cloud.kubernetes.io/region: us-east
     ibm-cloud.kubernetes.io/worker-id: sat-satellitei-5bd83963cdfedc7668c9040879c88113a134c4e7
     ibm-cloud.kubernetes.io/worker-pool-id: cbtljodw089nltg8k210-9a3f763
     ibm-cloud.kubernetes.io/worker-pool-name: default
     ibm-cloud.kubernetes.io/worker-version: 4.7.59_1583_openshift
     ibm-cloud.kubernetes.io/zone: us-east-2
     kubernetes.io/arch: amd64
     kubernetes.io/hostname: satellite-ibm-host-3
     kubernetes.io/os: linux
     node-role.kubernetes.io/master: ""
     node-role.kubernetes.io/worker: ""
     node.kubernetes.io/instance-type: upi
     node.openshift.io/os_id: rhel
     privateVLAN: "1"
     topology.kubernetes.io/region: us-east
     topology.kubernetes.io/zone: us-east-2
   

4. 创建 ConfigMap 并为工作节点定义不可用规则。 下面的示例显示了两个检查、defaultcheck.json 和一个检查模板。 您可以使用此示例检查来定义与 ConfigMap (defaultcheck.json) 中定义的任何检查都不匹配的所有工作程序节点的规则。使用检查模板来创建您自己的检查。 对于每个检查，要识别工作程序节点，必须选择在上一步中检索到的其中一个工作程序节点标签。

   对于每个检查，只能为 NodeSelectorKey 和 NodeSelectorValue 设置一个值。 在 ConfigMap 中最多定义 10 个检查。 如果添加更多检查，将忽略这些检查。

   示例

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: ibm-cluster-update-configuration
     namespace: kube-system
   data:
     drain_timeout_seconds: "120"
     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。

   defaultcheck.json

   在更新 Satellite 主机中的工作程序节点时，一次只能有 20% 的集群中的工作程序节点不可用。

   MaxUnavailablePercentage

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

   NodeSelectorKey

   要为其设置规则的工作程序节点的标签键。 可以为 IBM 提供的缺省标签以及您创建的工作程序节点标签设置规则。

   NodeSelectorValue

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

5. 在群集中创建 ConfigMap。

   kubectl apply -f <filepath/configmap.yaml>
   

6. 验证是否已创建 ConfigMap。

   kubectl get configmap --namespace kube-system
   

7. 通过按标识列出工作程序节点来更新这些节点。

   ibmcloud ks worker update --cluster <cluster_name_or_ID> --worker <worker_node1_ID> --worker <worker_node2_ID>
   

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

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

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

   kubectl get nodes
   

   如果更新失败，那么必须 通过替换主机来应用版本更新。

10. 确认没有重复的工作节点。 有时，旧版集群可能会在更新后列出重复的工作节点，其状态为 NotReady 状态的重复工作节点。 要除去重复项，请参阅故障诊断。