クラスターの更新

1. ターゲットバージョンは、ClusterVersion リソースの spec.desiredUpdate.version フィールドに保存され、Web コンソールまたは CLI から管理されます。
2. Cluster Version Operator (CVO) は、ClusterVersion リソースの desiredUpdate が現在のクラスターのバージョンとは異なることを検出します。OpenShift Update Service からのグラフデータを使用して、CVO は必要なクラスターバージョンをリリースイメージのプル仕様に解決します。
3. CVO は、リリースイメージの整合性と信頼性を検証します。Red Hat は、イメージ SHA ダイジェストを一意で不変のリリースイメージ識別子として使用し、公開されたリリースイメージに関する暗号署名されたステートメントを事前定義された場所に公開します。CVO はビルトイン公開鍵のリストを使用して、チェックされたリリースイメージに一致するステートメントの存在と署名を検証します。
4. CVO は、openshift-cluster-version namespace に version-$version-$hash という名前のジョブを作成します。このジョブはリリースイメージを実行しているコンテナーを使用するため、クラスターはコンテナーランタイムを通じてイメージをダウンロードします。次に、ジョブはマニフェストとメタデータをリリースイメージから CVO がアクセス可能な共有ボリュームに展開します。
5. CVO は、展開されたマニフェストとメタデータを検証します。
6. CVO はいくつかの前提条件をチェックして、クラスター内で問題のある状態が検出されないことを確認します。特定の状態により、更新が続行できない場合があります。これらの状態は、CVO 自体によって決定されるか、Operator が更新に問題ありと判断するクラスターの詳細を検出する個々のクラスター Operator によって報告されます。
7. CVO は、承認されたリリースを status.desired に記録し、新しい更新に関する status.history エントリーを作成します。
8. CVO は、リリースイメージからマニフェストの調整を開始します。クラスター Operator は Runlevels と呼ばれる別のステージで更新され、CVO は次のレベルに進む前に Runlevel 内のすべての Operator が更新を完了するようにします。
9. CVO 自体のマニフェストはプロセスの早い段階で適用されます。CVO デプロイメントが適用されると、現在の CVO Pod が停止し、新しいバージョンを使用する CVO Pod が開始されます。新しい CVO は、残りのマニフェストの調整を進めます。
10. 更新は、コントロールプレーン全体が新しいバージョンに更新されるまで続行されます。個々のクラスター Operator は、クラスターのドメインで更新タスクを実行することがあり、その場合は実行中に、Progressing=True 状態を通して状態を報告します。
11. Machine Config Operator (MCO) マニフェストはプロセスの最後に適用されます。その後、更新された MCO は、すべてのノードのシステム設定とオペレーティングシステムの更新を開始します。各ノードは、再びワークロードの受け入れを開始する前に、ドレイン、更新、および再起動される可能性があります。

1. ノードを遮断してドレインします。

   注記

   ノードが遮断されている場合、ワークロードをそのノードにスケジュールすることはできません。

2. ノードのシステム設定およびオペレーティングシステム (OS) を更新します。
3. ノードを再起動します。
4. ノードの遮断を解除します。

1. MCO はノード 1、2、3 を遮断し、それらのドレインを開始します。
2. ノード 2 は、ドレインを完了して再起動すると再び使用可能になります。MCO はノード 4 を遮断し、そのドレインを開始します。
3. ノード 1 は、ドレインを完了して再起動すると再び使用可能になります。MCO はノード 5 を遮断し、そのドレインを開始します。
4. ノード 3 は、ドレインを完了して再起動すると再び使用可能になります。
5. ノード 5 は、ドレインを完了して再起動すると再び使用可能になります。
6. ノード 4 は、ドレインを完了して再起動すると再び使用可能になります。

手順

1. 次のコマンドを実行して、適用する更新のプル仕様を取得します。

   $ oc adm upgrade

   このコマンドの出力には、次のような利用可能な更新のプル仕様が含まれます。

   部分的な出力例

   ...
   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> は、使用するリリースイメージのプル仕様です。以下に例を示します。

   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 について、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 も同様の形式ですが、プラットフォーム固有の異なる値があります。

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

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

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

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

   $ chmod 775 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 エンドポイントとして使用します。代わりに、パブリック CloudFront 配布 URL を介して IAM ID プロバイダーによってアクセスされるプライベート S3 バケットに OIDC 設定を保存するには、--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

   GCP サービスアカウントを作成するには、CredentialsRequest マニフェストのファイルが含まれるディレクトリーを指定します。

   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 にあると想定します。

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

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

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

手順

1. 新しいリリースイメージで追加される CredentialsRequest カスタムリソースのシークレットを含む YAML ファイルを作成します。シークレットは、それぞれの CredentialsRequest オブジェクトに、spec.secretRef に定義される namespace およびシークレット名を使用して保存する必要があります。

   例2.6 サンプル AWS YAML ファイル

   シークレットを含むサンプル 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 ファイル

   注記

   Global Azure と Azure Stack Hub は、同じ CredentialsRequest オブジェクトとシークレット形式を使用します。

   シークレットを含むサンプル 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 ファイル

   シークレットを含むサンプル 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. シークレットに保存される既存の認証情報の CredentialsRequest カスタムリソースにパーミッション要件を変更した場合は、必要に応じてパーミッションを更新します。

手順

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. イメージの検証ステージ
2. ビルドの検証ステージ
3. 署名の検証ステージ

手順

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.13.10
   Upstream is unset, so the cluster will use an appropriate default.
   Channel: stable-4.13 (available channels: candidate-4.13, candidate-4.14, fast-4.13, stable-4.13)
   Recommended updates:
     VERSION     IMAGE
     4.13.14     quay.io/openshift-release-dev/ocp-release@sha256:406fcc160c097f61080412afcfa7fd65284ac8741ac7ad5b480e304aba73674b
     4.13.13     quay.io/openshift-release-dev/ocp-release@sha256:d62495768e335c79a215ba56771ff5ae97e3cbb2bf49ed8fb3f6cefabcdc0f17
     4.13.12     quay.io/openshift-release-dev/ocp-release@sha256:73946971c03b43a0dc6f7b0946b26a177c2f3c9d37105441315b4e3359373a55
     4.13.11     quay.io/openshift-release-dev/ocp-release@sha256:e1c2377fdae1d063aaddc753b99acf25972b6997ab9a0b7e80cfef627b9ef3dd

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

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

   $ oc adm upgrade channel <channel>

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

   $ oc adm upgrade channel stable-4.14

   重要

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

   注記

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

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

3. 更新を適用します。

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

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

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

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

     1 1

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

     重要

     oc adm upgrade --help を使用する場合、--force のオプションがリストされています。--force オプションを使用すると、リリースの検証や前提条件のチェックをはじめとするクラスター側のガードがバイパスされるため、これは 可能な限り使用しないでください。--force を使用しても、更新が成功することは保証されません。ガードをバイパスすると、クラスターが危険にさらされます。

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

   $ oc adm upgrade

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

   $ oc adm upgrade

   出力例

   Cluster version is <version>
   
   Upstream is unset, so the cluster will use an appropriate default.
   Channel: stable-<version> (available channels: candidate-<version>, eus-<version>, fast-<version>, stable-<version>)
   
   No updates available. You may force an update 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.27.3
   ip-10-0-170-223.ec2.internal   Ready    master   82m   v1.27.3
   ip-10-0-179-95.ec2.internal    Ready    worker   70m   v1.27.3
   ip-10-0-182-134.ec2.internal   Ready    worker   70m   v1.27.3
   ip-10-0-211-16.ec2.internal    Ready    master   82m   v1.27.3
   ip-10-0-250-100.ec2.internal   Ready    worker   69m   v1.27.3

手順

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

   $ oc adm upgrade --include-not-recommended

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

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

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

手順

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. 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.14 など、更新するバージョンの正しいチャネルに設定されていることを確認してください。

   重要

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

   注記

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

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

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

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

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

   注記

   クラスターを次のマイナーバージョン (バージョン 4.10 から 4.11 など) に更新する場合は、新しい機能を利用するワークロードをデプロイする前に、ノードが更新されていることを確認してください。更新されていないワーカーノードを持つプールは Cluster Settings ページに表示されます。

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

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

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

手順

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

2. Update cluster モーダルの Select new version ドロップダウンで Include supported but not recommended versions を有効にして、ドロップダウンリストに条件付き更新を入力できます。

   注記

   Supported but not recommended バージョンを選択すると、そのバージョンの潜在的な問題に関する詳細情報が提供されます。

3. 更新の潜在的なリスクについて詳しく説明した通知を確認してください。

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

   注記

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

   警告

   OpenShift Container Platform のすべてのマシン設定プールにおける maxUnavailable のデフォルト設定は 1 です。この値を変更せず、一度に 1 つのコントロールプレーンノードを更新することを推奨します。コントロールプレーンプールのこの値を 3 に変更しないでください。

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

   重要

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

3. 更新プロセスの一部として更新しない MCP を一時停止します。
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. Web コンソールから、Administration → Cluster Settings をクリックし、Details タブの内容を確認します。

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

   重要

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

   注記

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

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

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

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

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

   注記

   クラスターを次のマイナーバージョン (バージョン 4.10 から 4.11 など) に更新する場合は、新しい機能を利用するワークロードをデプロイする前に、ノードが更新されていることを確認してください。更新されていないワーカーノードを持つプールは 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.14 で必要なリポジトリーを有効にします。

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

      # subscription-manager repos --disable=rhocp-4.13-for-rhel-8-x86_64-rpms \
                                   --enable=rhocp-4.14-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.13-for-rhel-8-x86_64-rpms \
                                   --enable=rhocp-4.14-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.27.3
   mycluster-control-plane-1   Ready                         master   145m   v1.27.3
   mycluster-control-plane-2   Ready                         master   145m   v1.27.3
   mycluster-rhel8-0           Ready                         worker   98m    v1.27.3
   mycluster-rhel8-1           Ready                         worker   98m    v1.27.3
   mycluster-rhel8-2           Ready                         worker   98m    v1.27.3
   mycluster-rhel8-3           Ready                         worker   98m    v1.27.3

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

   # yum update

   注記

   4.14 のインストール時に使用したものと同じ 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. 以下のコマンドを実行して、Cluster Version Operator (CVO) で RetrievedUpdates 条件が True になっていることを確認します。

   $ oc get clusterversion/version -o=jsonpath="{.status.conditions[?(.type=='RetrievedUpdates')].status}"

   RetrievedUpates 条件が False の場合、以下のコマンドを使用して障害に関する補足情報を見つけることができます。

   $ oc adm upgrade

   クラスターバージョンの条件タイプに関する詳細は、クラスターバージョンの条件タイプについて を参照してください。

2. RetrievedUpdates 条件が False の場合は、次のコマンドを実行してチャネルを stable-<4.y> または fast-<4.y> に変更します。

   $ oc adm upgrade channel <channel>

   チャネルを設定したら、RetrievedUpdates が True になっているか確認します。

   チャネルの詳細は、更新チャネルとリリースについて を参照してください。

3. 以下のコマンドを実行して、マルチアーキテクチャーペイロードに移行します。

   $ oc adm upgrade --to-multi-arch

手順

1. 管理クラスターの config map 内に MachineConfig オブジェクトを作成するには、次の情報を入力します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: <configmap-name>
     namespace: clusters
   data:
     config: |
       apiVersion: machineconfiguration.openshift.io/v1
       kind: MachineConfig
       metadata:
         labels:
           machineconfiguration.openshift.io/role: worker
         name: <machineconfig-name>
       spec:
         config:
           ignition:
             version: 3.2.0
           storage:
             files:
             - contents:
                 source: data:...
               mode: 420
               overwrite: true
               path: ${PATH} 1

   1

   MachineConfig オブジェクトが保存されているノード上のパスを設定します。

2. オブジェクトを config map に追加した後、次のように config map をノードプールに適用できます。

   $ oc edit nodepool <nodepool_name> --namespace <hosted_cluster_namespace>

   apiVersion: hypershift.openshift.io/v1alpha1
   kind: NodePool
   metadata:
   # ...
     name: nodepool-1
     namespace: clusters
   # ...
   spec:
     config:
     - name: ${configmap-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.14.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