5.4. クラスター更新のベストプラクティス
OpenShift Container Platform は、更新中のワークロードの中断を最小限に抑える堅牢な更新エクスペリエンスを提供します。更新要求時にクラスターがアップグレード可能な状態にない限り、更新は開始されません。
この設計では、更新を開始する前にいくつかの重要な条件を強制しますが、クラスターの更新が成功する可能性を高めるために実行できるアクションは多数あります。
5.4.1. OpenShift Update Service 推奨バージョンの選択
OpenShift Update Service (OSUS) は、クラスターがサブスクライブしているチャネルなどをはじめとするクラスターの特性に基づき、更新に関する推奨を提示します。Cluster Version Operator は、これらの推奨事項を推奨される更新または条件付き更新として保存します。OSUS が推奨していないバージョンへの更新を試行できますが、推奨される更新パスに従うことで、ユーザーはクラスター上での既知の問題や予期せぬ結果の発生から保護されます。
更新を確実に成功させるためには、OSUS が推奨する更新ターゲットのみを選択してください。
5.4.2. クラスター上ですべての重大アラートに対処する
重大なアラートには、常に可能な限り早く対処する必要がありますが、クラスターの更新を開始する前にこれらのアラートに対処し、問題を解決することが特に重要です。更新を開始する前に重大アラートに対処しなければ、クラスターが問題のある状態に陥る可能性があります。
Web コンソールの Administrator パースペクティブで、Observe
5.4.3. クラスターの状態が Upgradable であることを確認する
1 つ以上の Operator が 1 時間以上 Upgradeable
条件を True
として報告しなかった場合、クラスター内で ClusterNotUpgradeable
警告アラートがトリガーされます。このアラートがパッチ更新をブロックすることはほぼありませんが、このアラートを解決し、すべての Operator が Upgradeable
に対して True
と報告するまで、マイナーバージョンの更新は実行できません。
Upgradeable
条件の詳細には、追加リソースセクションの「クラスター Operator の条件タイプ」を参照してください。
5.4.4. 十分な予備ノードが利用可能であることを確認する
特にクラスターの更新を開始する場合は、予備のノード容量がほとんどない、またはまったくない状態でクラスターを実行するべきではありません。ノードが実行されておらず、使用できない場合、クラスターのワークロードの中断を最小限に抑えつつ更新を実行するという能力が制限される可能性があります。
クラスターの maxUnavailable
仕様の設定値によっては、使用できないノードがある場合にクラスターはマシン設定の変更をノードに適用できない可能性があります。さらに、コンピュートノードに十分な予備容量がない場合、最初のノードが更新のためにオフラインになっている間、ワークロードを一時的に別のノードに移行できない可能性があります。
ノード更新が成功する可能性を高めるために、各ワーカープールに十分な使用可能なノードがあること、およびコンピュートノードに十分な予備容量があることを確認してください。
OpenShift Container Platform のすべてのマシン設定プールにおける maxUnavailable
のデフォルト設定は 1
です。この値を変更せず、一度に 1 つのコントロールプレーンノードを更新することを推奨します。コントロールプレーンプールのこの値を 3
に変更しないでください。
5.4.5. クラスターの PodDisruptionBudget が適切に設定されていることを確認する
PodDisruptionBudget
オブジェクトを使用して、常に使用可能でなければならない Pod レプリカの最小数または割合を定義できます。この設定により、クラスター更新などのメンテナンスタスク中にワークロードが中断されないように保護できます。
ただし、クラスターの更新中にノードがドレインおよび更新されないように、特定のトポロジーに対して PodDisruptionBudget
を設定できます。
クラスターの更新を計画する際には、次の要因に対する PodDisruptionBudget
オブジェクトの設定を確認してください。
-
高可用性ワークロードの場合は、
PodDisruptionBudget
で禁止されることなく一時的にオフラインにできるレプリカがあることを確認してください。 -
高可用性以外のワークロードの場合は、
PodDisruptionBudget
で保護されていないこと、または最終的にこれらのワークロードをドレインするための代替メカニズム (定期的な再起動や最終的な終了の保証など) があることを確認してください。