支持控制台（Console）开发人员开始试用联系人

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. 按平台类型进行凭证更新要求

决策树根据配置的 CCO 凭证模式，显示集群的可能更新路径。
Red Hat OpenStack Platform (RHOSP) 和 VMware vSphere

这些平台不支持在手动模式中使用 CCO。这些平台上的集群会自动处理云供应商资源的更改，不需要对 upgradeable-to 的注解进行更新。

这些平台上的集群管理员应该跳过更新过程的手动维护凭证部分。

IBM Cloud 和 Nutanix

在这些平台上安装的集群使用 ccoctl 工具进行配置。

这些平台上的集群管理员必须执行以下操作：

  1. 为新版本提取并准备 CredentialsRequest 自定义资源 (CR)。
  2. 为新版本配置 ccoctl 工具，并使用它来更新云供应商资源。
  3. 指明集群可以使用 upgradeable-to 注解进行更新。
Microsoft Azure Stack Hub

这些集群使用带有长期凭证的手动模式，且不使用 ccoctl 工具。

这些平台上的集群管理员必须执行以下操作：

  1. 为新版本提取并准备 CredentialsRequest 自定义资源 (CR)。
  2. 为新版本手动更新云供应商资源。
  3. 指明集群可以使用 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 帐户。

流程

  1. 以具有 cluster-admin 角色的用户身份登录到 OpenShift Container Platform web 控制台。
  2. 导航至 Administration Cluster Settings。
  3. 在 Cluster Settings 页面中，选择 Configuration 选项卡。
  4. 在 Configuration resource 下，选择 CloudCredential。
  5. 在 CloudCredential 详情页中，选择 YAML 选项卡。

  6. 在 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 对象来确定集群是否使用了此策略。

  7. 只使用 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。

  8. 仅使用手动模式的 AWS、GCP 或全局 Microsoft Azure 集群 ：要确定集群是否被配置为从集群外部创建和管理云凭证，您必须检查集群 Authentication 对象 YAML 值。

    1. 导航至 Administration Cluster Settings。
    2. 在 Cluster Settings 页面中，选择 Configuration 选项卡。
    3. 在 Configuration resource 下，选择 Authentication。
    4. 在 Authentication details 页面中，选择 YAML 选项卡。

    5. 在 YAML 块中，检查 .spec.serviceAccountIssuer 参数的值。

      • 包含与云供应商关联的 URL 的值表示 CCO 使用手动模式和组件的短期凭证。集群被配置为使用 ccoctl 实用程序从集群外创建和管理云凭证。
      • 空值 ('') 表示集群在手动模式中使用 CCO，但没有使用 ccoctl 工具进行配置。

后续步骤

  • 如果您要更新以 mint 或 passthrough 模式运行的 CCO 的集群，且存在 root secret，则不需要更新任何云供应商资源，并可以继续进入更新过程的下一部分。
  • 如果您的集群在 mint 模式中使用删除了 root secret 的 CCO，则必须重新使用管理员级别的凭证重新恢复凭证 secret，然后才能继续更新过程的下一部分。

  • 如果您的集群使用 CCO 实用程序 (ccoctl) 配置，您必须执行以下操作：

    1. 为新版本提取并准备 CredentialsRequest 自定义资源 (CR)。
    2. 为新版本配置 ccoctl 工具，并使用它来更新云供应商资源。
    3. 更新 upgradeable-to 注解，以指示集群已准备好更新。

  • 如果您的集群以手动模式使用 CCO，但没有使用 ccoctl 工具配置，则必须执行以下操作：

    1. 为新版本提取并准备 CredentialsRequest 自定义资源 (CR)。
    2. 为新版本手动更新云供应商资源。
    3. 更新 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)。

流程

  1. 以具有 cluster-admin 角色的用户身份登录到集群中的 oc。

  2. 要确定 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 对象来确定集群是否使用了此策略。

  3. 仅使用 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。

  4. 仅使用手动模式的 AWS、GCP 或全局 Microsoft Azure 集群：要确定集群是否被配置为从集群外部创建和管理云凭证，请运行以下命令： 

    $ oc get authentication cluster \
  -o jsonpath \
  --template='{ .spec.serviceAccountIssuer }'

    此命令显示集群 Authentication 对象中 .spec.serviceAccountIssuer 参数的值。

    • 与云供应商关联的 URL 的输出表示 CCO 使用手动模式和组件的短期凭证。集群被配置为使用 ccoctl 实用程序从集群外创建和管理云凭证。
    • 空输出表示集群以手动模式使用 CCO，但没有使用 ccoctl 工具进行配置。

后续步骤

  • 如果您要更新以 mint 或 passthrough 模式运行的 CCO 的集群，且存在 root secret，则不需要更新任何云供应商资源，并可以继续进入更新过程的下一部分。
  • 如果您的集群在 mint 模式中使用删除了 root secret 的 CCO，则必须重新使用管理员级别的凭证重新恢复凭证 secret，然后才能继续更新过程的下一部分。

  • 如果您的集群使用 CCO 实用程序 (ccoctl) 配置，您必须执行以下操作：

    1. 为新版本提取并准备 CredentialsRequest 自定义资源 (CR)。
    2. 为新版本配置 ccoctl 工具，并使用它来更新云供应商资源。
    3. 更新 upgradeable-to 注解，以指示集群已准备好更新。

  • 如果您的集群以手动模式使用 CCO，但没有使用 ccoctl 工具配置，则必须执行以下操作：

    1. 为新版本提取并准备 CredentialsRequest 自定义资源 (CR)。
    2. 为新版本手动更新云供应商资源。
    3. 更新 upgradeable-to 注解，以指示集群已准备好更新。

其他资源

2.2.2. 提取和准备凭证请求资源

在更新以手动模式使用 Cloud Credential Operator (CCO) 的集群前，您必须提取并准备新版本的 CredentialsRequest 自定义资源 (CR)。

先决条件

  • 安装与更新版本的版本匹配的 OpenShift CLI(oc)。
  • 使用具有 cluster-admin 权限的用户登陆到集群。

流程

  1. 运行以下命令，获取您要应用的更新的 pull spec： 

    $ oc adm upgrade

    这个命令的输出包括 pull specs 用于可用的更新，如下所示：

    输出部分示例

    ...
Recommended updates:

VERSION IMAGE
4.14.0  quay.io/openshift-release-dev/ocp-release@sha256:6a899c54dda6b844bb12a247e324a0f6cde367e880b73ba110c056df6d018032
...

  2. 运行以下命令，使用您要使用的发行镜像设置 $RELEASE_IMAGE 变量： 

    $ RELEASE_IMAGE=<update_pull_spec>

    其中 <update_pull_spec> 是您要使用的发行镜像的 pull spec。例如： 

    quay.io/openshift-release-dev/ocp-release@sha256:6a899c54dda6b844bb12a247e324a0f6cde367e880b73ba110c056df6d018032

  3. 运行以下命令，从 OpenShift Container Platform 发行镜像中提取 CredentialsRequest 自定义资源 (CR) 列表： 

    $ oc adm release extract \
  --from=$RELEASE_IMAGE \
  --credentials-requests \
  --included \1
  --to=<path_to_directory_for_credentials_requests> 2
    1
    --included 参数只包含目标发行版本所需的特定集群配置的清单。
    2
    指定要存储 CredentialsRequest 对象的目录的路径。如果指定的目录不存在，这个命令会创建它。

    此命令为每个 CredentialsRequest 对象创建一个 YAML 文件。

  4. 对于发行镜像中的每个 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 具有与不同平台值类似的格式。

  5. 对于任何集群的 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 字段中文本匹配的命名空间。

流程

  1. 运行以下命令，为 OpenShift Container Platform 发行镜像设置变量： 

    $ RELEASE_IMAGE=$(oc get clusterversion -o jsonpath={..desired.image})

  2. 运行以下命令，从 OpenShift Container Platform 发行镜像获取 CCO 容器镜像： 

    $ CCO_IMAGE=$(oc adm release info --image-for='cloud-credential-operator' $RELEASE_IMAGE -a ~/.pull-secret)
    注意

    确保 $RELEASE_IMAGE 的架构与将使用 ccoctl 工具的环境架构相匹配。

  3. 运行以下命令，将 CCO 容器镜像中的 ccoctl 二进制文件提取到 OpenShift Container Platform 发行镜像中： 

    $ oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret

  4. 运行以下命令更改权限以使 ccoctl 可执行： 

    $ chmod 775 ccoctl

验证

  • 要验证 ccoctl 是否准备就绪，可以尝试显示帮助文件。运行命令时使用相对文件名，例如： 

    $ ./ccoctl.rhel9

    输出示例

    OpenShift credentials provisioning tool

Usage:
  ccoctl [command]

Available Commands:
  alibabacloud Manage credentials objects for alibaba cloud
  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 二进制文件。

流程

  1. 通过为您的云供应商运行 命令，使用 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
    1
    为用于跟踪的所有创建 GCP 资源指定用户定义的名称。
    2
    指定在其中创建云资源的 GCP 区域。
    3
    指定在其中创建云资源的 GCP 项目 ID。
    4
    指定包含 CredentialsRequest 清单文件的目录，以创建 GCP 服务帐户。
    5
    可选：指定您希望 ccoctl 实用程序在其中创建对象的目录。默认情况下，实用程序在运行命令的目录中创建对象。

    例 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
    1
    指定包含组件 CredentialsRequest 对象文件的目录。
    2
    指定 OpenShift Container Platform 集群的名称。
    3
    可选：指定您希望 ccoctl 实用程序在其中创建对象的目录。默认情况下，实用程序在运行命令的目录中创建对象。
    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
    1
    指定包含组件 CredentialsRequests 对象文件的目录路径。
    2
    可选：指定您希望 ccoctl 实用程序在其中创建对象的目录。默认情况下，实用程序在运行命令的目录中创建对象。
    3
    可选：指定包含凭证数据 YAML 文件的目录。默认情况下，ccoctl 预期此文件位于 <home_directory>/.nutanix/credentials 中。

    对于每个 CredentialsRequest 对象，ccoctl 会创建所需的供应商资源和 OpenShift Container Platform 发行镜像中的每个 CredentialsRequest 对象中定义的权限策略。

  2. 运行以下命令，将 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 字段中文本匹配的命名空间。

流程

  1. 为新发行镜像添加的任何 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>

  2. 如果存储在 secret 中的任何现有凭证的 CredentialsRequest 自定义资源更改了其权限要求，请根据需要更新权限。

后续步骤

  • 更新 upgradeable-to 注解，以指示集群已准备好升级。

其他资源

2.2.6. 表示集群已准备好升级

默认情况下，带有手动维护凭证的集群的 Cloud Credential Operator(CCO)U gradable 状态为 False。

先决条件

  • 对于您要升级到的发行镜像，您可以手动处理任何新凭证，或使用 Cloud Credential Operator 实用程序 (ccoctl) 处理。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 以具有 cluster-admin 角色的用户身份登录到集群中的 oc。

  2. 运行以下命令，编辑 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。

    添加可升级状态进行更改的注解后，可能需要几分钟时间。

验证

  1. 在 Web 控制台的 Administrator 视角中，导航到 Administration Cluster Settings。

  2. 要查看 CCO 状态详情，请点击 Cluster Operators 列表中的 cloud-credential。

    • 如果 Conditions 部分中的 Upgradeable 状态为 False，请验证 upgradeable-to 注解没有拼写错误。
  3. 当 Conditions 部分中的 Upgradeable 状态为 True 时，开始 OpenShift Container Platform 升级。
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

© 2024 Red Hat, Inc.