第2章 クラスターの更新の準備
2.1. OpenShift Container Platform 4.15 への更新の準備
更新を正常に初期化するためにクラスター管理者が実行する必要がある管理タスクと、更新を確実に成功させるためのオプションのガイドラインを詳しく説明します。
2.1.1. RHEL 9.2 マイクロアーキテクチャー要件の変更
OpenShift Container Platform は現在、RHEL 9.2 ホストオペレーティングシステムをベースとしています。マイクロアーキテクチャーの要件が x86_64-v2、Power9、Z14 に増加しました。RHEL マイクロアーキテクチャー要件ドキュメント を参照してください。この ナレッジベース に記載されている手順に従って、更新前に互換性を確認できます。
正しいマイクロアーキテクチャー要件がないと、更新プロセスは失敗します。各アーキテクチャーに適切なサブスクリプションを購入してください。詳細は Get Started with Red Hat Enterprise Linux - additional architectures を参照してください。
2.1.2. Kubernetes API の削除
OpenShift Container Platform 4.15 では Kubernetes API は削除されていません。
クラスターで IPsec が有効になっている場合は、OpenShift Container Platform 4.15 にアップグレードする前に無効にする必要があります。IPsec を無効にせずに 4.15 に更新すると、Pod 間通信が中断または失われる可能性があるという既知の問題があります。IPsec を無効にする方法については、IPsec 暗号化の設定 を参照してください。(OCPBUGS-43323)
2.1.3. 条件付き更新のリスク評価
条件付き更新 は、使用可能な更新ターゲットですが、クラスターに適用される既知のリスクのため推奨されません。Cluster Version Operator (CVO) は、OpenShift Update Service (OSUS) に定期的にクエリーを実行して、更新の推奨事項に関する最新のデータを取得します。ターゲットとなりうる一部の更新には、それに関連するリスクが含まれる可能性があります。
CVO は条件付きリスクを評価します。そのリスクがクラスターに当てはまらない場合、クラスターはそのターゲットバージョンを推奨される更新パスとして使用できます。リスクが当てはまると判断された場合、または何らかの理由で CVO がリスクを評価できない場合、クラスターはその更新ターゲットを条件付き更新として使用できます。
ターゲットバージョンに更新しようとしているときに条件付き更新が発生した場合は、クラスターをそのバージョンに更新するリスクを評価する必要があります。一般的に、そのターゲットバージョンに更新する必要性が特にない場合は、推奨される更新パスが Red Hat から提供されるまで待つのが最善です。
ただし、そのバージョンに更新する明確な理由がある場合 (たとえば重要な CVE を修正する必要がある場合など)、CVE を修正する利点が、更新によってクラスターに問題が発生するリスクを上回る可能性があります。以下のタスクを実行して、Red Hat の更新リスク評価に同意するか判断してください。
- 実稼働環境で問題なく更新を完了できると確信が持てるまで、非実稼働環境で幅広くテストしてください。
- 条件付き更新の説明に記載されているリンクを使用してバグを調査し、使用しているクラスターに問題を引き起こす可能性があるか判断します。リスクを把握するためにサポートが必要な場合は、Red Hat サポートにお問い合わせください。
関連情報
2.1.4. クラスター更新前の etcd バックアップ
etcd バックアップには、クラスターとそのすべてのリソースオブジェクトの状態が記録されます。現在機能不全状態にあるクラスターを復元できない障害シナリオでは、バックアップを使用してクラスターの状態の復元を試みることができます。
更新のコンテキストでは、更新によってクラスターの以前のバージョンに戻さないと修正できない壊滅的な状態が発生した場合に、クラスターの etcd 復元を試みることができます。etcd 復元は、実行中のクラスターにとって破壊的で不安定になる可能性があるため、最後の手段としてのみ使用してください。
etcd 復元は重大な影響をもたらすため、ロールバックソリューションとして使用することは意図されていません。クラスターの以前のバージョンへのロールバックはサポートされていません。更新が完了しない場合は、Red Hat サポートにお問い合わせください。
etcd 復元の実行可能性に影響を与える要因がいくつかあります。詳細は、「etcd データのバックアップ」および「以前のクラスター状態への復元」を参照してください。
2.1.5. クラスター更新のベストプラクティス
OpenShift Container Platform は、更新中のワークロードの中断を最小限に抑える堅牢な更新エクスペリエンスを提供します。更新要求時にクラスターがアップグレード可能な状態にない限り、更新は開始されません。
この設計では、更新を開始する前にいくつかの重要な条件を強制しますが、クラスターの更新が成功する可能性を高めるために実行できるアクションは多数あります。
2.1.5.1. OpenShift Update Service 推奨バージョンの選択
OpenShift Update Service (OSUS) は、クラスターがサブスクライブしているチャネルなどをはじめとするクラスターの特性に基づき、更新に関する推奨を提示します。Cluster Version Operator は、これらの推奨事項を推奨される更新または条件付き更新として保存します。OSUS が推奨していないバージョンへの更新を試行できますが、推奨される更新パスに従うことで、ユーザーはクラスター上での既知の問題や予期せぬ結果の発生から保護されます。
更新を確実に成功させるためには、OSUS が推奨する更新ターゲットのみを選択してください。
2.1.5.2. クラスター上ですべての重大アラートに対処する
重大なアラートには、常に可能な限り早く対処する必要がありますが、クラスターの更新を開始する前にこれらのアラートに対処し、問題を解決することが特に重要です。更新を開始する前に重大アラートに対処しなければ、クラスターが問題のある状態に陥る可能性があります。
Web コンソールの Administrator パースペクティブで、Observe
2.1.5.3. クラスターの状態が Upgradable であることを確認する
1 つ以上の Operator が 1 時間以上 Upgradeable
条件を True
として報告しなかった場合、クラスター内で ClusterNotUpgradeable
警告アラートがトリガーされます。このアラートがパッチ更新をブロックすることはほぼありませんが、このアラートを解決し、すべての Operator が Upgradeable
に対して True
と報告するまで、マイナーバージョンの更新は実行できません。
Upgradeable
条件の詳細には、追加リソースセクションの「クラスター Operator の条件タイプ」を参照してください。
2.1.5.4. 十分な予備ノードが利用可能であることを確認する
特にクラスターの更新を開始する場合は、予備のノード容量がほとんどない、またはまったくない状態でクラスターを実行するべきではありません。ノードが実行されておらず、使用できない場合、クラスターのワークロードの中断を最小限に抑えつつ更新を実行するという能力が制限される可能性があります。
クラスターの maxUnavailable
仕様の設定値によっては、使用できないノードがある場合にクラスターはマシン設定の変更をノードに適用できない可能性があります。さらに、コンピュートノードに十分な予備容量がない場合、最初のノードが更新のためにオフラインになっている間、ワークロードを一時的に別のノードに移行できない可能性があります。
ノード更新が成功する可能性を高めるために、各ワーカープールに十分な使用可能なノードがあること、およびコンピュートノードに十分な予備容量があることを確認してください。
OpenShift Container Platform のすべてのマシン設定プールにおける maxUnavailable
のデフォルト設定は 1
です。この値を変更せず、一度に 1 つのコントロールプレーンノードを更新することを推奨します。コントロールプレーンプールのこの値を 3
に変更しないでください。
2.1.5.5. クラスターの PodDisruptionBudget が適切に設定されていることを確認する
PodDisruptionBudget
オブジェクトを使用して、常に使用可能でなければならない Pod レプリカの最小数または割合を定義できます。この設定により、クラスター更新などのメンテナンスタスク中にワークロードが中断されないように保護できます。
ただし、クラスターの更新中にノードがドレインおよび更新されないように、特定のトポロジーに対して PodDisruptionBudget
を設定できます。
クラスターの更新を計画する際には、次の要因に対する PodDisruptionBudget
オブジェクトの設定を確認してください。
-
高可用性ワークロードの場合は、
PodDisruptionBudget
で禁止されることなく一時的にオフラインにできるレプリカがあることを確認してください。 -
高可用性以外のワークロードの場合は、
PodDisruptionBudget
で保護されていないこと、または最終的にこれらのワークロードをドレインするための代替メカニズム (定期的な再起動や最終的な終了の保証など) があることを確認してください。