プロンプトとスコープ
ワークロードがPodDisruptionBudgetとトポロジスプレッド制約を使用しているクラスタで、ローリングノードアップグレードを行う必要があります。候補ノード、退避の並行性、スケジュール不可な代替Pod、キャパシティ予約、復旧、可観測性を網羅したメンテナンスオーケストレーターを設計してください。
Kubernetesは自発的な中断によって影響を受けるPodを制限するためにPDBを定義しています。メンテナンスツールは予算がアドミッションに関与するようEviction APIを使用する必要があります。トポロジスプレッド制約は、ゾーンやノードなどの障害ドメイン間での偏り（skew）を制御します。優れた設計では、Pod数を一度確認してバッチを削除するのではなく、両方の制約を1つの制御ループに組み込みます。
面接官が評価するポイント
- 自発的な中断と非自発的な障害の区別、およびその保証境界。
- Podを直接削除する代わりにEviction APIを使用すること。
maxSkew、whenUnsatisfiable、およびトポロジスプレッドのラベルセレクターの評価。- ノードおよび障害ドメインごとの並行性とキャパシティ予約の設計。
- PDBのブロック、未準備（unready）Pod、リトライ、タイムアウト、ロールバックの処理。
- イベント、メトリクス、監査ログを通じた意思決定の説明。
確認すべき明確化のための質問
- これはOSのアップグレード、インスタンスの交換、それとも緊急修復ですか？緊急障害ではPDBの保護をバイパスする場合があります。
- レプリカ数、PDB設定、トポロジドメイン、予備キャパシティはどのようになっていますか？
- 優先事項は総所要時間ですか、最小限のユーザーリスクですか、それとも各ゾーンでの厳格な冗長性ですか？
- Cluster Autoscaler、一時ノードプール、またはゾーンをまたぐキャパシティ制限はありますか？
- コントローラーは、一時停止、デグレード、または承認要求を行う前に、PDB上でどのくらいの時間待機できますか？
30秒の回答
ノード、Pod、PDB、トポロジ制約、およびスケジュール可能なキャパシティを読み取る宣言的コントローラーを構築します。正常なレプリカとトポロジの偏りに対する1回の退避の影響をシミュレーションし、Eviction APIを介して小さなバッチを実行します。ノードと障害ドメインのトークンによって並行性を定義し、コントローラーは代替PodがReadyになるのを待ってから続行します。PDBの競合や満たされないトポロジ制約がある場合、強制的に削除するのではなく、理由を記録してバッチを一時停止します。すべての操作は冪等で可測であり、タイムアウト、ロールバック、および非自発的障害に対する個別のリスクパスを備えています。
ステップごとの詳細解説
1. 状態と制約の入力を定義する
タスクには、対象ノード、アップグレードバッチ、最大並行性、デッドライン、ロールバックポリシーが含まれます。ノードラベル、Podのオーナー、レディネス、PDBのdisruptionsAllowed、トポロジ制約、予備キャパシティをキャッシュしますが、古いスナップショットを信頼するのではなく、各決定の前にクリティカルな状態を再読み込みします。
2. 候補ノードと安全なバッチの選択
cordonされたノード、クリティカルなシステムPodを実行しているノード、代替キャパシティのないノードをフィルタリングします。候補をゾーン、ラック、ワークロードごとにグループ化します。バッチは各ワークロードのPDB許容量の範囲内に収まり、置換後のトポロジの偏りをシミュレーションする必要があります。障害ドメインを単一障害点にしない予備キャパシティを持つノードを優先します。
3. Eviction APIの使用
自発的なメンテナンスにはEviction APIを呼び出し、KubernetesにPDBを評価させます。競合または拒否が発生した場合は、特定のPDB、ワークロード、および再試行時間を記録します。直接削除は予算をバイパスするため、明示的に承認された破壊的な緊急パスに限定する必要があります。
read constraints -> choose one node -> create eviction request
-> PDB allows? no: back off and re-evaluate
-> yes: wait for Ready replacement and topology recovery
-> success: mark node complete; failure: pause and recover4. トポロジとキャパシティのフィードバックへの対応
退避は完了を意味しません。DoNotSchedule、トポロジキーの欠落、アフィニティ、またはキャパシティ不足のために、代替PodがPendingのままになることがあります。スケジューラーのイベントを監視し、適切な場合は一時プールを拡張するかバッチの順序を変更しますが、ワークロードの制約を黙って緩和してはなりません。ScheduleAnywayであっても、実際の偏りとコストを記録する必要があります。
5. 並行性、リース、冪等性の設計
ノードとコントローラーの世代に対してタスクリースを使用し、複数のメンテナンスワーカーが同じターゲットを退避できないようにします。ゾーンごとの小さな制限またはワークロードのトークンバケットから開始します。代替PodがReadyになり、PDBの予算が回復し、トポロジの偏りが意図した範囲内に収まった後にのみ、次のトークンを取得します。重複した退避は処理済みとして扱い、コントローラーの再起動後はAPIの状態から回復します。
6. 障害、タイムアウト、ロールバック
PodがPendingのままである、PDBがゼロのままである、ドレインがタイムアウトする、または新しいノードが異常である場合は、以降のバッチを一時停止し、不要なcordonを解除します。アップグレードされたノードを古いイメージに戻せない場合は、古いプールを維持するか、検証済みのイメージに切り替えます。ロールバックはサービスの冗長性を復元するものであり、メンテナンスの割合を無理に100%にするものではありません。
7. 可観測性と訓練
選択されたノード、影響を受けるワークロード、前後のPDB許容量、トポロジ数、退避の応答、Pendingの理由、および所要時間を記録します。退避の成功、PDBのブロック時間、最大の偏り、Readyまでのレイテンシ、ゾーン間トラフィック、再試行回数を測定します。単一ゾーンのキャパシティ不足、PDB予算ゼロ、スケジューラーの障害、コントローラーの再起動、突然のノード喪失の訓練を実施します。
質の高い模範解答
オーケストレーターを、ノードおよび障害ドメイン単位で進行する宣言的コントローラーとしてモデル化します。Podのオーナー、レディネス、PDB、トポロジスプレッド、ノードラベル、およびスケジュール可能なキャパシティを読み取ります。正常なレプリカとmaxSkewに対する1回の退避の影響をシミュレーションし、その後小さなEviction APIバッチを送信します。各ゾーンは並行性トークンを持ち、次のノードはReady状態の代替Pod、回復したPDB予算、および満たされたトポロジ制約を待機します。
PDBの競合、Pendingの代替Pod、キャパシティ不足、またはタイムアウトが発生した場合は、バッチを一時停止して理由を記録します。コントローラーは一時プールを拡張したり候補の順序を変更したりできますが、Podを直接削除したり制約を黙って緩和したりすることはありません。リースと世代によって再試行が冪等になり、再起動時はAPIの状態から回復します。メトリクスは、バッチを拡大する前に、予算のブロック、最大の偏り、Readyレイテンシ、再試行、およびゾーン間コストをカバーします。
よくある間違い
- ドレインを速めるためにPodを直接削除する → PDBをバイパスする → 自発的なメンテナンスにはEviction APIを使用する。
disruptionsAllowedのみを確認する → 代替Podがトポロジに違反するかキャパシティが不足する可能性がある → 最初に偏りと配置をシミュレーションする。- 複数のゾーンのレプリカを一度に退避する → 障害ドメインの冗長性が失われる → ゾーンおよびワークロードの並行性トークンを使用する。
- PDBがブロックしたときにPDBを編集する → リスクをユーザーに転嫁する → 一時停止、キャパシティの追加、または承認を要求する。
- 削除のみを待機する → サービスにReadyな代替Podが存在しない可能性がある → レディネス、スケジューラーイベント、デッドラインで状態を駆動する。
- コントローラーのリースを省略する → ワーカーが操作を繰り返す → リース、世代、および冪等な状態を永続化する。
フォローアップの質問と回答
PDBはノードの突然の消失から保護できますか？
完全にはできません。PDBは主に自発的な中断を制限します。ハードウェア障害やリソース枯渇はレプリカを直接削除する可能性があります。冗長性には依然として複数の障害ドメイン、レプリカ、および予備キャパシティが必要です。
なぜkubectl delete podを使用しないのですか？
直接削除はPDBのアドミッションチェックをバイパスします。APIサーバーが許可または競合の決定を返すように、メンテナンスコントローラーはEviction APIを呼び出す必要があります。
PDBが退避を許可したにもかかわらず、代替PodがPendingのままになっている場合はどうしますか？
バッチを一時停止し、スケジューラーイベントとトポロジ数を確認して、キャパシティを追加するか別のノードを選択します。退避を続けると、冗長性のギャップがさらに広がります。
ScheduleAnywayは偏りを無視するものとして扱えますか？
いいえ。これは偏りを減らすノードを優先するようスケジューラーに指示するものですが、偏りが残る可能性があります。実際の分散、コスト、および冗長性のリスクを記録してください。
コントローラーの再起動時に重複した退避を回避するにはどうすればよいですか？
タスクリース、ノードロック、コントローラー世代、および永続化された状態を使用します。復旧時は、メモリ内のキューを再生するのではなく、APIからのPod、Eviction、ノードの状態を信頼します。
強制削除が許容されるのはどのような場合ですか？
自発的なパスではリスクに対処できず、上位の権限を持ち、PDBと冗長性が侵害される可能性があることが記録されている、明示的に承認された緊急事態の場合のみです。