プロンプトとコンテキスト
あるステートレスサービスが複数ゾーンにまたがって稼働しており、2から30レプリカの間でスケールします。ノード障害、スケーリング、ローリングリリースの間、チームは新しいリリースのスケジューリングが不可能にならないようにしつつ、レプリカが単一の障害ドメインに集中するのを防ぎたいと考えています。topologySpreadConstraintsを設計し、DoNotSchedule、ScheduleAnyway、またはanti-affinityをどのような場合に使用すべきかを説明してください。
面接官の評価ポイント
- 可用性を、ノード、ゾーン、リージョンの明示的な障害ドメイン目標に落とし込めているか。
maxSkew、minDomains、topologyKey、whenUnsatisfiableを正しく説明できるか。- セレクター、トポロジーラベルの欠落、少数のレプリカにおけるエッジケースを捉えられているか。
- 配置、PDB、ローリングアップデート、オートスケーリング、可観測性が単一の設計として連携して機能しているか。
明確化のための質問
- 各ゾーンは電力、ネットワーク、キャパシティの面で独立していますか？また、リージョン全体の障害はスコープに含まれますか？
- 1つの障害ドメインを失った後、最低いくつのレプリカを維持する必要がありますか？
- スケジューリング不能なPodは待機すべきですか、可用性を下げるべきですか、それとも一時的な偏り（skew）を許容すべきですか？
- ワークロードのラベル、ノードのトポロジーラベル、デフォルトの制約はプラットフォーム側で管理されていますか？
- ローリングアップデート中、新旧のバージョンは同じ
labelSelectorを使用しますか？
30秒の回答
まず障害ドメインと最小キャパシティを定義し、ノードとゾーンに対して別々の配置目標を設定します。ミッションクリティカルなサービスには境界付きのDoNotScheduleを使用し、通常のワークロードや弾力的なワークロードにはソフトな目標としてScheduleAnywayを使用します。maxSkewは対象ドメイン全体における1つのセレクターの差異を制限し、minDomainsはドメインが不足している際の誤った計算を防ぎます。ロールアウト前にはラベル、スケーリング、ローリングアップデート、単一ドメイン障害をテストし、本番環境ではドメインごとのレプリカ数、Pending時間、利用可能なキャパシティ、PDBの中断バジェットを監視します。
詳細な回答
ステップ1：ドメインとキャパシティを定義する
ノード、ゾーン、リージョンを個別のtopologyKey値にマッピングします。サービスが1つのゾーン喪失に耐える必要がある場合、少なくとも2つのゾーンに十分なレプリカを維持します。レプリカが2つしかない場合、3つのゾーンに均等に配置することと、1つ喪失した後に2つの正常なレプリカを維持することを両立させる約束はできません。厳密性を選択する前に、キャパシティの不変条件（invariant）を定義してください。
ステップ2：maxSkewとminDomainsを選択する
maxSkewは、対象ドメインとグローバル最小値との間で許容される差です。DoNotScheduleを使用している場合、これを超えるとPodはPendingのままになります。minDomainsは適格なドメインがいくつ必要かを表現し、不十分なドメインセットが有効な分散として扱われるのを防ぎます。制約によってリリースがブロックされないよう、レプリカ数が少ないサービスでテストしてください。
ステップ3：ハードな制約とソフトな制約を分離する
コントロールプレーンや決済サービスでは、ゾーンレベルのDoNotScheduleを使用し、配置の失敗をキャパシティアラートに変換できます。バッチ処理や延期可能な処理ではScheduleAnywayを使用し、一時的な不均衡を許容しながらスケジューラーに偏りの軽減を要求できます。ハードなanti-affinityは単純な「同じ場所に配置しない」というルールに適しています。複数レベルのトポロジーや測定可能な偏りを扱う場合は、通常spread constraintsの方が明確です。
ステップ4：セレクターとラベルの信頼性を確保する
制約のlabelSelectorは実際のPodテンプレートと一致していなければならず、そうでなければ新しいPodが誤ったセットに対してカウントされる可能性があります。ノードには安定したゾーン、リージョン、ホスト名のラベルが必要です。トポロジーキーを持たないノードは、そのドメイン計算に正しく参加しません。アドミッションチェックにより、チームが壊れたマニフェストをコピーする前にセレクター、ラベル、デフォルト値を検証する必要があります。
ステップ5：リリース、PDB、スケーリングを連携させる
ローリングアップデートでは、古いレプリカ、新しいレプリカ、maxUnavailableを一緒に考慮する必要があります。PDBは自発的な中断（voluntary disruption）を制限するものであり、ドメインをまたぐ配置を代替するものではありません。オートスケーラーはPending状態のPodとドメインごとのキャパシティを理解する必要があり、そうでなければ厳密な制約によって使用可能なノードが追加されないまま永久に待機する可能性があります。
ステップ6：障害時およびデグラデーション時のアクションを定義する
ノードの喪失、ゾーンの喪失、ノードラベルの欠落をシミュレーションし、新しいPodが拒否されるか、偏るか、あるいはPendingになるかを観察します。クリティカルなサービスでは、優先度の低いリリースを一時停止したり、正常なドメインにキャパシティを追加したり、読み取り専用モードに移行したりできます。可用性のリスクを記録することなく、本番環境でハードな制約を解除してはなりません。デグラデーション時のアクションはバージョン管理し、ロールバックできるようにします。
ステップ7：分散メトリクスで検証する
ワークロード、バージョン、トポロジードメインごとに、レプリカ数、偏り（skew）、Pending期間、スケジューリング理由、利用可能なキャパシティ、PDBの中断、リクエストエラーを記録します。負荷テストでは、2〜30レプリカ、不均等なドメインキャパシティ、ローリングアップデート、オートスケーリングをカバーする必要があります。目標は、単にレプリカが異なるノードに配置されたことだけでなく、ドメイン喪失後も残りのキャパシティがSLOを満たしていることを証明することです。
模範回答
ノード、ゾーン、リージョンを3つの障害ドメイン層としてモデル化し、まずゾーン喪失後に必要な最小レプリカ数を設定します。サービスPodはテンプレートと一致するセレクターを使用し、制約はホスト名とゾーンに対して個別に適用します。クリティカルなサービスにはDoNotScheduleを指定した小さなゾーンmaxSkewを使用し、バッチ処理にはScheduleAnywayを使用します。適格なドメインがminDomainsを下回る場合は、誤解を招く分散を黙って受け入れるのではなく、キャパシティアラートを発行します。ローリングアップデート中はPDB、maxUnavailable、新旧のセレクターを検証し、オートスケーラーにPending理由とドメインキャパシティを監視させます。監視モードでロールアウトした上で、ドメインごとのレプリカ数、Pending時間、障害ドメイン訓練、ビジネスSLOをロールバックのゲートとして段階的にハードな制約を有効化します。
よくある間違い
topologyKeyやキャパシティの目標を挙げずに「複数ゾーンにデプロイする」とだけ述べる。maxSkewをドメインごとの絶対的なレプリカ制限値として扱う。- セレクターの不一致を無視し、その結果誤ったPodセットをカウントしてしまう。
- PDBをスケジューラーの制約として扱ったり、あらゆるノード障害からの保護策として扱ったりする。
- レプリカが2つしかないのに、3つのゾーンへの均等配置とゾーン喪失時の無停止（デグラデーションなし）を約束する。
- 可用性のトレードオフを記録せずに、Pendingを解消するためだけに
DoNotScheduleを削除する。
フォローアップ質問
フォローアップ1：ScheduleAnywayは依然として可用性に役立ちますか？
はい。キャパシティが逼迫している場合でもワークロードの実行を許可しつつ、偏りを小さくすることをスケジューリングの優先事項とします。延期可能な処理や他の冗長性を備えたワークロードに適しています。クリティカルなサービスはあらかじめスケールさせておき、ハードな制約を使用できます。
フォローアップ2：なぜPod anti-affinityだけを使用しないのですか？
Anti-affinityは選択されたPodと同じ場所に配置しないことを意味します。複数レベルのトポロジー、数値的な偏り（skew）、最小ドメイン要件などを直接的に表現することは難しくなります。Spread constraintsはドメイン間の不均衡を記述するのに対し、anti-affinityは単一の排他ルールのために依然として有用です。
フォローアップ3：minDomainsが正しくない場合どうなりますか？
適格なドメインが少なすぎる場合、偏りの計算に使用されるグローバル最小値によって制約が満たされているように見えたり、PodがPendingのままになったりする可能性があります。アドミッションチェックやキャパシティアラートにドメインの可用性を含め、クラスタのバージョンにおけるフィールドの挙動を確認してください。
フォローアップ4：なぜローリングリリースが分散を崩すことがあるのですか？
新旧のバージョンで異なるセレクターが使用されていたり、maxUnavailableやmaxSurgeによって一時的に特定のドメインにレプリカが追加されたりすることがあるためです。リリース前に中間状態をシミュレーションし、バージョンおよびドメインごとの偏りを検査してください。
フォローアップ5：ノードにゾーンラベルがない場合はどうなりますか？
要求されたトポロジー計算に正しく参加しません。ノードを修復するか隔離してください。ラベルのないノードを独立した障害ドメインとしてカウントしてはなりません。
フォローアップ6：ゾーン障害後もSLOを維持できることをどのように証明しますか？
隔離訓練（isolation drill）を実行し、残りのドメインにおけるスケジューリング可能なキャパシティ、正常なレプリカ、リクエストエラー、復旧時間を検証します。PDBの状態、Pendingの理由、スケールアップ時間を記録し、スケジューリングからビジネスメトリクスに至るまでの完全なパスを検証します。