更新集群、工作程序节点和集群组件
查看以下部分以了解使集群主节点和工作程序节点保持最新的步骤。
更新主节点
- 如何知道何时更新母版?
- 当更新可用时,将在控制台,声明和 CLI 中通知您。 您还可以定期检查 受支持的版本页面。
- 主版本比最新版本晚多少个版本?
- 只能将 API 服务器更新到其当前版本 (
n+1
) 之前的下一个版本。 - 我的工作节点能否运行比主节点更晚的版本?
- 您的工作节点不能运行比主节点更晚的
major.minor
Kubernetes 版本。 此外,工作程序节点只能是主版本 (n-1
) 之后的一个版本。首先,将主节点 更新 到最新的 Kubernetes 版本。 然后,在集群中更新工作程序节点。
工作程序节点运行的补丁版本可以高于主节点,例如特定于工作程序节点以用于安全性更新的补丁版本。
- 如何应用补丁更新?
- 缺省情况下,主节点补丁更新会自动应用,但需要若干天时间,因此主节点补丁版本可能会在应用于主节点之前显示为可用。 自动更新还会跳过运行状况欠佳或当前有操作正在执行的集群。 有时,IBM 可能会对特定主节点修订包禁用自动更新,例如仅当主节点从一个次版本更新到另一个次版本时才需要的补丁。 在上述任何一种情况下,您都可以检查 Red Hat OpenShift on IBM Cloud 版本信息 是否有任何潜在影响,并选择自己安全地使用
ibmcloud oc cluster master update
命令,而无需等待更新自动化应用。
与主节点不同的是,您必须为工作程序更新每个补丁版本。
- 母版更新期间会发生什么?
- 主节点具有高可用性,有三个副本主节点 pod。 主节点 pod 采用滚动更新,在此期间,一次只有一个 pod 不可用。 在更新期间会有两个实例启动且正在运行,以便您可以访问和更改集群。 工作程序节点、应用程序和资源会继续运行。
- 我可以回滚更新吗?
- 不行,更新过程结束后,无法将群集回滚到以前的版本。 请确保使用测试集群并按照指示信息来解决潜在问题,然后再更新生产主节点。
- 我可以按照什么流程更新母版?
- 下图显示更新主节点时可以执行的流程。
更新集群主节点的步骤
开始之前,请确保您拥有 操作员或管理员 IAM 平台访问角色。
更新 Red Hat OpenShift _主_版本或_次要_版本:
-
查看 Red Hat OpenShift on IBM Cloud 版本信息,并将任何更新标记为 在主节点之前更新。
-
查看任何 Kubernetes 有用的警告,例如废弃声明。
-
请检查集群中安装的附加组件和插件,以了解更新集群版本可能造成的任何影响。
-
正在检查附加组件
- 列出集群中的附加组件。
ibmcloud oc cluster addon ls --cluster CLUSTER
- 检查所安装的每个附加组件的受支持 Red Hat OpenShift 版本。
ibmcloud oc addon-versions
- 如果必须更新附加组件以在要将集群更新到的 Red Hat OpenShift 版本中运行,请 更新附加组件。
- 列出集群中的附加组件。
-
检查插件
- 在 Helm 目录中,找到已安装在集群中的插件。
- 从侧边菜单中,展开 源和 TAR 文件 部分。
- 下载并打开源代码。
- 请检查
README.md
或RELEASENOTES.md
文件以获取受支持的版本。 - 如果必须更新插件才能在要更新集群的 Red Hat OpenShift 版本中运行,请遵循插件指示信息来更新插件。
-
-
使用 IBM Cloud 控制台或运行 CLI
ibmcloud oc cluster master update
命令来更新 API 服务器和关联的主节点组件。 -
稍等几分钟,然后确认更新是否已完成。 在 IBM Cloud 集群仪表板上查看 API 服务器版本,或运行
ibmcloud oc cluster ls
。 -
安装与主节点中运行的 API 服务器版本相匹配的
oc cli
版本。 Kubernetes 不支持 与服务器版本相差两个或更多版本(n +/- 2)的客户端版本。oc
主节点更新完成后,可以更新工作程序节点,具体取决于您拥有的集群基础架构提供者的类型。
更新经典工作程序节点
您注意到更新可用于 经典基础架构 集群中的工作程序节点。 这意味着什么呢? 由于 API 服务器和其他主节点组件的安全性更新和补丁已到位,因此您必须确保工作程序节点保持同步。 可以进行两种类型的更新:只更新补丁版本,或者更新含有补丁版本的 major.minor
版本。
- 补丁:工作程序节点补丁更新包含安全修订。 您可以使用
ibmcloud oc worker reload
或update
命令将经典工作程序节点更新为最新补丁。 请记住,如果major.minor
版本更新也可用,那么update
命令还会将工作程序节点更新为与主补丁版本和最新补丁版本相同的major.minor
版本。 - Major.minor:
major.minor
更新将工作程序节点的 Kubernetes 版本升级到与主节点相同的版本。 此类型的更新通常包含对 Kubernetes API 的更改或必须准备集群以用于的其他行为。 请记住,工作程序节点只能是主版本 (n-1
) 之后的一个版本。您可以使用ibmcloud oc worker update
命令将经典工作程序节点更新到同一补丁。
有关更多信息,请参阅更新类型。
- 更新期间我的应用程序会发生什么情况?
- 如果在更新的工作程序节点上作为部署的一部分运行应用程序,那么会将应用程序重新安排到集群中的其他工作程序节点上。 这些工作程序节点可能位于其他工作程序池中,或者如果您具有独立工作程序节点,那么可能会将应用程序安排到独立工作程序节点上。 为避免应用程序发生中断,必须确保集群中有足够的容量来执行工作负载。
- 如何控制更新或重载过程中一次有多少个工作节点宕机?
- 如果需要所有工作程序节点都启动并运行,请考虑通过调整工作程序池大小或添加独立工作程序节点来添加更多工作程序节点。 可以在更新完成后除去其他工作程序节点。
此外,您还可以创建 Kubernetes 配置映射,指定在同一时间(如更新期间)不可用的最大工作节点数。 工作程序节点通过工作程序节点标签进行标识。 可以使用 IBM 提供的标签,也可以使用已添加到工作程序节点的定制标签。
Kubernetes 配置映射规则仅用于更新工作程序节点。 这些规则不会影响工作程序节点重新装入,这意味着在请求时将立即执行重新装入。
- 如果我选择不定义配置映射怎么办?
- 未定义配置映射时,将使用缺省值。 默认情况下,每个群集中最多有 20% 的工作节点在更新过程中不可用。
先决条件
在更新经典基础架构工作程序节点之前,请查看必备步骤。
更新工作程序节点可能会导致应用程序和服务产生停机时间。 系统会对工作程序节点机器重新应用映像,并且如果数据未存储在 pod 外部,那么将删除数据。
- 对于最新的安全补丁和修订,请确保在工作程序节点可用后尽快将其更新为最新的补丁。 有关最新更新的更多信息,请查看 Red Hat OpenShift on IBM Cloud 版本信息。
- 访问 Red Hat OpenShift 集群。
- 更新主节点。 Worker 节点版本不能高于 Kubernetes master 中运行的 API 服务器版本。
- 在 Red Hat OpenShift 版本准备指南 中进行任何标记为 在主服务器之后更新 的更改。
- 如果要应用补丁更新,请查看 Red Hat OpenShift on IBM Cloud 版本信息。
- 考虑添加更多的工作节点,以便集群有足够的能力在更新期间重新安排工作负载。 有关更多信息,请参阅 将工作程序节点添加到经典集群 或 将工作程序节点添加到 VPC 集群。
- 确保您拥有 操作员或管理员 IAM 平台访问角色。
在 CLI 中使用配置映射更新经典工作程序节点
设置配置映射以执行经典工作程序节点的滚动更新。
-
完成必备步骤。
-
列出可用的工作程序节点,并记录其专用 IP 地址。
ibmcloud oc worker ls --cluster CLUSTER
-
查看工作程序节点的标签。 可以在 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
-
创建配置映射,并定义工作程序节点的不可用性规则。 以下示例显示了四个检查:
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
根据区域标签识别工作节点,而regioncheck.json
则使用在配置过程中添加到每个工作节点的区域标签。 在示例中,更新期间,dal13
作为区域标签的所有工作节点中的 30% 和us-south
中的所有工作节点中的 20% 可能不可用。 defaultcheck.json
- 如果没有创建配置映射或映射配置不正确,则会应用 Kubernetes 默认值。 缺省情况下,集群中只能有 20% 的工作程序节点同时不可用。 您可以通过向配置映射添加缺省检查来覆盖缺省值。 在示例中,每个未在区域和地区检查中指定的工作节点(
dal13
或us-south
)都可能在更新期间不可用。 MaxUnavailablePercentage
- 对于指定的标签键和值,允许不可用的最大节点数,指定为百分比。 工作程序节点在部署、重新装入或供应过程中会不可用。 如果排队的工作程序节点超过任何定义的最大不可用百分比,那么会阻止这些节点更新。
NodeSelectorKey
- 要为其设置规则的工作程序节点的标签键。 可以为 IBM 提供的缺省标签以及您创建的工作程序节点标签设置规则。 如果要为属于一个工作池的工作节点添加规则,可以使用
ibm-cloud.kubernetes.io/machine-type
标签。 NodeSelectorValue
- 必须为定义的规则考虑工作程序节点的标签值。
-
在集群中创建配置映射。
oc apply -f <filepath/configmap.yaml>
-
验证配置映射是否已创建。
oc get configmap --namespace kube-system
-
更新工作程序节点。
ibmcloud oc worker update --cluster CLUSTER --worker WORKER-NODE-1-ID --worker WORKER-NODE-2-ID
-
可选:验证由配置映射触发的事件以及发生的任何验证错误。 可以在 CLI 输出的 Events 部分中查看这些事件。
oc describe -n kube-system cm ibm-cluster-update-configuration
-
通过复查工作程序节点的 Kubernetes 版本,确认更新是否已完成。
oc get nodes
-
确认没有重复的工作节点。 有时,旧版集群可能会在更新后列出重复的工作节点,其状态为
NotReady
状态的重复工作节点。 要除去重复项,请参阅故障诊断。
后续步骤:
- 对其他工作程序池重复更新过程。
- 通知在集群中工作的开发者将其
oc
CLI 更新到 Kubernetes 主节点的版本。 - 如果 Kubernetes 仪表板未显示利用率图形,请删除
kube-dashboard
pod。
在控制台中更新经典工作程序节点
首次设置配置映射后,接着就可以使用 IBM Cloud 控制台来更新工作程序节点。
要通过控制台更新工作程序节点,请执行以下操作:
- 完成必备步骤和设置配置映射,以控制工作程序节点的更新方式。
- 从 IBM Cloud 控制台 菜单
,单击容器 > 集群。
- 在集群页面中,单击您的集群。
- 在“工作节点”选项卡上,选择要更新的每个工作节点的复选框。 在表标题行的上方显示有操作栏。
- 在操作栏中,单击更新。
如果在集群中安装了 Portworx,那么必须在更新后的工作程序节点上重新启动 Portworx pod。 有关更多信息,请参阅 Portworx 限制。
更新 VPC 工作程序节点
您注意到更新可用于 VPC 集群中的工作程序节点。 这意味着什么呢? 由于 API 服务器和其他主节点组件的安全性更新和补丁已到位,因此您必须确保工作程序节点保持同步。 可以进行两种类型的更新:只更新补丁版本,或者更新含有补丁版本的 major.minor
版本。
如果在集群中部署了 Portworx,请遵循 使用 Portworx 卷更新 VPC 工作程序节点 的步骤。
如果在集群中部署了 OpenShift Data Foundation,请遵循 使用 OpenShift Data Foundation 更新 VPC 工作程序节点 的步骤。
- 补丁:工作程序节点补丁更新包含安全修订。 您可以使用
ibmcloud oc worker replace
命令将 VPC 工作节点更新为最新补丁。 - Major.minor:
major.minor
更新将工作程序节点的 Kubernetes 版本升级到与主节点相同的版本。 此类型的更新通常包含对 Kubernetes API 的更改或必须准备集群以用于的其他行为。 请记住,工作程序节点只能是主版本 (n-1
) 之后的一个版本。您可以使用带有--update
选项的ibmcloud oc worker replace
命令将 VPC 工作程序节点更新到同一补丁。
- 更新期间我的应用程序会发生什么情况?
- 如果在更新的工作程序节点上作为部署的一部分运行应用程序,那么会将应用程序重新安排到集群中的其他工作程序节点上。 这些工作程序节点可能位于其他工作程序池中。 为避免应用程序宕机,您必须确保群集有足够的容量来承载工作负载,例如调整工作池的大小。 有关更多信息,请参阅 将工作程序节点添加到经典集群 或 将工作程序节点添加到 VPC 集群。
- 更新期间,我的工作节点会发生什么情况?
- 通过移除旧的工作者节点并配置一个以更新补丁或
major.minor
版本运行的新工作者节点,来替换您的 VPC 工作者节点。 替换工作程序节点在同一专区、同一工作程序池中创建,并且其类型模板与删除的工作程序节点相同。 但是,替换的工作员节点会被分配一个新的私有 IP 地址,并丢失应用到旧工作员节点的任何自定义标签或污点(工作员池标签和污点仍会应用到替换的工作员节点)。 - 如果我同时更换多个工作程序节点会怎样?
- 如果同时替换多个工作程序节点,那么将同时删除并替换这些节点,而不是逐个进行替换。 在更换工作程序节点之前,请确保集群中有足够的容量来重新调度工作负载。
- 如果未创建替换工作程序节点,该怎么办?
- 如果工作程序池未启用 自动重新平衡,那么不会创建替换工作程序节点。
先决条件
在更新 VPC 基础架构工作程序节点之前,请查看必备步骤。
更新工作程序节点可能会导致应用程序和服务产生停机时间。 系统会除去工作程序节点机器,并且如果数据未存储在 pod 外部,那么将删除数据。
- 对于最新的安全补丁和修订,请确保在工作程序节点可用后尽快将其更新为最新的补丁。 有关最新更新的更多信息,请查看 Red Hat OpenShift on IBM Cloud 版本信息。
- 访问 Red Hat OpenShift 集群。
- 更新主节点。 Worker 节点版本不能高于 Kubernetes master 中运行的 API 服务器版本。
- 在 Red Hat OpenShift 版本准备指南 中进行任何标记为 在主服务器之后更新 的更改。
- 如果要应用补丁更新,请查看 Red Hat OpenShift on IBM Cloud 版本信息。
- 确保您拥有 操作员或管理员 IAM 平台访问角色。
在 CLI 中更新 VPC 工作程序节点
完成以下步骤以使用 CLI 更新工作程序节点。
- 完成必备步骤。
- 可选:通过调整工人池的大小来增加群集的容量。 工作程序节点上的 pod 可以重新安排,并且这些 pod 在更新期间继续在添加的工作程序节点上运行。 有关更多信息,请参阅 将工作程序节点添加到经典集群 或 将工作程序节点添加到 VPC 集群。
- 列出集群中的工作程序节点,并记下要更新的工作程序节点的 ID 和 Primary IP。
ibmcloud oc worker ls --cluster CLUSTER
- 替换工作程序节点,以更新与主节点版本匹配的补丁版本或
major.minor
版本。- 要将工作程序节点更新为与主节点相同的
major.minor
版本,请包含--update
选项。ibmcloud oc worker replace --cluster CLUSTER --worker WORKER-NODE-ID --update
- 要将工作程序节点更新为同一
major.minor
版本的最新补丁版本,请不要包含--update
选项。ibmcloud oc worker replace --cluster CLUSTER --worker WORKER-NODE-ID
- 要将工作程序节点更新为与主节点相同的
- 对必须更新的每个工作程序节点重复上述步骤。
- 可选:在替换的工作者节点处于就绪状态后,调整工作者池的大小,以满足所需的群集容量。 有关更多信息,请参阅 将工作程序节点添加到 VPC 集群。
如果要在 VPC 集群中运行 Portworx,那么必须 手动将 Block Storage for VPC 卷连接到新的工作程序节点。
在控制台中更新 VPC 工作程序节点
可以在控制台中更新 VPC 工作程序节点。 开始之前,请考虑 添加工作程序节点 到集群,以帮助避免应用程序的停机时间。
- 完成必备步骤。
- 从 IBM Cloud 控制台 菜单
,单击容器 > 集群。
- 在集群页面中,单击您的集群。
- 在“工作节点”选项卡上,选择要更新的每个工作节点的复选框。 在表标题行的上方显示有操作栏。
- 在操作栏中,单击更新。
更新类型模板(机器类型)
开始之前:
- 访问 Red Hat OpenShift 集群。
- 将删除工作程序节点上的数据。 请考虑将数据存储在工作程序节点外部的持久存储器上。
- 确保您拥有 操作员或管理员 IAM 平台访问角色。
要更新类型模板,请执行以下操作:
-
列出可用的工作程序节点,并记录其专用 IP 地址。
- 列出集群中的可用工作程序池。
ibmcloud oc worker-pool ls --cluster CLUSTER
- 列出工作程序池中的工作程序节点。 记下 ID 和 Private IP。
ibmcloud oc worker ls --cluster CLUSTER --worker-pool WORKER-POOL
- 获取工作程序节点的详细信息。 在输出中,记下区域以及经典集群的专用和公用 VLAN 标识或 VPC 集群的子网标识。
ibmcloud oc worker get --cluster CLUSTER --worker WORKER-ID
- 列出集群中的可用工作程序池。
-
列出专区中可用的类型模板。
ibmcloud oc flavors --zone <zone>
-
创建具有新机器类型的工作程序节点。
- 创建工作程序池,其中的工作程序节点数与要替换的节点数相同。
- 经典集群:
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
- 经典集群:
- 验证工作程序池是否已创建。
ibmcloud oc worker-pool ls --cluster CLUSTER
- 将专区添加到先前检索到的工作程序池。 添加专区时,工作程序池中定义的工作程序节点将在专区中供应,并考虑用于未来的工作负载安排。 如果要跨多个专区分布工作程序节点,请选择 经典 或 VPC 多专区位置。
- 经典集群:
ibmcloud oc zone add classic --zone ZONE --cluster CLUSTER --worker-pool WORKER-POOL --private-vlan PRIVATE-VLAN-ID --public-vlan PUBLIC-VLAN-ID
- VPC 集群:
ibmcloud oc zone add vpc-gen2 --zone ZONE --cluster CLUSTER --worker-pool WORKER-POOL --subnet-id VPC-SUBNET-ID
- 经典集群:
- 创建工作程序池,其中的工作程序节点数与要替换的节点数相同。
-
等待工作程序节点进行部署。 工作程序节点的状态更改为 Normal 时,说明部署完成。
ibmcloud oc worker ls --cluster CLUSTER
-
除去旧的工作程序节点。 注:如果要除去按月计费的类型模板(如裸机),那么仍将对整个月收费。
- 除去具有旧机器类型的工作程序池。 除去工作程序池将除去所有专区中该池中的所有工作程序节点。 此过程可能需要几分钟才能完成。
ibmcloud oc worker-pool rm --worker-pool WORKER-POOL --cluster CLUSTER
- 验证工作程序池是否已除去。
ibmcloud oc worker-pool ls --cluster CLUSTER
- 除去具有旧机器类型的工作程序池。 除去工作程序池将除去所有专区中该池中的所有工作程序节点。 此过程可能需要几分钟才能完成。
-
验证工作程序节点是否已从集群中除去。
ibmcloud oc worker ls --cluster CLUSTER
-
重复这些步骤以将其他工作程序池或独立工作程序节点更新为不同的类型模板。
如何缩减工作程序池?
当工作程序池中的工作程序节点数减少 (例如,在工作程序节点更新期间或使用 ibmcloud oc worker-pool resize
命令) 时,将根据多个属性 (包括状态,运行状况和版本) 来划分工作程序节点的删除优先级。
此优先级逻辑与自动缩放器附加组件无关。
下表显示了要删除的工作程序节点的优先顺序。
您可以运行 ibmcloud oc worker ls
命令以查看表中列出的所有工作程序节点属性。
优先级 | 属性 | 描述 |
---|---|---|
1 | 工作程序节点状态 | 处于非工作状态或低工作状态的工作程序节点将被划分优先级以进行移除。 此列表显示从最高优先级到最低优先级排序的状态: provision_failed ,deploy_failed ,deleting ,provision_pending ,provisioning ,deploying ,provisioned ,reloading_failed ,reloading 和 deployed 。 |
2 | 工作程序节点运行状况 | 运行状况不佳的工作程序节点优先于运行状况正常的工作程序节点。 此列表显示从最高优先级到最低优先级排序的运行状况状态: critical ,warning ,pending ,unsupported 和 normal 。 |
3 | 工作程序节点版本 | 在较旧版本上运行的工作程序节点具有更高的删除优先级。 |
4 | 期望的放置设置 | 仅适用于在专用主机上运行的工作程序。 在 DesiredPlacementDisabled 选项设置为 true 的专用主机上运行的工作程序节点具有更高的删除优先级。 |
5 | 字母顺序 | 根据以上列出的因素对工作程序节点进行优先级划分后,将按字母顺序删除这些工作程序节点。 请注意,根据工作程序节点标识约定,经典集群和 VPC 集群上工作程序的标识与年龄相关,因此将首先除去较旧的工作程序节点。 |
更新集群组件
Red Hat OpenShift on IBM Cloud 集群随附在供应集群时自动安装的组件,例如 Ingress。 缺省情况下,IBM 会自动更新这些组件。 但是,您可以禁用某些组件的自动更新,而单独从主节点和工作程序节点手动更新这些组件。
- 哪些默认组件可以脱离群集单独更新?
- 您可以选择禁用以下组件的自动更新:
- 有哪些组件我不能从群集中单独更新?
- 需要。 您的群集部署了以下受管组件和相关资源,除了扩展 pod 或编辑配置映射以获得某些性能优势外,这些组件和资源是不能更改的。 如果尝试更改下列其中一个部署组件,那么在使用集群主节点定期更新这些部署组件的原始设置时,其原始设置会复原。 但是,请注意,不会更新创建的与这些组件关联的资源,例如,您创建以由 Calico 部署组件实施的 Calico 网络策略。
calico
组件coredns
组件ibm-cloud-provider-ip
ibm-file-plugin
ibm-keepalived-watcher
ibm-master-proxy
ibm-storage-watcher
kubernetes-dashboard
组件metrics-server
olm-operator
和catalog
组件 (1.16 和更高版本)vpn
- 除了默认组件,我还能安装其他插件或附加组件吗?
- 是的。Red Hat OpenShift on IBM Cloud 提供了其他插件和附加组件,您可以从中选择,为您的集群增加功能。 例如,您可能希望 使用 Helm Chart 来安装 strongSwan VPN。 或者,您可能希望在集群中启用 IBM管理的附加组件,例如诊断和调试工具。 您必须按照 Helm 图表自述文件中的说明或按照 更新托管附加组件 的步骤分别更新这些 Helm 图表和附加组件。
管理 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 此后不会自动更新。 示例命令ibmcloud oc logging config update --cluster CLUSTER --id LOG-CONFIG-ID --type LOG-TYPE --force-update
-
管理 Ingress ALB 的自动更新
控制何时更新 Ingress 应用程序负载均衡器 (ALB) 组件。 有关使 ALB 保持最新的信息,请参阅 管理 Ingress ALB 生命周期。
更新受管附加组件
托管的 IBM Cloud Kubernetes Service 集群附加组件是利用 Istio 等开源功能增强集群的简便方法。 您添加到群集的开源工具版本已通过 IBM 测试,并获准在 IBM Cloud Kubernetes Service 中使用。 要将集群中启用的受管附加组件更新到最新版本,请参阅更新受管附加组件。