更新分配为工作程序节点的主机
查看以下步骤,为分配给启用 Satellite 服务(如群集)作为工作节点的主机获取最新的 OpenShift Container Platform、操作系统和安全补丁。
服务群集是所有 IBM Cloud 服务的底层平台,由 Code Engine 或 IBM Cloud Object Storage 等服务创建,并由 IBM 维护。
- 更新期间我的应用程序会发生什么情况?
- 如果在更新的工作程序节点上作为部署的一部分运行应用程序,那么会将应用程序重新安排到集群中的其他工作程序节点上。 这些工作程序节点可能位于其他工作程序池中,或者如果您具有独立工作程序节点,那么可能会将应用程序安排到独立工作程序节点上。 为避免应用程序发生中断,必须确保集群中有足够的容量来执行工作负载。
- 如何控制更新或重载过程中一次有多少个工作节点宕机?
- 如果需要所有工作程序节点都已启动并正在运行,请考虑 连接 并向服务 分配 其他主机。 您可以将其他主机临时添加到位置,然后在更新完成时将其移除。
- 此外,您还可以创建 Kubernetes ConfigMap,指定在同一时间(如更新期间)不可用的最大工作节点数。 工作程序节点通过工作程序节点标签进行标识。 可以使用 IBM 提供的标签,也可以使用已添加到工作程序节点的定制标签。
检查版本更新是否可用于工作程序节点主机
您可以使用 IBM Cloud CLI 或 IBM Cloud 控制台来检查版本更新是否可用于作为工作程序节点分配给 Satellite-enabled IBM Cloud 服务 的主机。
要查看每个版本更新中包含的更改,请参阅 Red Hat OpenShift on IBM Cloud。
使用 IBM Cloud CLI 检查版本更新是否可用
- 登录到 IBM Cloud。 如果有联合账户,请将
--sso
选项包括在内。ibmcloud login [--sso]
- 列出帐户中的 Satellite 集群。
ibmcloud ks cluster ls --provider satellite
- 列出要为其更新版本的集群中的工作程序节点。 在输出中,检查带有指示版本更新可用的消息的星号
*
。
示例输出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 控制台检查版本更新是否可用
- 登录到 Satellite 控制台。
- 单击要更新的主机所在的位置。
- 单击主机选项卡。
- 从主机列表中,单击要更新的主机的 集群 链接。 将打开 Red Hat OpenShift on IBM Cloud 集群详细信息的新选项卡。
- 单击“工作节点”选项卡。
- 在 “版本”栏中,检查是否有一个信息图标,点击该图标时会显示
Update available
。 如果没有可用的更新,那么不存在任何图标。 - 确定版本更新是主要更新,次要更新还是补丁更新。
标识工作程序节点主机
确定您的主机是控制平面的一部分,分配给受管服务还是连接到位置。
-
列出位置主机并记下其标识。 工作程序节点主机没有在输出的
Cluster
列中列出infrastructure
。ibmcloud sat host ls --location <location>
查看示例输出。
Name ID State Status Zone Cluster Worker ID Worker IP satdemo-cp1 0bc3b92f55968a230985 assigned Ready zone-1 infrastructure sat-satdemocp1-2bda578e901b4047c6e48d766cd99bc11a45fddd 169.62.42.178 satdemo-cp2 999cd38c39ddffe4b672 assigned Ready zone-2 infrastructure sat-satdemocp2-940134e69c2609c5421b2426a7640fa80569668d 169.62.42.183 satdemo-cp5 6ca4fd8fcad1fa622aa4 assigned Ready zone-3 infrastructure sat-satdemocp5-d46581b509357ea4b429fddc38a18b155463bf1c 169.62.42.181 satdemo-cp4 1ac2b92f55968a333335 assigned Ready zone-1 satdemo-cluster sat-satdemocp4-2bda578e901b4047c6e48d766cd99bc11a45fddd 169.62.42.180 satdemo-cp6 234cd56c78ddffe4b672 assigned Ready zone-2 satdemo-cluster sat-satdemocp6-940134e69c2609c5421b2426a7640fa80569668d 169.62.42.179 satdemo-cp3 8fg4ff8faaa1fa622bb5 assigned Ready zone-3 satdemo-cluster sat-satdemocp3-d46581b509357ea4b429fddc38a18b155463bf1c 169.62.42.182
-
列出分配为 Satellite-enabled IBM Cloud 服务的工作程序节点的当前主机,并记下其标识。
ibmcloud ks worker ls -c <cluster_name_or_ID>
查看示例输出。
ID Primary IP Flavor State Status Zone Version sat-satellitei-5bd83963cdfedc7668c9040879c88113a134c4e7 10.241.0.4 upi normal Ready us-east-2 4.7.55_1575_openshift sat-satellitei-854beae4556401b5761e34ed849ba64c4b0a674c 10.241.128.4 upi normal Ready us-east-1 4.7.55_1575_openshift sat-satellitei-bf1fc9b135011d5c0d9d500855db6e489d15610b 10.241.64.4 upi normal Ready us-east-3 4.7.55_1575_openshift
将版本更新应用于工作程序节点主机,而不将其拆离
您可以在不从位置拆离工作程序节点主机的情况下更新这些主机。 您还可以使用 ConfigMap对工作程序节点主机执行滚动更新。
准备工作
- 验证所有工作程序节点是否处于正常状态。
- 如果您正在使用持久块存储卷,那么必须先从节点拆离这些卷,然后再启动更新。 将持久卷移至不需要更新的其他工作程序节点。 然后,从工作程序节点中封锁并排出工作负载,以使用
kubectl drain NODENAME
命令进行更新。 如果无法移动块存储卷,请使用 通过替换主机将版本更新应用于工作程序节点。
向工作节点应用更新可能会导致应用程序和服务停机。 当更新过程正在运行时,请勿在主机上执行任何操作。 在更新过程中,最多可以有 20% 的所有工作程序节点不可用。
一次向工作程序节点主机应用一个版本更新
-
识别工作程序节点主机。 工作程序节点主机未在输出的
Cluster
列中列出infrastructure
,而是具有集群的名称。 -
通过运行
ibmcloud ks worker update
命令来单独更新工作程序节点。ibmcloud ks worker update -c CLUSTER_NAME_OR_ID --worker WORKER_ID
-
通过复查工作程序节点的 Kubernetes 版本,确认更新是否已完成。
kubectl get nodes
如果更新失败,那么必须 通过替换主机来应用版本更新。
使用 ConfigMap 将版本更新应用于工作程序节点主机
您可以使用 ConfigMap将更新推广到所有工作程序节点主机。 使用标签指定要更新的节点。 您还可以指定
-
识别工作程序节点主机。 工作程序节点主机未列示为
Infrastructure
。 -
查看工作程序节点的标签。 可以在 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
-
创建 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
- 必须为定义的规则考虑工作程序节点的标签值。
-
在群集中创建 ConfigMap。
kubectl apply -f <filepath/configmap.yaml>
-
验证是否已创建 ConfigMap。
kubectl get configmap --namespace kube-system
-
通过按标识列出工作程序节点来更新这些节点。
ibmcloud ks worker update --cluster <cluster_name_or_ID> --worker <worker_node1_ID> --worker <worker_node2_ID>
-
可选:验证 ConfigMap 触发的事件以及发生的任何验证错误。 可以在 CLI 输出的 Events 部分中查看这些事件。
kubectl describe -n kube-system cm ibm-cluster-update-configuration
-
通过复查工作程序节点的 Kubernetes 版本,确认更新是否已完成。
kubectl get nodes
如果更新失败,那么必须 通过替换主机来应用版本更新。
-
确认没有重复的工作节点。 有时,旧版集群可能会在更新后列出重复的工作节点,其状态为
NotReady
状态的重复工作节点。 要除去重复项,请参阅故障诊断。
通过替换主机将版本更新应用于工作程序节点
连接到位置的主机不会自动更新。 要应用版本更新,您可以首先将新主机连接并分配给 Satellite-enabled IBM Cloud 服务,然后除去旧主机。 您还可以在适当位置应用 次版本更新和补丁版本更新。
-
列出当前主机并记下其标识。 这些是连接更新后的主机后要除去的主机。
ibmcloud ks worker ls -c <cluster_name_or_ID>
查看示例输出。
ID Primary IP Flavor State Status Zone Version sat-satliberty-5b4c7f3a7bfc14cf58cbb14ad5c08429475274fe 208.43.36.202 upi normal Ready zone-1 4.7.19_1525_openshift*
-
将新主机连接到 Satellite 位置。 您连接的主机数必须与要更新的主机数相匹配。
-
将新连接的主机分配给 Satellite 资源。 当您分配这些主机时,这些主机会自动接收更新。
-
将新主机成功分配到 Satellite 资源后,请 除去并删除先前记录的旧主机。
在 Red Hat OpenShift on IBM Cloud 控制台中更新工作程序节点主机
您可以使用 Red Hat OpenShift on IBM Cloud 控制台来更新工作程序节点主机。
- 登录到 IBM Cloud 控制台,然后单击 OpenShift > 集群。
- 单击要更新的主机所分配到的集群,然后浏览至“工作程序节点”页面。
- 选择要更新的每台主机。 选择主机后,将显示 更新 选项。
- 单击更新。 在显示的对话框中,再次单击 更新。 此时将显示一条消息,指示更新已成功启动。
- 等待主机更新。 当主机的 状态 返回到 正常 并且新版本在 版本 列中列出时,将完成每个主机的更新过程。
确定工作程序节点版本更新是主要更新,次要更新还是补丁更新
对于所有类型的更新,更新工作程序节点的过程相同。 但是,您可以找到有关更新是主要更新,次要更新还是补丁更新的信息。
要确定可用的更新类型,请将当前工作程序节点版本与 Red Hat OpenShift 版本更改日志 中的最新 worker node fix pack
版本进行比较。 主要更新由版本标签 (4.x.x) 中的第一个数字指示,次要更新由第二个数字 (x.7.x) 指示,补丁更新由尾部数字 (x.x.23_1528_openshift)
指示。 有关版本更新的更多信息,请参阅 版本信息和更新操作。