2.2. 准备使用手动维护的凭证更新集群
默认情况下,带有手动维护凭证的集群的 Cloud Credential Operator(CCO)U gradable
状态为 False
。
-
对于次发行版本(例如从 4.12 升级到 4.13),这个状态会阻止升级,直到您解决了任何更新的权限并
添加了 CloudCredential
资源,以指示下一版本根据需要更新权限。此注解将Upgradable
状态更改为True
。 - 对于 z-stream 版本(例如从 4.13.0 到 4.13.1),没有添加或更改任何权限,因此不会阻止升级。
在使用手动维护的凭证更新集群前,您必须在要升级到的 OpenShift Container Platform 版本的发行镜像中包含任何新的或更改的凭证。
2.2.1. 使用手动维护的凭证更新集群的要求
在通过 Cloud Credential Operator (CCO) 更新使用手动维护凭证的集群前,您必须为新版本更新云供应商资源。
如果使用 CCO 实用程序 (ccoctl
) 配置集群的云凭证管理,请使用 ccoctl
实用程序更新资源。配置为在没有 ccoctl
工具的情况下使用手动模式的集群需要手动更新资源。
更新云供应商资源后,您必须更新集群的 upgradeable-to
注解,以指示它已准备好更新。
更新云供应商资源和 upgradeable-to
注解的过程只能通过命令行工具完成。
2.2.1.1. 云凭证配置选项并根据平台类型更新要求
有些平台只支持在一个模式中使用 CCO。对于在这些平台上安装的集群,平台类型决定了凭证更新要求。
对于支持多个模式中使用 CCO 的平台,您必须确定集群配置为使用哪种模式,并对该配置执行所需操作。
图 2.1. 按平台类型进行凭证更新要求
- Red Hat OpenStack Platform (RHOSP) 和 VMware vSphere
这些平台不支持在手动模式中使用 CCO。这些平台上的集群会自动处理云供应商资源的更改,不需要对
upgradeable-to
的注解进行更新。这些平台上的集群管理员应该跳过更新过程的手动维护凭证部分。
- IBM Cloud 和 Nutanix
在这些平台上安装的集群使用
ccoctl
工具进行配置。这些平台上的集群管理员必须执行以下操作:
-
为新版本提取并准备
CredentialsRequest
自定义资源 (CR)。 -
为新版本配置
ccoctl
工具,并使用它来更新云供应商资源。 -
指明集群可以使用
upgradeable-to
注解进行更新。
-
为新版本提取并准备
- Microsoft Azure Stack Hub
这些集群使用带有长期凭证的手动模式,且不使用
ccoctl
工具。这些平台上的集群管理员必须执行以下操作:
-
为新版本提取并准备
CredentialsRequest
自定义资源 (CR)。 - 为新版本手动更新云供应商资源。
-
指明集群可以使用
upgradeable-to
注解进行更新。
-
为新版本提取并准备
- Amazon Web Services (AWS)、全局 Microsoft Azure 和 Google Cloud Platform (GCP)
在这些平台上安装的集群支持多个 CCO 模式。
所需的更新过程取决于集群配置为使用的模式。如果您不确定 CCO 在集群中要使用的模式,您可以使用 Web 控制台或 CLI 来决定此信息。
2.2.1.2. 使用 Web 控制台确定 Cloud Credential Operator 模式
您可以使用 Web 控制台确定 Cloud Credential Operator (CCO) 配置为使用哪种模式。
只有 Amazon Web Services (AWS)、全局 Microsoft Azure 和 Google Cloud Platform (GCP) 集群支持多个 CCO 模式。
先决条件
- 您可以使用集群管理员权限访问 OpenShift Container Platform 帐户。
流程
-
以具有
cluster-admin
角色的用户身份登录到 OpenShift Container Platform web 控制台。 -
导航至 Administration
Cluster Settings。 - 在 Cluster Settings 页面中,选择 Configuration 选项卡。
- 在 Configuration resource 下,选择 CloudCredential。
- 在 CloudCredential 详情页中,选择 YAML 选项卡。
在 YAML 块中,检查
spec.credentialsMode
的值。以下是可能的值,但它们可能并不会在所有平台上都被支持:-
''
:CCO 在默认模式下运行。在这个配置中,CCO 以 mint 或 passthrough 模式运行,具体取决于安装期间提供的凭证。 -
Mint
:CCO 在 mint 模式中运行。 -
Passthrough
:CCO 在 passthrough 模式运行。 -
Manual
:CCO 以手动模式运行。
重要要确定 AWS、GCP 或全局 Microsoft Azure 集群的特定配置,其
spec.credentialsMode
为''
、Mint
或Manual
,您必须进一步调查。AWS 和 GCP 集群支持使用删除了 root secret 的 mint 模式。如果集群被特别配置为使用 mint 模式或默认使用 mint 模式,则必须在更新前确定集群中是否存在 root secret。
使用手动模式的 AWS、GCP 或全局 Microsoft Azure 集群可能会被配置为从使用 AWS STS、GCP Workload Identity 或 Microsoft Entra Workload ID 的集群外部创建和管理云凭证。您可以通过检查集群
Authentication
对象来确定集群是否使用了此策略。-
只使用 mint 模式的 AWS 或 GCP 集群:要确定集群是否在没有 root secret 的情况下运行,请进入到 Workloads
Secrets 并为您的云供应商查找 root secret。 注意确保将 项目 下拉菜单设置为 All Projects。
平台 Secret 名称 AWS
aws-creds
GCP
gcp-credentials
- 如果您看到这些值之一,您的集群将使用 mint 或 passthrough 模式,并带有 root secret。
- 如果没有看到这些值,您的集群将以 mint 模式使用 CCO,并删除 root secret。
仅使用手动模式的 AWS、GCP 或全局 Microsoft Azure 集群 :要确定集群是否被配置为从集群外部创建和管理云凭证,您必须检查集群
Authentication
对象 YAML 值。-
导航至 Administration
Cluster Settings。 - 在 Cluster Settings 页面中,选择 Configuration 选项卡。
- 在 Configuration resource 下,选择 Authentication。
- 在 Authentication details 页面中,选择 YAML 选项卡。
在 YAML 块中,检查
.spec.serviceAccountIssuer
参数的值。-
包含与云供应商关联的 URL 的值表示 CCO 使用手动模式和组件的短期凭证。集群被配置为使用
ccoctl
实用程序从集群外创建和管理云凭证。 -
空值 (
''
) 表示集群在手动模式中使用 CCO,但没有使用ccoctl
工具进行配置。
-
包含与云供应商关联的 URL 的值表示 CCO 使用手动模式和组件的短期凭证。集群被配置为使用
-
导航至 Administration
后续步骤
- 如果您要更新以 mint 或 passthrough 模式运行的 CCO 的集群,且存在 root secret,则不需要更新任何云供应商资源,并可以继续进入更新过程的下一部分。
- 如果您的集群在 mint 模式中使用删除了 root secret 的 CCO,则必须重新使用管理员级别的凭证重新恢复凭证 secret,然后才能继续更新过程的下一部分。
如果您的集群使用 CCO 实用程序 (
ccoctl
) 配置,您必须执行以下操作:-
为新版本提取并准备
CredentialsRequest
自定义资源 (CR)。 -
为新版本配置
ccoctl
工具,并使用它来更新云供应商资源。 -
更新
upgradeable-to
注解,以指示集群已准备好更新。
-
为新版本提取并准备
如果您的集群以手动模式使用 CCO,但没有使用
ccoctl
工具配置,则必须执行以下操作:-
为新版本提取并准备
CredentialsRequest
自定义资源 (CR)。 - 为新版本手动更新云供应商资源。
-
更新
upgradeable-to
注解,以指示集群已准备好更新。
-
为新版本提取并准备
其他资源
2.2.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 或全局 Microsoft Azure 集群的特定配置,其
spec.credentialsMode
为''
、Mint
或Manual
,您必须进一步调查。AWS 和 GCP 集群支持使用删除了 root secret 的 mint 模式。如果集群被特别配置为使用 mint 模式或默认使用 mint 模式,则必须在更新前确定集群中是否存在 root secret。
使用手动模式的 AWS、GCP 或全局 Microsoft Azure 集群可能会被配置为从使用 AWS STS、GCP Workload Identity 或 Microsoft Entra Workload ID 的集群外部创建和管理云凭证。您可以通过检查集群
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 或全局 Microsoft Azure 集群:要确定集群是否被配置为从集群外部创建和管理云凭证,请运行以下命令:
$ oc get authentication cluster \ -o jsonpath \ --template='{ .spec.serviceAccountIssuer }'
此命令显示集群
Authentication
对象中.spec.serviceAccountIssuer
参数的值。-
与云供应商关联的 URL 的输出表示 CCO 使用手动模式和组件的短期凭证。集群被配置为使用
ccoctl
实用程序从集群外创建和管理云凭证。 -
空输出表示集群以手动模式使用 CCO,但没有使用
ccoctl
工具进行配置。
-
与云供应商关联的 URL 的输出表示 CCO 使用手动模式和组件的短期凭证。集群被配置为使用
后续步骤
- 如果您要更新以 mint 或 passthrough 模式运行的 CCO 的集群,且存在 root secret,则不需要更新任何云供应商资源,并可以继续进入更新过程的下一部分。
- 如果您的集群在 mint 模式中使用删除了 root secret 的 CCO,则必须重新使用管理员级别的凭证重新恢复凭证 secret,然后才能继续更新过程的下一部分。
如果您的集群使用 CCO 实用程序 (
ccoctl
) 配置,您必须执行以下操作:-
为新版本提取并准备
CredentialsRequest
自定义资源 (CR)。 -
为新版本配置
ccoctl
工具,并使用它来更新云供应商资源。 -
更新
upgradeable-to
注解,以指示集群已准备好更新。
-
为新版本提取并准备
如果您的集群以手动模式使用 CCO,但没有使用
ccoctl
工具配置,则必须执行以下操作:-
为新版本提取并准备
CredentialsRequest
自定义资源 (CR)。 - 为新版本手动更新云供应商资源。
-
更新
upgradeable-to
注解,以指示集群已准备好更新。
-
为新版本提取并准备
其他资源
2.2.2. 提取和准备凭证请求资源
在更新以手动模式使用 Cloud Credential Operator (CCO) 的集群前,您必须提取并准备新版本的 CredentialsRequest
自定义资源 (CR)。
先决条件
-
安装与更新版本的版本匹配的 OpenShift CLI(
oc
)。 -
使用具有
cluster-admin
权限的用户登陆到集群。
流程
运行以下命令,获取您要应用的更新的 pull spec:
$ oc adm upgrade
这个命令的输出包括 pull specs 用于可用的更新,如下所示:
输出部分示例
... Recommended updates: VERSION IMAGE 4.16.0 quay.io/openshift-release-dev/ocp-release@sha256:6a899c54dda6b844bb12a247e324a0f6cde367e880b73ba110c056df6d018032 ...
运行以下命令,使用您要使用的发行镜像设置
$RELEASE_IMAGE
变量:$ RELEASE_IMAGE=<update_pull_spec>
其中
<update_pull_spec>
是您要使用的发行镜像的 pull spec。例如:quay.io/openshift-release-dev/ocp-release@sha256:6a899c54dda6b844bb12a247e324a0f6cde367e880b73ba110c056df6d018032
运行以下命令,从 OpenShift Container Platform 发行镜像中提取
CredentialsRequest
自定义资源 (CR) 列表:$ oc adm release extract \ --from=$RELEASE_IMAGE \ --credentials-requests \ --included \1 --to=<path_to_directory_for_credentials_requests> 2
此命令为每个
CredentialsRequest
对象创建一个 YAML 文件。对于发行镜像中的每个
CredentialsRequest
CR,请确保集群中存在与spec.secretRef.namespace
字段中的文本匹配的命名空间。此字段是保存凭证配置的生成的 secret 的位置。AWS
CredentialsRequest
对象示例apiVersion: cloudcredential.openshift.io/v1 kind: CredentialsRequest metadata: name: cloud-credential-operator-iam-ro namespace: openshift-cloud-credential-operator spec: providerSpec: apiVersion: cloudcredential.openshift.io/v1 kind: AWSProviderSpec statementEntries: - effect: Allow action: - iam:GetUser - iam:GetUserPolicy - iam:ListAccessKeys resource: "*" secretRef: name: cloud-credential-operator-iam-ro-creds namespace: openshift-cloud-credential-operator 1
- 1
- 此字段指示必须存在的命名空间来保存生成的 secret。
其他平台的
CredentialsRequest
CR 具有与不同平台值类似的格式。对于任何集群的
CredentialsRequest
CR 还没有在spec.secretRef.namespace
中指定的命名空间,运行以下命令创建命名空间:$ oc create namespace <component_namespace>
后续步骤
-
如果使用 CCO 实用程序 (
ccoctl
) 配置了集群的云凭证管理,请为集群更新配置ccoctl
工具,并使用它来更新云供应商资源。 -
如果您的集群没有使用
ccoctl
工具配置,请手动更新云供应商资源。
2.2.3. 为集群更新配置 Cloud Credential Operator 工具
要升级以手动模式使用 Cloud Credential Operator (CCO) 从集群外部创建和管理云凭证集群,提取并准备 CCO 实用程序 (ccoctl
) 二进制文件。
ccoctl
工具是在 Linux 环境中运行的 Linux 二进制文件。
先决条件
- 您可以访问具有集群管理员权限的 OpenShift Container Platform 帐户。
-
已安装 OpenShift CLI(
oc
)。
-
集群被配置为使用
ccoctl
实用程序从集群外创建和管理云凭证。 -
您已从 OpenShift Container Platform 发行镜像中提取
CredentialsRequest
自定义资源 (CR),并确保集群中存在与spec.secretRef.namespace
字段中文本匹配的命名空间。
流程
运行以下命令,为 OpenShift Container Platform 发行镜像设置变量:
$ RELEASE_IMAGE=$(oc get clusterversion -o jsonpath={..desired.image})
运行以下命令,从 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.<rhel_version>" \1 -a ~/.pull-secret
- 1
- 对于
<rhel_version>
,请指定与主机使用的 Red Hat Enterprise Linux (RHEL) 版本对应的值。如果没有指定值,则默认使用ccoctl.rhel8
。以下值有效:-
rhel8
: 为使用 RHEL 8 的主机指定这个值。 -
rhel9
:为使用 RHEL 9 的主机指定这个值。
-
运行以下命令更改权限以使
ccoctl
可执行:$ chmod 775 ccoctl.<rhel_version>
验证
要验证
ccoctl
是否准备就绪,可以尝试显示帮助文件。运行命令时使用相对文件名,例如:$ ./ccoctl.rhel9
输出示例
OpenShift credentials provisioning tool Usage: ccoctl [command] Available Commands: aws Manage credentials objects for AWS cloud azure Manage credentials objects for Azure gcp Manage credentials objects for Google cloud help Help about any command ibmcloud Manage credentials objects for IBM Cloud nutanix Manage credentials objects for Nutanix Flags: -h, --help help for ccoctl Use "ccoctl [command] --help" for more information about a command.
2.2.4. 使用 Cloud Credential Operator 工具更新云供应商资源
升级使用 CCO 实用程序 (ccoctl
) 配置的 OpenShift Container Platform 集群的过程与在安装过程中创建云供应商资源类似。
在 AWS 集群中,一些 ccoctl
命令会发出 AWS API 调用来创建或修改 AWS 资源。您可以使用 --dry-run
标志来避免 API 调用。使用此标志可在本地文件系统中创建 JSON 文件。您可以使用 --cli-input-json
参数查看和修改 JSON 文件,然后使用 AWS CLI 工具应用它们。
先决条件
-
您已从 OpenShift Container Platform 发行镜像中提取
CredentialsRequest
自定义资源 (CR),并确保集群中存在与spec.secretRef.namespace
字段中文本匹配的命名空间。 -
您已从发行镜像中提取并配置了
ccoctl
二进制文件。
流程
通过为您的云供应商运行 命令,使用
ccoctl
工具处理所有CredentialsRequest
对象。以下命令处理CredentialsRequest
对象:例 2.1. Amazon Web Services (AWS)
$ ccoctl aws create-all \1 --name=<name> \2 --region=<aws_region> \3 --credentials-requests-dir=<path_to_credentials_requests_directory> \4 --output-dir=<path_to_ccoctl_output_dir> \5 --create-private-s3-bucket 6
- 1
- 要单独创建 AWS 资源,请使用"使用自定义"内容在 AWS 上安装集群中的"创建 AWS 资源"。如果您需要在修改 AWS 资源前查看
ccoctl
工具创建的 JSON 文件,或者ccoctl
工具用于创建 AWS 资源的进程自动满足您的机构要求时,这个选项可能很有用。 - 2
- 指定用于标记创建用于跟踪的任何云资源的名称。
- 3
- 指定在其中创建云资源的 AWS 区域。
- 4
- 指定包含组件
CredentialsRequest
对象文件的目录。 - 5
- 可选:指定您希望
ccoctl
实用程序在其中创建对象的目录。默认情况下,实用程序在运行命令的目录中创建对象。 - 6
- 可选:默认情况下,
ccoctl
实用程序将 OpenID Connect (OIDC) 配置文件存储在公共 S3 存储桶中,并使用 S3 URL 作为公共 OIDC 端点。要将 OIDC 配置存储在 IAM 身份提供程序通过公共 CloudFront 发行版 URL 访问的专用 S3 存储桶中,请使用--create-private-s3-bucket
参数。
例 2.2. Google Cloud Platform (GCP)
$ ccoctl gcp create-all \ --name=<name> \1 --region=<gcp_region> \2 --project=<gcp_project_id> \3 --credentials-requests-dir=<path_to_credentials_requests_directory> \4 --output-dir=<path_to_ccoctl_output_dir> 5
例 2.3. IBM Cloud
$ ccoctl ibmcloud create-service-id \ --credentials-requests-dir=<path_to_credential_requests_directory> \1 --name=<cluster_name> \2 --output-dir=<installation_directory> \3 --resource-group-name=<resource_group_name> 4
例 2.4. Microsoft Azure
$ ccoctl azure create-managed-identities \ --name <azure_infra_name> \1 --output-dir ./output_dir \ --region <azure_region> \2 --subscription-id <azure_subscription_id> \3 --credentials-requests-dir <path_to_directory_for_credentials_requests> \ --issuer-url "${OIDC_ISSUER_URL}" \4 --dnszone-resource-group-name <azure_dns_zone_resourcegroup_name> \5 --installation-resource-group-name "${AZURE_INSTALL_RG}" 6
- 1
name
参数的值用于创建 Azure 资源组。要使用现有的 Azure 资源组而不是创建新 Azure 资源组,请使用现有组名称指定--oidc-resource-group-name
参数作为其值。- 2
- 指定现有集群的区域。
- 3
- 指定现有集群的订阅 ID。
- 4
- 指定现有集群的 OIDC 签发者 URL。您可以运行以下命令来获取这个值:
$ oc get authentication cluster \ -o jsonpath \ --template='{ .spec.serviceAccountIssuer }'
- 5
- 指定包含 DNS 区的资源组的名称。
- 6
- 指定 Azure 资源组名称。您可以运行以下命令来获取这个值:
$ oc get infrastructure cluster \ -o jsonpath \ --template '{ .status.platformStatus.azure.resourceGroupName }'
例 2.5. Nutanix
$ ccoctl nutanix create-shared-secrets \ --credentials-requests-dir=<path_to_credentials_requests_directory> \1 --output-dir=<ccoctl_output_dir> \2 --credentials-source-filepath=<path_to_credentials_file> 3
对于每个
CredentialsRequest
对象,ccoctl
会创建所需的供应商资源和 OpenShift Container Platform 发行镜像中的每个CredentialsRequest
对象中定义的权限策略。运行以下命令,将 secret 应用到集群:
$ ls <path_to_ccoctl_output_dir>/manifests/*-credentials.yaml | xargs -I{} oc apply -f {}
验证
您可以通过查询云供应商来验证是否已创建所需的供应商资源和权限策略。如需更多信息,请参阅有关列出角色或服务帐户的云供应商文档。
后续步骤
-
更新
upgradeable-to
注解,以指示集群已准备好升级。
其他资源
2.2.5. 手动更新云供应商资源
在使用手动维护的凭证升级集群前,您必须为您要升级到的发行镜像为新凭证创建 secret。您还必须查看现有凭证所需的权限,并满足这些组件的新版本中任何新权限要求。
先决条件
-
您已从 OpenShift Container Platform 发行镜像中提取
CredentialsRequest
自定义资源 (CR),并确保集群中存在与spec.secretRef.namespace
字段中文本匹配的命名空间。
流程
为新发行镜像添加的任何
CredentialsRequest
自定义资源创建 YAML 文件。secret 必须使用在spec.secretRef
中为每个CredentialsRequest
定义的命名空间和 secret 名称存储。例 2.6. AWS YAML 文件示例
使用 secret 的 AWS
CredentialsRequest
对象示例apiVersion: cloudcredential.openshift.io/v1 kind: CredentialsRequest metadata: name: <component_credentials_request> namespace: openshift-cloud-credential-operator ... spec: providerSpec: apiVersion: cloudcredential.openshift.io/v1 kind: AWSProviderSpec statementEntries: - effect: Allow action: - s3:CreateBucket - s3:DeleteBucket resource: "*" ... secretRef: name: <component_secret> namespace: <component_namespace> ...
AWS
Secret
对象示例apiVersion: v1 kind: Secret metadata: name: <component_secret> namespace: <component_namespace> data: aws_access_key_id: <base64_encoded_aws_access_key_id> aws_secret_access_key: <base64_encoded_aws_secret_access_key>
例 2.7. Azure YAML 文件示例
注意全局 Azure 和 Azure Stack Hub 使用相同的
CredentialsRequest
对象和 secret 格式。带有 secret 的 Azure
CredentialsRequest
对象示例apiVersion: cloudcredential.openshift.io/v1 kind: CredentialsRequest metadata: name: <component_credentials_request> namespace: openshift-cloud-credential-operator ... spec: providerSpec: apiVersion: cloudcredential.openshift.io/v1 kind: AzureProviderSpec roleBindings: - role: Contributor ... secretRef: name: <component_secret> namespace: <component_namespace> ...
Azure
Secret
对象示例apiVersion: v1 kind: Secret metadata: name: <component_secret> namespace: <component_namespace> data: azure_subscription_id: <base64_encoded_azure_subscription_id> azure_client_id: <base64_encoded_azure_client_id> azure_client_secret: <base64_encoded_azure_client_secret> azure_tenant_id: <base64_encoded_azure_tenant_id> azure_resource_prefix: <base64_encoded_azure_resource_prefix> azure_resourcegroup: <base64_encoded_azure_resourcegroup> azure_region: <base64_encoded_azure_region>
例 2.8. GCP YAML 文件示例
带有 secret 的 GCP
CredentialsRequest
对象示例apiVersion: cloudcredential.openshift.io/v1 kind: CredentialsRequest metadata: name: <component_credentials_request> namespace: openshift-cloud-credential-operator ... spec: providerSpec: apiVersion: cloudcredential.openshift.io/v1 kind: GCPProviderSpec predefinedRoles: - roles/iam.securityReviewer - roles/iam.roleViewer skipServiceCheck: true ... secretRef: name: <component_secret> namespace: <component_namespace> ...
GCP
Secret
对象示例apiVersion: v1 kind: Secret metadata: name: <component_secret> namespace: <component_namespace> data: service_account.json: <base64_encoded_gcp_service_account_file>
-
如果存储在 secret 中的任何现有凭证的
CredentialsRequest
自定义资源更改了其权限要求,请根据需要更新权限。
后续步骤
-
更新
upgradeable-to
注解,以指示集群已准备好升级。
2.2.6. 表示集群已准备好升级
默认情况下,带有手动维护凭证的集群的 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
要添加的文本
... metadata: annotations: cloudcredential.openshift.io/upgradeable-to: <version_number> ...
其中
<version_number>
是您要升级到的版本,格式为x.y.z
。例如,OpenShift Container Platform 4.12.2 使用4.12.2
。添加可升级状态进行更改的注解后,可能需要几分钟时间。
验证
-
在 Web 控制台的 Administrator 视角中,导航到 Administration
Cluster Settings。 要查看 CCO 状态详情,请点击 Cluster Operators 列表中的 cloud-credential。
-
如果 Conditions 部分中的 Upgradeable 状态为 False,请验证
upgradeable-to
注解没有拼写错误。
-
如果 Conditions 部分中的 Upgradeable 状态为 False,请验证
- 当 Conditions 部分中的 Upgradeable 状态为 True 时,开始 OpenShift Container Platform 升级。