ゾーンをまたぐ Kubernetes Topology Aware Routing をどのように設計しますか？

質問と背景

3 ゾーン構成の Kubernetes クラスターで、高コストなゾーン間トラフィックが発生するサービスが稼働しています。チームは、ゾーンのキャパシティ不足、トラフィックの偏り、またはノード障害が発生した際にも可用性を維持しつつ、リクエストが送信元ゾーン内の Pod を優先するようにルーティングしたいと考えています。機能の有効化、エンドポイントの分散、フォールバック、オブザーバビリティ、およびロールバックを設計してください。

面接官が評価するポイント

EndpointSlice ヒント、kube-proxy による消費、および Service のトラフィックポリシーを明確に区別できているか。
同一ゾーンが常に優れていると決めつけるのではなく、エンドポイント数やバランスの取れた送信元トラフィックなどの前提条件を特定できているか。
グローバルなフォールバック、障害に対するセーフガード、およびホットスポットの監視を設計できているか。
ゾーン間コスト、レイテンシ、エンドポイントの負荷、およびロールアウトのリスクを定量化できているか。

最初に確認すべき明確化の質問

トラフィックと目標

送信元トラフィックはゾーン間で均等に分散されていますか？目標は p95 レイテンシの削減、ゾーン間コストの削減、またはデータレジデンシーの維持のいずれですか？エラーを返すよりもゾーン間アクセスを許可する方が望ましいですか？

エンドポイントとスケーリング

各ゾーンに準備完了（Ready）状態の Pod はいくつ存在しますか？スケーリング、ローリングリリース、または PodDisruptionBudget によって、安全なエンドポイント数が一時的に減少する可能性はありますか？その Service はノードローカルなトラフィックも必要としていますか？

障害とオブザーバビリティ

障害ドメインはゾーン、ノード、またはネットワークのいずれですか？ゾーンの過負荷、ヒントの欠落、または kube-proxy のフォールバックをどのように検知しますか？この機能は Service ごとに有効化できますか？

30秒での回答

まず送信元トラフィックとエンドポイントの分散がルーティングの前提条件を満たしていることを検証し、次に EndpointSlice ヒントまたは Service でサポートされている traffic-distribution 設定を介してゾーンの優先設定を有効化します。キャパシティまたは安全条件が満たされない場合、コントロールプレーンと kube-proxy はクラスター全体のエンドポイントへフォールバックする必要があります。ゾーン間バイト数、p95 レイテンシ、ゾーンごとのリクエスト数、およびエンドポイント負荷を監視し、変更をカナリアリリースして、ホットスポットや障害が発生した場合には優先設定を無効化します。

詳細なソリューション

1. コントロールプレーンとデータプレーンの分離

EndpointSlice コントローラーはエンドポイントのトポロジーを使用してヒントを生成し、kube-proxy または他のノードデータプレーンコンポーネントがそれを消費します。Topology Aware Routing は送信元ゾーン内のエンドポイントを優先しますが、厳格な同一ゾーン内ルーティングを保証するものではありません。コントロールプレーンの計算、EndpointSlice の伝播、およびノードの動作を個別に観察します。

2. 前提条件の確認

Kubernetes のドキュメントでは、ゾーンごとに最低 3 つのエンドポイントが推奨されています。3 ゾーンのクラスターでは、通常少なくとも 9 つのエンドポイントを意味します。エンドポイントが少なすぎると、コントローラーはヒントを出力しない場合があります。また、送信元が特定のゾーンに集中していると、そのゾーンが過負荷になる可能性があるため、トラフィック履歴とキャパシティデータを用いて前提条件を検証します。

3. 設定の選択

対象の Kubernetes バージョンに応じたトポロジーモードまたはサポートされている trafficDistribution 機能を使用します。例:

yaml

apiVersion: v1
kind: Service
metadata:
  name: checkout
  annotations:
    service.kubernetes.io/topology-mode: "Auto"
spec:
  selector:
    app: checkout
  ports:
    - port: 443
      targetPort: 8443

API バージョン、フィーチャーゲート、および kube-proxy の動作を確認することなく、レガシーな topology-aware-hints アノテーション、現在のトポロジーモード、およびバージョン固有のフィールドを混在させないでください。

4. 安全なフォールバックの設計

エンドポイントが不十分な場合、ヒントが無効な場合、または割り当てが安全でない場合、コントロールプレーンまたは kube-proxy はクラスター全体のエンドポイントを使用する必要があります。フォールバックは可観測にしておく必要があります。そうしないと、ゾーン間トラフィックの発生が最適化の成功と誤認される可能性があります。ゾーン全体の障害、EndpointSlice の伝播遅延、不正なノードラベル、および kube-proxy のバージョン混在をテストします。

5. ホットスポットの防止

同一ゾーンの優先設定はエンドポイントのセットを狭めます。ゾーンごとのリクエスト数、接続数、CPU、キューの深さ、およびエラーを追跡します。あるゾーンが不釣り合いに大きな送信元シェアを受け取っている場合やエンドポイントが少なすぎる場合は、優先度を下げるか一時的にグローバルルーティングを使用します。スケーリングやローリングリリースでは、すべてのゾーンで準備完了エンドポイントと PDB のヘッドルームを維持する必要があります。

6. コストとレイテンシの評価

ゾーン間バイト数、リクエストの p50/p95/p99、コネクションの再利用、エンドポイントの負荷、およびエラー率をまとめて記録します。有効化の前後で同じトラフィックウィンドウを比較します。そうしないと、キャッシュヒットやクライアントのリトライの変化がトポロジールーティングの影響と誤認される可能性があります。コスト削減のためにエラー率やテールレイテンシを悪化させてはなりません。

7. 段階的なロールアウトとロールバック

重要度の低い Service または 1 ゾーンのカナリアで機能を有効にし、EndpointSlice ヒント、kube-proxy の選択、およびフォールバックイベントを検証した上で、同様のサービスに展開します。ロールバック時は優先設定を削除し、グローバルエンドポイントに戻ることを検証します。設定バージョン、メトリクスウィンドウ、および障害訓練のエビデンスを保持します。

優れた回答の例

私はトポロジーの優先設定を、元に戻すことが可能なパフォーマンス最適化として扱います。まずエンドポイント数と送信元の分散を検証し、次に EndpointSlice コントローラーにノードデータプレーン用のヒントを作成させます。エンドポイント不足、ゾーンの不均衡、または非互換コンポーネントがある場合は、グローバルフォールバックをトリガーします。ゾーン間バイト数、ゾーンごとの負荷、レイテンシ、エラー、およびフォールバック数を監視し、展開前にカナリアリリースを実施します。過負荷や障害が発生したゾーンは、優先設定を無効にすることで可用性を回復できます。

よくある間違い

ヒントが厳格な同一ゾーン内ルーティングを保証すると思い込むこと。
エンドポイント数や送信元トラフィックのバランスに関する前提条件を無視すること。
ゾーン間コストばかりに注目し、エンドポイントの過負荷やテールレイテンシを見落とすこと。
レガシーなアノテーション、バージョン固有のフィールド、フィーチャーゲートを単一の汎用 API として扱うこと。
ヒントが消失した際のグローバルフォールバックや障害訓練を用意していないこと。
ロールアウトやスケールダウンによって、ゾーンが安全な準備完了エンドポイントのマージンを下回るのを放置すること。

フォローアップの質問と回答

エンドポイントが不足している場合にフォールバックするのはなぜですか？

トポロジーの優先設定は候補セットを狭めるため、エンドポイントが少なすぎると過負荷や障害のリスクが高まります。グローバルエンドポイントを使用することで可用性を最優先に維持します。

エンドポイント 3 つというルールは厳格な要件ですか？

これはゾーンへの割り当てを改善するために Kubernetes のドキュメントで推奨されている適用基準であり、すべてのワークロードに対する絶対的な保証ではありません。トラフィック、キャパシティ、および障害目標に照らして検証してください。

すべてのリクエストが 1 つのゾーンから発生している場合はどうなりますか？

同一ゾーン優先設定によって、そのゾーンに負荷が集中する可能性があります。優先度を下げるか、そのゾーンにエンドポイントを追加するか、グローバルにフォールバックした上で、負荷とレイテンシのメトリクスで確認します。

kube-proxy がヒントを消費したことをどのように証明しますか？

EndpointSlice のヒント、ノードコンポーネントのバージョン、および実際のリクエスト分散を検査します。コントロールプレーンのオブジェクトを確認するだけでなく、ゾーン間バイト数とゾーンごとのエンドポイントヒット率を用いてエンドツーエンドのエビデンスを取得します。

ロールバックには Service の再作成が必要ですか？

通常はトポロジーの優先設定を削除または調整し、EndpointSlice およびノードデータプレーンの動作がグローバルな選択に戻ることを確認するだけで十分です。ロールバック手順の訓練とメトリクスのエビデンスを保持してください。