aws-creds
gcp-credentials
如果您看到这些值之一,您的集群将使用 mint 或 passthrough 模式,并带有 root secret。
如果没有看到这些值,您的集群将以 mint 模式使用 CCO,并删除 root secret。
只使用手动模式的 AWS 或 GCP 集群 :要确定集群是否被配置为从集群外创建和管理云凭证,您必须检查 cluster
Authentication
对象 YAML 值。
导航至
Administration
→
Cluster Settings
。
在
Cluster Settings
页面中,选择
Configuration
选项卡。
在
Configuration resource
下,选择
Authentication
。
在
Authentication details
页面中,选择
YAML
选项卡。
在 YAML 块中,检查
.spec.serviceAccountIssuer
参数的值。
包含与云供应商关联的 URL 的值表示 CCO 在 AWS STS 或 GCP Workload Identity 中使用手动模式从集群外部创建和管理云凭证。这些集群使用
ccoctl
工具进行配置。
空值 (
''
) 表示集群在手动模式中使用 CCO,但没有使用
ccoctl
工具进行配置。
如果您要更新以 mint 或 passthrough 模式运行的 CCO 的集群,且存在 root secret,则不需要更新任何云供应商资源,并可以继续进入更新过程的下一部分。
如果您的集群在 mint 模式中使用删除了 root secret 的 CCO,则必须重新使用管理员级别的凭证重新恢复凭证 secret,然后才能继续更新过程的下一部分。
如果您的集群使用 CCO 实用程序 (
ccoctl
) 配置,您必须执行以下操作:
为新版本配置
ccoctl
工具,并使用它来更新云供应商资源。
更新
upgradeable-to
注解,以指示集群已准备好更新。
如果您的集群以手动模式使用 CCO,但没有使用
ccoctl
工具配置,则必须执行以下操作:
为新版本手动更新云供应商资源。
更新
upgradeable-to
注解,以指示集群已准备好更新。
为集群更新配置 Cloud Credential Operator 工具
使用手动维护的凭证更新云供应商资源
6.1.3. 使用 CLI 确定 Cloud Credential Operator 模式
您可以使用 CLI 确定 Cloud Credential Operator (CCO) 配置为使用哪种模式。
只有 Amazon Web Services (AWS)、全局 Microsoft Azure 和 Google Cloud Platform (GCP) 集群支持多个 CCO 模式。
您可以使用集群管理员权限访问 OpenShift Container Platform 帐户。
已安装 OpenShift CLI(
oc
)。
以具有
cluster-admin
角色的用户身份登录到集群中的
oc
。
要确定 CCO 被配置为使用的模式,请输入以下命令:
$ oc get cloudcredentials cluster \
-o=jsonpath={.spec.credentialsMode}
以下输出值可能,但并非所有平台上都不支持所有值:
''
:CCO 在默认模式下运行。在这个配置中,CCO 以 mint 或 passthrough 模式运行,具体取决于安装期间提供的凭证。
Mint
:CCO 在 mint 模式中运行。
Passthrough
:CCO 在 passthrough 模式运行。
Manual
:CCO 以手动模式运行。
要确定 AWS 或 GCP 集群的特定配置,其
spec.credentialsMode
为
''
,
Mint
, 或
Manual
,您必须进一步调查。
AWS 和 GCP 集群支持使用删除了 root secret 的 mint 模式。如果集群被特别配置为使用 mint 模式或默认使用 mint 模式,则必须在更新前确定集群中是否存在 root secret。
使用手动模式的 AWS 或 GCP 集群可能会被配置为使用 AWS 安全令牌服务 (STS) 或 GCP Workload Identity 从集群外部创建和管理云凭证。您可以通过检查集群
Authentication
对象来确定集群是否使用了此策略。
仅使用 mint 模式的 AWS 或 GCP 集群:要确定集群是否在没有 root secret 的情况下运行,请运行以下命令:
$ oc get secret <secret_name> \
-n=kube-system
其中
<secret_name>
是 AWS 的
aws-creds
或 GCP 的
gcp-credentials
。
如果存在 root secret,这个命令的输出会返回有关 secret 的信息。错误表示集群中不存在 root secret。
仅使用手动模式的 AWS 或 GCP 集群 :要确定集群是否被配置为从集群外部创建和管理云凭证,请运行以下命令:
$ oc get authentication cluster \
-o jsonpath \
--template='{ .spec.serviceAccountIssuer }'
此命令显示集群
Authentication
对象中
.spec.serviceAccountIssuer
参数的值。
包含与云供应商关联的 URL 的输出表示 CCO 在 AWS STS 或 GCP Workload Identity 中使用手动模式从集群外部创建和管理云凭证。这些集群使用
ccoctl
工具进行配置。
空输出表示集群以手动模式使用 CCO,但没有使用
ccoctl
工具进行配置。
如果您要更新以 mint 或 passthrough 模式运行的 CCO 的集群,且存在 root secret,则不需要更新任何云供应商资源,并可以继续进入更新过程的下一部分。
如果您的集群在 mint 模式中使用删除了 root secret 的 CCO,则必须重新使用管理员级别的凭证重新恢复凭证 secret,然后才能继续更新过程的下一部分。
如果您的集群使用 CCO 实用程序 (
ccoctl
) 配置,您必须执行以下操作:
为新版本配置
ccoctl
工具,并使用它来更新云供应商资源。
更新
upgradeable-to
注解,以指示集群已准备好更新。
如果您的集群以手动模式使用 CCO,但没有使用
ccoctl
工具配置,则必须执行以下操作:
为新版本手动更新云供应商资源。
更新
upgradeable-to
注解,以指示集群已准备好更新。
为集群更新配置 Cloud Credential Operator 工具
使用手动维护的凭证更新云供应商资源
6.2. 为集群更新配置 Cloud Credential Operator 工具
要升级以手动模式使用 Cloud Credential Operator (CCO) 从集群外部创建和管理云凭证集群,提取并准备 CCO 实用程序 (
ccoctl
) 二进制文件。
ccoctl
工具是在 Linux 环境中运行的 Linux 二进制文件。
您可以访问具有集群管理员权限的 OpenShift Container Platform 帐户。
已安装 OpenShift CLI(
oc
)。
集群被配置为使用
ccoctl
实用程序从集群外创建和管理云凭证。
运行以下命令来获取 OpenShift Container Platform 发行镜像:
$ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')
运行以下命令,从 OpenShift Container Platform 发行镜像获取 CCO 容器镜像:
$ CCO_IMAGE=$(oc adm release info --image-for='cloud-credential-operator' $RELEASE_IMAGE -a ~/.pull-secret)
确保
$RELEASE_IMAGE
的架构与将使用
ccoctl
工具的环境架构相匹配。
运行以下命令,将 CCO 容器镜像中的
ccoctl
二进制文件提取到 OpenShift Container Platform 发行镜像中:
$ oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret
运行以下命令更改权限以使
ccoctl
可执行:
$ chmod 775 ccoctl
6.3. 使用 Cloud Credential Operator 工具更新云供应商资源
升级使用 CCO 实用程序 (
ccoctl
) 配置的 OpenShift Container Platform 集群的过程与在安装过程中创建云供应商资源类似。
默认情况下,
ccoctl
在运行命令的目录中创建对象。要在其他目录中创建对象,请使用
--output-dir
标志。此流程使用
<path_to_ccoctl_output_dir>
来引用这个目录。
在 AWS 集群中,一些
ccoctl
命令会发出 AWS API 调用来创建或修改 AWS 资源。您可以使用
--dry-run
标志来避免 API 调用。使用此标志可在本地文件系统中创建 JSON 文件。您可以使用
--cli-input-json
参数查看和修改 JSON 文件,然后使用 AWS CLI 工具应用它们。
获取您要升级到的版本的 OpenShift Container Platform 发行镜像。
从发行镜像中提取并准备
ccoctl
二进制文件。
运行以下命令,从 OpenShift Container Platform 发行镜像中提取
CredentialsRequest
自定义资源 (CR) 列表:
$ oc adm release extract --credentials-requests \
--cloud=<provider_type> \
--to=<path_to_directory_with_list_of_credentials_requests>/credrequests \
quay.io/<path_to>/ocp-release:<version>
<provider_type>
是云供应商的值。有效值为
alibabacloud
、
aws
、
gcp
、
ibmcloud
和
nutanix
。
credrequests
是存储
CredentialsRequest
对象列表的目录。如果该目录不存在,此命令就会创建该目录。
对于发行镜像中的每个
CredentialsRequest
CR,请确保集群中存在与
spec.secretRef.namespace
字段中的文本匹配的命名空间。此字段是保存凭证配置的生成的 secret 的位置。
在使用手动维护凭证升级集群前,您必须为要升级到的发行镜像创建新凭证。您还必须查看现有凭证所需的权限,并满足这些组件的新版本中任何新权限要求。
提取并检查
新版本的 CredentialsRequest
自定义资源。
详情请参阅您的云供应商的“手动创建 IAM”部分来了解如何获取和使用您的云所需的凭证。
更新集群中手动维护的凭证:
为新发行镜像添加的任何
CredentialsRequest
自定义资源创建新 secret。
如果存储在 secret 中的任何现有凭证的
CredentialsRequest
自定义资源更改了其权限要求,请根据需要更新权限。
更新
upgradeable-to
注解,以指示集群已准备好升级。
为 AWS 手动创建 IAM
为 Azure 手动创建 IAM
为 Azure Stack Hub 手动创建 IAM
为 GCP 手动创建 IAM
表示集群已准备好升级
默认情况下,带有手动维护凭证的集群的 Cloud Credential Operator(CCO)U
gradable
状态为 False
。
对于您要升级到的发行镜像,您可以手动处理任何新凭证,或使用 Cloud Credential Operator 实用程序 (
ccoctl
) 处理。
已安装 OpenShift CLI(
oc
)。
以具有
cluster-admin
角色的用户身份登录到集群中的
oc
。
运行以下命令,编辑
CloudCredential
资源,以在
metadata
字段中添加
upgradeable-to
注解:
$ oc edit cloudcredential cluster
您可以使用 web 控制台对 OpenShift Container Platform 集群进行更新或升级。以下步骤在次版本中更新集群。您可以使用相同的说明在次版本之间更新集群。
使用 Web 控制台或
oc adm upgrade channel
<channel>
更改更新频道。在改到一个 4.11 频道后,按
使用 CLI 更新集群
中的步骤完成更新。
-
使用具有
admin
权限的用户访问集群。请参阅
使用 RBAC 定义和应用权限
。
具有最新的
etcd 备份
,以防因为升级失败需要
将集群恢复到以前的状态
。
OpenShift Container Platform 4.11 删除了对 RHEL7 worker 的支持。升级到 OpenShift Container Platform 4.11 之前,您必须将 RHEL7 worker 替换为 RHEL8 或 RHCOS worker。红帽不支持对 RHEL worker 的 从 RHEL7 到 RHEL8 的原位升级 ; 这些主机必须使用干净的操作系统安装替换。
确保之前通过 Operator Lifecycle Manager(OLM)安装的所有 Operator 均更新至其最新频道中的最新版本。更新 Operator 可确保当默认 OperatorHub 目录在集群升级过程中从当前次要版本切换到下一个次版本时,它们有有效的升级路径。如需更多信息,请参阅
更新安装的 Operator
。
确保所有机器配置池 (MCP) 都正在运行且未暂停。在更新过程中跳过与暂停 MCP 关联的节点。如果要执行 canary rollout 更新策略,可以暂停 MCP。
要容纳更新所需的时间,您可以通过更新 worker 或自定义池节点来进行部分更新。您可以在每个池的进度栏中暂停并恢复。
如果您的集群使用手动维护的凭证,请更新新发行版本的云供应商资源。如需更多信息,包括如何确定这是集群的要求,请参阅
准备使用手动维护的凭证更新集群
。
如果您运行 Operator 或您已配置了 pod 中断预算,您可能会在升级过程中遇到中断。如果在
PodDisruptionBudget
中将
minAvailable
设置为 1,则节点会排空以应用可能会阻止驱除过程的待处理机器配置。如果重启了几个节点,则所有 pod 只能有一个节点上运行,
PodDisruptionBudget
字段可能会阻止节点排空。
当更新无法完成时,Cluster Version Operator(CVO)会在尝试协调更新时报告任何阻塞组件的状态。当前还不支持将集群还原到以前的版本。如果您的更新无法完成,请联系红帽支持。
使用
unsupportedConfigOverrides
部分修改 Operator 配置不受支持,并可能会阻止集群更新。您必须在更新集群前删除此设置。
非受管 Operator 的支持策略
7.2. 执行 canary rollout 更新
在某些情况下,您可能需要一个受控的更新过程,如您不希望特定节点与集群的其余部分同时更新。这些用例包括但不限于:
您有任务关键型应用程序,您希望在更新过程中仍然可以使用这些应用程序。在更新后,您可以慢慢地以小批的形式对应用进行测试。
您有一个短的维护窗口,在此期间不允许更新所有节点;或者您有多个维护窗口。
滚动更新过程
不是
典型的更新工作流。对于较大的集群,这可能是一个耗时的过程,需要您执行多个命令。这种复杂性可能会导致出现可能会影响整个集群的错误。建议您仔细考虑您的机构是否希望使用滚动更新,并在开始前仔细规划流程的实施。
本主题中描述的滚动更新过程涉及:
创建一个或多个自定义机器配置池 (MCP)。
标记您不想立即更新的每个节点,以将这些节点移至自定义 MCP。
暂停这些自定义 MCP,这会阻止对这些节点的更新。
执行集群更新。
取消暂停一个自定义 MCP,它会在这些节点上触发更新。
测试这些节点上的应用程序,以确保应用程序在这些新更新的节点上可以正常工作。
(可选)从小批处理中的其余节点移除自定义标签,并在这些节点上测试应用。
暂停 MCP 可防止 Machine Config Operator 在关联的节点上应用任何配置更改。暂停 MCP 还可以防止任何自动轮转的证书被推送到关联的节点,包括自动轮转
kube-apiserver-to-kubelet-signer
CA 证书。
如果
kube-apiserver-to-kubelet-signer
CA 证书过期且 MCO 尝试自动更新证书时,MCP 会暂停,但不会在相应机器配置池中的节点中应用新证书。这会导致多个
oc
命令失败,包括
oc debug
、
oc logs
、
oc exec
和
oc attach
。如果在轮转证书时,如果 MCP 被暂停,则 OpenShift Container Platform Web 控制台的 Alerting UI 中收到警报。
在暂停 MCP 时应该非常小心,需要仔细考虑
kube-apiserver-to-kubelet-signer
CA 证书过期的问题,且仅在短时间内暂停。
如果要使用 Canary rollout 更新过程,请参阅
执行 Canary 推出部署更新
。
7.3. 使用 Web 控制台暂停 MachineHealthCheck 资源
在升级过程中,集群中的节点可能会临时不可用。对于 worker 节点,机器健康检查可能会认为这样的节点不健康,并重新引导它们。为避免重新引导这样的节点,请在更新集群前暂停所有
MachineHealthCheck
资源。
您可以使用
cluster-admin
权限访问集群。
访问 OpenShift Container Platform web 控制台。
登陆到 OpenShift Container Platform Web 控制台。
进入到
Compute
→
MachineHealthChecks
。
要暂停机器健康检查,请在每个
MachineHealthCheck
资源中添加
cluster.x-k8s.io/paused=""
注解。例如,要将注解添加到
machine-api-termination-handler
资源,请完成以下步骤:
点
machine-api-termination-handler
旁边的 Options 菜单
并点
Edit annotations
。
在
Edit annotations
对话框中,点
Add more
。
在
Key
和
Value
字段中,分别添加
cluster.x-k8s.io/paused
和
""
值,然后点
Save
。
7.4. 关于更新单个节点 OpenShift Container Platform
您可以使用控制台或 CLI 更新或升级单节点 OpenShift Container Platform 集群。
但请注意以下限制:
不需要暂停
MachineHealthCheck
资源,因为没有其他节点可以执行健康检查。
不支持使用 etcd 备份来恢复单节点 OpenShift Container Platform 集群。但是,最好在升级失败时执行 etcd 备份。如果 control plane 健康,您可以使用备份将集群恢复到以前的状态。
更新单节点 OpenShift Container Platform 集群需要停机,并可包括自动重启。停机时间取决于更新有效负载,如下例所示:
如果更新有效负载包含操作系统更新(需要重启),则停机时间会非常显著,并影响集群管理和用户工作负载。
如果更新包含不需要重启的机器配置更改,则停机时间会减少,并且对集群管理和用户工作负载的影响会减少。在这种情况下,节点排空步骤会通过单节点 OpenShift Container Platform 跳过,因为集群中没有其他节点可以重新调度工作负载。
如果更新有效负载不包含操作系统更新或机器配置更改,则会出现简短的 API 中断并快速解决。
某些条件(如更新的软件包中的错误)可能会导致单个节点在重启后无法重启。在这种情况下,更新不会自动回滚。
有关机器配置更改需要重启的详情,请参考
了解 Machine Config Operator
的备注。
如果有可用更新,您可以从Web控制台更新集群。
您可以在客户门户网站的
勘误部分
找到有关可用 OpenShift Container Platform 公告和更新的信息。
使用具有
admin
权限的用户登陆到 web 控制台。
暂停所有
MachineHealthCheck
资源。
在 web 控制台中点击
Administration
→
Cluster Settings
并查看
Details
选项卡中的内容。
对于生产环境中的集群,请确保将
Channel
设置为您要升级到的版本的正确频道,如
stable-4.11
。
对于生产环境中的集群,您必须订阅一个
stable-*
,
eus-*
或
fast-*
频道。
当您准备好升级到下一个次版本时,请选择与该次版本对应的频道。声明更新频道后,集群可以更方便地为您的目标版本更新路径。集群可能需要一些时间来评估所有可用的更新,并提供最佳更新建议。更新建议可能会随时间变化,因为它们基于哪些更新选项。
如果您无法看到到目标次版本的更新路径,请保持将集群更新至当前版本的最新补丁版本,直到下一个次版本在路径中可用。
如果
Update 状态
不是
Updates available
,则无法升级集群。
Select channel
表示集群正在运行或正在更新的集群版本。
选择要更新到的版本,然后单击
Save
。
输入频道
Update Status
变为
Update to <product-version> in progress
,您可以通过监视 Operator 和节点的进度条来查看集群更新的进度。
如果您要将集群升级到下一个次版本,如从 4.y 升级到 4.(y+1),建议在部署依赖新功能的工作负载前确认您的节点已升级。任何尚未更新的 worker 节点池都会显示在
Cluster Settings
页面。
更新完成后,Cluster Version Operator 会刷新可用更新,检查当前频道中是否有更多可用更新。
如果有可用更新,请继续在当前频道中执行更新,直到您无法再更新为止。
如果没有可用的更新,请将
Channel
改为下一个次版本的
stable-*
,
eus-*
或
fast-*
频道,并更新至您在该频道中想要的版本。
您可能需要执行一些过渡的更新,直到您到达您想要的版本。
更改更新服务器是可选的。如果您在本地安装和配置了 OpenShift Update Service (OSUS),您必须将服务器的 URL 设置为
upstream
,以便在更新期间使用本地服务器。
导航到
Administration
→
Cluster Settings
,点
version
。
点击
YAML
选项卡,然后编辑
upstream
参数值:
spec:
clusterID: db93436d-7b05-42cc-b856-43e11ad2d31a
upstream: '<update-server-url>'
1
<update-server-url>
变量指定更新服务器的 URL。
默认
upstream
是
https://api.openshift.com/api/upgrades_info/v1/graph
。
点击
Save
。
了解更新频道和发行版本
您可以使用 OpenShift CLI (
oc
) 将 OpenShift Container Platform 集群更新或升级到一个次版本。您还可以按照相同的说明在次版本间更新集群。
-
使用具有
admin
权限的用户访问集群。请参阅
使用 RBAC 定义和应用权限
。
具有最新的
etcd 备份
,以防因为升级失败需要
将集群恢复到以前的状态
。
OpenShift Container Platform 4.11 删除了对 RHEL7 worker 的支持。升级到 OpenShift Container Platform 4.11 之前,您必须将 RHEL7 worker 替换为 RHEL8 或 RHCOS worker。红帽不支持对 RHEL worker 的 从 RHEL7 到 RHEL8 的原位升级 ; 这些主机必须使用干净的操作系统安装替换。
确保之前通过 Operator Lifecycle Manager(OLM)安装的所有 Operator 均更新至其最新频道中的最新版本。更新 Operator 可确保当默认 OperatorHub 目录在集群升级过程中从当前次要版本切换到下一个次版本时,它们有有效的升级路径。如需更多信息,请参阅
更新安装的 Operator
。
确保所有机器配置池 (MCP) 都正在运行且未暂停。在更新过程中跳过与暂停 MCP 关联的节点。如果要执行 canary rollout 更新策略,可以暂停 MCP。
如果您的集群使用手动维护的凭证,请更新新发行版本的云供应商资源。如需更多信息,包括如何确定这是集群的要求,请参阅
准备使用手动维护的凭证更新集群
。
确保解决所有
Upgradeable=False
条件,以便集群可以更新到下一个次版本。当您有一个或多个无法升级的集群 Operator 时,
Cluster Settings
页面的顶部会显示一个警报。您仍然可以更新到当前当前使用的次发行版本的下一个可用补丁更新。
如果您运行 Operator 或您已配置了 pod 中断预算,您可能会在升级过程中遇到中断。如果在
PodDisruptionBudget
中将
minAvailable
设置为 1,则节点会排空以应用可能会阻止驱除过程的待处理机器配置。如果重启了几个节点,则所有 pod 只能有一个节点上运行,
PodDisruptionBudget
字段可能会阻止节点排空。
当更新无法完成时,Cluster Version Operator(CVO)会在尝试协调更新时报告任何阻塞组件的状态。当前还不支持将集群还原到以前的版本。如果您的更新无法完成,请联系红帽支持。
使用
unsupportedConfigOverrides
部分修改 Operator 配置不受支持,并可能会阻止集群更新。您必须在更新集群前删除此设置。
非受管 Operator 的支持策略
8.2. 暂停 MachineHealthCheck 资源
在升级过程中,集群中的节点可能会临时不可用。对于 worker 节点,机器健康检查可能会认为这样的节点不健康,并重新引导它们。为避免重新引导这样的节点,请在更新集群前暂停所有
MachineHealthCheck
资源。
安装 OpenShift CLI (
oc
) 。
要列出您要暂停的所有可用
MachineHealthCheck
资源,请运行以下命令:
$ oc get machinehealthcheck -n openshift-machine-api
要暂停机器健康检查,请将
cluster.x-k8s.io/paused=""
注解添加到
MachineHealthCheck
资源。运行以下命令:
$ oc -n openshift-machine-api annotate mhc <mhc-name> cluster.x-k8s.io/paused=""
注解的
MachineHealthCheck
资源类似以下 YAML 文件:
apiVersion: machine.openshift.io/v1beta1
kind: MachineHealthCheck
metadata:
name: example
namespace: openshift-machine-api
annotations:
cluster.x-k8s.io/paused: ""
spec:
selector:
matchLabels:
role: worker
unhealthyConditions:
- type: "Ready"
status: "Unknown"
timeout: "300s"
- type: "Ready"
status: "False"
timeout: "300s"
maxUnhealthy: "40%"
status:
currentHealthy: 5
expectedMachines: 5
更新集群后恢复机器健康检查。要恢复检查,请运行以下命令从
MachineHealthCheck
资源中删除暂停注解:
$ oc -n openshift-machine-api annotate mhc <mhc-name> cluster.x-k8s.io/paused-
8.3. 关于更新单个节点 OpenShift Container Platform
您可以使用控制台或 CLI 更新或升级单节点 OpenShift Container Platform 集群。
但请注意以下限制:
不需要暂停
MachineHealthCheck
资源,因为没有其他节点可以执行健康检查。
不支持使用 etcd 备份来恢复单节点 OpenShift Container Platform 集群。但是,最好在升级失败时执行 etcd 备份。如果 control plane 健康,您可以使用备份将集群恢复到以前的状态。
更新单节点 OpenShift Container Platform 集群需要停机,并可包括自动重启。停机时间取决于更新有效负载,如下例所示:
如果更新有效负载包含操作系统更新(需要重启),则停机时间会非常显著,并影响集群管理和用户工作负载。
如果更新包含不需要重启的机器配置更改,则停机时间会减少,并且对集群管理和用户工作负载的影响会减少。在这种情况下,节点排空步骤会通过单节点 OpenShift Container Platform 跳过,因为集群中没有其他节点可以重新调度工作负载。
如果更新有效负载不包含操作系统更新或机器配置更改,则会出现简短的 API 中断并快速解决。
某些条件(如更新的软件包中的错误)可能会导致单个节点在重启后无法重启。在这种情况下,更新不会自动回滚。
有关机器配置更改需要重启的详情,请参考
了解 Machine Config Operator
的备注。
您可以使用 OpenShift CLI (
oc
) 来检查和请求集群更新。
您可以在客户门户网站的
勘误部分
找到有关可用 OpenShift Container Platform 公告和更新的信息。
安装与更新版本的版本匹配的 OpenShift CLI(
oc
)。
使用具有
cluster-admin
权限的用户登陆到集群。
暂停所有
MachineHealthCheck
资源。
查看可用更新,记录下要应用的更新的版本号:
$ oc adm upgrade
您可以使用 Web 控制台或 OpenShift CLI(
oc
)根据一个有条件的升级路径进行升级。当一个有条件更新对于您的集群不推荐进行时,您可以使用 OpenShift CLI(
oc
)4.10 或更高版本来根据一个有条件的路径进行升级。
因为存在风险而不推荐的更新,您可以使用以下命令查看它的描述信息:
$ oc adm upgrade --include-not-recommended
如果集群管理员已评估了潜在的已知风险,并确定这些风险对于当前集群是可接受的,管理员可以执行以下命令来忽略这些安全保护并继续更新:
$ oc adm upgrade --allow-not-recommended --to <version> <.>
<.>
<version>
是从上一个命令输出中获取的被支持但不推荐的更新版本。
了解更新频道和发行版本
更改更新服务器是可选的。如果您在本地安装和配置了 OpenShift Update Service (OSUS),您必须将服务器的 URL 设置为
upstream
,以便在更新期间使用本地服务器。
upstream
的默认值是
https://api.openshift.com/api/upgrades_info/v1/graph
。
更改集群版本中的
upstream
参数值:
$ oc patch clusterversion/version --patch '{"spec":{"upstream":"<update-server-url>"}}' --type=merge
<update-server-url>
变量指定更新服务器的 URL。
clusterversion.config.openshift.io/version patched
第 9 章 执行 canary rollout 更新
有些情况下,您可能希望对 worker 节点进行更多受控的更新推出,以确保任务关键型应用程序在更新过程中仍然可用,即使更新过程导致您的应用程序失败。根据您的机构需求,您可能需要更新一小部分 worker 节点,在一个时间段内评估集群和工作负载健康状况,然后更新剩余的节点。这通常被称为
Canary
更新。或者,您可能还希望将通常需要主机重新引导的 worker 节点更新放入较小的定义的维护窗口(不可能一次使用大型维护窗口来更新整个集群)。
在这些情况下,您可以创建多个自定义机器配置池 (MCP),以防止某些 worker 节点在更新集群时进行更新。在更新剩余的集群后,您可以在适当的时间批量更新这些 worker 节点。
例如,如果您的集群有 100 个节点,且有 10% 过量的容量,维护窗口不能超过 4 小时,并且您知道排空和重新引导 worker 节点的时间不超过 8 分钟,您可以利用 MCP 来实现您的目标。例如,您可以定义四个 MCP,分别名为
workerpool-canary
、
workerpool-A
、
workerpool-B
和
workerpool-C
,分别有 10、30、30 和 30 个节点。
在第一次维护窗口中,您将暂停
workerpool-A
、
workerpool-B
和
workerpool-C
的 MCP,然后启动集群更新。这会更新在 OpenShift Container Platform 上运行的组件,以及属于
workerpool-canary MCP
成员的 10 个节点,因为这个池没有暂停。其他三个 MCP 不会更新,因为它们已暂停。如果出于某种原因,您确定集群或工作负载健康受到
workerpool-canary
更新的负面影响,那么在分析完问题前,您会在保持足够容量的同时,对那个池中的所有节点进行 cordon 和 drain 操作。当一切正常时,您将在决定取消暂停前评估集群和工作负载健康状况,从而在每个额外的维护窗口中持续更新
workerpool-A
、
workerpool-B
和
workerpool-C
。
使用自定义 MCP 管理 worker 节点更新提供了灵活性,这可能是一个耗时的过程,需要您执行多个命令。这种复杂性可能会导致出现可能会影响整个集群的错误。建议您仔细考虑您的组织需求,并在开始之前仔细规划流程的实施。
不建议将 MCP 更新至不同的 OpenShift Container Platform 版本。例如,请勿将一个 MCP 从 4.y.10 更新至 4.y.11,另一个更新为 4.y.12。这个场景还没有被测试,可能会导致未定义的集群状态。
暂停机器配置池可防止 Machine Config Operator 在关联的节点上应用任何配置更改。暂停 MCP 还可以防止任何自动轮转的证书被推送到关联的节点,包括自动轮转
kube-apiserver-to-kubelet-signer
CA 证书。
当
kube-apiserver-to-kubelet-signer
CA 证书过期且 MCO 尝试自动更新证书时,MCO 无法将新轮转的证书推送到这些节点。这会导致多个
oc
命令失败,包括
oc debug
、
oc logs
、
oc exec
和
oc attach
。如果在轮转证书时,如果 MCP 被暂停,则 OpenShift Container Platform Web 控制台的 Alerting UI 中收到警报。
在暂停 MCP 时应该非常小心,需要仔细考虑
kube-apiserver-to-kubelet-signer
CA 证书过期的问题,且仅在短时间内暂停。
9.1. 关于 Canary rollout 更新过程和 MCP
在 OpenShift Container Platform 中,节点不会被单独考虑。节点分组到机器配置池中 (MCP)。默认 OpenShift Container Platform 集群中有两个 MCP:一个用于 control plane 节点,一个用于 worker 节点。OpenShift Container Platform 更新会同时影响所有 MCP。
在更新过程中,Machine Config Operator (MCO) 会排空并记录 MCP 中的所有节点,直至指定的
maxUnavailable
数量(如果指定),默认为
1
。排空节点取消调度节点上的所有 pod,并将该节点标记为不可调度。节点排空后,Machine Config Daemon 应用一个新的机器配置,其中包括更新操作系统 (OS)。更新操作系统需要主机重新引导。
要防止特定节点被更新,且不会排空、进行 cordoned 和更新,您可以创建自定义 MCP。然后,暂停这些 MCP,以确保不更新与这些 MCP 关联的节点。MCO 不会更新任何暂停的 MCP。您可以创建一个或多个自定义 MCP,这样可以让您更好地控制您更新这些节点的顺序。更新第一个 MCP 中的节点后,您可以验证应用兼容性,然后逐步将其余节点更新至新版本。
为确保 control plane 的稳定性,不支持从 control plane 节点创建自定义 MCP。Machine Config Operator (MCO) 会忽略为 control plane 节点创建的任何自定义 MCP。
根据工作负载部署拓扑,您应该仔细考虑您创建的 MCP 数以及每个 MCP 中的节点数量。例如,如果需要将更新融入特定的维护窗口,您需要知道 OpenShift Container Platform 可在窗口中更新的节点数量。这个数字取决于您具体的集群和工作负载特性。
另外,您需要考虑集群中可用的额外容量量。例如,当应用程序无法在更新的节点上按预期工作时,您可以对池中那些节点进行 cordon 和 drain 操作,这会将应用 pod 移到其他节点上。您需要考虑您可用的额外容量数量,以确定您需要的自定义 MCP 数量以及每个 MCP 中有多少节点。例如,如果您使用两个自定义 MCP 和 50% 的节点在每个池中,则需要确定运行 50% 的节点是否能为您的应用程序提供足够的服务质量(QoS)。
您可以将这个更新过程与所有记录的 OpenShift Container Platform 更新过程一起使用。但是,该过程不适用于使用 Ansible playbook 进行更新的 Red Hat Enterprise Linux (RHEL) 机器。
9.2. 关于执行 canary rollout 更新
本主题描述了此 canary rollout 更新过程的一般工作流。以下小节介绍了工作流中执行每项任务的步骤。
根据 worker 池创建 MCP。每个 MCP 中的节点数量取决于几个因素,如每个 MCP 的维护窗口持续时间以及集群中可用的保留容量(即额外的 worker 节点)。
您可以更改 MCP 中的
maxUnavailable
设置,以指定在任意给定时间可以更新的机器的百分比或数量。默认值为 1。
将节点选择器添加到自定义 MCP。对于您不想与剩余的集群同时更新的每个节点,请向节点添加匹配的标签。该标签将节点与 MCP 相关联。
不要从节点中删除默认 worker 标签。节点
必须具有
role 标签才能在集群中正常工作。
在更新过程中暂停您不想更新的 MCP。
暂停 MCP 也会暂停
kube-apiserver-to-kubelet-signer
自动 CA 证书轮转。在自安装日期起的 292 天生成新 CA 证书,旧证书将从安装日期的 365 天后删除。请参
阅红帽 OpenShift 4 中的了解 CA 证书自动续订
,以了解您在下一次自动 CA 证书轮转前的时间。
确保发生 CA 证书轮转时取消暂停池。如果 MCP 暂停,MCO 无法将新轮转的证书推送到这些节点。这会导致集群降级,并在多个
oc
命令中造成失败,包括
oc debug
、
oc logs
、
oc exec
和
oc attach
。如果在轮转证书时,如果 MCP 被暂停,则 OpenShift Container Platform Web 控制台的 Alerting UI 中收到警报。
执行集群更新。更新过程更新没有暂停的 MCP,包括 control plane 节点。
在更新的节点上测试应用,以确保它们按预期工作。
逐一取消暂停剩余的 MCP,并在这些节点上测试应用程序,直到所有 worker 节点都已更新。取消暂停 MCP 会启动与该 MCP 关联的节点的更新过程。您可以通过点击
Administration
→
Cluster settings
从 web 控制台检查更新的进度。或者,使用
oc get machineconfigpools
CLI 命令。
(可选)从更新的节点中删除自定义标签并删除自定义 MCP。
9.3. 创建机器配置池来执行 canary rollout 更新
执行此 canary rollout 更新的第一个任务是创建一个或多个机器配置池 (MCP)。
从 worker 节点创建 MCP。
列出集群中的 worker 节点。
$ oc get -l 'node-role.kubernetes.io/master!=' -o 'jsonpath={range .items[*]}{.metadata.name}{"\n"}{end}' nodes
在这个 Canary rollout 更新过程中,在使用 OpenShift Container Platform 集群的其余集群标记了节点并创建机器配置池 (MCP) 后,您会暂停这些 MCP。暂停 MCP 可防止 Machine Config Operator (MCO) 更新与该 MCP 关联的节点。
暂停 MCP 也会暂停
kube-apiserver-to-kubelet-signer
自动 CA 证书轮转。在自安装日期起的 292 天生成新 CA 证书,旧证书将从安装日期的 365 天后删除。请参
阅红帽 OpenShift 4 中的了解 CA 证书自动续订
,以了解您在下一次自动 CA 证书轮转前的时间。
确保发生 CA 证书轮转时取消暂停池。如果 MCP 暂停,MCO 无法将新轮转的证书推送到这些节点。这会导致集群降级,并在多个
oc
命令中造成失败,包括
oc debug
、
oc logs
、
oc exec
和
oc attach
。如果在轮转证书时,如果 MCP 被暂停,则 OpenShift Container Platform Web 控制台的 Alerting UI 中收到警报。
暂停 MCP:
对您要暂停的 MCP 进行补丁:
$ oc patch mcp/<mcp_name> --patch '{"spec":{"paused":true}}' --type=merge
$ oc patch mcp/workerpool-canary --patch '{"spec":{"paused":true}}' --type=merge
在这个 Canary rollout 更新过程中,OpenShift Container Platform 更新完成后,取消逐一暂停自定义 MCP。取消暂停 MCP 允许 Machine Config Operator (MCO) 更新与该 MCP 关联的节点。
取消暂停 MCP:
对您要取消暂停的 MCP 进行补丁:
$ oc patch mcp/<mcp_name> --patch '{"spec":{"paused":false}}' --type=merge
$ oc patch mcp/workerpool-canary --patch '{"spec":{"paused":false}}' --type=merge
如果应用程序出现故障,如应用程序未在更新的节点上工作,您可以对池中的节点进行 cordon 和 drain 操作,这会将应用 pod 移到其他节点,以帮助维护应用程序的服务质量。第一个 MCP 不应大于过量容量。
在这个 Canary rollout 更新过程中,在取消暂停自定义机器配置池 (MCP) 并验证与该 MCP 关联的节点上的应用程序是否按预期工作后,您应该删除添加到节点的自定义标签,将节点移回原始 MCP。
节点必须具有角色才能在集群中正常工作。
将节点移动到其原始 MCP 中:
从节点移除自定义标签。
$ oc label node <node_name> node-role.kubernetes.io/<custom-label>-
$ oc label node ci-ln-0qv1yp2-f76d1-kl2tq-worker-a-j2ssz node-role.kubernetes.io/workerpool-canary-
第 10 章 更新包含使用 RHEL 的计算(compute)系统的集群
您可以更新或升级OpenShift Container Platform集群。如果您的集群包含Red Hat Enterprise Linux(RHEL)系统,则必须执行额外的步骤来更新这些系统。
-
使用具有
admin
权限的用户访问集群。请参阅
使用 RBAC 定义和应用权限
。
具有最新的
etcd 备份
,以防因为升级失败需要
将集群恢复到以前的状态
。
OpenShift Container Platform 4.11 删除了对 RHEL7 worker 的支持。升级到 OpenShift Container Platform 4.11 之前,您必须将 RHEL7 worker 替换为 RHEL8 或 RHCOS worker。红帽不支持对 RHEL worker 的 从 RHEL7 到 RHEL8 的原位升级 ; 这些主机必须使用干净的操作系统安装替换。
如果您的集群使用手动维护的凭证,请更新新发行版本的云供应商资源。如需更多信息,包括如何确定这是集群的要求,请参阅
准备使用手动维护的凭证更新集群
。
如果您运行 Operator 或您已配置了 pod 中断预算,您可能会在升级过程中遇到中断。如果在
PodDisruptionBudget
中将
minAvailable
设置为 1,则节点会排空以应用可能会阻止驱除过程的待处理机器配置。如果重启了几个节点,则所有 pod 只能有一个节点上运行,
PodDisruptionBudget
字段可能会阻止节点排空。
非受管 Operator 的支持策略
如果有可用更新,您可以从Web控制台更新集群。
您可以在客户门户网站的
勘误部分
找到有关可用 OpenShift Container Platform 公告和更新的信息。
使用具有
admin
权限的用户登陆到 web 控制台。
暂停所有
MachineHealthCheck
资源。
在 web 控制台中点击
Administration
→
Cluster Settings
并查看
Details
选项卡中的内容。
对于生产环境中的集群,请确保将
Channel
设置为您要升级到的版本的正确频道,如
stable-4.11
。
对于生产环境中的集群,您必须订阅一个
stable-*
,
eus-*
或
fast-*
频道。
当您准备好升级到下一个次版本时,请选择与该次版本对应的频道。声明更新频道后,集群可以更方便地为您的目标版本更新路径。集群可能需要一些时间来评估所有可用的更新,并提供最佳更新建议。更新建议可能会随时间变化,因为它们基于哪些更新选项。
如果您无法看到到目标次版本的更新路径,请保持将集群更新至当前版本的最新补丁版本,直到下一个次版本在路径中可用。
如果
Update 状态
不是
Updates available
,则无法升级集群。
Select channel
表示集群正在运行或正在更新的集群版本。
选择要更新到的版本,然后单击
Save
。
输入频道
Update Status
变为
Update to <product-version> in progress
,您可以通过监视 Operator 和节点的进度条来查看集群更新的进度。
如果您要将集群升级到下一个次版本,如从 4.y 升级到 4.(y+1),建议在部署依赖新功能的工作负载前确认您的节点已升级。任何尚未更新的 worker 节点池都会显示在
Cluster Settings
页面。
更新完成后,Cluster Version Operator 会刷新可用更新,检查当前频道中是否有更多可用更新。
如果有可用更新,请继续在当前频道中执行更新,直到您无法再更新为止。
如果没有可用的更新,请将
Channel
改为下一个次版本的
stable-*
,
eus-*
或
fast-*
频道,并更新至您在该频道中想要的版本。
您可能需要执行一些过渡的更新,直到您到达您想要的版本。
当您更新包含有 Red Hat Enterprise Linux (RHEL) worker 机器的集群时,这些 worker 会在更新过程中暂时不可用。当集群进入
NotReady
状态时,您需要针对每个 RHEL 机器运行升级 playbook 以完成更新。
10.3. 可选:添加 hook 以在RHEL系统上执行Ansible任务
在OpenShift Container Platform更新期间,您可以使用
hook
在RHEL计算系统上运行Ansible任务。
10.3.1. 在升级过程中使用 Ansible hook
更新OpenShift Container Platform时,可以使用
hook
在执行特定操作时在Red Hat Enterprise Linux(RHEL)节点上运行自定义的任务。您可以使用 hook 提供定义了在执行特定任务之前或之后要运行的任务的文件。在OpenShift Container Platform集群中更新RHEL计算节点时,可以使用 hook 来验证或修改自定义的基础架构。
因为当 hook 失败时,这个操作将会失败,所以您必须把 hook 设计为可以多次运行,并且获得相同的结果。
hook 有以下限制: - hook 没有已定义或版本化的界面。它们可以使用内部的
openshift-ansible
变量,但这些变量可能会在将来的OpenShift Container Platform版本被修改或删除。 - hook 本身没有错误处理机制,因此 hook 中的错误会暂停更新过程。如果出现错误,则需要解决相关的问题,然后再次进行升级。
10.3.2. 配置Ansible inventory文件以使用 hook
您可以在
hosts
inventory 文件的
all:vars
部分中定义 Red Hat Enterprise Linux(RHEL)compute 机器(也称为 worker 机器)更新时使用的 hook 。
您可以访问用于添加RHEL compute 系统集群的计算机。您必须有访问定义RHEL系统的
hosts
Ansible 清单文件的权限。
在设计了 hook 后,创建一个YAML文件,为其定义Ansible任务。此文件必须是一组任务,不能是一个 playbook,如以下示例所示:
# Trivial example forcing an operator to acknowledge the start of an upgrade
# file=/home/user/openshift-ansible/hooks/pre_compute.yml
- name: note the start of a compute machine update
debug:
msg: "Compute machine upgrade of {{ inventory_hostname }} is about to start"
- name: require the user agree to start an upgrade
pause:
prompt: "Press Enter to start the compute machine update"
修改
hosts
Ansible inventory 文件来指定 hook 文件。hook 文件作为参数值在
[all:vars]
部分指定。如下所示:
在更新OpenShift Container Platform集群中的Red Hat Enterprise Linux(RHEL)compute 系统时,可以使用以下 hook。
Hook 名
|
描述
|
openshift_node_pre_cordon_hook
在每个节点被封锁(cordon)
之前
运行。
此 hook 以串行方式针对
每个节点
运行。
如果某个任务必须针对其他主机运行,则该任务必须使用
delegate_to
或
local_action
。
openshift_node_pre_upgrade_hook
在每个节点被封锁
后
,且被更新
前
运行。
此 hook 以串行方式针对
每个节点
运行。
如果某个任务必须针对其他主机运行,则该任务必须使用
delegate_to
或
local_action
。
openshift_node_pre_uncordon_hook
在每个节点被更新
后
,且被取消封锁(uncordon)
前
运行。
此 hook 以串行方式针对
每个节点
运行。
如果某个任务必须针对其他主机运行,则该任务必须使用
delegate_to
或
local_action
。
openshift_node_post_upgrade_hook
每个节点未被取消封锁
后
运行。这是
最后一个
节点更新操作。
此 hook 以串行方式针对
每个节点
运行。
如果某个任务必须针对其他主机运行,则该任务必须使用
delegate_to
或
local_action
。
|
10.4. 更新集群中的RHEL compute 系统
在对集群进行更新后,必须更新集群中的Red Hat Enterprise Linux(RHEL)compute 系统。
RHEL 计算机器支持 Red Hat Enterprise Linux (RHEL) 版本 8.6 及更新的版本。
如果您使用 RHEL 作为操作系统,您还可以将计算机器更新至 OpenShift Container Platform 的另一个次要版本。当执行次版本更新时,您不需要排除 RHEL 中的任何 RPM 软件包。
您无法将 RHEL 7 计算机器升级到 RHEL 8。您必须部署新的 RHEL 8 主机,并且应该删除旧的 RHEL 7 主机。
已更新了集群。
因为 RHEL 机器需要集群生成的资产才能完成更新过程,所以您必须在更新其中的 RHEL worker 机器前更新集群。
您可以访问用于将 RHEL 计算机器添加到集群的本地机器。您必须有权访问定义了 RHEL 系统及
upgrade
playbook 的
hosts
Ansible 清单文件。
对于次版本的更新,RPM 存储库使用的是集群上运行的相同版本的 OpenShift Container Platform。
停止并禁用主机上的防火墙:
# systemctl disable --now firewalld.service
默认情况下,使用 "Minimal" 安装选项的基础操作系统 RHEL 启用 firewalld 保护。在主机上启用了 firewalld 服务会阻止您访问 worker 上的 OpenShift Container Platform 日志。如果您希望继续访问 worker 上的 OpenShift Container Platform 日志,以后不要启用 firewalld。
启用 OpenShift Container Platform 4.11 所需的存储库:
在运行 Ansible playbook 的机器上,更新所需的存储库:
# subscription-manager repos --disable=rhocp-4.10-for-rhel-8-x86_64-rpms \
--disable=ansible-2.9-for-rhel-8-x86_64-rpms \
--enable=rhocp-4.11-for-rhel-8-x86_64-rpms
自 OpenShift Container Platform 4.11 起,只有 RHEL 8 提供 Ansible playbook。如果 RHEL 7 系统用作 OpenShift Container Platform 4.10 Ansible playbook 的主机,您必须将 Ansible 主机升级到 RHEL 8,或者在 RHEL 8 系统中创建新的 Ansible 主机,并从旧的 Ansible 主机复制清单。
在运行 Ansible playbook 的机器上,更新 Ansible 软件包:
# yum swap ansible ansible-core
在运行 Ansible playbook 的机器上,更新所需的软件包,包括
openshift-ansible
:
# yum update openshift-ansible openshift-clients
在每个 RHEL 计算节点上,更新所需的软件仓库:
# subscription-manager repos --disable=rhocp-4.10-for-rhel-8-x86_64-rpms \
--enable=rhocp-4.11-for-rhel-8-x86_64-rpms
更新 RHEL worker 机器:
检查
/<path>/inventory/hosts
中的 Ansible 清单文件并更新其内容,以便 RHEL 8 机器列在
[workers]
部分中,如下例所示:
[all:vars]
ansible_user=root
#ansible_become=True
openshift_kubeconfig_path="~/.kube/config"
[workers]
mycluster-rhel8-0.example.com
mycluster-rhel8-1.example.com
mycluster-rhel8-2.example.com
mycluster-rhel8-3.example.com
进入
openshift-ansible
目录:
$ cd /usr/share/ansible/openshift-ansible
运行
upgrade
playbook:
$ ansible-playbook -i /<path>/inventory/hosts playbooks/upgrade.yml 1
-
1
-
对于
<path>
,指定您创建的Ansible库存文件的路径。
upgrade
playbook 仅升级 OpenShift Container Platform 软件包。它不会更新操作系统软件包。
更新完所有 worker 后,确认所有集群节点已更新至新版本:
# oc get node
断开连接的环境是集群节点无法访问互联网的环境。因此,您必须在 registry 中填充安装镜像。如果您的 registry 主机无法同时访问互联网和集群,您可以将镜像镜像到与这个环境断开连接的文件系统中,然后使用主机或可移动介质填补该空白。如果本地容器 registry 和集群连接到镜像 registry 的主机,您可以直接将发行镜像推送到本地 registry。
一个独立的容器镜像 registry 足以为断开连接的网络中的多个集群托管 mirror 的镜像。
11.2. 镜像 OpenShift Container Platform 镜像存储库
您必须将容器镜像镜像到镜像 registry 中,然后才能在受限网络环境中更新集群。您还可以在连接的环境中使用此流程来确保集群只运行满足您机构对外部内容控制的批准的容器镜像。
您的镜像 registry 必须始终在集群运行时都运行。
以下步骤概述了如何将镜像镜像到镜像 registry 的高级别工作流:
在用于检索和推送发行镜像的所有设备上安装 OpenShift CLI (
oc
)。
下载 registry pull secret,并将其添加到集群中。
如果使用
oc-mirror OpenShift CLI (
oc
) 插件
:
在用于检索和推送发行镜像的所有设备中安装 oc-mirror 插件。
为插件创建镜像设置配置文件,以便在决定要镜像的发行镜像时使用。您可以稍后编辑此配置文件,以更改插件镜像的镜像。
将目标发行镜像直接镜像到镜像 registry 或可移动介质,然后镜像到镜像 registry。
配置集群以使用 oc-mirror 插件生成的资源。
根据需要重复这些步骤以更新您的镜像 registry。
如果使用
oc adm release mirror
命令
:
设置环境变量,对应于您的环境以及您要镜像的发行镜像。
将目标发行镜像直接镜像到镜像 registry 或可移动介质,然后镜像到镜像 registry。
根据需要重复这些步骤以更新您的镜像 registry。
与使用
oc adm release mirror
命令相比,oc-mirror 插件具有以下优点:
它可以镜像容器镜像以外的内容。
在首次镜像镜像后,可以更轻松地更新 registry 中的镜像。
oc-mirror 插件提供了一种自动从 Quay 镜像发行版本有效负载的方法,并为在断开连接的环境中运行的 OpenShift Update Service 构建最新的图形数据镜像。
执行镜像步骤前,必须准备主机以检索内容并将其推送到远程位置。
11.2.2.1. 通过下载二进制文件安装 OpenShift CLI
您可以安装 OpenShift CLI(
oc
)来使用命令行界面与 OpenShift Container Platform 进行交互。您可以在 Linux、Windows 或 macOS 上安装
oc
。
如果安装了旧版本的
oc
,则无法使用 OpenShift Container Platform 4.11 中的所有命令。下载并安装新版本的
oc
。如果要在断开连接的环境中升级集群,请安装您要升级到的
oc
版本。
在 Linux 上安装 OpenShift CLI
您可以按照以下流程在 Linux 上安装 OpenShift CLI(
oc
)二进制文件。
导航到红帽客户门户网站上的
OpenShift Container Platform 下载页面
。
在
产品变体
下拉菜单中选择架构。
在
Version
下拉菜单中选择相应的版本。
点
OpenShift v4.11 Linux Client
条目旁的
Download Now
来保存文件。
解包存档:
$ tar xvf <file>
将
oc
二进制文件放到
PATH 中的目录中
。
要查看您的
PATH
,请执行以下命令:
$ echo $PATH
在 Windows 上安装 OpenShift CLI
您可以按照以下流程在 Windows 上安装 OpenShift CLI(
oc
)二进制文件。
导航到红帽客户门户网站上的
OpenShift Container Platform 下载页面
。
在
Version
下拉菜单中选择相应的版本。
点
OpenShift v4.11 Windows Client
条目旁的
Download Now
来保存文件。
使用 ZIP 程序解压存档。
将
oc
二进制文件移到
PATH 中的目录中
。
要查看您的
PATH
,请打开命令提示并执行以下命令:
C:\> path
在 macOS 上安装 OpenShift CLI
您可以按照以下流程在 macOS 上安装 OpenShift CLI(
oc
)二进制文件。
导航到红帽客户门户网站上的
OpenShift Container Platform 下载页面
。
在
Version
下拉菜单中选择相应的版本。
点
OpenShift v4.11 macOS Client
条目旁的
Download Now
来保存文件。
对于 macOS arm64,请选择
OpenShift v4.11 macOS arm64 Client
条目。
解包和解压存档。
将
oc
二进制文件移到 PATH 的目录中。
要查看您的
PATH
,请打开终端并执行以下命令:
$ echo $PATH
11.2.2.2. 配置允许对容器镜像进行镜像的凭证
创建容器镜像 registry 凭证文件,允许将红帽的镜像镜像到您的镜像环境中。
安装集群时不要使用此镜像 registry 凭据文件作为 pull secret。如果在安装集群时提供此文件,集群中的所有机器都将具有镜像 registry 的写入权限。
此过程需要您可以对镜像 registry 上的容器镜像 registry 进行写操作,并将凭证添加到 registry pull secret。
您已将镜像 registry 配置为在断开连接的环境中使用。
您在镜像 registry 中标识了镜像仓库的位置,以将容器镜像镜像(mirror)到这个位置。
您置备了一个镜像 registry 帐户,允许将镜像上传到该镜像仓库。
在安装主机上完成以下步骤:
下载您的
registry.redhat.io
pull secret(从Red Hat OpenShift Cluster Manager)
。
以 JSON 格式创建您的 pull secret 副本:
$ cat ./pull-secret | jq . > <path>/<pull_secret_file_in_json> 1
-
1
-
指定到存储 pull secret 的文件夹的路径,以及您创建的 JSON 文件的名称。
该文件类似于以下示例:
"auths": {
"cloud.openshift.com": {
"auth": "b3BlbnNo...",
"email": " [email protected]"
"quay.io": {
"auth": "b3BlbnNo...",
"email": " [email protected]"
"registry.connect.redhat.com": {
"auth": "NTE3Njg5Nj...",
"email": " [email protected]"
"registry.redhat.io": {
"auth": "NTE3Njg5Nj...",
"email": " [email protected]"
可选:如果使用 oc-mirror 插件,请将文件保存为
~/.docker/config.json
或
$XDG_RUNTIME_DIR/containers/auth.json
。
为您的镜像 registry 生成 base64 编码的用户名和密码或令牌:
$ echo -n '<user_name>:<password>' | base64 -w0 1
BGVtbYk3ZHAtqXs=
-
1
-
通过
<user_name>
和
<password>
指定 registry 的用户名和密码。
编辑 JSON 文件并添加描述 registry 的部分:
"auths": {
"<mirror_registry>": { 1
"auth": "<credentials>", 2
"email": "[email protected]"
对于 <mirror_registry> ,指定 registry 域名,以及您的镜像 registry 用来提供内容的可选端口。例如:registry.example.com 或 registry.example.com:8443
使用 <credentials> 为您的镜像 registry 指定 base64 编码的用户名和密码。
该文件类似于以下示例:
"auths": {
"registry.example.com": {
"auth": "BGVtbYk3ZHAtqXs=",
"email": "[email protected]"
"cloud.openshift.com": {
"auth": "b3BlbnNo...",
"email": "[email protected]"
"quay.io": {
"auth": "b3BlbnNo...",
"email": "[email protected]"
"registry.connect.redhat.com": {
"auth": "NTE3Njg5Nj...",
"email": "[email protected]"
"registry.redhat.io": {
"auth": "NTE3Njg5Nj...",
"email": "[email protected]"
}
11.2.3. 使用 oc-mirror 插件镜像资源
您可以使用 oc-mirror OpenShift CLI (
oc
)插件在完全或部分断开连接的环境中将镜像镜像到镜像 registry。您必须从具有互联网连接的系统运行 oc-mirror,以便从官方红帽 registry 中下载所需的镜像。
11.2.3.1. 关于 oc-mirror 插件
您可以使用 oc-mirror OpenShift CLI(
oc
)插件,使用单个工具将所有所需的 OpenShift Container Platform 内容和其他镜像(mirror)镜像到您的镜像 registry。它提供以下功能:
提供镜像 OpenShift Container Platform 发行版本、Operator、helm chart 和其他镜像的集中方法。
维护 OpenShift Container Platform 和 Operator 的更新路径。
使用声明的镜像设置配置文件来仅包含集群所需的 OpenShift Container Platform 发行版本、Operator 和镜像。
执行增量镜像,从而减少将来镜像集的大小。
从上一执行以来,从镜像集配置中排除的目标镜像 registry 中修剪镜像的镜像。
(可选)为 OpenShift Update Service (OSUS) 使用生成支持工件。
使用 oc-mirror 插件时,您可以在镜像设置配置文件中指定要镜像的内容。在这个 YAML 文件中,您可以将配置微调为仅包含集群需要的 OpenShift Container Platform 发行版本和 Operator。这可减少您下载和传输所需的数据量。oc-mirror 插件也可以镜像任意 helm chart 和附加容器镜像,以帮助用户将其工作负载无缝同步到镜像 registry 中。
第一次运行 oc-mirror 插件时,它会使用所需内容填充您的镜像 registry,以执行断开连接的集群安装或更新。要让断开连接的集群继续接受更新,您必须更新镜像 registry。要更新您的镜像 registry,请使用与第一次运行相同的配置运行 oc-mirror 插件。oc-mirror 插件引用存储后端的元数据,并只下载上次运行该工具后所发布的元数据。这为 OpenShift Container Platform 和 Operator 提供了更新路径,并根据需要执行依赖项解析。
当使用 oc-mirror CLI 插件填充镜像 registry 时,必须使用 oc-mirror 工具对镜像 registry 进行进一步的更新。
11.2.3.2. oc-mirror 兼容性和支持
oc-mirror 插件支持为 OpenShift Container Platform 版本 4.9 及之后的版本的镜像 OpenShift Container Platform 有效负载镜像和 Operator 目录。
使用 oc-mirror 插件的最新版本,无论您需要镜像的 OpenShift Container Platform 版本是什么。
如果您在 OpenShift Container Platform 4.10 中使用 oc-mirror 插件的技术预览版本,则无法将镜像 registry 迁移到 OpenShift Container Platform 4.11。您必须下载新的 oc-mirror 插件,使用新的存储后端,并在目标镜像 registry 上使用新的顶级命名空间。
您可以将 OpenShift Container Platform 安装和后续的产品更新镜像(mirror)到支持
Docker v2-2
(如 Red Hat Quay)的容器镜像(如 Red Hat Quay)的容器镜像。如果您无法访问大型容器 registry,可以使用
Red Hat OpenShift 的镜像 registry
,这是 OpenShift 中包含的小型容器 registry。
无论您所选 registry 是什么,都会将互联网上红帽托管站点的内容镜像到隔离的镜像 registry 相同。镜像内容后,您要将每个集群配置为从镜像 registry 中检索此内容。
OpenShift 镜像 registry 不能用作目标 registry,因为它不支持没有标签的推送,在镜像过程中需要这个推送。
如果选择的容器 registry 不是
mirror registry for Red Hat OpenShift
,则需要集群中置备的每台机器都可以访问它。如果 registry 无法访问,安装、更新或常规操作(如工作负载重新定位)可能会失败。因此,您必须以高度可用的方式运行镜像 registry,镜像 registry 至少必须与 OpenShift Container Platform 集群的生产环境可用性相匹配。
使用 OpenShift Container Platform 镜像填充镜像 registry 时,可以遵循以下两种情况。如果您的主机可以同时访问互联网和您的镜像 registry,而不能访问您的集群节点,您可以直接从该机器中镜像该内容。这个过程被称为
连接的镜像(mirror)
。如果没有这样的主机,则必须将该镜像文件镜像到文件系统中,然后将该主机或者可移动介质放入受限环境中。这个过程被称为
断开连接的镜像
。
对于已镜像的 registry,若要查看拉取镜像的来源,您必须查看
Trying 以访问
CRI-O 日志中的日志条目。查看镜像拉取源的其他方法(如在节点上使用
crictl images
命令)显示非镜像镜像名称,即使镜像是从镜像位置拉取的。
红帽没有针对 OpenShift Container Platform 测试第三方 registry。
有关查看 CRI-O 日志以查看镜像源的详情,请参阅
查看镜像拉取源
。
11.2.3.4. 安装 oc-mirror OpenShift CLI 插件
要使用 oc-mirror OpenShift CLI 插件来镜像 registry 镜像,您必须安装插件。如果您在一个完全断开连接的环境中镜像镜像集,请确保在具有互联网访问的主机上的 oc-mirror 插件以及可访问镜像 registry 的断开连接的环境中安装 oc-mirror 插件。
已安装 OpenShift CLI(
oc
)。
下载 oc-mirror CLI 插件。
进入到
OpenShift Cluster Manager Hybrid Cloud Console
的
Downloads
页面。
在
OpenShift disconnected 安装工具
部分下,点
Download
for
OpenShift Client(oc)mirror 插件
并保存该文件。
解压归档:
$ tar xvzf oc-mirror.tar.gz
如有必要,将插件文件更新为可执行。
$ chmod +x oc-mirror
不要重命名
oc-mirror
文件。
通过将文件放在
PATH
中,例如
/usr/local/bin
,安装 oc-mirror CLI 插件:
$ sudo mv oc-mirror /usr/local/bin/.
在使用 oc-mirror 插件镜像集之前,必须先创建镜像设置配置文件。此镜像设置配置文件定义哪些 OpenShift Container Platform 发行版本、Operator 和其他镜像要镜像,以及 oc-mirror 插件的其他配置设置。
您必须在镜像设置配置文件中指定存储后端。此存储后端可以是本地目录或支持
Docker v2-2
的 registry。oc-mirror 插件在创建镜像的过程中将元数据存储在这个存储后端中。
不要删除或修改 oc-mirror 插件生成的元数据。每次针对同一镜像 registry 运行 oc-mirror 插件时,都必须使用相同的存储后端。
您已创建了容器镜像 registry 凭证文件。具体步骤,请参阅
配置允许镜像镜像的凭证
。
使用
oc mirror init
命令为镜像设置配置创建模板,并将其保存到名为
imageset-config.yaml
的文件中:
$ oc mirror init --registry example.com/mirror/oc-mirror-metadata > imageset-config.yaml 1
-
1
-
将
example.com/mirror/oc-mirror-metadata
替换为存储后端的 registry 的位置。
编辑该文件并根据需要调整设置:
kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v1alpha2
archiveSize: 4 1
storageConfig: 2
registry:
imageURL: example.com/mirror/oc-mirror-metadata 3
skipTLS: false
mirror:
platform:
channels:
- name: stable-4.11 4
type: ocp
graph: true 5
operators:
- catalog: registry.redhat.io/redhat/redhat-operator-index:v4.11 6
packages:
- name: serverless-operator 7
channels:
- name: stable 8
additionalImages:
- name: registry.redhat.io/ubi8/ubi:latest 9
helm: {}
-
1
-
添加
archiveSize
以设置镜像集合中的每个文件的最大大小(以 GiB 为单位)。
设置后端位置,以将镜像设置元数据保存到。此位置可以是 registry 或本地目录。必须指定
storageConfig
值。
设置存储后端的 registry URL。
将频道设置为从中检索 OpenShift Container Platform 镜像。
添加
graph: true
以构建并推送 graph-data 镜像推送到镜像 registry。创建 OpenShift Update Service (OSUS) 需要 graph-data 镜像。
graph: true
字段还会生成
UpdateService
自定义资源清单。
oc
命令行界面 (CLI) 可以使用
UpdateService
自定义资源清单来创建 OSUS。如需更多信息,请参阅
关于 OpenShift Update Service
。
将 Operator 目录设置为从中检索 OpenShift Container Platform 镜像。
仅指定要包含在镜像集中的某些 Operator 软件包。删除此字段以检索目录中的所有软件包。
仅指定要包含在镜像集中的 Operator 软件包的某些频道。即使您没有使用该频道中的捆绑包,还必须始终包含 Operator 软件包的默认频道。您可以运行以下命令来找到默认频道:
oc mirror list operators --catalog=<catalog_name> --package=<package_name>
。
指定要在镜像集中包含的任何其他镜像。
如需完整的参数列表,请参阅
Image set configuration parameters
;对于不同的镜像用例,请参阅
Image set configuration examples
。
保存更新的文件。
在镜像内容时,
oc mirror
命令需要此镜像设置配置文件。
镜像设置配置参数
镜像设置配置示例
关于 OpenShift Update 服务
11.2.3.6. 将镜像集镜像(mirror)到镜像 registry
您可以使用 oc-mirror CLI 插件在
部分断开连接的环境中
或
完全断开连接的环境中
将镜像镜像到镜像 registry。
以下流程假设您已设置了镜像 registry。
11.2.3.6.1. 在部分断开连接的环境中镜像设置的镜像
在部分断开连接的环境中,您可以直接镜像到目标镜像 registry 的镜像。
11.2.3.6.1.1. 镜像(mirror)到镜像(mirror)的镜像
您可以使用 oc-mirror 插件将镜像直接设置为在镜像设置过程中可访问的目标镜像 registry。
您必须在镜像设置配置文件中指定存储后端。这个存储后端可以是本地目录或 Docker v2 registry。oc-mirror 插件在创建镜像的过程中将元数据存储在这个存储后端中。
不要删除或修改 oc-mirror 插件生成的元数据。每次针对同一镜像 registry 运行 oc-mirror 插件时,都必须使用相同的存储后端。
您可以访问互联网来获取所需的容器镜像。
已安装 OpenShift CLI(
oc
)。
已安装
oc-mirror
CLI 插件。
您已创建了镜像设置配置文件。
运行
oc mirror
命令将指定镜像集配置中的镜像镜像到指定的 registry:
$ oc mirror --config=./imageset-config.yaml \1
docker://registry.example:5000 2
-
1
-
传递创建的镜像设置配置文件。此流程假设它名为
imageset-config.yaml
。
指定要镜像设置文件的 registry。registry 必须以
docker://
开头。如果为镜像 registry 指定顶层命名空间,则必须在后续执行时使用此命名空间。
进入生成的
oc-mirror-workspace/
目录。
导航到结果目录,例如,
results-1639608409/
。
验证
ImageContentSourcePolicy
和
CatalogSource
资源是否存在 YAML 文件。
配置集群以使用 oc-mirror 生成的资源。
无法检索源镜像
。
11.2.3.6.2. 镜像在完全断开连接的环境中设置的镜像
要镜像在完全断开连接的环境中设置的镜像,您必须首先
将镜像集镜像到磁盘
, 然后
将磁盘上的镜像集文件镜像到一个镜像
。
您可以使用 oc-mirror 插件生成镜像集,并将内容保存到磁盘。然后,生成的镜像集可以转移到断开连接的环境中,并镜像到目标 registry。
根据镜像设置配置文件中指定的配置,使用 oc-mirror 的镜像可能会将几百 GB 数据下载到磁盘。
您填充镜像 registry 时初始镜像集下载通常是最大镜像。因为您只下载自上次运行命令以来更改的镜像,所以再次运行 oc-mirror 插件时,所生成的镜像集通常比较小。
您必须在镜像设置配置文件中指定存储后端。这个存储后端可以是本地目录或 docker v2 registry。oc-mirror 插件在创建镜像的过程中将元数据存储在这个存储后端中。
不要删除或修改 oc-mirror 插件生成的元数据。每次针对同一镜像 registry 运行 oc-mirror 插件时,都必须使用相同的存储后端。
您可以访问互联网来获取所需的容器镜像。
已安装 OpenShift CLI(
oc
)。
已安装
oc-mirror
CLI 插件。
您已创建了镜像设置配置文件。
运行
oc mirror
命令将指定镜像集配置镜像到磁盘:
$ oc mirror --config=./imageset-config.yaml \1
file://<path_to_output_directory> 2
-
1
-
传递创建的镜像设置配置文件。此流程假设它名为
imageset-config.yaml
。
指定要输出镜像集文件的目标目录。目标目录路径必须以
file://
开头。
进入您的输出目录:
$ cd <path_to_output_directory>
-
验证是否创建了镜像设置
.tar
文件:
$ ls
您可以使用 oc-mirror 插件将生成的镜像集的内容镜像到目标镜像 registry。
您已在断开连接的环境中安装了 OpenShift CLI(
oc
)。
您已在断开连接的环境中安装了
oc-mirror
CLI 插件。
已使用
oc mirror
命令生成镜像集文件。
您已将镜像集文件传送到断开连接的环境中。
运行
oc mirror
命令,以处理磁盘上镜像集文件,并将内容镜像到目标镜像 registry:
$ oc mirror --from=./mirror_seq1_000000.tar \1
docker://registry.example:5000 2
-
1
-
传递镜像集 .tar 文件以进行镜像,在本例中名为
mirror_seq1_000000.tar
。如果在镜像设置配置文件中指定了
archiveSize
值,则镜像集可能会划分为多个 .tar 文件。在这种情况下,您可以传递一个包含镜像设置 .tar 文件的目录。
指定要镜像设置文件的 registry。registry 必须以
docker://
开头。如果为镜像 registry 指定顶层命名空间,则必须在后续执行时使用此命名空间。
此命令使用镜像集更新镜像 registry,并生成
ImageContentSourcePolicy
和
CatalogSource
资源。
进入生成的
oc-mirror-workspace/
目录。
导航到结果目录,例如,
results-1639608409/
。
验证
ImageContentSourcePolicy
和
CatalogSource
资源是否存在 YAML 文件。
配置集群以使用 oc-mirror 生成的资源。
无法检索源镜像
。
11.2.3.7. 配置集群以使用 oc-mirror 生成的资源
将镜像设置为镜像 registry 后,您必须将生成的
ImageContentSourcePolicy
、
CatalogSource
和发行版本镜像签名资源应用到集群。
ImageContentSourcePolicy
资源将镜像 registry 与源 registry 关联,并将在线 registry 中的镜像拉取请求重定向到镜像 registry。Operator Lifecycle Manager(OLM)使用
CatalogSource
资源检索有关镜像 registry 中可用 Operator 的信息。发行镜像签名用于验证镜像的发行镜像。
您已将镜像设置为断开连接的环境中的 registry 镜像。
您可以使用具有
cluster-admin
角色的用户访问集群。
以具有
cluster-admin
角色的用户身份登录 OpenShift CLI。
运行以下命令,将结果目录中的 YAML 文件应用到集群:
$ oc apply -f ./oc-mirror-workspace/results-1639608409/
如果镜像(mirror)镜像,请运行以下命令将发行版本镜像签名应用到集群:
$ oc apply -f ./oc-mirror-workspace/results-1639608409/release-signatures/
如果要镜像 Operator 而不是集群,则不需要运行
$ oc apply -f ./oc-mirror-workspace/results-1639608409/release-signatures/
。运行该命令将返回错误,因为没有要应用的发行版本镜像签名。
运行以下命令验证
ImageContentSourcePolicy
资源是否已成功安装:
$ oc get imagecontentsourcepolicy --all-namespaces
运行以下命令验证
CatalogSource
资源是否已成功安装:
$ oc get catalogsource --all-namespaces
11.2.3.8. 保持镜像 registry 内容更新
使用初始镜像集填充目标镜像 registry 后,您必须定期更新它,使其具有最新的内容。如果可能,您可以设置 cron 任务以定期更新镜像 registry。
根据需要更新您的镜像设置配置,以添加或删除 OpenShift Container Platform 和 Operator 版本。从镜像 registry 中修剪移除的镜像。
11.2.3.8.1. 关于更新您的镜像 registry 内容
当您再次运行 oc-mirror 插件时,它会生成一个镜像集,该集合仅包含与之前执行后的全新和更新镜像。因为它只拉取自以前的镜像集的差异,所以所生成的镜像集通常比初始镜像集更小且更快。
生成的镜像集是有序的,且必须推送到目标镜像 registry。您可以从生成的镜像设置归档文件的文件名中获取序列号。
添加新和更新的镜像
根据镜像设置配置中的设置,oc-mirror 的将来执行可能会镜像新的和更新镜像。查看镜像设置配置中的设置,以确保根据需要检索新版本。例如,如果要限制特定版本,可以将 Operator 的最小和最大版本设置为 mirror。另外,您可以将最小版本设置为镜像的起点,但保持对版本范围保持打开状态,以便在以后的 oc-mirror 上执行新的 Operator 版本。省略任何最小或最大版本会为您提供频道中的 Operator 的完整版本历史记录。省略明确指定的频道会为您提供指定 Operator 的所有频道的所有发行版本。省略任何命名 Operator 都会为您提供所有 Operator 的整个目录及其所有版本。
所有这些约束和条件均针对红帽每次调用 oc-mirror 时根据公开发布的内容进行评估。这样,它会自动获取新版本和全新的 Operator。约束只能通过列出所需的 Operator 集合来指定,它不会自动将其他新发布的 Operator 添加到镜像集中。您还可以指定特定的发行版本频道,将镜像限制为只为此频道,而不是任何已添加的新频道。这对于 Operator 产品(如 Red Hat Quay)来说,在其次发行版本中使用不同的发行频道。最后,您可以指定一个特定 Operator 的最大版本,这会导致工具只镜像指定的版本范围,这样您不会自动获得任何更新版本镜像 (mirror) 版本。在所有用例中,您必须更新镜像设置配置文件以扩大 Operator 镜像范围,以获取其他 Operator、新频道和较新版本的 Operator,以便在目标 registry 中提供。
建议将诸如频道规格或版本范围等约束与所选 Operator 的发行策略保持一致。例如,当 Operator 使用
stable
频道时,您应该将镜像限制到该频道,并有可能最小的版本来查找下载卷之间的正确平衡并定期获取稳定更新。如果 Operator 选择了发行版本频道方案,如
stable-3.7
,您应该镜像该频道中的所有发行版本。这可让您继续使用 Operator 的补丁版本,如
3.7.1
。您还可以定期调整镜像设置配置,为新产品版本添加频道,如
stable-3.8
。
如果镜像不再包含在生成和镜像的最新镜像集中,则会自动从目标镜像 registry 中修剪镜像。这可让您轻松管理和清理不需要的内容并回收存储资源。
如果不再需要 OpenShift Container Platform 发行版本或 Operator 版本,您可以修改镜像设置配置以排除它们,并在镜像 (mirror) 后从镜像 registry 中修剪它们。这可以通过调整镜像设置配置文件中的每个 Operator 的最小或最大版本范围设置,或者从目录中镜像 (mirror) 的 Operator 中移除。您还可以从配置文件中删除整个 Operator 目录或整个 OpenShift Container Platform 版本。
如果没有要镜像的新的或更新的镜像,则不会从目标镜像 registry 中修剪排除的镜像。另外,如果 Operator publisher 从频道中删除 Operator 版本,则从目标镜像 registry 中删除了删除的版本。
11.2.3.8.2. 更新您的镜像 registry 内容
将初始镜像设置为镜像 registry 后,您可以使用 oc-mirror 插件来保持断开连接的集群更新。
根据您的镜像设置配置,oc-mirror 会自动检测 OpenShift Container Platform 的较新版本,以及在完成 inital mirror 后发布的所选 Operator。建议您定期运行 oc-mirror,例如在每日 cron 作业中运行 oc-mirror,以及时接收产品和安全更新。
您已使用 oc-mirror 插件将初始镜像设置为您的镜像 registry。
您可以访问用于进行 oc-mirror 插件的初始执行的存储后端。
您必须使用与 oc-mirror 的初始执行相同镜像 registry 的存储后端。不要删除或修改 oc-mirror 插件生成的元数据镜像。
如有必要,更新您的镜像设置配置文件,以获取新的 OpenShift Container Platform 和 Operator 版本。对于示例镜像使用情况,请参阅
Image set configuration examples
。
按照您用来将初始镜像设置为镜像 registry 的步骤操作。具体步骤,请参阅
在部分断开连接的环境中镜像镜像集
,或
在完全断开连接的环境中镜像镜像集
。
您必须提供相同的存储后端,以便只创建并镜像不同的镜像集。
如果您在初始镜像集创建过程中为镜像 registry 指定顶层命名空间,则每次针对同一镜像 registry 运行 oc-mirror 插件时都必须使用此命名空间。
配置集群以使用 oc-mirror 生成的资源。
镜像设置配置示例
在部分断开连接的环境中镜像设置的镜像
镜像在完全断开连接的环境中设置的镜像
配置集群以使用 oc-mirror 生成的资源
您可以使用 oc-mirror 来执行空运行,而无需实际镜像(mirror)。这可让您查看要镜像的镜像列表,以及从镜像 registry 修剪的所有镜像。它还允许您在早期版本中捕获与镜像集配置相关的任何错误,或使用生成的镜像列表以及其他工具来执行镜像操作。
您可以访问互联网来获取所需的容器镜像。
已安装 OpenShift CLI(
oc
)。
已安装
oc-mirror
CLI 插件。
您已创建了镜像设置配置文件。
使用
--dry-run
标志运行
oc mirror
命令来执行空运行:
$ oc mirror --config=./imageset-config.yaml \1
docker://registry.example:5000 \2
--dry-run 3
-
1
-
传递创建的镜像设置配置文件。此流程假设它名为
imageset-config.yaml
。
指定镜像 registry。在使用
--dry-run
标志时,不会镜像这个 registry。
使用
--dry-run
标志来生成空运行工件,而不是实际的镜像设置文件。
Checking push permissions for registry.example:5000
Creating directory: oc-mirror-workspace/src/publish
Creating directory: oc-mirror-workspace/src/v2
Creating directory: oc-mirror-workspace/src/charts
Creating directory: oc-mirror-workspace/src/release-signatures
No metadata detected, creating new workspace
wrote mirroring manifests to oc-mirror-workspace/operators.1658342351/manifests-redhat-operator-index
info: Planning completed in 31.48s
info: Dry run complete
Writing image mapping to oc-mirror-workspace/mapping.txt
进入生成的工作区目录:
$ cd oc-mirror-workspace/
-
查看生成的
mapping.txt
文件。
此文件包含将要镜像的所有镜像的列表。
查看生成的
prune-plan.json
文件。
此文件包含在发布镜像集时从镜像 registry 中修剪的所有镜像的列表。
只有在 oc-mirror 命令指向您的镜像 registry 且需要修剪的镜像时,才会生成
prune-plan.json
文件。
基于文件的目录
oc-mirror 插件需要一个镜像设置配置文件,该文件定义哪些镜像要镜像(mirror)。下表列出了
ImageSetConfiguration
资源的可用参数。
表 11.1. ImageSetConfiguration 参数
参数
|
描述
|
值
|
apiVersion
ImageSetConfiguration
内容的 API 版本。
字符串.例如:
mirror.openshift.io/v1alpha2
。
archiveSize
镜像集中的每个存档文件的最大大小(以 GiB 为单位)。
整数.例如:
4
mirror
镜像集的配置。
mirror.additionalImages
镜像集的额外镜像配置。
对象数组。例如:
additionalImages:
- name: registry.redhat.io/ubi8/ubi:latest
mirror.additionalImages.name
要 mirror 的镜像的标签或摘要。
字符串.例如:
registry.redhat.io/ubi8/ubi:latest
mirror.blockedImages
阻止 mirror 的镜像的完整标签、摘要或模式。
字符串数组。例如:
docker.io/library/alpine
mirror.helm
镜像集的 helm 配置。请注意,oc-mirror 插件只支持 helm chart,在呈现时不需要用户输入。
mirror.helm.local
要镜像的本地 helm chart。
对象数组。例如:
local:
- name: podinfo
path: /test/podinfo-5.0.0.tar.gz
mirror.helm.local.name
要镜像的本地 helm chart 的名称。
字符串.例如:
podinfo
。
mirror.helm.local.path
到镜像的本地 helm chart 的路径。
字符串.例如:
/test/podinfo-5.0.0.tar.gz
。
mirror.helm.repositories
从其中镜像的的远程 helm 软件仓库。
对象数组。例如:
repositories:
- name: podinfo
url: https://example.github.io/podinfo
charts:
- name: podinfo
version: 5.0.0
mirror.helm.repositories.name
从其中镜像(mirror)的 helm 存储库的名称。
字符串.例如:
podinfo
。
mirror.helm.repositories.url
从其中镜像(mirror)的 helm 存储库的 URL。
字符串.例如:
https://example.github.io/podinfo
。
mirror.helm.repositories.charts
要镜像的远程 helm chart。
对象数组。
mirror.helm.repositories.charts.name
要镜像的 helm chart 的名称。
字符串.例如:
podinfo
。
mirror.helm.repositories.charts.version
要镜像命名 helm chart 的版本。
字符串.例如:
5.0.0
。
mirror.operators
镜像集的 Operator 配置。
对象数组。例如:
operators:
- catalog: registry.redhat.io/redhat/redhat-operator-index:v4.11
packages:
- name: elasticsearch-operator
minVersion: '2.4.0'
mirror.operators.catalog
包括在镜像集中的 Operator 目录。
字符串.例如:
registry.redhat.io/redhat/redhat-operator-index:v4.11
。
mirror.operators.full
为
true
时,下载完整的目录、Operator 软件包或 Operator 频道。
布尔值.默认值为
false
。
mirror.operators.packages
Operator 软件包配置。
对象数组。例如:
operators:
- catalog: registry.redhat.io/redhat/redhat-operator-index:v4.11
packages:
- name: elasticsearch-operator
minVersion: '5.2.3-31'
mirror.operators.packages.name
镜像集中要包含的 Operator 软件包名称
字符串.例如:
elasticsearch-operator
。
mirror.operators.packages.channels
Operator 软件包频道配置。
mirror.operators.packages.channels.name
Operator 频道名称(软件包中唯一)要包括在镜像集中。
字符串.例如:
fast
或
stable-v4.11
。
mirror.operators.packages.channels.maxVersion
Operator 镜像的最高版本,在其中存在所有频道。
字符串.例如:
5.2.3-31
mirror.operators.packages.channels.minBundle
要包括的最小捆绑包的名称,以及将图中到频道头的所有捆绑包。仅在命名捆绑包没有语义版本元数据时设置此字段。
字符串.例如:
bundleName
mirror.operators.packages.channels.minVersion
Operator 的最低版本,用于镜像存在的所有频道。
字符串.例如:
5.2.3-31
mirror.operators.packages.maxVersion
Operator 最高版本,可跨所有存在的频道进行镜像。
字符串.例如:
5.2.3-31
。
mirror.operators.packages.minVersion
Operator 的最低版本,用于镜像存在的所有频道。
字符串.例如:
5.2.3-31
。
mirror.operators.skipDependencies
如果为
true
,则不会包含捆绑包的依赖项。
布尔值.默认值为
false
。
mirror.operators.targetName
将引用的目录镜像为可选的替代名称。
字符串.例如:
my-operator-catalog
mirror.operators.targetTag
附加到
targetName
的可选替代标签。
字符串.例如:
v1
mirror.platform
镜像集的平台配置。
mirror.platform.architectures
要镜像的平台发行版本有效负载的架构。
字符串数组。例如:
architectures:
- amd64
- arm64
mirror.platform.channels
镜像集的平台频道配置。
对象数组。例如:
channels:
- name: stable-4.10
- name: stable-4.11
mirror.platform.channels.full
为
true
时,将
minVersion
设置为频道中的第一个发行版本,将
maxVersion
设置为该频道的最后一个发行版本。
布尔值.默认值为
false
。
mirror.platform.channels.name
发行频道的名称。
字符串.例如:
stable-4.11
mirror.platform.channels.minVersion
要镜像引用的平台的最低版本。
字符串.例如:
4.9.6
mirror.platform.channels.maxVersion
要镜像引用的平台的最高版本。
字符串.例如:
4.11.1
mirror.platform.channels.shortestPath
切换最短的路径镜像或完整范围镜像。
布尔值.默认值为
false
。
mirror.platform.channels.type
要镜像的平台的类型。
字符串.例如:
ocp
或
okd
。默认为
ocp
。
mirror.platform.graph
指明是否将 OSUS 图表添加到镜像集中,然后发布到镜像。
布尔值.默认值为
false
。
storageConfig
镜像集的后端配置。
storageConfig.local
镜像集的本地后端配置。
storageConfig.local.path
包含镜像设置元数据的目录路径。
字符串.例如:
./path/to/dir/
。
storageConfig.registry
镜像集的 registry 后端配置。
storageConfig.registry.imageURL
后端 registry URI。可以选择在 URI 中包含命名空间引用。
字符串.例如:
quay.io/myuser/imageset:metadata
。
storageConfig.registry.skipTLS
(可选)跳过引用的后端 registry 的 TLS 验证。
布尔值.默认值为
false
。
|
以下
ImageSetConfiguration
文件示例演示了各种镜像用例的配置。
用例:包含任意镜像和 helm chart
以下
ImageSetConfiguration
文件使用 registry 存储后端,并包含 helm chart 和额外的 Red Hat Universal Base Image(UBI)。
使用案例:包含从最低到最新的 Operator 版本
以下
ImageSetConfiguration
文件使用本地存储后端,仅包含
latest
频道中从 3.68.0 及之后的版本开始的 Red Hat Advanced Cluster Security for Kubernetes Operator。
使用案例:包含最短的 OpenShift Container Platform 升级路径
以下
ImageSetConfiguration
文件使用本地存储后端,并包括所有 OpenShift Container Platform 版本,以及从最低
4.9.37
版本到最大
4.10.22
版本的升级路径。
使用案例:包含从最小到最新的 OpenShift Container Platform 的所有版本
以下
ImageSetConfiguration
文件使用一个 registry 存储后端,并包括从最小
4.10.10
迁移到频道中最新版本的所有 OpenShift Container Platform 版本。
对于每个使用此镜像集合配置的 oc-mirror,评估
stable-4.10
频道的最新发行版本,因此定期运行 oc-mirror 可确保您自动收到最新版本的 OpenShift Container Platform 镜像。
使用案例:包含 Operator 版本最少到最大值
以下
ImageSetConfiguration
文件使用本地存储后端,仅包含一个示例 Operator,在
stable
频道中从
1.0.0
到
2.0.0
开始。
这可让您只镜像特定 Operator 的特定版本范围。当时间进行时,您可以使用这些设置将版本调整为较新的版本,例如当您不再有版本
1.0.0
正常运行时。在这种情况下,您可以将
minVersion
增加到较新的内容,例如
1.5.0
。当使用更新版本范围再次运行 oc-mirror 时,它会自动检测到不再需要任何版本超过
1.5.0
,并从 registry 中删除这些版本以节省存储空间。
11.2.3.12. oc-mirror 的命令参考
下表描述了
oc mirror
子命令和标志:
表 11.2. oc mirror 子命令
子命令
|
描述
|
completion
为指定的 shell 生成自动完成脚本。
describe
输出镜像集合的内容。
显示有关任何子命令的帮助。
输出初始镜像设置配置模板。
列出可用平台和 Operator 内容及其版本。
version
输出 oc-mirror 版本。
|
表 11.3. oc mirror 标记
标记
|
描述
|
-c
,
--config
<string>
指定镜像设置配置文件的路径。
--continue-on-error
如果发生任何非镜像拉取相关的错误,请继续并尝试进行镜像(mirror)。
--dest-skip-tls
禁用目标 registry 的 TLS 验证。
--dest-use-http
使用 HTTP 用于目标 registry。
--dry-run
仅输出操作情况,不实际 mirror 镜像。生成
mapping.txt
和
pruning-plan.json
文件。
--from <string>
指定由执行 oc-mirror 生成的镜像设置归档的路径,以加载到目标 registry 中。
-h
,
--help
显示帮助。
--ignore-history
下载镜像和打包层时,忽略过去的镜像。禁用增量镜像,并可能会下载更多数据。
--manifests-only
为
ImageContentSourcePolicy
对象生成清单,将集群配置为使用镜像 registry,但不实际镜像任何镜像。要使用此标志,您必须使用
--from
标志传递镜像集存档。
--max-per-registry <int>
指定每个 registry 允许的并发请求数。默认值为
6
。
--skip-cleanup
跳过删除工件目录。
--skip-image-pin
不要将镜像标签替换为 Operator 目录中的摘要。
--skip-metadata-check
发布镜像集时跳过元数据。只有在使用
--ignore-history
创建镜像集时才建议使用。
--skip-missing
如果没有找到镜像,则跳过它而不是报告错误并中止执行。不适用于在镜像设置配置中明确指定的自定义镜像。
--skip-verification
跳过摘要验证。
--source-skip-tls
为源 registry 禁用 TLS 验证。
--source-use-http
将普通 HTTP 用于源 registry。
-v
,
--verbose
<int>
指定日志级别详细程度的数量。有效值为
0
-
9
。默认值为
0
。
|
11.2.4. 使用 oc adm release mirror 命令 mirror 镜像
为了避免 OpenShift Update Service 应用程序过量内存用量,您必须将发行镜像镜像到单独的存储库,如以下步骤所述。
您已将镜像 registry 配置为在受限网络中使用,并可访问您配置的证书和凭证。
您已从
Red Hat OpenShift Cluster Manager 下载了 pull secret
,并已修改为包含镜像存储库身份验证信息。
如果您使用自签名证书,已在证书中指定 Subject Alternative Name。
使用
Red Hat OpenShift Container Platform Upgrade Graph visualizer 和 update planner
计划从一个版本升级到另一个版本。OpenShift Upgrade Graph 提供频道图形,并演示了如何确认您的当前和预定集群版本之间有更新路径。
设置所需的环境变量:
导出发行版本信息:
$ export OCP_RELEASE=<release_version>
对于
<release_version>
,请指定与升级到的 OpenShift Container Platform 版本对应的标签,如
4.5.4
。
导出本地 registry 名称和主机端口:
$ LOCAL_REGISTRY='<local_registry_host_name>:<local_registry_host_port>'
对于
<local_registry_host_name>
,请指定镜像存储库的 registry 域名;对于
<local_registry_host_port>
,请指定用于提供内容的端口。
导出本地存储库名称:
$ LOCAL_REPOSITORY='<local_repository_name>'
对于
<local_repository_name>
,请指定要在 registry 中创建的仓库名称,如
ocp4/openshift4
。
如果使用 OpenShift Update Service,请导出一个额外的本地存储库名称,使其包含发行镜像:
$ LOCAL_RELEASE_IMAGES_REPOSITORY='<local_release_images_repository_name>'
对于
<local_release_images_repository_name>
,请指定要在 registry 中创建的仓库名称,如
ocp4/openshift4-release-images
。
导出要进行镜像的存储库名称:
$ PRODUCT_REPO='openshift-release-dev'
对于生产环境版本,必须指定
openshift-release-dev
。
导出 registry pull secret 的路径:
$ LOCAL_SECRET_JSON='<path_to_pull_secret>'
对于
<path_to_pull_secret>
,请指定您创建的镜像 registry 的 pull secret 的绝对路径和文件名。
如果您的集群使用
ImageContentSourcePolicy
对象来配置存储库镜像,则只能将全局 pull secret 用于镜像 registry。您不能在项目中添加 pull secret。
导出发行版本镜像:
$ RELEASE_NAME="ocp-release"
对于生产环境版本,您必须指定
ocp-release
。
为您的服务器导出构架类型,如
x86_64
。
$ ARCHITECTURE=<server_architecture>
导出托管镜像的目录的路径:
$ REMOVABLE_MEDIA_PATH=<path> 1
-
1
-
指定完整路径,包括开始的前斜杠(/)字符。
查看要镜像的镜像和配置清单:
$ oc adm release mirror -a ${LOCAL_SECRET_JSON} --to-dir=${REMOVABLE_MEDIA_PATH}/mirror quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} --dry-run
将版本镜像镜像(mirror)到镜像 registry。
如果您的镜像主机无法访问互联网,请执行以下操作:
将可移动介质连接到连接到互联网的系统。
将镜像和配置清单镜像到可移动介质的目录中:
$ oc adm release mirror -a ${LOCAL_SECRET_JSON} --to-dir=${REMOVABLE_MEDIA_PATH}/mirror quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE}
此命令还会生成镜像发行镜像签名配置映射并将其保存到可移动介质中。
将介质上传到受限网络环境中,并将镜像上传到本地容器 registry。
$ oc image mirror -a ${LOCAL_SECRET_JSON} --from-dir=${REMOVABLE_MEDIA_PATH}/mirror "file://openshift/release:${OCP_RELEASE}*" ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} 1
-
1
-
对于
REMOVABLE_MEDIA_PATH
,您必须使用与镜像镜像时指定的同一路径。
使用
oc
命令行界面(CLI)登录到您要升级的集群。
将镜像发行镜像签名配置映射应用到连接的集群:
$ oc apply -f ${REMOVABLE_MEDIA_PATH}/mirror/config/<image_signature_file> 1
-
1
-
对于
<image_signature_file>
,指定文件的路径和名称,例如
signature-sha256-81154f5c03294534.yaml
。
如果使用 OpenShift Update Service,请将发行镜像镜像到单独的存储库:
$ oc image mirror -a ${LOCAL_SECRET_JSON} ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE} ${LOCAL_REGISTRY}/${LOCAL_RELEASE_IMAGES_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}
如果本地容器 registry 和集群连接到镜像主机,请执行以下操作:
将发行镜像直接推送到本地 registry,并使用以下命令将配置映射应用到集群:
$ oc adm release mirror -a ${LOCAL_SECRET_JSON} --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \
--to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} --apply-release-image-signature
如果包含
--apply-release-image-signature
选项,不要为镜像签名验证创建配置映射。
如果使用 OpenShift Update Service,请将发行镜像镜像到单独的存储库:
$ oc image mirror -a ${LOCAL_SECRET_JSON} ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE} ${LOCAL_REGISTRY}/${LOCAL_RELEASE_IMAGES_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}
11.3. 使用 OpenShift Update Service 在断开连接的环境中更新集群
要获得与连接的集群类似的更新体验,您可以使用以下步骤在断开连接的环境中安装和配置 OpenShift Update Service(OSUS)。
以下步骤概述了如何使用 OSUS 在断开连接的环境中更新集群的高级工作流:
配置对安全 registry 的访问。
更新全局集群 pull secret 以访问您的镜像 registry。
安装 OSUS Operator。
为 OpenShift Update Service 创建图形数据容器镜像。
安装 OSUS 应用程序,并将集群配置为使用本地 OpenShift Update Service。
如连接的集群一样,执行文档中的支持的更新步骤。
11.3.1. 在断开连接的环境中使用 OpenShift Update Service
OpenShift Update Service (OSUS) 为 OpenShift Container Platform 集群提供更新建议。红帽公开托管 OpenShift Update Service,连接的环境中的集群可以通过公共 API 连接到该服务,以检索更新建议。
但是,在断开连接的环境中的集群无法访问这些公共 API 来检索更新信息。要在断开连接的环境中提供类似的更新体验,您可以在本地安装和配置 OpenShift Update Service,使其在断开连接的环境中可用。
单个 OSUS 实例能够为数千台集群提供建议。通过更改 replica 值,OSUS 可以水平扩展到 cater 到更多集群。因此,对于大多数断开连接的用例,一个 OSUS 实例就足够了。例如,红帽为整个连接的集群只运行一个 OSUS 实例。
如果要在不同环境中单独保留更新建议,您可以为每个环境运行一个 OSUS 实例。例如,如果您有单独的测试和暂存环境,您可能不希望在暂存环境中有一个集群来接收对版本 A 的更新建议(如果还没有在测试环境中测试该版本)。
以下小节介绍了如何安装本地 OSUS 实例,并将其配置为为集群提供更新建议。
关于 OpenShift Update 服务
了解更新频道和发行版本
11.3.3. 为 OpenShift Update Service 配置对安全 registry 的访问
如果发行镜像包含在由自定义证书颁发机构签名的 HTTPS X.509 证书的 registry 中,请完成
为镜像 registry 访问配置额外信任存储
的步骤,以及对更新服务进行以下更改。
OpenShift Update Service Operator 需要 registry CA 证书中的配置映射键名称为
updateservice-registry
。
11.3.4. 更新全局集群 pull secret
您可以通过替换当前的 pull secret 或附加新的 pull secret 来更新集群的全局 pull secret。
当用户使用单独的 registry 存储镜像而不使用安装过程中的 registry时,需要这个过程。
您可以使用具有
cluster-admin
角色的用户访问集群。
可选: 要将新的 pull secret 附加到现有 pull secret 中,请完成以下步骤:
输入以下命令下载 pull secret:
$ oc get secret/pull-secret -n openshift-config --template='{{index .data ".dockerconfigjson" | base64decode}}' ><pull_secret_location> 1
-
1
-
提供 pull secret 文件的路径。
输入以下命令来添加新 pull secret:
$ oc registry login --registry="<registry>" \ 1
--auth-basic="<username>:<password>" \ 2
--to=<pull_secret_location> 3
-
1
-
提供新的 registry。您可以在同一个 registry 中包含多个软件仓库,例如:
--registry="<registry/my-namespace/my-repository>"
。
提供新 registry 的凭据。
提供 pull secret 文件的路径。
另外,您可以对 pull secret 文件执行手动更新。
输入以下命令为您的集群更新全局 pull secret:
$ oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson=<pull_secret_location> 1
-
1
-
提供新 pull secret 文件的路径。
该更新将推广至所有节点,可能需要一些时间,具体取决于集群大小。
从 OpenShift Container Platform 4.7.4 开始,对全局 pull secret 的更改不再触发节点排空或重启。
11.3.5. 安装 OpenShift Update Service Operator
要安装 OpenShift Update Service,您必须首先使用 OpenShift Container Platform Web 控制台或 CLI 安装 OpenShift Update Service Operator。
对于在断开连接的环境中安装的集群,Operator Lifecycle Manager 默认无法访问托管在远程 registry 上的红帽提供的 OperatorHub 源,因为这些远程源需要足够的互联网连接。如需更多信息,请参阅
在受限网络中使用 Operator Lifecycle Manager
。
11.3.5.1. 使用 Web 控制台安装 OpenShift Update Service Operator
您可以使用 Web 控制台安装 OpenShift Update Service Operator。
在 Web 控制台中,点
Operators
→
OperatorHub
。
在
Filter by keyword…
字段中输入
Update Service
,以更快地查找 Operator。
从可用的 Operator 列表中选择
OpenShift Update Service
,然后点
Install
。
频道
v1
被选为
Update Channel
,因为它是这个版本中唯一可用的频道。
在
Installation Mode
下选择
A specific namespace on the cluster
。
为
Installed Namespace
选择一个命名空间,或接受推荐的命名空间
openshift-update-service
。
选择一个
批准策略
:
Automatic
策略允许 Operator Lifecycle Manager(OLM)在有新版本可用时自动更新 Operator。
Manual
策略要求集群管理员批准 Operator 更新。
点
Install
。
通过切换到
Operators
→
Installed Operators
页来验证 OpenShift Update Service Operator 是否已安装。
确保
OpenShift Update Service
列在所选命名空间中,
Status
为
Succeeded
。
11.3.5.2. 使用 CLI 安装 OpenShift Update Service Operator
您可以使用 OpenShift CLI(
oc
)安装 OpenShift Update Service Operator。
为 OpenShift Update Service Operator 创建命名空间:
为 OpenShift Update Service Operator 创建一个
Namespace
对象 YAML 文件,如
update-service-namespace.yaml
:
apiVersion: v1
kind: Namespace
metadata:
name: openshift-update-service
annotations:
openshift.io/node-selector: ""
labels:
openshift.io/cluster-monitoring: "true" 1
-
1
-
将
openshift.io/cluster-monitoring
标签设置为在该命名空间中启用 Operator-recommended 集群监控。
创建命名空间:
$ oc create -f <filename>.yaml
$ oc create -f update-service-namespace.yaml
-
通过创建以下对象来安装 OpenShift Update Service Operator:
创建一个
OperatorGroup
对象 YAML 文件,如
update-service-operator-group.yaml
:
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
name: update-service-operator-group
spec:
targetNamespaces:
- openshift-update-service
-
创建一个
OperatorGroup
对象:
$ oc -n openshift-update-service create -f <filename>.yaml
$ oc -n openshift-update-service create -f update-service-operator-group.yaml
-
创建一个
Subscription
对象 YAML 文件,如
update-service-subscription.yaml
:
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: update-service-subscription
spec:
channel: v1
installPlanApproval: "Automatic"
source: "redhat-operators" 1
sourceNamespace: "openshift-marketplace"
name: "cincinnati-operator"
指定提供 Operator 的目录源的名称。对于不使用自定义 Operator Lifecycle Manager(OLM)的集群,指定
redhat-operators
。如果 OpenShift Container Platform 集群安装在断开连接的环境中,请指定配置 Operator Lifecycle Manager (OLM) 时创建的
CatalogSource
对象的名称。
创建
Subscription
对象:
$ oc create -f <filename>.yaml
$ oc -n openshift-update-service create -f update-service-subscription.yaml
OpenShift Update Service Operator 被安装到
openshift-update-service
命名空间,并以
openshift-update-service
命名空间为目标。
验证 Operator 安装:
$ oc -n openshift-update-service get clusterserviceversions
11.3.6. 创建 OpenShift Update Service 图形数据容器镜像
OpenShift Update Service 需要图形数据容器镜像,OpenShift Update Service 从中检索有关频道成员资格和阻止更新边缘的信息。图形数据通常直接从升级图形数据仓库中获取。在互联网连接不可用的环境中,从 init 容器加载此信息是使图形数据可供 OpenShift Update Service 使用的另一种方式。init 容器的角色是提供图形数据的本地副本,在 pod 初始化期间,init 容器会将数据复制到该服务可访问的卷中。
oc-mirror OpenShift CLI (
oc
) 插件除镜像发行镜像外还会创建此图形数据容器镜像。如果您使用 oc-mirror 插件来镜像发行镜像,您可以跳过这个过程。
创建一个 Dockerfile,如
./Dockerfile
,包含以下内容:
FROM registry.access.redhat.com/ubi8/ubi:8.1
RUN curl -L -o cincinnati-graph-data.tar.gz https://api.openshift.com/api/upgrades_info/graph-data
RUN mkdir -p /var/lib/cincinnati-graph-data && tar xvzf cincinnati-graph-data.tar.gz -C /var/lib/cincinnati-graph-data/ --no-overwrite-dir --no-same-owner
CMD ["/bin/bash", "-c" ,"exec cp -rp /var/lib/cincinnati-graph-data/* /var/lib/cincinnati/graph-data"]
使用上一步中创建的 docker 文件来构建图形数据容器镜像,如
registry.example.com/openshift/graph-data:latest
:
$ podman build -f ./Dockerfile -t registry.example.com/openshift/graph-data:latest
将上一步中创建的 graph-data 容器镜像推送到 OpenShift Update Service 可以访问的存储库,如
registry.example.com/openshift/graph-data:latest
:
$ podman push registry.example.com/openshift/graph-data:latest
要将图形数据镜像推送到受限网络中的本地 registry,请将上一步中创建的 graph-data 容器镜像复制到可供 OpenShift Update Service 访问的存储库。运行
oc image mirror --help
查看可用选项。
11.3.7. 创建 OpenShift Update Service 应用程序
您可以使用 OpenShift Container Platform Web 控制台或 CLI 创建 OpenShift Update Service 应用程序。
11.3.7.1. 使用 Web 控制台创建 OpenShift Update Service 应用程序
您可以使用 OpenShift Container Platform Web 控制台使用 OpenShift Update Service Operator 创建 OpenShift Update Service 应用程序。
已安装 OpenShift Update Service Operator。
OpenShift Update Service graph-data 容器镜像已创建并推送到 OpenShift Update Service 访问的存储库。
当前发行版本和更新目标版本已被 mirror 到本地可访问的 registry 中。
在 Web 控制台中,点
Operators
→
Installed Operators
。
从安装的 Operator 列表中选择
OpenShift Update Service
。
点
Update Service
选项卡。
点
Create UpdateService
。
在
Name
字段中输入名称,如
service
。
在
Graph Data Image
字段中输入本地 pullspec,指向在"创建 OpenShift Update Service 图形数据容器镜像"中创建的图形数据容器镜像,如
registry.example.com/openshift/graph-data:latest
。
在
Releases
字段中,输入创建的本地 registry 和存储库,以在"镜像 OpenShift Container Platform 镜像存储库"中包括发行镜像,例如
registry.example.com/ocp4/openshift4-release-images
。
在
Replicas
字段中输入
2
。
单击
Create
以创建 OpenShift Update Service 应用。
验证 OpenShift Update Service 应用程序:
从
Update Service
选项卡中的
UpdateServices
列表中,点刚才创建的 Update Service 应用程序。
单击
Resources
选项卡。
验证每个应用资源的状态是否为
Created
。
11.3.7.2. 使用 CLI 创建 OpenShift Update Service 应用程序
您可以使用 OpenShift CLI(
oc
)来创建 OpenShift Update Service 应用。
已安装 OpenShift Update Service Operator。
OpenShift Update Service graph-data 容器镜像已创建并推送到 OpenShift Update Service 访问的存储库。
当前发行版本和更新目标版本已被 mirror 到本地可访问的 registry 中。
配置 OpenShift Update Service 目标命名空间,如
openshift-update-service
:
$ NAMESPACE=openshift-update-service
命名空间必须与 operator 组中的
targetNamespaces
值匹配。
配置 OpenShift Update Service 应用程序的名称,如
service
:
$ NAME=service
按照"镜像 OpenShift Container Platform 镜像存储库"中配置,为发行镜像配置本地 registry 和存储库,如
registry.example.com/ocp4/openshift4-release-images
:
$ RELEASE_IMAGES=registry.example.com/ocp4/openshift4-release-images
将 graph-data 镜像的本地 pullspec 设置为在"创建 OpenShift Update Service 图形数据容器镜像"中创建的图形数据容器镜像,如
registry.example.com/openshift/graph-data:latest
:
$ GRAPH_DATA_IMAGE=registry.example.com/openshift/graph-data:latest
创建 OpenShift Update Service 应用程序对象:
$ oc -n "${NAMESPACE}" create -f - <<EOF
apiVersion: updateservice.operator.openshift.io/v1
kind: UpdateService
metadata:
name: ${NAME}
spec:
replicas: 2
releases: ${RELEASE_IMAGES}
graphDataImage: ${GRAPH_DATA_IMAGE}
验证 OpenShift Update Service 应用程序:
使用以下命令获取策略引擎路由:
$ while sleep 1; do POLICY_ENGINE_GRAPH_URI="$(oc -n "${NAMESPACE}" get -o jsonpath='{.status.policyEngineURI}/api/upgrades_info/v1/graph{"\n"}' updateservice "${NAME}")"; SCHEME="${POLICY_ENGINE_GRAPH_URI%%:*}"; if test "${SCHEME}" = http -o "${SCHEME}" = https; then break; fi; done
您可能需要轮询,直到命令成功为止。
从策略引擎检索图形。确保为 channel 指定一个有效版本。例如,如果在 OpenShift Container Platform 4.11 中运行,请使用 stable-4.11 :
$ while sleep 10; do HTTP_CODE="$(curl --header Accept:application/json --output /dev/stderr --write-out "%{http_code}" "${POLICY_ENGINE_GRAPH_URI}?channel=stable-4.6")"; if test "${HTTP_CODE}" -eq 200; then break; fi; echo "${HTTP_CODE}"; done
这会轮询到图形请求成功为止,但生成的图形可能为空,具体取决于您已镜像的发行镜像。
基于 RFC-1123 的策略引擎路由名称不能超过 63 个字符。如果您看到 ReconcileCompleted 状态为 false ,原因为 CreateRouteFailed caused by host must conform to DNS 1123 naming convention and must be no more than 63 characters ,请尝试使用较短的名称创建 Update Service。
设置 OpenShift Update Service 应用程序的名称,如
service
:
$ NAME=service
获取策略引擎路由:
$ POLICY_ENGINE_GRAPH_URI="$(oc -n "${NAMESPACE}" get -o jsonpath='{.status.policyEngineURI}/api/upgrades_info/v1/graph{"\n"}' updateservice "${NAME}")"
为拉取图形数据设置补丁:
$ PATCH="{\"spec\":{\"upstream\":\"${POLICY_ENGINE_GRAPH_URI}\"}}"
对 CVO 进行补丁以使用本地 OpenShift 更新服务:
$ oc patch clusterversion version -p $PATCH --type merge
11.4. 在没有 OpenShift Update Service 的断开连接的环境中更新集群
使用以下步骤在断开连接的环境中更新集群,而无需访问 OpenShift Update Service。
-
您必须安装了
oc
命令行界面(CLI)工具。
您必须使用容器镜像置备本地容器镜像 registry,如
镜像 OpenShift Container Platform 镜像存储库
中所述。
您必须可以使用具有
admin
权限的用户访问集群。请参阅
使用 RBAC 定义和应用权限
。
您需要具有最新的
etcd 备份
,以防因为升级失败需要
将集群恢复到以前的状态
。
确保所有机器配置池 (MCP) 都正在运行且未暂停。在更新过程中跳过与暂停 MCP 关联的节点。如果要执行 canary rollout 更新策略,可以暂停 MCP。
如果您的集群使用手动维护的凭证,请更新新发行版本的云供应商资源。如需更多信息,包括如何确定这是集群的要求,请参阅
准备使用手动维护的凭证更新集群
。
如果您运行 Operator 或您已配置了 pod 中断预算,您可能会在升级过程中遇到中断。如果在
PodDisruptionBudget
中将
minAvailable
设置为 1,则节点会排空以应用可能会阻止驱除过程的待处理机器配置。如果重启了几个节点,则所有 pod 只能有一个节点上运行,
PodDisruptionBudget
字段可能会阻止节点排空。
如果您运行 Operator 或您已配置了 pod 中断预算,您可能会在升级过程中遇到中断。如果在
PodDisruptionBudget
中将
minAvailable
设置为 1,则节点会排空以应用可能会阻止驱除过程的待处理机器配置。如果重启了几个节点,则所有 pod 只能有一个节点上运行,
PodDisruptionBudget
字段可能会阻止节点排空。
11.4.2. 暂停 MachineHealthCheck 资源
在升级过程中,集群中的节点可能会临时不可用。对于 worker 节点,机器健康检查可能会认为这样的节点不健康,并重新引导它们。为避免重新引导这样的节点,请在更新集群前暂停所有
MachineHealthCheck
资源。
安装 OpenShift CLI (
oc
) 。
要列出您要暂停的所有可用
MachineHealthCheck
资源,请运行以下命令:
$ oc get machinehealthcheck -n openshift-machine-api
要暂停机器健康检查,请将
cluster.x-k8s.io/paused=""
注解添加到
MachineHealthCheck
资源。运行以下命令:
$ oc -n openshift-machine-api annotate mhc <mhc-name> cluster.x-k8s.io/paused=""
注解的
MachineHealthCheck
资源类似以下 YAML 文件:
apiVersion: machine.openshift.io/v1beta1
kind: MachineHealthCheck
metadata:
name: example
namespace: openshift-machine-api
annotations:
cluster.x-k8s.io/paused: ""
spec:
selector:
matchLabels:
role: worker
unhealthyConditions:
- type: "Ready"
status: "Unknown"
timeout: "300s"
- type: "Ready"
status: "False"
timeout: "300s"
maxUnhealthy: "40%"
status:
currentHealthy: 5
expectedMachines: 5
更新集群后恢复机器健康检查。要恢复检查,请运行以下命令从
MachineHealthCheck
资源中删除暂停注解:
$ oc -n openshift-machine-api annotate mhc <mhc-name> cluster.x-k8s.io/paused-
要使用
oc adm upgrade
命令和
--to-image
选项在断开连接的环境中更新集群,您必须引用与目标发行镜像对应的 sha256 摘要。
在连接到互联网的设备中运行以下命令:
$ oc adm release info -o 'jsonpath={.digest}{"\n"}' quay.io/openshift-release-dev/ocp-release:${OCP_RELEASE_VERSION}-${ARCHITECTURE}
对于
{OCP_RELEASE_VERSION}
,请指定您要更新的 OpenShift Container Platform 版本,如
4.10.16
。
对于
{ARCHITECTURE}
,请指定集群的构架,如
x86_64
,
aarch64
,
s390x
, 或
ppc64le
。
sha256:a8bfba3b6dddd1a2fbbead7dac65fe4fb8335089e4e7cae327f3bad334add31d
复制在更新集群时要使用的 sha256 摘要。
将受限网络集群更新至您下载的发行镜像的 OpenShift Container Platform 版本。
如果您有一个本地 OpenShift Update Service,您可以使用连接的 Web 控制台或 CLI 指令来更新,而不是使用此流程。
您已将新发行版本的镜像镜像(mirror)到 registry。
您已将发行镜像签名 ConfigMap 在新发行版本中应用到集群。
发行镜像签名配置映射允许 Cluster Version Operator (CVO) 通过验证实际镜像签名是否与预期的签名匹配来确保发行镜像的完整性。
获取目标发行镜像的 sha256 摘要。
已安装 OpenShift CLI(
oc
)。
您暂停所有
MachineHealthCheck
资源。
更新集群:
$ oc adm upgrade --allow-explicit-upgrade --to-image ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}@<digest> 1
-
1
-
<digest>
值是目标发行镜像的 sha256 摘要,例如
sha256:81154f5c03294534e1eaf0319bef7a601134f891689ccede5d705ef659aa8c92
如果镜像 registry 使用
ImageContentSourcePolicy
,可以使用 Canonical registry 名称而非
LOCAL_REGISTRY
。
您只能为具有
ImageContentSourcePolicy
对象的集群配置全局 pull secret。您不能在项目中添加 pull secret。
11.4.5. 配置镜像 registry 存储库镜像
通过设置容器 registry 存储库镜像,您可以进行以下操作:
配置 OpenShift Container Platform 集群,以便重定向从源镜像 registry 上的存储库拉取(pull)镜像的请求,并通过已镜像 (mirror) 的镜像 registry 上的存储库来解决该请求。
为每个目标存储库识别多个已镜像 (mirror)的存储库,以确保如果一个镜像停止运作,仍可使用其他镜像。
OpenShift Container Platform 中存储库镜像的属性包括:
镜像拉取(pull)可应对 registry 停机的问题。
在断开连接的环境中的集群可以从关键位置(如 quay.io)拉取镜像,并让公司防火墙后面的 registry 提供请求的镜像。
发出镜像拉取(pull)请求时尝试特定 registry 顺序,通常最后才会尝试持久性 registry。
您所输入的镜像信息会添加到 OpenShift Container Platform 集群中每个节点上的
/etc/containers/registries.conf
文件中。
当节点从源存储库中请求镜像时,它会依次尝试每个已镜像的存储库,直到找到所请求的内容。如果所有镜像均失败,集群则会尝试源存储库。如果成功,则镜像拉取至节点中。
可通过以下方式设置存储库镜像:
在 OpenShift Container Platform 安装中:
通过拉取(pull) OpenShift Container Platform 所需的容器镜像,然后将这些镜像放至公司防火墙后,即可将 OpenShift Container Platform 安装到受限网络中的数据中心。
安装 OpenShift Container Platform 后:
即使没有在 OpenShift Container Platform 安装期间配置镜像 (mirror),之后您仍可使用
ImageContentSourcePolicy
对象进行配置。
以下流程提供安装后镜像配置,您可在此处创建
ImageContentSourcePolicy
对象来识别:
您希望镜像 (mirror) 的容器镜像存储库的源。
您希望为其提供从源存储库请求的内容的每个镜像存储库的单独条目。
您只能为具有
ImageContentSourcePolicy
对象的集群配置全局 pull secret。您不能在项目中添加 pull secret。
使用具有
cluster-admin
角色的用户访问集群。
通过以下方法配置已镜像的存储库:
按照
Red Hat Quay 存储库镜像
中所述,使用 Red Hat Quay 来设置已镜像的存储库。使用 Red Hat Quay 有助于您将镜像从一个存储库复制到另一存储库,并可随着时间的推移重复自动同步这些存储库。
使用
skopeo
等工具手动将镜像从源目录复制到已镜像的存储库。
例如:在 Red Hat Enterprise Linux(RHEL 7 或 RHEL 8)系统上安装 skopeo RPM 软件包后,使用
skopeo
命令,如下例所示:
$ skopeo copy \
docker://registry.access.redhat.com/ubi8/ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455ebaa6 \
docker://example.io/example/ubi-minimal
在本例中,您有一个名为
example.io
的容器镜像 registry,其中包含一个名为
example
的镜像存储库,您希望将
ubi8/ubi-minimal
镜像从
registry.access.redhat.com
复制到此镜像存储库。创建该 registry 后,您可将 OpenShift Container Platform 集群配置为将源存储库的请求重定向到已镜像的存储库。
登录您的 OpenShift Container Platform 集群。
创建
ImageContentSourcePolicy
文件(如:
registryrepomirror.yaml
),将源和镜像 (mirror) 替换为您自己的 registry、存储库对和镜像中的源和镜像:
apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
name: ubi8repo
spec:
repositoryDigestMirrors:
- mirrors:
- example.io/example/ubi-minimal 1
- example.com/example/ubi-minimal 2
source: registry.access.redhat.com/ubi8/ubi-minimal 3
- mirrors:
- mirror.example.com/redhat
source: registry.redhat.io/openshift4 4
- mirrors:
- mirror.example.com
source: registry.redhat.io 5
- mirrors:
- mirror.example.net/image
source: registry.example.com/example/myimage 6
- mirrors:
- mirror.example.net
source: registry.example.com/example 7
- mirrors:
- mirror.example.net/registry-example-com
source: registry.example.com 8
-
1
-
指明镜像 registry 和存储库的名称。
表示每个目标仓库的多个镜像仓库。如果一个镜像停机,则目标仓库可以使用另一个镜像。
指明包含所镜像内容的 registry 和存储库。
您可以在 registry 中配置命名空间以使用该命名空间中的任何镜像。如果您使用 registry 域作为源,
ImageContentSourcePolicy
资源将应用到 registry 中的所有存储库。
如果配置 registry 名称,则
ImageContentSourcePolicy
资源将应用到源 registry 中的所有软件仓库。
拉取镜像
mirror.example.net/image@sha256:…
。
从 mirror
mirror.example.net/myimage@sha256:…
的源 registry 命名空间中拉取镜像
myimage
。
从 mirror registry
mirror.example.net/registry-example-com/example/myimage@sha256:…
拉取镜像
registry.example.com/example/myimage
。
ImageContentSourcePolicy
资源会应用到源 registry 中的所有仓库到到 mirror registry
mirror.example.net/registry-example-com
。
创建新的
ImageContentSourcePolicy
对象:
$ oc create -f registryrepomirror.yaml
创建
ImageContentSourcePolicy
对象后,新的设置将部署到每个节点,集群开始使用已镜像的存储库来响应源存储库请求。
要检查是否应用了已镜像的配置设置,在其中一个节点上执行以下内容。
列出您的节点:
$ oc get node
11.4.6. 镜像镜像目录的范围,以减少集群节点重启的频率
您可以在存储库级别或更广泛的 registry 级别限定镜像目录。一个范围广泛的
ImageContentSourcePolicy
资源可减少节点在响应资源更改时需要重启的次数。
要强化
ImageContentSourcePolicy
资源中镜像目录的范围,请执行以下步骤。
安装 OpenShift Container Platform CLI
oc
。
以具有
cluster-admin
特权的用户身份登录。
配置镜像镜像目录,以便在断开连接的集群中使用。
运行以下命令,为
<local_registry>
、
<pull_spec>
和
<pull_secret_file>
指定值:
$ oc adm catalog mirror <local_registry>/<pull_spec> <local_registry> -a <pull_secret_file> --icsp-scope=registry
-
<local_registry>
-
您为断开连接的集群配置的本地 registry,如
local.registry:5000
。
-
<pull_spec>
-
是断开连接的 registry 中配置的 pull 规格,如
redhat/redhat-operator-index:v4.11
-
<pull_secret_file>
-
是
.json
文件格式的
registry.redhat.io
pull secret。您可以从
Red Hat OpenShift Cluster Manager 下载 pull secret
。
oc adm catalog mirror
命令创建
/redhat-operator-index-manifests
目录,并生成
imageContentSourcePolicy.yaml
、
catalogSource.yaml
和
mapping.txt
文件。
将新的
ImageContentSourcePolicy
资源应用到集群:
$ oc apply -f imageContentSourcePolicy.yaml
11.5. 从集群中删除 OpenShift Update Service
要从集群中删除 OpenShift Update Service (OSUS) 的本地副本,您必须首先删除 OSUS 应用程序,然后卸载 OSUS Operator。
11.5.1. 删除 OpenShift Update Service 应用程序
您可以使用 OpenShift Container Platform Web 控制台或 CLI 删除 OpenShift Update Service 应用程序。
11.5.1.1. 使用 Web 控制台删除 OpenShift Update Service 应用程序
您可以使用 OpenShift Container Platform Web 控制台使用 OpenShift Update Service Operator 删除 OpenShift Update Service 应用程序。
已安装 OpenShift Update Service Operator。
在 Web 控制台中,点
Operators
→
Installed Operators
。
从安装的 Operator 列表中选择
OpenShift Update Service
。
点
Update Service
选项卡。
从安装的 OpenShift Update Service 应用列表中,选择要删除的应用,然后单击
Delete UpdateService
。
从
Delete UpdateService?
确认对话框中,单击
Delete
以确认删除。
11.5.1.2. 使用 CLI 删除 OpenShift Update Service 应用程序
您可以使用 OpenShift CLI(
oc
)删除 OpenShift Update Service 应用。
使用 OpenShift Update Service 应用程序在其中创建的命名空间获取 OpenShift Update Service 应用程序的名称,如
openshift-update-service
:
$ oc get updateservice -n openshift-update-service
11.5.2. 卸载 OpenShift Update Service Operator
您可以使用 OpenShift Container Platform Web 控制台或 CLI 卸载 OpenShift Update Service Operator。
11.5.2.1. 使用 Web 控制台卸载 OpenShift Update Service Operator
您可以使用 OpenShift Container Platform Web 控制台卸载 OpenShift Update Service Operator。
所有 OpenShift Update Service 应用都已删除。
在 Web 控制台中,点
Operators
→
Installed Operators
。
从安装的 Operator 列表中选择
OpenShift Update Service
并点
Uninstall Operator
。
在
Uninstall Operator?
确认对话框中点
Uninstall
确认卸载。
11.5.2.2. 使用 CLI 卸载 OpenShift Update Service Operator
您可以使用 OpenShift CLI(
oc
)卸载 OpenShift Update Service Operator。
所有 OpenShift Update Service 应用都已删除。
更改到包含 OpenShift Update Service Operator 的项目,如
openshift-update-service
:
$ oc project openshift-update-service
第 12 章 更新在 vSphere 上运行的节点上运行的硬件
您必须确保您在 vSphere 中运行的节点在 OpenShift Container Platform 支持的硬件版本上运行。目前,硬件版本 15 或更高版本都支持集群中的 vSphere 虚拟机。
您可以立即更新虚拟硬件,或在 vCenter 中计划更新。
OpenShift Container Platform 版本 4.11 需要 VMware 虚拟硬件版本 15 或更高版本。
要在 VMware vSphere 上更新虚拟机 (VM) 的硬件,请单独更新您的虚拟机,以减少集群停机风险。
12.1.1. 为 vSphere 上的 control plane 节点更新虚拟硬件
要减少停机的风险,建议按顺序更新 control plane 节点。这样可确保 Kubernetes API 保持可用,etcd 保留仲裁。
在托管 OpenShift Container Platform 集群的 vCenter 实例中具有执行所需权限的权限。
您的 vSphere ESXi 主机是 7.0U2 或更高版本。
列出集群中的 control plane 节点。
$ oc get nodes -l node-role.kubernetes.io/master
12.1.2. 更新 vSphere 上计算节点的虚拟硬件
要降低停机的风险,建议按顺序更新计算节点。
可以在并行给定工作负载中更新多个计算节点,可以接受具有
NotReady
状态的多个节点。管理员负责确保所需的计算节点可用。
在托管 OpenShift Container Platform 集群的 vCenter 实例中具有执行所需权限的权限。
您的 vSphere ESXi 主机是 7.0U2 或更高版本。
列出集群中的计算节点。
$ oc get nodes -l node-role.kubernetes.io/worker
12.1.3. 为 vSphere 上的模板更新虚拟硬件
先决条件
-
在托管 OpenShift Container Platform 集群的 vCenter 实例中具有执行所需权限的权限。
您的 vSphere ESXi 主机是 7.0U2 或更高版本。
如果 RHCOS 模板被配置为 vSphere 模板 ,请在进行下一步前参阅
将模板转换为一个虚拟机
。
从模板转换后,请不要打开虚拟机电源。
更新 vSphere 客户端中的虚拟机。如需更多信息,请参阅 VMware 文档中的
手动升级虚拟机兼容性
。
将 vSphere 客户端中的虚拟机从虚拟机转换为模板。如需更多信息,请参阅 VMware 文档中的
将虚拟机转换为 vSphere 客户端中的模板
。
了解如何撤离节点上的 pod
12.2. 在 vSphere 上调度虚拟硬件的更新
虚拟机开启或重新启动时,可以计划进行虚拟硬件更新。您可以按照 VMware 文档中的
虚拟机兼容性升级调度
专门在 vCenter 中调度虚拟硬件更新。
在 OpenShift Container Platform 升级前调度升级时,在 OpenShift Container Platform 升级过程中重启节点时会进行虚拟硬件更新。
第 13 章 更新包含 Special Resource Operator 的集群
当更新包含 Special Resource Operator (SRO) 的集群时,务必要考虑新的内核模块与当前由 SRO 加载的内核模块兼容。您可以运行 preflight 检查来确认 SRO 能够升级内核模块。
13.2. 对 Special Resource Operator 运行 preflight 检查
在更新包括 Special Resource Operator (SRO) 的集群前,您可以使用以下示例步骤检查内核模块版本的兼容性。
有一个正在运行的 OpenShift Container Platform 集群。
已安装 OpenShift CLI(
oc
)。
以具有
cluster-admin
权限的用户身份登录 OpenShift CLI。
已安装 SRO。
创建以下 preflight 验证自定义资源定义 (CRD),并将 YAML 保存为
prevalidation.yaml
。
apiVersion: sro.openshift.io/v1beta1
kind: PreflightValidation
metadata:
name: preflight
namespace: preflight
spec:
updateImage: quay.io/openshift-release-dev/ocp-release@sha256:f7f252c39b64601c8ac3de737a584ba4f6016b1f4b17801d726ca2fd15492878 1
-
1
-
此处指定更新镜像的名称。
运行以下命令启动验证检查:
$ oc apply -f prevalidation.yaml
验证
-
运行以下命令,检查自定义资源 (CR) 的状态:
$ oc describe preflightvalidations.sro.openshift.io/v1beta1 preflight
Status:
Cr Statuses:
Last Transition Time: 2022-08-02T08:48:45Z
Name: simple-oot
Status Reason: Verification successful, all driver-containers for the next kernel version are present
Verification Stage: Image
Verification Status: True
Events: <none>
preflight 检查会继续运行,直到验证所有 CR。您可以重复上述命令以检查状态。验证所有 CR 后,您应该删除 preflight CR。
-
特殊资源 Operator
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at
http://creativecommons.org/licenses/by-sa/3.0/
. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux
® is the registered trademark of Linus Torvalds in the United States and other countries.
Java
® is a registered trademark of Oracle and/or its affiliates.
XFS
® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL
® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js
® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
|