第2章 ポリシーおよびサービス定義

設計上、Pod は短期間存在することが意図されています。アプリケーション Pod の複数のインスタンスが実行されている場合は、個別の Pod またはコンテナーの問題から保護できるようにサービスを適切にスケーリングします。OpenShift ノードスケジューラーは、回復性をさらに強化するために、これらのワークロードが異なるワーカーノードに分散するようにします。

Pod の障害に対応する場合は、ストレージがアプリケーションに割り当てられる方法も理解することが重要になります。単一 Pod に割り当てられる単一の永続ボリュームは、Pod のスケーリングを完全に活用できませんが、複製されるデータベース、データベースサービス、または共有ストレージはこれを活用できます。

アップグレードなどの計画メンテナンス中にアプリケーションが中断されるのを防ぐには、Pod の Disruption Budget (停止状態の予算) を定義することが重要です。これらは Kubernetes API の一部であり、他のオブジェクトタイプと同様に oc コマンドで管理できます。この設定により、メンテナンスのためのノードのドレイン (解放) などの操作時に Pod への安全面の各種の制約を指定できます。

ワーカーノードは、アプリケーション Pod が含まれる仮想マシンです。デフォルトで、ROSA クラスターには単一アベイラビリティーゾーンのクラスター用のワーカーノードが 2 つ以上含まれます。ワーカーノードに障害が発生した場合、Pod は、既存ノードに関する問題が解決するか、ノードが置き換えられるまで、十分な容量がある限り、機能しているワーカーノードに移行します。ワーカーノードを追加することは、単一ノードの停止状態に対する保護策を強化することを意味し、ノードに障害が発生した場合に再スケジュールされる Pod の適切なクラスター容量を確保できます。

シングル AZ ROSA クラスターには、プライベートサブネット内の同じアベイラビリティゾーン (AZ) に少なくとも 3 つのコントロールプレーンと 2 つのインフラストラクチャーノードがあります。

マルチ AZ ROSA クラスターには、選択したクラスターのタイプに応じて、少なくとも 3 つのコントロールプレーンノードと 3 つのインフラストラクチャーノードがあり、高可用性のために事前設定されています。コントロールプレーンおよびインフラストラクチャーノードはワーカーノードと同じ耐障害性があり、この場合は Red Hat によって完全に管理される利点を活用できます。

コントロールプレーンが完全に停止する場合、OpenShift API は機能せず、既存のワーカーノード Pod は影響を受けません。ただし、Pod またはノードが同時に停止している場合は、コントロールプレーンのリカバリーが新規 Pod またはノードを追加される前、またはスケジュールする前に必要になります。

インフラストラクチャーノードで実行しているすべてのサービスは、高可用性を持ち、インフラストラクチャーノード間に分散されるように Red Hat によって設定されます。インフラストラクチャーが完全に停止すると、これらのサービスはこれらのノードが回復するまで利用できなくなります。

AWS のゾーン障害は、すべての仮想コンポーネント (ワーカーノード、ブロックまたは共有ストレージ、単一のアベイラビリティーゾーンに固有のロードバランサーなど) に影響を及ぼします。ゾーンの障害から保護するために、ROSA は複数のアベイラビリティーゾーンクラスターとして知られる 3 つのアベイラビリティーゾーンに分散するクラスターに関するオプションを提供します。既存のステートレスワークロードは、十分な容量がある限り、停止時に影響を受けないゾーンに再分散されます。

ステートフルなアプリケーションをデプロイしている場合、ストレージは重要なコンポーネントであり、高可用性を検討する際に考慮に入れる必要があります。単一ブロックストレージ PV は、Pod レベルでも停止状態になった状態では実行できません。ストレージの可用性を維持する最適な方法として、複製されたストレージソリューション、停止による影響を受けない共有ストレージ、またはクラスターから独立したデータベースサービスを使用できます。