クラスターの更新

手順

1. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージを取得します。

   $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')

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. 以下のコマンドを実行して、OpenShift Container Platform リリースイメージ内の CCO コンテナーイメージから ccoctl バイナリーを抽出します。

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

4. 次のコマンドを実行して、権限を変更して ccoctl を実行可能にします。

   $ chmod 775 ccoctl

手順

1. 以下のコマンドを実行して、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 オブジェクトのリストが格納されるディレクトリーです。ディレクトリーが存在しない場合、このコマンドはディレクトリーを作成します。

2. リリースイメージの各 credentialsrequest について、spec.secretRef.namespace フィールドのテキストと一致するネームスペースがクラスターに存在することを確認します。このフィールドには、クレデンシャルの設定を保持する生成されたシークレットが保存されます。

   サンプル 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

   このフィールドは、生成されたシークレットを保持するために存在する必要がある namespace を示します。

   他のプラットフォームの CredentialsRequest CR も同様の形式ですが、プラットフォーム固有の異なる値があります。

3. クラスターが spec.secretRef.namespace で指定された名前の namespace をまだ持っていない CredentialsRequest CR については、次のコマンドを実行して namespace を作成します。

   $ oc create namespace <component_namespace>

4. ccoctl ツールを使用し、適切なクラウドプロバイダーのコマンドを実行して credrequests ディレクトリー内のすべての CredentialsRequest オブジェクトを処理します。以下のコマンドは CredentialsRequest オブジェクトを処理します。

   • Alibaba Cloud: ccoctl alibabacloud create-ram-users
   • Amazon Web Services (AWS): ccoctl aws create-iam-roles
   • Google Cloud Platform (GCP): ccoctl gcp create-all
   • IBM Cloud: ccoctl ibmcloud create-service-id
   • Nutanix: ccoctl nutanix create-shared-secrets
   重要

   プラットフォームによって異なる必要な引数および特別な考慮事項について、詳しくはクラウドプロバイダーのインストールコンテンツで ccoctl ユーティリティーの手順を参照してください。

   OpenShift Container Platform リリースイメージの各 CredentialsRequest オブジェクトで定義されているとおり、ccoctl は CredentialsRequest オブジェクトごとに必要なプロバイダーリソースと権限ポリシーを作成します。

5. 次のコマンドを実行して、シークレットをクラスターに適用します。

   $ ls <path_to_ccoctl_output_dir>/manifests/*-credentials.yaml | xargs -I{} oc apply -f {}

手順

1. 新規リリースの CredentialsRequest カスタムリソースを抽出して検査します。

   クラウドプロバイダーのインストールコンテンツの IAM の手動作成についてのセクションでは、クラウドに必要な認証情報を取得し、使用する方法について説明します。

2. クラスターで手動でメンテナンスされる認証情報を更新します。

   • 新規リリースイメージによって追加される CredentialsRequest カスタムリソースの新規のシークレットを作成します。
   • シークレットに保存される既存の認証情報の CredentialsRequest カスタムリソースにパーミッション要件を変更した場合は、必要に応じてパーミッションを更新します。

3. クラスターでクラスター機能を使用して 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

   1

   Machine API Operator CR が必要です。

   2

   Cloud Credential Operator CR が必要です。

   3

   Image Registry Operator CR が必要です。

   4

   Ingress Operator CR が必要です。

   5

   Network Operator CR が必要です。

   6

   Storage Operator CR はオプションのコンポーネントであり、クラスターで無効になっている場合があります。

   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

   1

   Cloud Controller Manager Operator CR が必要です。

   2

   Machine API Operator CR が必要です。

   3

   Cloud Credential Operator CR が必要です。

   4

   Image Registry Operator CR が必要です。

   5

   Ingress Operator CR が必要です。

   6

   Network Operator CR が必要です。

   7

   Storage Operator CR はオプションのコンポーネントであり、クラスターで無効になっている場合があります。

手順

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 を使用します。

   アノテーションを追加してから、upgradeable のステータスが変更されるまで、数分かかる場合があります。

検証

1. Web コンソールの Administrator パースペクティブで、Administration → Cluster Settings に移動します。

2. CCO ステータスの詳細を表示するには、Cluster Operators リストで cloud-credential をクリックします。

   • Conditions セクションの Upgradeable ステータスが False の場合に、upgradeable-to アノテーションに間違いがないことを確認します。
3. Conditions セクションの Upgradeable ステータスが True の場合、OpenShift Container Platform のアップグレードを開始します。

手順

1. 新規リリースの CredentialsRequest カスタムリソースを抽出して検査します。

   クラウドプロバイダーのインストールコンテンツの IAM の手動作成についてのセクションでは、クラウドに必要な認証情報を取得し、使用する方法について説明します。

2. クラスターで手動でメンテナンスされる認証情報を更新します。

   • 新規リリースイメージによって追加される CredentialsRequest カスタムリソースの新規のシークレットを作成します。
   • シークレットに保存される既存の認証情報の CredentialsRequest カスタムリソースにパーミッション要件を変更した場合は、必要に応じてパーミッションを更新します。

3. クラスターでクラスター機能を使用して 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

   1

   Machine API Operator CR が必要です。

   2

   Cloud Credential Operator CR が必要です。

   3

   Image Registry Operator CR が必要です。

   4

   Ingress Operator CR が必要です。

   5

   Network Operator CR が必要です。

   6

   Storage Operator CR はオプションのコンポーネントであり、クラスターで無効になっている場合があります。

   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

   1

   Cloud Controller Manager Operator CR が必要です。

   2

   Machine API Operator CR が必要です。

   3

   Cloud Credential Operator CR が必要です。

   4

   Image Registry Operator CR が必要です。

   5

   Ingress Operator CR が必要です。

   6

   Network Operator CR が必要です。

   7

   Storage Operator CR はオプションのコンポーネントであり、クラスターで無効になっている場合があります。

手順

1. OpenShift Container Platform Web コンソールにログインします。
2. Compute → MachineHealthChecks に移動します。

3. マシンヘルスチェックを一時停止するには、cluster.x-k8s.io/paused="" アノテーションを各 MachineHealthCheck リソースに追加します。たとえば、アノテーションを machine-api-termination-handler リソースに追加するには、以下の手順を実行します。

   1. machine-api-termination-handler の横にあるオプションメニュー をクリックし､Edit annotations をクリックします。
   2. アノテーションの編集 ダイアログで、更に追加 をクリックします。
   3. キー および 値 フィールドにそれぞれ cluster.x-k8s.io/paused と "" の値を追加し、保存 をクリックします。

手順

1. Web コンソールから、Administration → Cluster Settings をクリックし、Details タブの内容を確認します。

2. 本番クラスターの場合は、チャネル が、stable-4.12 など、更新するバージョンの正しいチャネルに設定されていることを確認してください。

   重要

   実稼働クラスターの場合は、stable-*、eus-* または fast-* チャネルにサブスクライブする必要があります。

   注記

   次のマイナーバージョンに移行する準備ができたら、そのマイナーバージョンに対応するチャネルを選択します。更新チャネルの宣言が早ければ早いほど、クラスターはターゲットバージョンへの更新パスをより効果的に推奨できます。クラスターは、利用可能なすべての可能な更新プログラムを評価し、最適な更新プログラムの推奨事項を選択するために、しばらく時間がかかる場合があります。更新の推奨事項は、その時点で利用可能な更新オプションに基づいているため、時間の経過とともに変化する可能性があります。

   ターゲットマイナーバージョンへの更新パスが表示されない場合は、次のマイナーバージョンがパスで利用可能になるまで、現在のバージョンの最新のパッチリリースにクラスターを更新し続けます。

   • Update Status が Updates Available ではない場合、クラスターを更新することはできません。
   • Select Channel は、クラスターが実行されているか、更新されるクラスターのバージョンを示します。

3. 更新するバージョンを選択し、Save をクリックします。

   入力チャネルの Update Status が Update to <product-version> in progress 切り替わり、Operator およびノードの進捗バーを監視して、クラスター更新の進捗を確認できます。

   注記

   バージョン 4.y から 4.(y+1) などの次のマイナーバージョンにクラスターを更新する場合、新たな機能に依存するワークロードをデプロイする前にノードがアップグレードされていることを確認することが推奨されます。更新されていないワーカーノードを持つプールは Cluster Settings ページに表示されます。

4. 更新が完了し、Cluster Version Operator が利用可能な更新を更新したら、追加の更新が現在のチャネルで利用可能かどうかを確認します。

   • 更新が利用可能な場合は、更新ができなくなるまで、現在のチャネルでの更新を継続します。
   • 利用可能な更新がない場合は、チャネル を次のマイナーバージョンの stable-*、eus-* または fast-* チャネルに変更し、そのチャネルで必要なバージョンに更新します。

   必要なバージョンに達するまで、いくつかの中間更新を実行する必要がある場合があります。

手順

1. Administration → Cluster Settings に移動し、version をクリックします。

2. YAML タブをクリックし、upstream パラメーター値を編集します。

   出力例

     ...
     spec:
       clusterID: db93436d-7b05-42cc-b856-43e11ad2d31a
       upstream: '<update-server-url>' 1
     ...

   1

   <update-server-url> 変数は、更新サーバーの URL を指定します。

   デフォルトの upstream は https://api.openshift.com/api/upgrades_info/v1/graph です。

3. Save をクリックします。

手順

1. 一時停止する利用可能なすべての MachineHealthCheck リソースをリスト表示するには、以下のコマンドを実行します。

   $ oc get machinehealthcheck -n openshift-machine-api

2. マシンヘルスチェックを一時停止するには、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 リソースから pause アノテーションを削除します。

   $ oc -n openshift-machine-api annotate mhc <mhc-name> cluster.x-k8s.io/paused-

手順

1. 利用可能な更新を確認し、適用する必要のある更新のバージョン番号をメモします。

   $ oc adm upgrade

   出力例

   Cluster version is 4.9.23
   Upstream is unset, so the cluster will use an appropriate default.
   Channel: stable-4.9 (available channels: candidate-4.10, candidate-4.9, fast-4.10, fast-4.9, stable-4.10, stable-4.9, eus-4.10)
   Recommended updates:
   VERSION IMAGE
   4.9.24  quay.io/openshift-release-dev/ocp-release@sha256:6a899c54dda6b844bb12a247e324a0f6cde367e880b73ba110c056df6d018032
   4.9.25  quay.io/openshift-release-dev/ocp-release@sha256:2eafde815e543b92f70839972f585cc52aa7c37aa72d5f3c8bc886b0fd45707a
   4.9.26  quay.io/openshift-release-dev/ocp-release@sha256:3ccd09dd08c303f27a543351f787d09b83979cd31cf0b4c6ff56cd68814ef6c8
   4.9.27  quay.io/openshift-release-dev/ocp-release@sha256:1c7db78eec0cf05df2cead44f69c0e4b2c3234d5635c88a41e1b922c3bedae16
   4.9.28  quay.io/openshift-release-dev/ocp-release@sha256:4084d94969b186e20189649b5affba7da59f7d1943e4e5bc7ef78b981eafb7a8
   4.9.29  quay.io/openshift-release-dev/ocp-release@sha256:b04ca01d116f0134a102a57f86c67e5b1a3b5da1c4a580af91d521b8fa0aa6ec
   4.9.31  quay.io/openshift-release-dev/ocp-release@sha256:2a28b8ebb53d67dd80594421c39e36d9896b1e65cb54af81fbb86ea9ac3bf2d7
   4.9.32  quay.io/openshift-release-dev/ocp-release@sha256:ecdb6d0df547b857eaf0edb5574ddd64ca6d9aff1fa61fd1ac6fb641203bedfa

   注記
   • 利用可能な更新がない場合でも、サポート対象であるが推奨はされない更新が利用できる可能性があります。詳細は、条件付き更新パスに沿った更新 を参照してください。
   • EUS-to-EUS チャンネル更新を実行する方法の詳細と情報は、関連情報セクションにリストされている EUS-to-EUS アップグレードを実行するための準備 ページを参照してください。

2. 組織の要件に基づいて、適切な更新チャネルを設定します。たとえば、チャネルを stable-4.13 または fast-4.13 に設定できます。チャネルの詳細は、追加リソースセクションにリストされている 更新チャネルとリリースについて を参照してください。

   $ oc adm upgrade channel <channel>

   たとえば、チャネルを stable-4.12 に設定するには、以下を実行します。

   $ oc adm upgrade channel stable-4.12

   重要

   実稼働クラスターの場合、stable-*、eus-* または fast-* チャネルにサブスクライブする必要があります。

   注記

   次のマイナーバージョンに移行する準備ができたら、そのマイナーバージョンに対応するチャネルを選択します。更新チャネルの宣言が早ければ早いほど、クラスターはターゲットバージョンへの更新パスをより効果的に推奨できます。クラスターは、利用可能なすべての可能な更新プログラムを評価し、最適な更新プログラムの推奨事項を選択するために、しばらく時間がかかる場合があります。更新の推奨事項は、その時点で利用可能な更新オプションに基づいているため、時間の経過とともに変化する可能性があります。

   ターゲットマイナーバージョンへの更新パスが表示されない場合は、次のマイナーバージョンがパスで利用可能になるまで、現在のバージョンの最新のパッチリリースにクラスターを更新し続けます。

3. 更新を適用します。

   • 最新バージョンに更新するには、以下を実行します。

     $ oc adm upgrade --to-latest=true 1

   • 特定のバージョンに更新するには、以下を実行します。

     $ oc adm upgrade --to=<version> 1

     1 1

     <version> は、oc adm upgrade コマンドの出力から取得した更新バージョンです。

4. クラスターバージョン Operator を確認します。

   $ oc adm upgrade

5. 更新が完了したら、クラスターのバージョンが新たなバージョンに更新されていることを確認できます。

   $ oc get clusterversion

   出力例

   Cluster version is <version>
   
   Upstream is unset, so the cluster will use an appropriate default.
   Channel: stable-4.10 (available channels: candidate-4.10, candidate-4.11, eus-4.10, fast-4.10, fast-4.11, stable-4.10)
   
   No updates available. You may force an upgrade to a specific release image, but doing so might not be supported and might result in downtime or data loss.

6. クラスターを次のマイナーバージョン (バージョン X.y から X.(y+1) など) に更新する場合は、新しい機能に依存するワークロードをデプロイする前に、ノードが更新されていることを確認することが推奨されます。

   $ oc get nodes

   出力例

   NAME                           STATUS   ROLES    AGE   VERSION
   ip-10-0-168-251.ec2.internal   Ready    master   82m   v1.25.0
   ip-10-0-170-223.ec2.internal   Ready    master   82m   v1.25.0
   ip-10-0-179-95.ec2.internal    Ready    worker   70m   v1.25.0
   ip-10-0-182-134.ec2.internal   Ready    worker   70m   v1.25.0
   ip-10-0-211-16.ec2.internal    Ready    master   82m   v1.25.0
   ip-10-0-250-100.ec2.internal   Ready    worker   69m   v1.25.0

手順

1. リスクが適用される可能性があるため推奨されない場合に更新の説明を表示するには、次のコマンドを実行します。

   $ oc adm upgrade --include-not-recommended

2. クラスター管理者が潜在的な既知のリスクを評価し、それが現在のクラスターに受け入れられると判断した場合、管理者は次のコマンドを実行して安全ガードを放棄し、更新を続行できます。

   $ oc adm upgrade --allow-not-recommended --to <version> <.>

   <.> <version> は、前のコマンドの出力から取得した、サポートされているが推奨されていない更新バージョンです。

1. ワーカープールに基づいてカスタムマシン設定プール (MCP) を作成します。

   注記

   MCP の maxUnavailable 設定を変更して、任意の時点で更新できるパーセンテージまたはマシン数を指定できます。デフォルトは 1 です。

2. ノードセレクターをカスタム MCP に追加します。残りのクラスターと同時に更新しない各ノードに、一致するラベルをノードに追加します。このラベルは、ノードを MCP に関連付けます。

   重要

   ノードからデフォルトのワーカーラベルを削除しないでください。クラスター内でノードを適切に機能させるには、ノードにロールラベルが必要です。

3. 更新プロセスの一部として更新しない MCP を一時停止します。

   注記

   MCP を一時停止すると、kube-apiserver-to-kubelet-signer 自動 CA 証明書のローテーションも一時停止します。新しい CA 証明書は、インストール日と古い証明書の 292 日で生成され、インストール日から 365 日は削除されます。次の自動 CA 証明書のローテーションまでの所要時間については、Understanding CA cert auto updates in Red Hat OpenShift 4 を参照してください。

   CA 証明書のローテーションが発生したときに、プールが一時停止されていないことを確認してください。MCP が一時停止されている場合、MCO は新しくローテーションされた証明書をそれらのノードにプッシュできません。これにより、クラスターが劣化し、oc debug、oc logs、oc exec、oc attach などの複数の oc コマンドで障害が発生します。証明書がローテーションされたときに MCP が一時停止された場合、OpenShift Container Platform コンソールのアラート UI でアラートを受け取ります。

4. クラスターの更新を実行します。更新プロセスでは、コントロールプレーンノードを含む、一時停止されていない MCP が更新されます。
5. 更新されたノードでアプリケーションをテストし、期待どおりに動作することを確認します。
6. 残りの MCP の 1 つを一時停止解除し、そのプール内のノードの更新が完了するのを待ち、それらのノードでアプリケーションをテストします。すべてのワーカーノードが更新されるまで、このプロセスを繰り返します。
7. オプション: 更新されたノードからカスタムラベルを削除し、カスタム MCP を削除します。

手順

1. 次のコマンドを実行して、クラスター内のワーカーノードをリスト表示します。

   $ oc get -l 'node-role.kubernetes.io/master!=' -o 'jsonpath={range .items[*]}{.metadata.name}{"\n"}{end}' nodes

   出力例

   ci-ln-pwnll6b-f76d1-s8t9n-worker-a-s75z4
   ci-ln-pwnll6b-f76d1-s8t9n-worker-b-dglj2
   ci-ln-pwnll6b-f76d1-s8t9n-worker-c-lldbm

2. 更新を遅らせるノードごとに、次のコマンドを実行してカスタムラベルをノードに追加します。

   $ 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=

   出力例

   node/ci-ln-gtrwm8t-f76d1-spbl7-worker-a-xk76k labeled

3. 新規 MCP を作成します。

   1. MCP の YAML ファイルを作成します。

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      metadata:
        name: workerpool-canary 1
      spec:
        machineConfigSelector:
          matchExpressions:
            - {
               key: machineconfiguration.openshift.io/role,
               operator: In,
               values: [worker,workerpool-canary] 2
              }
        nodeSelector:
          matchLabels:
            node-role.kubernetes.io/workerpool-canary: "" 3

      1

      MCP の名前を指定します。

      2

      worker およびカスタム MCP 名を指定します。

      3

      このプールで必要なノードに追加したカスタムラベルを指定します。

   2. 次のコマンドを実行して、MachineConfigPool オブジェクトを作成します。

      $ oc create -f <file_name>

      出力例

      machineconfigpool.machineconfiguration.openshift.io/workerpool-canary created

4. 次のコマンドを実行して、クラスター内の MCP のリストとその現在の状態を表示します。

   $ oc get machineconfigpool

   出力例

   NAME              CONFIG                                                        UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
   master            rendered-master-b0bb90c4921860f2a5d8a2f8137c1867              True      False      False      3              3                   3                     0                      97m
   workerpool-canary rendered-workerpool-canary-87ba3dec1ad78cb6aecebf7fbb476a36   True      False      False      1              1                   1                     0                      2m42s
   worker            rendered-worker-87ba3dec1ad78cb6aecebf7fbb476a36              True      False      False      2              2                   2                     0                      97m

   新規マシン設定プールの workerpool-canary が作成され、カスタムラベルが追加されたノード数がマシン数に表示されます。ワーカー MCP マシン数は同じ数で縮小されます。マシン数の更新に数分かかることがあります。この例では、1 つのノードが worker MCP から workerpool-canary MCP に移動しました。

手順

1. 次の 2 つのステップに従ってセカンダリー MCP を作成します。

   1. 次の設定ファイルを machineConfigPool.yaml として保存します。

      machineConfigPool YAML の例

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      metadata:
        name: worker-perf
      spec:
        machineConfigSelector:
          matchExpressions:
            - {
               key: machineconfiguration.openshift.io/role,
               operator: In,
               values: [worker,worker-perf]
              }
        nodeSelector:
          matchLabels:
            node-role.kubernetes.io/worker-perf: ""
      # ...

   2. 次のコマンドを実行して、新しいマシン設定プールを作成します。

      $ oc create -f machineConfigPool.yaml

      出力例

      machineconfigpool.machineconfiguration.openshift.io/worker-perf created

2. セカンダリー MCP にいくつかのマシンを追加します。次の例では、ワーカーノード worker-a、worker-b、worker-c にラベルを付けて、MCP worker-perf に追加します。

   $ oc label node worker-a node-role.kubernetes.io/worker-perf=''

   $ oc label node worker-b node-role.kubernetes.io/worker-perf=''

   $ oc label node worker-c node-role.kubernetes.io/worker-perf=''

3. 次の 2 つのステップに従って、MCP worker-perf 用の新しい MachineConfig を作成します。

   1. 次の MachineConfig の例を new-machineconfig.yaml というファイルとして保存します。

      MachineConfig YAML の例

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfig
      metadata:
        labels:
          machineconfiguration.openshift.io/role: worker-perf
        name: 06-kdump-enable-worker-perf
      spec:
        config:
          ignition:
            version: 3.2.0
          systemd:
            units:
            - enabled: true
              name: kdump.service
        kernelArguments:
          - crashkernel=512M
      # ...

   2. 次のコマンドを実行して MachineConfig を適用します。

      $ oc create -f new-machineconfig.yaml

4. 新しいカナリア MCP を作成し、前の手順で作成した MCP からマシンを追加します。次の例では、worker-perf-canary という MCP を作成し、以前に作成した worker-perf MCP からマシンを追加します。

   1. 次のコマンドを実行して、カナリアワーカーノードに worker-a というラベルを付けます。

      $ oc label node worker-a node-role.kubernetes.io/worker-perf-canary=''

   2. 次のコマンドを実行して、元の MCP からカナリアワーカーノード worker-a を削除します。

      $ oc label node worker-a node-role.kubernetes.io/worker-perf-

   3. 次のファイルを machineConfigPool-Canary.yaml として保存します。

      machineConfigPool-Canary.yaml ファイルの例

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      metadata:
        name: worker-perf-canary
      spec:
        machineConfigSelector:
          matchExpressions:
            - {
               key: machineconfiguration.openshift.io/role,
               operator: In,
               values: [worker,worker-perf,worker-perf-canary] 1
              }
        nodeSelector:
          matchLabels:
            node-role.kubernetes.io/worker-perf-canary: ""

      1

      オプションの値。この例には、追加の値として worker-perf-canary が含まれています。このような形で値を使用すると、追加の MachineConfig のメンバーを設定できます。

   4. 次のコマンドを実行して、新しい worker-perf-canary を作成します。

      $ oc create -f machineConfigPool-Canary.yaml

      出力例

      machineconfigpool.machineconfiguration.openshift.io/worker-perf-canary created

5. MachineConfig が worker-perf-canary に継承されているかどうかを確認します。

   1. 次のコマンドを実行して、MCP がデグレード状態になっていないことを確認します。

      $ oc get mcp

      出力例

      NAME                  CONFIG                                                          UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
      master                rendered-master-2bf1379b39e22bae858ea1a3ff54b2ac                True      False      False      3              3                   3                     0                      5d16h
      worker                rendered-worker-b9576d51e030413cfab12eb5b9841f34                True      False      False      0              0                   0                     0                      5d16h
      worker-perf          rendered-worker-perf-b98a1f62485fa702c4329d17d9364f6a          True      False      False      2              2                   2                     0                      56m
      worker-perf-canary   rendered-worker-perf-canary-b98a1f62485fa702c4329d17d9364f6a   True      False      False      1              1                   1                     0                      44m

   2. マシンが worker-perf から worker-perf-canary に継承されていることを確認します。

      $ oc get nodes

      出力例

      NAME       STATUS   ROLES                        AGE     VERSION
      ...
      worker-a   Ready    worker,worker-perf-canary   5d15h   v1.27.13+e709aa5
      worker-b   Ready    worker,worker-perf          5d15h   v1.27.13+e709aa5
      worker-c   Ready    worker,worker-perf          5d15h   v1.27.13+e709aa5

   3. 次のコマンドを実行して、worker-a で kdump サービスが有効になっていることを確認します。

      $ systemctl status kdump.service

      出力例

      NAME       STATUS   ROLES                        AGE     VERSION
      ...
      kdump.service - Crash recovery kernel arming
           Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; preset: disabled)
           Active: active (exited) since Tue 2024-09-03 12:44:43 UTC; 10s ago
          Process: 4151139 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS)
         Main PID: 4151139 (code=exited, status=0/SUCCESS)

   4. 次のコマンドを実行して、MCP が crashkernel を更新したことを確認します。

      $ cat /proc/cmdline

      出力には更新された crashekernel 値が含まれるはずです。次に例を示します。

      出力例

      crashkernel=512M

6. オプション: アップグレードに問題がなければ、worker-a を worker-perf に戻すことができます。

   1. 次のコマンドを実行して、worker-a を worker-perf に戻します。

      $ oc label node worker-a node-role.kubernetes.io/worker-perf=''

   2. 次のコマンドを実行して、カナリア MCP から worker-a を削除します。

      $ oc label node worker-a node-role.kubernetes.io/worker-perf-canary-

手順

1. 次のコマンドを実行して、一時停止する MCP にパッチを適用します。

   $ oc patch mcp/<mcp_name> --patch '{"spec":{"paused":true}}' --type=merge

   以下に例を示します。

   $  oc patch mcp/workerpool-canary --patch '{"spec":{"paused":true}}' --type=merge

   出力例

   machineconfigpool.machineconfiguration.openshift.io/workerpool-canary patched

手順

1. 一時停止を解除する MCP にパッチを適用します。

   $ oc patch mcp/<mcp_name> --patch '{"spec":{"paused":false}}' --type=merge

   以下に例を示します。

   $  oc patch mcp/workerpool-canary --patch '{"spec":{"paused":false}}' --type=merge

   出力例

   machineconfigpool.machineconfiguration.openshift.io/workerpool-canary patched

2. オプション: 次のいずれかの方法を使用して、更新の進行状況を確認します。

   1. Web コンソールから Administration → Cluster settings をクリックして進行状況を確認します。

   2. 次のコマンドを実行して進行状況を確認します。

      $ oc get machineconfigpools

3. 更新されたノードでアプリケーションをテストし、想定通りに機能していることを確認します。
4. 他の一時停止中の MCP についても、1 つずつこのプロセスを繰り返します。

手順

1. カスタム 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-

   出力例

   node/ci-ln-0qv1yp2-f76d1-kl2tq-worker-a-j2ssz labeled

   Machine Config Operator がノードを元の MCP に戻し、ノードを MCP 設定に合わせて調整します。

2. ノードがカスタム MCP から削除されたことを確認するには、次のコマンドを実行して、クラスター内の MCP のリストとその現在の状態を表示します。

   $ oc get mcp

   出力例

   NAME                CONFIG                                                   UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
   master              rendered-master-1203f157d053fd987c7cbd91e3fbc0ed         True      False      False      3              3                   3                     0                      61m
   workerpool-canary   rendered-mcp-noupdate-5ad4791166c468f3a35cd16e734c9028   True      False      False      0              0                   0                     0                      21m
   worker              rendered-worker-5ad4791166c468f3a35cd16e734c9028         True      False      False      3              3                   3                     0                      61m

   ノードをカスタム MCP から削除し、元の MCP に戻すると、マシン数の更新に数分かかることがあります。この例では、削除した workerpool-canary MCP から 1 つのノードを worker MCP に移動しました。

3. オプション: 次のコマンドを実行してカスタム MCP を削除します。

   $ oc delete mcp <mcp_name>

1. システムのステータスを検査します。

   # bootupctl status

   x86_64 の出力例

   Component EFI
     Installed: grub2-efi-x64-1:2.04-31.el8_4.1.x86_64,shim-x64-15-8.el8_1.x86_64
     Update: At latest version

   aarch64 の出力例

   Component EFI
     Installed: grub2-efi-aa64-1:2.02-99.el8_4.1.aarch64,shim-aa64-15.4-2.el8_1.aarch64
     Update: At latest version

2. 最初にバージョン 4.4 以前にインストールされた OpenShift Container Platform クラスターには、明示的な導入フェーズが必要です。

   システムのステータスが Adoptable の場合に、導入を実行します。

   # bootupctl adopt-and-update

   出力例

   Updated: grub2-efi-x64-1:2.04-31.el8_4.1.x86_64,shim-x64-15-8.el8_1.x86_64

3. 更新が利用可能な場合は、更新を適用して、次回の再起動時に変更が有効になるようにします。

   # bootupctl update

   出力例

   Updated: grub2-efi-x64-1:2.04-31.el8_4.1.x86_64,shim-x64-15-8.el8_1.x86_64

1. bootupctl-update.service systemd ユニットの内容を含む Butane 設定ファイル 99-worker-bootupctl-update.bu を作成します。

   注記

   Butane の詳細は、「Butane を使用したマシン設定の作成」を参照してください。

   出力例

   variant: openshift
   version: 4.12.0
   metadata:
     name: 99-worker-chrony 1
     labels:
       machineconfiguration.openshift.io/role: worker 2
   systemd:
     units:
     - name: bootupctl-update.service
       enabled: true
       contents: |
         [Unit]
         Description=Bootupd automatic update
   
         [Service]
         ExecStart=/usr/bin/bootupctl update
         RemainAfterExit=yes
   
         [Install]
         WantedBy=multi-user.target

   1 2

   コントロールプレーンノードでは、これらの両方の場所で worker の代わりに master を使用します。

2. Butane を使用して、ノードに配信される設定を含む MachineConfig オブジェクトファイル (99-worker-bootupctl-update.yaml) を生成します。

   $ butane 99-worker-bootupctl-update.bu -o 99-worker-bootupctl-update.yaml

3. 以下の 2 つの方法のいずれかで設定を適用します。

   • クラスターがまだ起動していない場合は、マニフェストファイルを生成した後に、MachineConfig オブジェクトファイルを <installation_directory>/openshift ディレクトリーに追加してから、クラスターの作成を続行します。

   • クラスターがすでに実行中の場合は、ファイルを適用します。

     $ oc apply -f ./99-worker-bootupctl-update.yaml

手順

1. Web コンソールから、Administration → Cluster Settings をクリックし、Details タブの内容を確認します。

2. 本番クラスターの場合は、チャネル が、stable-4.12 など、更新するバージョンの正しいチャネルに設定されていることを確認してください。

   重要

   実稼働クラスターの場合は、stable-*、eus-* または fast-* チャネルにサブスクライブする必要があります。

   注記

   次のマイナーバージョンに移行する準備ができたら、そのマイナーバージョンに対応するチャネルを選択します。更新チャネルの宣言が早ければ早いほど、クラスターはターゲットバージョンへの更新パスをより効果的に推奨できます。クラスターは、利用可能なすべての可能な更新プログラムを評価し、最適な更新プログラムの推奨事項を選択するために、しばらく時間がかかる場合があります。更新の推奨事項は、その時点で利用可能な更新オプションに基づいているため、時間の経過とともに変化する可能性があります。

   ターゲットマイナーバージョンへの更新パスが表示されない場合は、次のマイナーバージョンがパスで利用可能になるまで、現在のバージョンの最新のパッチリリースにクラスターを更新し続けます。

   • Update Status が Updates Available ではない場合、クラスターを更新することはできません。
   • Select Channel は、クラスターが実行されているか、更新されるクラスターのバージョンを示します。

3. 更新するバージョンを選択し、Save をクリックします。

   入力チャネルの Update Status が Update to <product-version> in progress 切り替わり、Operator およびノードの進捗バーを監視して、クラスター更新の進捗を確認できます。

   注記

   バージョン 4.y から 4.(y+1) などの次のマイナーバージョンにクラスターを更新する場合、新たな機能に依存するワークロードをデプロイする前にノードがアップグレードされていることを確認することが推奨されます。更新されていないワーカーノードを持つプールは Cluster Settings ページに表示されます。

4. 更新が完了し、Cluster Version Operator が利用可能な更新を更新したら、追加の更新が現在のチャネルで利用可能かどうかを確認します。

   • 更新が利用可能な場合は、更新ができなくなるまで、現在のチャネルでの更新を継続します。
   • 利用可能な更新がない場合は、チャネル を次のマイナーバージョンの stable-*、eus-* または fast-* チャネルに変更し、そのチャネルで必要なバージョンに更新します。

   必要なバージョンに達するまで、いくつかの中間更新を実行する必要がある場合があります。

   注記

   Red Hat Enterprise Linux (RHEL) ワーカーマシンを含むクラスターを更新する場合、それらのワーカーは、更新プロセス時に一時的に使用できなくなります。クラスターの更新の終了において各 RHEL マシンがのステートが NotReady になる際に、アップグレード Playbook を各 RHEL マシンに対して実行する必要があります。

手順

1. ホストで firewalld を停止し、無効にします。

   # systemctl disable --now firewalld.service

   注記

   デフォルトでは、最小インストールオプションを持つベース OS RHEL により、firewalld サービスが有効になります。ホストで firewalld サービスを有効にすると、ワーカーで OpenShift Container Platform ログにアクセスできなくなります。ワーカーの OpenShift Container Platform ログへのアクセスを継続する場合は、firewalld を後で有効にしないでください。

2. OpenShift Container Platform 4.12 で必要なリポジトリーを有効にします。

   1. Ansible Playbook を実行するマシンで、必要なリポジトリーを更新します。

      # subscription-manager repos --disable=rhocp-4.11-for-rhel-8-x86_64-rpms \
                                   --disable=ansible-2.9-for-rhel-8-x86_64-rpms \
                                   --enable=rhocp-4.12-for-rhel-8-x86_64-rpms

      重要

      OpenShift Container Platform 4.11 の時点で、Ansible Playbook は RHEL 8 に対してのみ提供されています。RHEL 7 システムが OpenShift Container Platform 4.10 Ansible Playbook のホストとして使用された場合、Ansible ホストを RHEL 8 にアップグレードするか、RHEL 8 システムに新しい Ansible ホストを作成し、古い Ansible ホストからインベントリーをコピーする必要があります。

   2. Ansible Playbook を実行するマシンで、Ansible パッケージを更新します。

      # yum swap ansible ansible-core

   3. Ansible Playbook を実行するマシンで、openshift-ansible を含む必要なパッケージを更新します。

      # yum update openshift-ansible openshift-clients

   4. 各 RHEL コンピュートノードで、必要なリポジトリーを更新します。

      # subscription-manager repos --disable=rhocp-4.11-for-rhel-8-x86_64-rpms \
                                   --enable=rhocp-4.12-for-rhel-8-x86_64-rpms

3. RHEL ワーカーマシンを更新します。

   1. 次の例に示すように、/<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

   2. openshift-ansible ディレクトリーに移動します。

      $ cd /usr/share/ansible/openshift-ansible

   3. upgrade Playbook を実行します。

      $ ansible-playbook -i /<path>/inventory/hosts playbooks/upgrade.yml 1

      1

      <path> については、作成した Ansible インベントリーファイルへのパスを指定します。

      注記

      upgrade Playbook は OpenShift Container Platform パッケージのみをアップグレードします。オペレーティングシステムパッケージは更新されません。

4. すべてのワーカーを更新したら、すべてのクラスターノードが新規バージョンに更新されていることを確認します。

   # oc get node

   出力例

   NAME                        STATUS                        ROLES    AGE    VERSION
   mycluster-control-plane-0   Ready                         master   145m   v1.25.0
   mycluster-control-plane-1   Ready                         master   145m   v1.25.0
   mycluster-control-plane-2   Ready                         master   145m   v1.25.0
   mycluster-rhel8-0           Ready                         worker   98m    v1.25.0
   mycluster-rhel8-1           Ready                         worker   98m    v1.25.0
   mycluster-rhel8-2           Ready                         worker   98m    v1.25.0
   mycluster-rhel8-3           Ready                         worker   98m    v1.25.0

5. オプション: upgrade Playbook で更新されていないオペレーティングシステムパッケージを更新します。4.12 にないパッケージを更新するには、以下のコマンドを使用します。

   # yum update

   注記

   4.12 のインストール時に使用したものと同じ RPM リポジトリーを使用している場合は、RPM パッケージを除外する必要はありません。

1. リリースイメージの取得およびプッシュに使用されるすべてのデバイスに OpenShift CLI (oc) をインストールします。
2. レジストリープルシークレットをダウンロードし、クラスターに追加します。

3. oc-mirror OpenShift CLI (oc) プラグイン を使用する場合:

   1. リリースイメージの取得およびプッシュに使用されるすべてのデバイスに oc-mirror プラグインをインストールします。
   2. ミラーリングするリリースイメージを決定する際に、使用するプラグイン用のイメージセット設定ファイルを作成します。この設定ファイルは後で編集して、プラグインがミラーリングするリリースイメージを変更できます。
   3. ターゲットのリリースイメージをミラーレジストリーに直接ミラーリングするかリムーバブルメディアにミラーリングしてからミラーレジストリーにミラーリングします。
   4. oc-mirror プラグインが生成したリソースを使用するようにクラスターを設定します。
   5. 必要に応じてこれらの手順を繰り返し、ミラーレジストリーを更新します。

4. oc adm release mirror コマンド を使用する場合:

   1. 使用している環境とミラーリングするリリースイメージに対応する環境変数を設定します。
   2. ターゲットのリリースイメージをミラーレジストリーに直接ミラーリングするかリムーバブルメディアにミラーリングしてからミラーレジストリーにミラーリングします。
   3. 必要に応じてこれらの手順を繰り返し、ミラーレジストリーを更新します。

1. セキュアなレジストリーへのアクセスを設定します。
2. グローバルクラスタープルシークレットを更新して、ミラーレジストリーにアクセスします。
3. OSUS Operator をインストールします。
4. OpenShift Update Service のグラフデータコンテナーイメージを作成します。
5. OSUS アプリケーションをインストールし、ローカルの OpenShift Update Service を使用するようにクラスターを設定します。
6. 接続されたクラスターの場合と同様に、ドキュメントに記載されているサポートされている更新手順を実行します。

1. イメージの検証ステージ
2. ビルドの検証ステージ
3. 署名の検証ステージ