第3章 クラスターの更新の実行
3.1. CLI を使用したクラスターの更新
OpenShift CLI (oc) を使用して、OpenShift Container Platform クラスターでマイナーバージョンおよびパッチの更新を実行できます。
3.1.1. 前提条件
-
admin権限を持つユーザーとしてクラスターにアクセスできる。RBAC の使用によるパーミッションの定義および適用 を参照してください。 - 更新が失敗し、クラスターを以前の状態に復元する必要がある場合に備えて、最新の etcd バックアップ を用意している。
- Pod 障害により永続ボリュームを復元する必要がある場合に備えて、最新の Container Storage Interface (CSI) ボリュームのスナップショット を用意している。
- RHEL7 ワーカーは、RHEL8 または RHCOS ワーカーに置き換えられます。Red Hat は、RHEL7 から RHEL8 への RHEL ワーカーのインプレース更新をサポートしていません。このようなホストは、オペレーティングシステムをクリーンインストールして置き換える必要があります。
- Operator Lifecycle Manager (OLM) を通じて以前にインストールされたすべての Operator を、ターゲットリリースと互換性のあるバージョンに更新している。Operator を更新することで、デフォルトの OperatorHub カタログが、クラスターの更新時に現行のマイナーバージョンから次のマイナーバージョンに切り替わる際、確実に有効な更新パスがあるようにします。インストール済み Operator の更新 を参照し、互換性を確認する方法の詳細を確認して、インストールされている Operator を必要に応じて更新してください。
- すべてのマシン設定プール (MCP) が実行中であり、一時停止していないことを確認します。一時停止した MCP に関連付けられたノードは、更新プロセス中にスキップされます。カナリアロールアウト更新ストラテジーを実行している場合は、MCP を一時停止できる。
- クラスターが手動で維持された認証情報を使用している場合は、新しいリリース用にクラウドプロバイダーリソースを更新します。これがクラスターの要件かどうかを判断する方法などの詳細は、手動で維持された認証情報でクラスターを更新する準備 を参照してください。
-
クラスターで次のマイナーバージョンへの更新ができるように、すべての
Upgradeable=False条件に対応してください。アラートは、アップグレードできない 1 つ以上のクラスター Operator がある場合に Cluster Settings ページの上部に表示されます。引き続き、現在使用しているマイナーリリースについて、次に利用可能なパッチ更新に更新できます。 - Kubernetes 1.28 で削除された API のリストを確認し、影響を受けるすべてのコンポーネントを移行して新しい API バージョンを使用し、管理者に承認を提供します。詳細は、OpenShift Container Platform 4.16 への更新の準備 を参照してください。
-
Operator を実行している場合、または Pod 中断バジェットを使用してアプリケーションを設定している場合は、更新プロセス中に中断が発生する可能性があります。
PodDisruptionBudget で minAvailableが 1 に設定されている場合、削除プロセスをブロックする可能性がある保留中のマシン設定を適用するためにノードがドレインされます。複数のノードが再起動された場合に、すべての Pod が 1 つのノードでのみ実行される可能性があり、PodDisruptionBudgetフィールドはノードのドレインを防ぐことができます。
- 更新が完了しなかった場合、Cluster Version Operator (CVO) は、更新の調整を試みている間、ブロックしているコンポーネントのステータスを報告します。クラスターの以前のバージョンへのロールバックはサポートされていません。更新が完了しない場合は、Red Hat サポートにお問い合わせください。
-
unsupportedConfigOverridesセクションを使用して Operator の設定を変更することはサポートされておらず、クラスターの更新をブロックする可能性があります。クラスターを更新する前に、この設定を削除する必要があります。
3.1.2. MachineHealthCheck リソースの一時停止
更新プロセスで、クラスター内のノードが一時的に利用できなくなる可能性があります。ワーカーノードの場合、マシンのヘルスチェックにより、このようなノードは正常ではないと識別され、それらが再起動される場合があります。このようなノードの再起動を回避するには、クラスターを更新する前にすべての MachineHealthCheck リソースを一時停止します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。
手順
一時停止する利用可能なすべての
MachineHealthCheckリソースをリスト表示するには、以下のコマンドを実行します。$ oc get machinehealthcheck -n openshift-machine-api
マシンヘルスチェックを一時停止するには、
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-
3.1.3. 単一ノードの OpenShift Container Platform の更新
コンソールまたは CLI のいずれかを使用して、単一ノードの OpenShift Container Platform クラスターを更新またはアップグレードできます。
ただし、以下の制限事項に注意してください。
-
他にヘルスチェックを実行するノードがないので、
MachineHealthCheckリソースを一時停止する時に課される前提条件は必要ありません。 - etcd バックアップを使用した単一ノードの OpenShift Container Platform クラスターの復元は、正式にはサポートされていません。ただし、更新に失敗した場合は、etcd バックアップを実行することが推奨されます。コントロールプレーンが正常である場合には、バックアップを使用してクラスターを以前の状態に復元できる場合があります。
単一ノードの OpenShift Container Platform クラスターを更新するには、ダウンタイムが必要です。更新には、自動再起動も含まれる可能性があります。ダウンタイムの時間は、以下のシナリオのように更新ペイロードによって異なります。
- 更新ペイロードに再起動が必要なオペレーティングシステムの更新が含まれる場合には、ダウンタイムは、クラスター管理およびユーザーのワークロードに大きく影響します。
- 更新に含まれるマシン設定の変更で、再起動の必要がない場合には、ダウンタイムは少なくなり、クラスター管理およびユーザーワークロードへの影響は低くなります。この場合、クラスターに、ワークロードの再スケジューリングするノードが他にないため、単一ノードの OpenShift Container Platform でノードのドレイン (解放) のステップが省略されます。
- 更新ペイロードにオペレーティングシステムの更新またはマシン設定の変更が含まれていない場合は、API が短時間してすぐに解決します。
更新パッケージのバグなどの制約があり、再起動後に単一ノードが再起動されないことがあります。この場合、更新は自動的にロールバックされません。
関連情報
- 再起動が必要なマシン設定の変更は、Machine Config Operator について を参照してください。
3.1.4. CLI を使用したクラスターの更新
OpenShift CLI (oc) を使用して、クラスターの更新を確認および要求できます。
利用可能な OpenShift Container Platform アドバイザリーおよび更新については、カスタマーポータルの エラータ のセクションを参照してください。
前提条件
-
仕様している更新バージョンのバージョンに一致する OpenShift CLI (
oc) をインストールしている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしている。 -
すべての
MachineHealthCheckリソースを一時停止している。
手順
利用可能な更新を確認し、適用する必要のある更新のバージョン番号をメモします。
$ 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
注記- 推奨される更新がない場合でも、既知の問題がある更新がまだ利用できる可能性があります。詳細は、条件付き更新パスに沿った更新 を参照してください。
- コントロールプレーンのみの更新を実行する方法の詳細と情報については、「関連情報」セクションに記載されている コントロールプレーンのみの更新を実行するための準備 ページを参照してください。
組織の要件に基づいて、適切な更新チャネルを設定します。たとえば、チャネルを
stable-4.13またはfast-4.13に設定できます。チャネルの詳細は、追加リソースセクションにリストされている 更新チャネルとリリースについて を参照してください。$ oc adm upgrade channel <channel>
たとえば、チャネルを
stable-4.16に設定するには、以下を実行します。$ oc adm upgrade channel stable-4.16
重要実稼働クラスターの場合、
stable-*、eus-*またはfast-*チャネルにサブスクライブする必要があります。注記次のマイナーバージョンに移行する準備ができたら、そのマイナーバージョンに対応するチャネルを選択します。更新チャネルの宣言が早ければ早いほど、クラスターはターゲットバージョンへの更新パスをより効果的に推奨できます。クラスターは、利用可能なすべての可能な更新プログラムを評価し、最適な更新プログラムの推奨事項を選択するために、しばらく時間がかかる場合があります。更新の推奨事項は、その時点で利用可能な更新オプションに基づいているため、時間の経過とともに変化する可能性があります。
ターゲットマイナーバージョンへの更新パスが表示されない場合は、次のマイナーバージョンがパスで利用可能になるまで、現在のバージョンの最新のパッチリリースにクラスターを更新し続けます。
更新を適用します。
最新バージョンに更新するには、以下を実行します。
$ oc adm upgrade --to-latest=true 1特定のバージョンに更新するには、以下を実行します。
$ oc adm upgrade --to=<version> 1重要oc adm upgrade --helpを使用する場合、--forceのオプションがリストされています。--forceオプションを使用すると、リリースの検証や前提条件のチェックをはじめとするクラスター側のガードがバイパスされるため、これは 可能な限り使用しないでください。--forceを使用しても、更新が成功することは保証されません。ガードをバイパスすると、クラスターが危険にさらされます。
クラスターバージョン Operator を確認します。
$ oc adm upgrade
更新が完了したら、クラスターのバージョンが新たなバージョンに更新されていることを確認できます。
$ 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.
クラスターを次のマイナーバージョン (バージョン X.y から X.(y+1) など) に更新する場合は、新しい機能に依存するワークロードをデプロイする前に、ノードが更新されていることを確認することが推奨されます。
$ oc get nodes
出力例
NAME STATUS ROLES AGE VERSION ip-10-0-168-251.ec2.internal Ready master 82m v1.29.4 ip-10-0-170-223.ec2.internal Ready master 82m v1.29.4 ip-10-0-179-95.ec2.internal Ready worker 70m v1.29.4 ip-10-0-182-134.ec2.internal Ready worker 70m v1.29.4 ip-10-0-211-16.ec2.internal Ready master 82m v1.29.4 ip-10-0-250-100.ec2.internal Ready worker 69m v1.29.4
3.1.5. oc adm upgrade status を使用してクラスターの更新に関する情報を取得する (テクノロジープレビュー)
クラスターを更新するときは、更新の進行状況を把握しておくと役立ちます。oc adm upgrade コマンドは更新のステータスに関する限定的な情報を返しますが、このリリースでは oc adm upgrade status コマンドがテクノロジープレビュー機能として導入されています。このコマンドは、oc adm upgrade コマンドからステータス情報を分離し、コントロールプレーンのステータスやワーカーノードの更新など、クラスターの更新に関する特定の情報を提供します。
oc adm upgrade status コマンドは読み取り専用であり、クラスターの状態を変更することはありません。
oc adm upgrade status コマンドはテクノロジープレビューのみの機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
oc adm upgrade status コマンドは、バージョン 4.12 から最新のサポートされているリリースまでのクラスターに使用できます。
クラスターはテクノロジープレビュー対応のクラスターである必要はありませんが、OC_ENABLE_CMD_UPGRADE_STATUS テクノロジープレビュー環境変数を有効にする必要があります。有効にしないと、OpenShift CLI (oc) がコマンドを認識せず、機能を使用できなくなります。
手順
次のコマンドを実行して、
OC_ENABLE_CMD_UPGRADE_STATUS環境変数をtrueに設定します。$ export OC_ENABLE_CMD_UPGRADE_STATUS=true
oc adm upgrade statusコマンドを実行します。$ oc adm upgrade status
例3.1 更新が正常に進行した場合の出力例
= Control Plane = Assessment: Progressing Target Version: 4.14.1 (from 4.14.0) Completion: 97% Duration: 54m Operator Status: 32 Healthy, 1 Unavailable Control Plane Nodes NAME ASSESSMENT PHASE VERSION EST MESSAGE ip-10-0-53-40.us-east-2.compute.internal Progressing Draining 4.14.0 +10m ip-10-0-30-217.us-east-2.compute.internal Outdated Pending 4.14.0 ? ip-10-0-92-180.us-east-2.compute.internal Outdated Pending 4.14.0 ? = Worker Upgrade = = Worker Pool = Worker Pool: worker Assessment: Progressing Completion: 0% Worker Status: 3 Total, 2 Available, 1 Progressing, 3 Outdated, 1 Draining, 0 Excluded, 0 Degraded Worker Pool Nodes NAME ASSESSMENT PHASE VERSION EST MESSAGE ip-10-0-4-159.us-east-2.compute.internal Progressing Draining 4.14.0 +10m ip-10-0-20-162.us-east-2.compute.internal Outdated Pending 4.14.0 ? ip-10-0-99-40.us-east-2.compute.internal Outdated Pending 4.14.0 ? = Worker Pool = Worker Pool: infra Assessment: Progressing Completion: 0% Worker Status: 1 Total, 0 Available, 1 Progressing, 1 Outdated, 1 Draining, 0 Excluded, 0 Degraded Worker Pool Node NAME ASSESSMENT PHASE VERSION EST MESSAGE ip-10-0-4-159-infra.us-east-2.compute.internal Progressing Draining 4.14.0 +10m = Update Health = SINCE LEVEL IMPACT MESSAGE 14m4s Info None Update is proceeding well
この情報を利用して、更新をどのように進めるかについて十分な情報に基づいた決定を下すことができます。
3.1.6. 条件付き更新パスに沿った更新
Web コンソールまたは OpenShift CLI (oc) を使用して、推奨される条件付き更新パスに沿って更新できます。クラスターで条件付き更新が推奨されない場合は、OpenShift CLI (oc) 4.10 以降を使用して条件付き更新パスに沿って更新できます。
手順
リスクが適用される可能性があるため推奨されない場合に更新の説明を表示するには、次のコマンドを実行します。
$ oc adm upgrade --include-not-recommended
クラスター管理者が潜在的な既知のリスクを評価し、それが現在のクラスターに受け入れられると判断した場合、管理者は次のコマンドを実行して安全ガードを放棄し、更新を続行できます。
$ oc adm upgrade --allow-not-recommended --to <version> <.>
<.>
<version>は、前のコマンドの出力から取得した更新バージョンです。サポートされていますが、既知の問題やリスクもあります。
関連情報
3.1.7. CLI を使用した更新サーバーの変更
更新サーバーの変更は任意です。OpenShift Update Service (OSUS) がローカルにインストールされ、設定されている場合は、更新時にローカルサーバーを使用できるようにサーバーの URL を upstream として設定する必要があります。upstream のデフォルト値は https://api.openshift.com/api/upgrades_info/v1/graph です。
手順
クラスターバージョンで
upstreamパラメーター値を変更します。$ oc patch clusterversion/version --patch '{"spec":{"upstream":"<update-server-url>"}}' --type=merge<update-server-url>変数は、更新サーバーの URL を指定します。出力例
clusterversion.config.openshift.io/version patched
