プロンプトとコンテキスト
あなたは、ノードのメンテナンスおよびクラスタのスケールダウン中もクォーラムを維持しなければならない5レプリカのステートフルサービスを所有しています。PDBを設計し、minAvailableとmaxUnavailableのいずれかを選択し、設定後も障害が発生する可能性がある理由を説明してください。StatefulSetとEviction APIを使用するメンテナンスタスクツールを前提とします。
面接官がテストしていること
- YAMLを書く前に可用性とクォーラムの制約を定義しているかどうか。
- 自発的な中断（voluntary disruption）と、ノード障害、リソース圧迫、その他の非自発的な中断（involuntary disruption）を区別しているかどうか。
- PDBがエビクションを制限するものであり、常時健全なPodの絶対数を制限するものではないことを理解しているかどうか。
- ローリングアップグレードの例外、セレクター、パーセンテージの端数処理（切り上げ）、およびキャパシティに関連するドレイン（drain）の停止を把握しているかどうか。
回答前の明確化のための質問
- クォーラムは何ですか？ 5レプリカのコンセンサスサービスでは3つの正常なレプリカが必要になる場合があります。ステートレスサービスではキャパシティのパーセンテージを目標にする場合があります。
- 誰がエビクションを実行しますか？ PDBはEviction APIによって尊重されます。DeploymentやPodの直接削除はPDBをバイパスする可能性があります。
- メンテナンスにはアプリケーションのロールアウトが含まれますか？ PDBはDeploymentやStatefulSetのローリングアップデートを制限しません。ワークロードの戦略がそれを制限します。
- 代替Podのためのキャパシティはありますか？ エビクションが許可されたからといって、代替Podがすぐにスケジュールできるとは限りません。キャパシティ不足によってドレインがブロックされる可能性があります。
30秒の回答フレームワーク
「まず、健全なレプリカの要件とエビクションの経路を確認します。5つのレプリカと3つのクォーラムの場合、StatefulSetに一致するセレクターとともにminAvailable: 3、またはレプリカ規模が変化する場合は同等のmaxUnavailable: 2を使用します。PDBは自発的なエビクションを制限するものであり、ノード障害を防いだりロールアウト戦略に代わるものではありません。ロールアウトの前に、制御されたkubectl drainを実行し、disruptionsAllowedを検査し、代替Podにスケジュール可能なキャパシティがあることを確認します。」
ステップごとの詳細な回答
1. 可用性をバジェットに変換する
PDBのバジェットとは、自発的な中断によって一度に削除できるレプリカの数です。5つのレプリカが3つの健全なPodを維持する必要がある場合、バジェットは最大で2です。minAvailable: 3は残りの健全な数を指定し、maxUnavailable: 2は許容される利用不可の数を指定します。これらのフィールドは相互に排他的です。
2. スケーリングに一致する表現を選択する
minAvailableは固定クォーラムに対して直接的です。レプリカがオートスケールする場合、Kubernetesのドキュメントでは、希望するレプリカ数に対して評価されるmaxUnavailableの検討を推奨しています。パーセンテージは切り上げられます。7つの希望レプリカ数でmaxUnavailable: 30%の場合、2つではなく3つのPodが利用不可になる可能性があります。キャパシティプランニングにはその端数処理を含める必要があります。
3. 正しいワークロードをバインドする
PDBのラベルセレクターは、StatefulSetのセレクターと一致している必要があります。一致していない場合、ターゲットPodをまったく保護しなかったり、誤って複数のアプリケーションを結合したりする可能性があります。ラベルは安定した状態に保ち、バジェットを回避するためにリリース中に変更しないでください。
4. PDBの境界を明示する
PDBは、kubectl drainや自動メンテナンスなどの自発的な中断を制限します。ハードウェア障害、ノードの喪失、リソース圧迫によるエビクションは非自発的です。PDBはこれらを防ぐことはできず、これらもバジェットに対してカウントされます。PodやDeploymentを直接削除することでもPDBをバイパスできます。
5. ドレインの停止（Stall）を説明する
バジェットを使い果たすと、Eviction APIは新しいエビクションを拒否し、ドレインは再試行します。許可されたエビクションであっても、キャパシティを持つノードがない場合は代替PodがPendingのままになる可能性があり、ドレインはブロックされたままになります。Podのrequests、ゾーン分散、起動時間、ノードのヘッドルームを考慮してください。PDBはキャパシティ管理システムではありません。
6. ロールアウトとヘルスチェックポリシーを分離する
PDBはDeploymentやStatefulSetのローリングアップデートを制限しません。maxUnavailable、maxSurge、Readinessなどのアップデート戦略フィールドがリリース中の代替を制御します。Kubernetesは不健全なPodのエビクションポリシー（unhealthy Pod eviction policy）も提供しており、障害が発生しているPodを最初にクリーンアップする必要があるかどうかに基づいて選択する必要があります。ロールアウト、メンテナンス、およびインシデント復旧は個別にテストしてください。
高品質な回答例
5レプリカのサービスがクォーラムのために3つの健全なレプリカを必要とし、メンテナンスツールがEviction APIを呼び出すことを確認します。基本的なPDBは、StatefulSetの正確なセレクターを指定したminAvailable: 3です。レプリカがオートスケールする場合は、maxUnavailable: 2または切り上げ動作を伴うパーセンテージを評価します。PDBは自発的なエビクションのみを制限します。ノード障害、リソース圧迫、直接削除、ローリングアップデートポリシーを防ぐものではありません。
ロールアウト中は、disruptionsAllowedを検査し、制御されたドレインを実行して、終了時間、代替Podのスケジューリング、クォーラム状態を観察します。バジェットが枯渇したときにドレインが一時停止するのは予期された動作です。代替PodがPendingになっている場合は、バジェットを拡大するのではなく、キャパシティを追加するかrequestsを調整します。最後に、アップグレード、ノード喪失、メンテナンスのロールバックパスを個別にテストします。
よくある間違い
- 間違い → PDBがあらゆる障害を防ぐと想定する。 失敗する理由：非自発的な中断はPDBの制御外です。修正：ノード障害、リソース圧迫、メンテナンスによるエビクションの境界を明示します。
- 間違い →
maxUnavailable: 50%のみを記述する。 失敗する理由：切り上げ動作により、直感よりも多くのレプリカの損失が許容される可能性があります。修正：希望するレプリカ数から計算します。 - 間違い → PDBをロールアウトポリシーとして扱う。 失敗する理由：DeploymentおよびStatefulSetのアップデートはPDBによって制限されません。修正：ワークロードのアップデート戦略を個別に設定します。
- 間違い → ドレインの停止をPDBのせいにする。 失敗する理由：バジェットの枯渇とノードキャパシティの不足は原因が異なります。修正：
disruptionsAllowed、Pending状態のPod、requests、キャパシティを併せて検査します。
フォローアップの質問と回答
5つのレプリカのうち3つだけが健全です。別のPodをエビクションできますか？
minAvailable: 3の場合、自発的なエビクションはEviction APIによって拒否される必要があります。健全なレプリカを復元するか、メンテナンスの一時停止を受け入れます。ドレインを完了させるためにPDBを削除すると、クォーラム保護が失われます。
Cluster Autoscalerが停止しています。PDBを緩和すべきですか？
まず、スケールダウンが自発的であること、バジェットが枯渇していること、代替Podがスケジュールできることを確認します。クォーラムサービスのバジェットを緩和すると、一貫性が損なわれる可能性があります。すべてのアプリケーションのバジェットを弱めるのではなく、キャパシティを追加するか、ドレインのバッチを変更するか、ステートレスワークロード用のキャパシティパーセンテージを使用します。
なぜ直接のPod削除はPDBをバイパスできるのですか？
PDBは、すべての削除操作ではなく、Eviction APIを介した自発的エビクション要求を制御します。直接削除の権限を制限し、メンテナンスの自動化でAPIを使用するように強制するとともに、緊急時用に管理者向けの明示的なバイパス手段を残しておきます。
maxUnavailable: 0のリスクは何ですか？
自発的に利用不可になるPodが0個であることが要求されるため、選択されたワークロードがそのノードに存在する限り、ノードのドレインを完了できなくなります。ビジネスが自発的な中断を一切許容できず、調整されたメンテナンス手順が存在する場合にのみ使用してください。