第 12 章 使用 Topology Aware Lifecycle Manager 在断开连接的环境中更新受管集群
您可以使用 Topology Aware Lifecycle Manager (TALM) 来管理 OpenShift Container Platform 受管集群的软件生命周期。TALM 使用 Red Hat Advanced Cluster Management(RHACM)策略在目标集群中进行更改。
其他资源
- 有关 Topology Aware Lifecycle Manager 的更多信息,请参阅关于 Topology Aware Lifecycle Manager。
12.1. 在断开连接的环境中更新集群
您可以使用 GitOps Zero Touch Provisioning (ZTP) 和 Topology Aware Lifecycle Manager (TALM) 为您部署的受管集群升级受管集群和 Operator。
12.1.1. 设置环境
TALM 可以同时执行平台和 Operator 更新。
您必须在镜像 registry 中镜像您要升级到的平台镜像和 Operator 镜像,然后才能使用 TALM 更新断开连接的集群。完成以下步骤以镜像镜像:
对于平台更新,您必须执行以下步骤:
镜像所需的 OpenShift Container Platform 镜像存储库。根据"镜像 OpenShift Container Platform 镜像存储库"流程在附加资源中链接,确保所需的平台镜像已被镜像。在
imageContentSources.yaml
文件中保存imageContentSources
部分的内容:输出示例
imageContentSources: - mirrors: - mirror-ocp-registry.ibmcloud.io.cpak:5000/openshift-release-dev/openshift4 source: quay.io/openshift-release-dev/ocp-release - mirrors: - mirror-ocp-registry.ibmcloud.io.cpak:5000/openshift-release-dev/openshift4 source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
保存已镜像的所需平台镜像的镜像签名。对于平台更新,您必须将镜像签名添加到
PolicyGenTemplate
CR 中。要获取镜像签名,请执行以下步骤:运行以下命令指定所需的 OpenShift Container Platform 标签:
$ OCP_RELEASE_NUMBER=<release_version>
运行以下命令指定集群的构架:
$ ARCHITECTURE=<cluster_architecture> 1
- 1
- 指定集群的构架,如
x86_64
,aarch64
,s390x
, 获ppc64le
。
运行以下命令,从 Quay 获取发行版本镜像摘要
$ DIGEST="$(oc adm release info quay.io/openshift-release-dev/ocp-release:${OCP_RELEASE_NUMBER}-${ARCHITECTURE} | sed -n 's/Pull From: .*@//p')"
运行以下命令来设置摘要算法:
$ DIGEST_ALGO="${DIGEST%%:*}"
运行以下命令来设置摘要签名:
$ DIGEST_ENCODED="${DIGEST#*:}"
运行以下命令,从 mirror.openshift.com 网站获取镜像签名:
$ SIGNATURE_BASE64=$(curl -s "https://mirror.openshift.com/pub/openshift-v4/signatures/openshift/release/${DIGEST_ALGO}=${DIGEST_ENCODED}/signature-1" | base64 -w0 && echo)
运行以下命令,将镜像签名保存到
checksum-<OCP_RELEASE_NUMBER>.yaml
文件中:$ cat >checksum-${OCP_RELEASE_NUMBER}.yaml <<EOF ${DIGEST_ALGO}-${DIGEST_ENCODED}: ${SIGNATURE_BASE64} EOF
准备更新图表。您可以通过两个选项来准备更新图形:
使用 OpenShift Update Service。
有关如何在 hub 集群上设置图形的更多信息,请参阅为 OpenShift Update Service 部署 Operator 并构建图形数据 init 容器。
生成上游图形的本地副本。在可访问受管集群的断开连接的环境中的
http
或https
服务器上托管更新图表。要下载更新图表,请使用以下命令:$ curl -s https://api.openshift.com/api/upgrades_info/v1/graph?channel=stable-4.15 -o ~/upgrade-graph_stable-4.15
对于 Operator 更新,您必须执行以下任务:
- 镜像 Operator 目录。确保所需的 Operator 镜像按照"Mirroring Operator 目录以用于断开连接的集群"部分中的步骤进行镜像。
其他资源
- 有关如何更新 GitOps Zero Touch Provisioning (ZTP) 的更多信息,请参阅升级 GitOps ZTP。
- 有关如何镜像 OpenShift Container Platform 镜像存储库的更多信息,请参阅镜像 OpenShift Container Platform 镜像存储库。
- 有关如何为断开连接的集群镜像 Operator 目录的更多信息,请参阅镜像 Operator 目录以用于断开连接的集群。
- 有关如何准备断开连接的环境并镜像所需的镜像存储库的更多信息,请参阅准备断开连接的环境。
- 有关更新频道和发行版本的更多信息,请参阅了解更新频道和发行版本。
12.1.2. 执行平台更新
您可以使用 TALM 执行平台更新。
先决条件
- 安装 Topology Aware Lifecycle Manager(TALM)。
- 将 GitOps Zero Touch Provisioning (ZTP) 更新至最新版本。
- 使用 GitOps ZTP 置备一个或多个受管集群。
- 镜像所需的镜像存储库。
-
以具有
cluster-admin
特权的用户身份登录。 - 在 hub 集群中创建 RHACM 策略。
流程
为平台更新创建
PolicyGenTemplate
CR:将
PolicyGenTemplate
CR 的以下内容保存到du-upgrade.yaml
文件中。平台更新的
PolicyGenTemplate
示例apiVersion: ran.openshift.io/v1 kind: PolicyGenTemplate metadata: name: "du-upgrade" namespace: "ztp-group-du-sno" spec: bindingRules: group-du-sno: "" mcp: "master" remediationAction: inform sourceFiles: - fileName: ImageSignature.yaml 1 policyName: "platform-upgrade-prep" binaryData: ${DIGEST_ALGO}-${DIGEST_ENCODED}: ${SIGNATURE_BASE64} 2 - fileName: DisconnectedICSP.yaml policyName: "platform-upgrade-prep" metadata: name: disconnected-internal-icsp-for-ocp spec: repositoryDigestMirrors: 3 - mirrors: - quay-intern.example.com/ocp4/openshift-release-dev source: quay.io/openshift-release-dev/ocp-release - mirrors: - quay-intern.example.com/ocp4/openshift-release-dev source: quay.io/openshift-release-dev/ocp-v4.0-art-dev - fileName: ClusterVersion.yaml 4 policyName: "platform-upgrade" metadata: name: version spec: channel: "stable-4.15" upstream: http://upgrade.example.com/images/upgrade-graph_stable-4.15 desiredUpdate: version: 4.15.4 status: history: - version: 4.15.4 state: "Completed"
- 1
ConfigMap
CR 包含要更新到的所需发行镜像的签名。- 2
- 显示所需 OpenShift Container Platform 发行版本的镜像签名。按照"设置环境"部分中的步骤,从您保存的
checksum-${OCP_RELEASE_NUMBER}.yaml
文件中获取签名。 - 3
- 显示包含所需 OpenShift Container Platform 镜像的镜像存储库。获取在"设置 environment"部分中的步骤时所保存的
imageContentSources.yaml
文件中的镜像。 - 4
- 显示触发更新的
ClusterVersion
CR。对于预缓存,channel
,upstream
, 和desiredVersion
项都是必需的。
PolicyGenTemplate
CR 会生成两个策略:-
du-upgrade-platform-upgrade-prep
策略为平台更新做准备。它为所需的发行版本镜像签名创建ConfigMap
CR,创建镜像的发行镜像存储库的镜像内容源,并使用所需的更新频道更新集群版本,以及在断开连接的环境中由 spoke 集群访问的更新图。 -
du-upgrade-platform-upgrade
策略用于执行平台升级。
将
du-upgrade.yaml
文件内容添加到PolicyGenTemplate
CR 的 GitOps ZTP Git 存储库中的kustomization.yaml
文件中,并将更改推送到 Git 存储库。ArgoCD 从 Git 存储库拉取更改并在 hub 集群上生成策略。
运行以下命令检查创建的策略:
$ oc get policies -A | grep platform-upgrade
为平台更新创建
ClusterGroupUpdate
CR,将spec.enable
项设置为false
。将平台更新
ClusterGroupUpdate
CR 的内容,带有du-upgrade-platform-upgrade-prep
和du-upgrade-platform-upgrade
策略,以及目标集群保存到cgu-platform-upgrade.yml
文件,如以下示例所述:apiVersion: ran.openshift.io/v1alpha1 kind: ClusterGroupUpgrade metadata: name: cgu-platform-upgrade namespace: default spec: managedPolicies: - du-upgrade-platform-upgrade-prep - du-upgrade-platform-upgrade preCaching: false clusters: - spoke1 remediationStrategy: maxConcurrency: 1 enable: false
运行以下命令,将
ClusterGroupUpdate
CR 应用到 hub 集群:$ oc apply -f cgu-platform-upgrade.yml
可选:缓存平台更新的镜像。
运行以下命令,在
ClusterGroupUpdate
CR 中启用预缓存:$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-platform-upgrade \ --patch '{"spec":{"preCaching": true}}' --type=merge
监控更新过程,并等待预缓存完成。在 hub 集群中运行以下命令来检查预缓存的状态:
$ oc get cgu cgu-platform-upgrade -o jsonpath='{.status.precaching.status}'
启动平台更新:
运行以下命令启用
cgu-platform-upgrade
策略并禁用预缓存:$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-platform-upgrade \ --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge
监控进程。在完成后,运行以下命令来确保策略兼容:
$ oc get policies --all-namespaces
其他资源
- 有关在断开连接的环境中镜像镜像的更多信息,请参阅准备断开连接的环境。
12.1.3. 执行 Operator 更新
您可以使用 TALM 执行 Operator 更新。
先决条件
- 安装 Topology Aware Lifecycle Manager(TALM)。
- 将 GitOps Zero Touch Provisioning (ZTP) 更新至最新版本。
- 使用 GitOps ZTP 置备一个或多个受管集群。
- 镜像捆绑包镜像、捆绑包镜像以及捆绑包镜像中引用的所有 Operator 镜像。
-
以具有
cluster-admin
特权的用户身份登录。 - 在 hub 集群中创建 RHACM 策略。
流程
为 Operator 更新更新
PolicyGenTemplate
CR。使用
du-upgrade.yaml
文件中的以下额外内容更新du-upgrade
PolicyGenTemplate
CR:apiVersion: ran.openshift.io/v1 kind: PolicyGenTemplate metadata: name: "du-upgrade" namespace: "ztp-group-du-sno" spec: bindingRules: group-du-sno: "" mcp: "master" remediationAction: inform sourceFiles: - fileName: DefaultCatsrc.yaml remediationAction: inform policyName: "operator-catsrc-policy" metadata: name: redhat-operators spec: displayName: Red Hat Operators Catalog image: registry.example.com:5000/olm/redhat-operators:v4.15 1 updateStrategy: 2 registryPoll: interval: 1h status: connectionState: lastObservedState: READY 3
- 1
- 索引镜像 URL 包含所需的 Operator 镜像。如果索引镜像始终推送到相同的镜像名称和标签,则不需要此更改。
- 2
- 使用
registryPoll.interval
字段设置 Operator Lifecycle Manager(OLM)轮询新 Operator 版本的索引镜像。如果为 y-stream 和 z-stream Operator 更新而总是推送新的索引镜像标签,则不需要此更改。registryPoll.interval
字段可以设置为较短的间隔,以加快更新,但较短的间隔会增大计算负载。要影响这个问题,您可以在更新完成后将registryPoll.interval
恢复到默认值。 - 3
- 目录连接的最后观察到状态。
READY
值确保CatalogSource
策略已就绪,表示索引 Pod 已拉取并在运行。这样,TALM 根据最新的策略合规性状态升级 Operator。
在这个版本中,生成一个策略
du-upgrade-operator-catsrc-policy
,以使用包含所需 Operator 镜像的新索引镜像更新redhat-operators
目录源。注意如果要使用 Operator 预缓存,并且有来自
redhat-operators
以外的其他目录源的 Operator,您必须执行以下任务:- 使用新的索引镜像或 registry 轮询间隔更新准备单独的目录源策略。
- 为来自不同目录源的所需 Operator 准备单独的订阅策略。
例如,所需的 SRIOV-FEC Operator 在
certified-operators
目录源中提供。要更新目录源和 Operator 订阅,请添加以下内容来生成两个策略:du-upgrade-fec-catsrc-policy
和du-upgrade-subscriptions-fec-policy
:apiVersion: ran.openshift.io/v1 kind: PolicyGenTemplate metadata: name: "du-upgrade" namespace: "ztp-group-du-sno" spec: bindingRules: group-du-sno: "" mcp: "master" remediationAction: inform sourceFiles: … - fileName: DefaultCatsrc.yaml remediationAction: inform policyName: "fec-catsrc-policy" metadata: name: certified-operators spec: displayName: Intel SRIOV-FEC Operator image: registry.example.com:5000/olm/far-edge-sriov-fec:v4.10 updateStrategy: registryPoll: interval: 10m - fileName: AcceleratorsSubscription.yaml policyName: "subscriptions-fec-policy" spec: channel: "stable" source: certified-operators
如果存在,在常规
PolicyGenTemplate
CR 中删除指定的订阅频道。GitOps ZTP 镜像的默认订阅频道用于更新。注意通过 GitOps ZTP 4.15 应用的 Operator 的默认频道是
stable
,但performance-addon-operator
除外。从 OpenShift Container Platform 4.11 开始,performance-addon-operator
功能被移到node-tuning-operator
中。对于 4.10 发行版本,PAO 的默认频道是v4.10
。您还可以在常规PolicyGenTemplate
CR 中指定默认频道。将
PolicyGenTemplate
CR 更新推送到 GitOps ZTP Git 存储库。ArgoCD 从 Git 存储库拉取更改并在 hub 集群上生成策略。
运行以下命令检查创建的策略:
$ oc get policies -A | grep -E "catsrc-policy|subscription"
在启动 Operator 更新前,应用所需的目录源更新。
使用目录源策略将名为
operator-upgrade-prep
的ClusterGroupUpgrade
CR 的内容保存到cgu-operator-upgrade-prep.yml
文件中:apiVersion: ran.openshift.io/v1alpha1 kind: ClusterGroupUpgrade metadata: name: cgu-operator-upgrade-prep namespace: default spec: clusters: - spoke1 enable: true managedPolicies: - du-upgrade-operator-catsrc-policy remediationStrategy: maxConcurrency: 1
运行以下命令,将策略应用到 hub 集群:
$ oc apply -f cgu-operator-upgrade-prep.yml
监控更新过程。在完成后,运行以下命令来确保策略兼容:
$ oc get policies -A | grep -E "catsrc-policy"
为 Operator 更新创建
ClusterGroupUpgrade
CR,并将spec.enable
字段设置为false
。使用
du-upgrade-operator-catsrc-policy
策略和从常规PolicyGenTemplate
创建的订阅策略,将 Operator 更新ClusterGroupUpgrade
CR 的内容保存到cgu-operator-upgrade.yml
文件,如下例所示:apiVersion: ran.openshift.io/v1alpha1 kind: ClusterGroupUpgrade metadata: name: cgu-operator-upgrade namespace: default spec: managedPolicies: - du-upgrade-operator-catsrc-policy 1 - common-subscriptions-policy 2 preCaching: false clusters: - spoke1 remediationStrategy: maxConcurrency: 1 enable: false
注意一个
ClusterGroupUpgrade
CR 只能从ClusterGroupUpgrade
CR 中包含的一个目录源中预缓存订阅策略中定义的 Operator 镜像。如果所需的 Operator 来自不同目录源,如 SRIOV-FEC Operator 示例,则必须使用du-upgrade-fec-catsrc-policy
和du-upgrade-subscriptions-fec-policy
镜像(pre-FEC Operator 镜像)创建另一个ClusterGroupUpgrade
CR。运行以下命令,将
ClusterGroupUpgrade
CR 应用到 hub 集群:$ oc apply -f cgu-operator-upgrade.yml
可选:缓存 Operator 更新的镜像。
在启动镜像预缓存前,运行以下命令验证订阅策略在此时是否是
NonCompliant
:$ oc get policy common-subscriptions-policy -n <policy_namespace>
输出示例
NAME REMEDIATION ACTION COMPLIANCE STATE AGE common-subscriptions-policy inform NonCompliant 27d
运行以下命令,在
ClusterGroupUpgrade
CR 中启用预缓存:$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-operator-upgrade \ --patch '{"spec":{"preCaching": true}}' --type=merge
监控进程并等待预缓存完成。在受管集群中运行以下命令来检查预缓存的状态:
$ oc get cgu cgu-operator-upgrade -o jsonpath='{.status.precaching.status}'
运行以下命令,检查预缓存是否在启动更新前完成:
$ oc get cgu -n default cgu-operator-upgrade -ojsonpath='{.status.conditions}' | jq
输出示例
[ { "lastTransitionTime": "2022-03-08T20:49:08.000Z", "message": "The ClusterGroupUpgrade CR is not enabled", "reason": "UpgradeNotStarted", "status": "False", "type": "Ready" }, { "lastTransitionTime": "2022-03-08T20:55:30.000Z", "message": "Precaching is completed", "reason": "PrecachingCompleted", "status": "True", "type": "PrecachingDone" } ]
启动 Operator 更新。
运行以下命令,启用
cgu-operator-upgrade
ClusterGroupUpgrade
CR,并禁用预缓存来启动 Operator 更新:$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-operator-upgrade \ --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge
监控进程。在完成后,运行以下命令来确保策略兼容:
$ oc get policies --all-namespaces
其他资源
- 有关更新 GitOps ZTP 的更多信息,请参阅升级 GitOps ZTP。
- 由于过时的策略合规状态导致的 missed Operator 更新进行故障排除。
12.1.3.1. 由于过时的策略合规状态导致的 missed Operator 更新进行故障排除
在某些情况下,Topology Aware Lifecycle Manager (TALM)可能会因为过时的策略合规状态而丢失 Operator 更新。
在目录源更新后,Operator Lifecycle Manager (OLM)需要时间来更新订阅状态。当 TALM 决定是否需要补救时,订阅策略的状态可能会继续显示为合规。因此,订阅策略中指定的 Operator 不会升级。
要避免这种情况,请在 PolicyGenTemplate
中添加另一个目录源配置,并为需要更新的任何 Operator 在订阅中指定此配置。
流程
在
PolicyGenTemplate
资源中添加目录源配置:- fileName: DefaultCatsrc.yaml remediationAction: inform policyName: "operator-catsrc-policy" metadata: name: redhat-operators spec: displayName: Red Hat Operators Catalog image: registry.example.com:5000/olm/redhat-operators:v{product-version} updateStrategy: registryPoll: interval: 1h status: connectionState: lastObservedState: READY - fileName: DefaultCatsrc.yaml remediationAction: inform policyName: "operator-catsrc-policy" metadata: name: redhat-operators-v2 1 spec: displayName: Red Hat Operators Catalog v2 2 image: registry.example.com:5000/olredhat-operators:<version> 3 updateStrategy: registryPoll: interval: 1h status: connectionState: lastObservedState: READY
更新
Subscription
资源,以指向需要更新的 Operator 的新配置:apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: operator-subscription namespace: operator-namspace # ... spec: source: redhat-operators-v2 1 # ...
- 1
- 输入您在
PolicyGenTemplate
资源中定义的额外目录源配置的名称。
12.1.4. 一起执行平台和 Operator 更新
您可以同时执行平台和 Operator 更新。
先决条件
- 安装 Topology Aware Lifecycle Manager(TALM)。
- 将 GitOps Zero Touch Provisioning (ZTP) 更新至最新版本。
- 使用 GitOps ZTP 置备一个或多个受管集群。
-
以具有
cluster-admin
特权的用户身份登录。 - 在 hub 集群中创建 RHACM 策略。
流程
-
按照 "forming a platform update" 和 "Performing an Operator update" 部分所述的步骤为更新创建
PolicyGenTemplate
CR。 为平台和 Operator 更新应用准备工作。
使用平台更新准备工作、目录源更新和目标集群的
ClusterGroupUpgrade
CR 将内容保存到cgu-platform-operator-upgrade-prep.yml
文件中,例如:apiVersion: ran.openshift.io/v1alpha1 kind: ClusterGroupUpgrade metadata: name: cgu-platform-operator-upgrade-prep namespace: default spec: managedPolicies: - du-upgrade-platform-upgrade-prep - du-upgrade-operator-catsrc-policy clusterSelector: - group-du-sno remediationStrategy: maxConcurrency: 10 enable: true
运行以下命令,将
cgu-platform-operator-upgrade-prep.yml
文件应用到 hub 集群:$ oc apply -f cgu-platform-operator-upgrade-prep.yml
监控进程。在完成后,运行以下命令来确保策略兼容:
$ oc get policies --all-namespaces
为平台创建
ClusterGroupUpdate
CR,并将spec.enable
字段设置为false
的 Operator 更新。将平台的内容和带有策略和目标集群的 Operator 更新
ClusterGroupUpdate
CR 保存为cgu-platform-operator-upgrade.yml
文件,如下例所示:apiVersion: ran.openshift.io/v1alpha1 kind: ClusterGroupUpgrade metadata: name: cgu-du-upgrade namespace: default spec: managedPolicies: - du-upgrade-platform-upgrade 1 - du-upgrade-operator-catsrc-policy 2 - common-subscriptions-policy 3 preCaching: true clusterSelector: - group-du-sno remediationStrategy: maxConcurrency: 1 enable: false
运行以下命令,将
cgu-platform-operator-upgrade.yml
文件应用到 hub 集群:$ oc apply -f cgu-platform-operator-upgrade.yml
可选:为平台和 Operator 更新缓存镜像。
运行以下命令,在
ClusterGroupUpgrade
CR 中启用预缓存:$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-du-upgrade \ --patch '{"spec":{"preCaching": true}}' --type=merge
监控更新过程,并等待预缓存完成。在受管集群中运行以下命令来检查预缓存的状态:
$ oc get jobs,pods -n openshift-talm-pre-cache
运行以下命令,检查预缓存是否在启动更新前完成:
$ oc get cgu cgu-du-upgrade -ojsonpath='{.status.conditions}'
启动平台和 Operator 更新。
运行以下命令,启用
cgu-du-upgrade
ClusterGroupUpgrade
CR 来启动平台和 Operator 更新:$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-du-upgrade \ --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge
监控进程。在完成后,运行以下命令来确保策略兼容:
$ oc get policies --all-namespaces
注意可通过将设置配置为
spec.enable: true
,从开始创建平台和 Operator 更新 CR。在这种情况下,更新会在预缓存完成后立即启动,且不需要手动启用 CR。预缓存和更新都创建额外的资源,如策略、放置规则、放置规则、受管集群操作和受管集群视图,以帮助完成这个过程。将
afterCompletion.deleteObjects
字段设置为true
在更新完成后删除所有这些资源。
12.1.5. 从部署的集群中删除 Performance Addon Operator 订阅
在早期版本的 OpenShift Container Platform 中,Performance Addon Operator 为应用程序提供了自动、低延迟的性能调整。在 OpenShift Container Platform 4.11 或更高版本中,这些功能是 Node Tuning Operator 的一部分。
不要在运行 OpenShift Container Platform 4.11 或更高版本的集群中安装 Performance Addon Operator。如果您升级到 OpenShift Container Platform 4.11 或更高版本,Node Tuning Operator 会自动删除 Performance Addon Operator。
您需要删除创建 Performance Addon Operator 订阅的任何策略,以防止重新安装 Operator。
参考 DU 配置集在 PolicyGenTemplate
CR common-ranGen.yaml
中包含 Performance Addon Operator。要从部署的受管集群中删除订阅,您必须更新 common-ranGen.yaml
。
如果在 OpenShift Container Platform 4.11 或更高版本上安装 Performance Addon Operator 4.10.3-5 或更高版本,Performance Addon Operator 会检测到集群版本并自动休眠,以避免与 Node Tuning Operator 正常工作。但是,为了确保获得最佳性能,请从 OpenShift Container Platform 4.11 集群中删除 Performance Addon Operator。
先决条件
- 创建一个 Git 存储库,在其中管理自定义站点配置数据。存储库必须可从 hub 集群访问,并定义为 Argo CD 的源存储库。
- 更新至 OpenShift Container Platform 4.11 或更高版本。
-
以具有
cluster-admin
特权的用户身份登录。
流程
在
common-ranGen.yaml
文件中,为 Performance Addon Operator 命名空间、Operator 组和订阅的complianceType
更改为mustnothave
。- fileName: PaoSubscriptionNS.yaml policyName: "subscriptions-policy" complianceType: mustnothave - fileName: PaoSubscriptionOperGroup.yaml policyName: "subscriptions-policy" complianceType: mustnothave - fileName: PaoSubscription.yaml policyName: "subscriptions-policy" complianceType: mustnothave
-
将更改与自定义站点存储库合并,并等待 ArgoCD 应用程序对 hub 集群同步更改。
common-subscriptions-policy
策略的状态更改为Non-Compliant
。 - 使用 Topology Aware Lifecycle Manager 将更改应用到您的目标集群。有关滚动配置更改的更多信息,请参阅“附加资源”部分。
监控进程。当目标集群的
common-subscriptions-policy
策略的状态为Compliant
时,Performance Addon Operator 已从集群中移除。运行以下命令,获取common-subscriptions-policy
的状态:$ oc get policy -n ztp-common common-subscriptions-policy
-
从
common-ranGen.yaml
文件中的.spec.sourceFiles
中删除 Performance Addon Operator 命名空间、Operator 组和订阅 CR。 - 将更改与自定义站点存储库合并,并等待 ArgoCD 应用程序对 hub 集群同步更改。策略保持合规。
12.1.6. 在单节点 OpenShift 集群中使用 TALM 预缓存用户指定的镜像
在升级应用程序前,您可以在单节点 OpenShift 集群上预缓存应用程序相关的工作负载镜像。
您可以使用以下自定义资源(CR)指定预缓存作业的配置选项:
-
PreCachingConfig
CR -
ClusterGroupUpgrade
CR
PreCachingConfig
CR 中的所有字段都是可选的。
PreCachingConfig CR 示例
apiVersion: ran.openshift.io/v1alpha1 kind: PreCachingConfig metadata: name: exampleconfig namespace: exampleconfig-ns spec: overrides: 1 platformImage: quay.io/openshift-release-dev/ocp-release@sha256:3d5800990dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47e2e1ef operatorsIndexes: - registry.example.com:5000/custom-redhat-operators:1.0.0 operatorsPackagesAndChannels: - local-storage-operator: stable - ptp-operator: stable - sriov-network-operator: stable spaceRequired: 30 Gi 2 excludePrecachePatterns: 3 - aws - vsphere additionalImages: 4 - quay.io/exampleconfig/application1@sha256:3d5800990dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47e2e1ef - quay.io/exampleconfig/application2@sha256:3d5800123dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47adfaef - quay.io/exampleconfig/applicationN@sha256:4fe1334adfafadsf987123adfffdaf1243340adfafdedga0991234afdadfsa09
带有 PreCachingConfig CR 引用的 ClusterGroupUpgrade CR 示例
apiVersion: ran.openshift.io/v1alpha1 kind: ClusterGroupUpgrade metadata: name: cgu spec: preCaching: true 1 preCachingConfigRef: name: exampleconfig 2 namespace: exampleconfig-ns 3
12.1.6.1. 为预缓存创建自定义资源
您必须在 ClusterGroupUpgrade
CR 之前或同时创建 PreCachingConfig
CR。
使用您要预缓存的额外镜像列表创建
PreCachingConfig
CR。apiVersion: ran.openshift.io/v1alpha1 kind: PreCachingConfig metadata: name: exampleconfig namespace: default 1 spec: [...] spaceRequired: 30Gi 2 additionalImages: - quay.io/exampleconfig/application1@sha256:3d5800990dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47e2e1ef - quay.io/exampleconfig/application2@sha256:3d5800123dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47adfaef - quay.io/exampleconfig/applicationN@sha256:4fe1334adfafadsf987123adfffdaf1243340adfafdedga0991234afdadfsa09
创建一个
ClusterGroupUpgrade
CR,并将preCaching
字段设置为true
并指定上一步中创建的PreCachingConfig
CR:apiVersion: ran.openshift.io/v1alpha1 kind: ClusterGroupUpgrade metadata: name: cgu namespace: default spec: clusters: - sno1 - sno2 preCaching: true preCachingConfigRef: - name: exampleconfig namespace: default managedPolicies: - du-upgrade-platform-upgrade - du-upgrade-operator-catsrc-policy - common-subscriptions-policy remediationStrategy: timeout: 240
警告在集群上安装镜像后,您无法更改或删除它们。
当您要启动预缓存镜像时,请运行以下命令应用
ClusterGroupUpgrade
CR:$ oc apply -f cgu.yaml
TALM 验证 ClusterGroupUpgrade
CR。
此时,您可以继续 TALM 预缓存工作流。
所有站点都同时预缓存。
验证
运行以下命令,检查应用
ClusterUpgradeGroup
CR 的 hub 集群上的预缓存状态:$ oc get cgu <cgu_name> -n <cgu_namespace> -oyaml
输出示例
precaching: spec: platformImage: quay.io/openshift-release-dev/ocp-release@sha256:3d5800990dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47e2e1ef operatorsIndexes: - registry.example.com:5000/custom-redhat-operators:1.0.0 operatorsPackagesAndChannels: - local-storage-operator: stable - ptp-operator: stable - sriov-network-operator: stable excludePrecachePatterns: - aws - vsphere additionalImages: - quay.io/exampleconfig/application1@sha256:3d5800990dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47e2e1ef - quay.io/exampleconfig/application2@sha256:3d5800123dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47adfaef - quay.io/exampleconfig/applicationN@sha256:4fe1334adfafadsf987123adfffdaf1243340adfafdedga0991234afdadfsa09 spaceRequired: "30" status: sno1: Starting sno2: Starting
通过检查受管策略是否存在预缓存配置来验证预缓存配置。
ClusterGroupUpgrade
和PreCachingConfig
CR 的有效配置会导致以下状态:有效 CR 的输出示例
- lastTransitionTime: "2023-01-01T00:00:01Z" message: All selected clusters are valid reason: ClusterSelectionCompleted status: "True" type: ClusterSelected - lastTransitionTime: "2023-01-01T00:00:02Z" message: Completed validation reason: ValidationCompleted status: "True" type: Validated - lastTransitionTime: "2023-01-01T00:00:03Z" message: Precaching spec is valid and consistent reason: PrecacheSpecIsWellFormed status: "True" type: PrecacheSpecValid - lastTransitionTime: "2023-01-01T00:00:04Z" message: Precaching in progress for 1 clusters reason: InProgress status: "False" type: PrecachingSucceeded
无效的 PreCachingConfig CR 示例
Type: "PrecacheSpecValid" Status: False, Reason: "PrecacheSpecIncomplete" Message: "Precaching spec is incomplete: failed to get PreCachingConfig resource due to PreCachingConfig.ran.openshift.io "<pre-caching_cr_name>" not found"
您可以在受管集群中运行以下命令来查找预缓存作业:
$ oc get jobs -n openshift-talo-pre-cache
预缓存作业正在进行的示例
NAME COMPLETIONS DURATION AGE pre-cache 0/1 1s 1s
您可以运行以下命令来检查为预缓存作业创建的 pod 状态:
$ oc describe pod pre-cache -n openshift-talo-pre-cache
预缓存作业正在进行的示例
Type Reason Age From Message Normal SuccesfulCreate 19s job-controller Created pod: pre-cache-abcd1
您可以运行以下命令来获取作业状态的实时更新:
$ oc logs -f pre-cache-abcd1 -n openshift-talo-pre-cache
要验证预缓存作业是否已成功完成,请运行以下命令:
$ oc describe pod pre-cache -n openshift-talo-pre-cache
完成的预缓存作业示例
Type Reason Age From Message Normal SuccesfulCreate 5m19s job-controller Created pod: pre-cache-abcd1 Normal Completed 19s job-controller Job completed
要验证镜像是否在单节点 OpenShift 上成功预缓存,请执行以下操作:
以 debug 模式进入节点:
$ oc debug node/cnfdf00.example.lab
将 root 更改为
host
:$ chroot /host/
搜索所需的镜像:
$ sudo podman images | grep <operator_name>
其他资源
- 有关 TALM 预缓存工作流的更多信息,请参阅使用容器镜像预缓存功能。