このページでは、Google Kubernetes Engine(GKE)での StatefulSet オブジェクトの使用方法について説明します。ステートフル アプリケーションをデプロイする方法もご覧ください。
StatefulSet について
StatefulSet は、スケジュールされた場所にかかわらず GKE が保持する一意で永続的な ID と固有のホスト名を持つ「ポッド」のセットを表します。任意の StatefulSet Pod の状態情報やその他の復元データは、StatefulSet の各 Pod に関連付けられた永続ディスク ストレージに保持されます。StatefulSet Pod はいつでも再起動できます。
ステートレス アプリケーションには、Deployment を使用します。
StatefulSet は GKE と Kubernetes で同様に機能します。このドキュメントでは、GKE 固有の考慮事項について説明します。StatefulSet の仕組みについては、StatefulSet に関する Kubernetes のドキュメントをご覧ください。
StatefulSet のネットワーキングを計画する
StatefulSet は、永続ボリュームと一意のネットワーク ID(ホスト名)の形式で永続ストレージを提供します。次の表に、StatefulSet を構成するときにアプリケーション運用者が知っておくべき注意事項を示します。
ネットワーキングの注意事項 | 説明 | ベスト プラクティス |
---|---|---|
固定 IP アドレスではない GKE サービス |
Pod のレプリカには一意の序数インデックスがあり、レプリカごとのボリュームとネットワーク ID(ホスト名)をサポートしていますが、GKE が再スケジュールしたり、Pod を強制排除したりすると、レプリカに割り当てられる IP アドレスが変わる可能性があります。 |
ネットワークの問題を軽減するために、このアーキテクチャでは Kubernetes Service リソースを使用する必要があります。詳細については、Kubernetes Service のタイプをご覧ください。 |
Headless Services |
初期化時に、StatefulSet が一致する Headless Service とペアになります。 |
Service の「metadata.name」が StatefulSet の |
ピアの検出 |
ステートフル アプリケーションが完全な可用性で機能するには、最小数(クォーラム)のレプリカが必要です。 |
Pod はクラッシュ、再スケジュール、強制排除の可能性があるため、StatefulSet の各レプリカは、クォーラムから離脱して再参加できる必要があります。ピアリングが必要なアプリケーションには、Kubernetes の Headless Service を介して他のピアを検出する機能が必要です。 |
readinessProbe と livenessProbe に基づくヘルスチェック |
アプリケーションでは、readinessProbe、livenessProbe、startupProbe が適切に構成されている必要があります。各プローブのタイムアウトの選択は、アプリケーションの要件によって異なります。 |
readinessProbe では、以下のベスト プラクティスに沿って、トラフィックを処理する準備が整ったときに readiness をマークするようにアプリケーションを構成します。
|
プローブの詳細については、livenessProbe、readinessProbe、startupProbe を構成するをご覧ください。
StatefulSet を操作する
GKE クラスタに StatefulSet をデプロイして操作する方法については、Kubernetes ドキュメントで StatefulSet の基本をご覧ください。
次のステップ
- ステートフル アプリケーションをデプロイする方法を確認する
- ローリング アップデートを使用して StatefulSet を更新する方法を確認する
- GKE にワークロードをデプロイする方法の詳細を確認する
- Kubernetes ドキュメントで StatefulSet の詳細を確認する
- ステートフル ワークロードを実行するクラスタのアップグレードに関するチュートリアルに進む