19.4. 手動モードの使用
手動モードは、Alibaba Cloud、Amazon Web Services (AWS)、Microsoft Azure、IBM Cloud、および Google Cloud Platform (GCP) でサポートされています。
手動モードでは、ユーザーは Cloud Credential Operator (CCO) の代わりにクラウド認証情報を管理します。このモードを使用するには、実行またはインストールしている OpenShift Container Platform バージョンのリリースイメージの CredentialsRequest
CR を検査し、基礎となるクラウドプロバイダーで対応する認証情報を作成し、クラスターのクラウドプロバイダーのすべての CredentialsRequest
CR に対応するために Kubernetes Secret を正しい namespace に作成する必要があります。
手動モードを使用すると、クラスターに管理者レベルの認証情報を保存する必要なく、各クラスターコンポーネントに必要なパーミッションのみを指定できます。このモードでは、AWS パブリック IAM エンドポイントへの接続も必要ありません。ただし、各アップグレードについて、パーミッションを新規リリースイメージを使用して手動で調整する必要があります。
手動モードを使用するようにクラウドプロバイダーを設定する方法については、クラウドプロバイダーの手動認証情報管理オプションを参照してください。
19.4.1. クラスター外で作成および管理されるクラウド認証情報を使用する手動モード
手動モードを使用する AWS または GCP クラスターは、AWS Security Token Service (STS) または GCP Workload Identity を使用して、クラスターの外部からクラウド認証情報を作成および管理するように設定されている場合があります。この設定では、CCO は異なるコンポーネントに一時的な認証情報を使用します。
詳細は、Amazon Web Services Security Token Service での手動モードの使用 または GCP ワークロードアイデンティティーでの手動モードの使用 を参照してください。
19.4.2. 手動で維持された認証情報によるクラウドプロバイダーリソースの更新
手動でメンテナンスされる認証情報でクラスターをアップグレードする前に、アップグレードするリリースイメージ用に認証情報を新規作成する必要があります。また、既存の認証情報に必要なアクセス許可を確認し、それらのコンポーネントの新しいリリースでの新しいアクセス許可要件に対応する必要があります。
手順
新規リリースの
CredentialsRequest
カスタムリソースを抽出して検査します。クラウドプロバイダーのインストールコンテンツの IAM の手動作成についてのセクションでは、クラウドに必要な認証情報を取得し、使用する方法について説明します。
クラスターで手動でメンテナンスされる認証情報を更新します。
-
新規リリースイメージによって追加される
CredentialsRequest
カスタムリソースの新規のシークレットを作成します。 -
シークレットに保存される既存の認証情報の
CredentialsRequest
カスタムリソースにパーミッション要件を変更した場合は、必要に応じてパーミッションを更新します。
-
新規リリースイメージによって追加される
クラスターでクラスター機能を使用して 1 つ以上のオプションコンポーネントを無効にする場合は、無効なコンポーネントの
CredentialsRequest
カスタムリソースを削除します。AWS 上の OpenShift Container Platform 4.12 の
credrequests
ディレクトリーの内容の例0000_30_machine-api-operator_00_credentials-request.yaml 1 0000_50_cloud-credential-operator_05-iam-ro-credentialsrequest.yaml 2 0000_50_cluster-image-registry-operator_01-registry-credentials-request.yaml 3 0000_50_cluster-ingress-operator_00-ingress-credentials-request.yaml 4 0000_50_cluster-network-operator_02-cncc-credentials.yaml 5 0000_50_cluster-storage-operator_03_credentials_request_aws.yaml 6
GPC 上の OpenShift Container Platform 4.12 の
credrequests
ディレクトリーの内容の例0000_26_cloud-controller-manager-operator_16_credentialsrequest-gcp.yaml 1 0000_30_machine-api-operator_00_credentials-request.yaml 2 0000_50_cloud-credential-operator_05-gcp-ro-credentialsrequest.yaml 3 0000_50_cluster-image-registry-operator_01-registry-credentials-request-gcs.yaml 4 0000_50_cluster-ingress-operator_00-ingress-credentials-request.yaml 5 0000_50_cluster-network-operator_02-cncc-credentials.yaml 6 0000_50_cluster-storage-operator_03_credentials_request_gcp.yaml 7
次のステップ
-
upgradeable-to
アノテーションを更新して、クラスターをアップグレードする準備ができていることを示します。
19.4.2.1. クラスターがアップグレードの準備ができていることを示す
手動で維持された認証情報をを含むクラスターの Cloud Credential Operator (CCO) の upgradable
ステータスはデフォルトで 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
を使用します。アノテーションを追加してから、upgradeable のステータスが変更されるまで、数分かかる場合があります。
検証
-
Web コンソールの Administrator パースペクティブで、Administration
Cluster Settings に移動します。 CCO ステータスの詳細を表示するには、Cluster Operators リストで cloud-credential をクリックします。
-
Conditions セクションの Upgradeable ステータスが False の場合に、
upgradeable-to
アノテーションに間違いがないことを確認します。
-
Conditions セクションの Upgradeable ステータスが False の場合に、
- Conditions セクションの Upgradeable ステータスが True の場合、OpenShift Container Platform のアップグレードを開始します。