プロンプトとコンテキスト
高可用性（HA）Kubernetesクラスターが、コントロールプレーンをv1.35からv1.36へローリングアップデートしています。この移行期間中、異なる kube-apiserver インスタンスは異なるリソースバージョンを認識している可能性があるため、古いサーバーにルーティングされたクライアントは、新しいピアに存在するリソースに対して誤解を招く404を受信する可能性があります。Mixed Version Proxyがリクエストをルーティングし、信頼関係を制限し、オブザーバビリティを提供し、ロールバックをサポートする方法を設計・説明してください。また、Kubernetes v1.36のBeta動作と通常のバージョン偏差ポリシー（version-skew policy）を区別してください。
面接官が評価するポイント
- バージョン偏差、ディスカバリキャッシュ、APIの可視性を個別の障害ドメインに分離できているか。
- プロキシがリソースリクエストをルーティングするものであり、API変換やストレージ移行を代替するものではないことを理解しているか。
- ピアディスカバリ、フォワーディング、ID伝播、およびループ防止を説明できるか。
- アップグレードの安全性、監査性、タイムアウト、リトライ、およびロールバックを網羅しているか。
確認すべき明確化のための質問
- これは単一クラスター内でのローリング置換ですか、それともクラスター間移行ですか？ 複数のピアAPIサーバーを持つ1つのクラスターを想定します。
- クライアントはKubernetesの組み込みリソースのみを使用していますか、それともAggregated APIサーバーやCRDも使用していますか？ 未知のリソースバージョンに対するプロキシのカバレッジを確認します。
- 共有ロードバランサー、mTLS、集中監査ログ、およびメトリクスはすでに利用可能ですか？ これらはID伝播と診断のアプローチを決定します。
- 追加レイテンシ、利用不可時間、ロールバック時間の許容予算（バジェット）はどのくらいですか？
30秒の回答フレームワーク
まず障害事象から始めます。ローリングアップグレード中、古いAPIサーバーは新しいリソースバージョンを存在しないリソースと誤認する可能性があります。次に処理経路を示します。エントリAPIサーバーがディスカバリとローカル判定を実行し、バージョンがローカルで未知である場合、互換性のあるピアに転送し、ピアのレスポンス、ステータス、監査IDを呼び出し元に返します。最後に境界条件で締めくくります。バージョン偏差ポリシーに従い、プロキシのループを禁止し、プロキシのID権限を制限し、明示的なフォワーディング失敗を返し、コントロールプレーンの障害を隠蔽するリトライを回避し、メトリクスと段階的なフィーチャースイッチによってロールバックします。
ステップごとの詳細解説
1. リクエストの分類と転送の判断
APIサーバーは、グループ、バージョン、リソース、および動詞（verb）を解析します。リソースがローカルに登録されている場合、ローカルの認証、認可、アドミッション、ストレージ処理に従います。リクエストされたバージョンがローカルディスカバリで未知である場合、サーバーはどのピアがそのリソースバージョンをアドバタイズしているかを確認します。ピアがサポートを明示的に確認した後にのみ転送し、それ以外の場合は識別可能なエラーを返します。プロキシはバージョンを推測したり、通常のビジネスロジック上の404をすべて転送トリガーにしてはなりません。
2. ピアディスカバリ、IDの保持、およびループの防止
ピアは、制御されたコントロールプレーンメンバーシップリストまたは信頼された内部ディスカバリメカニズムから取得する必要があります。接続には既存のコントロールプレーンサービスIDと暗号化チャネルを使用します。転送されるリクエストには、元のユーザーID、グループ、認可ヘッダー、監査コンテキストが含まれますが、プロキシは引き続き独自の認可境界を強制します。ホップマーカーまたは同等の内部メタデータを追加します。マーカーを検出したサーバーは再度転送してはならず、AからB、BからAへのループを防止します。
3. 一貫性と障害の処理
読み取り操作では、APIサーバー間でディスカバリキャッシュの一時的な不一致が観測される可能性があるため、クライアントはサーバーのリソースバージョンと resourceVersion に依存する必要があります。転送はターゲットが到達可能かつバージョン互換である場合にのみ行われます。タイムアウト、拒否、またはバージョン不一致のレスポンスは、記録された理由とともにフェイルファストします。副作用が重複する可能性があるため、書き込み操作に無制限のリトライを適用してはなりません。リトライが必要な場合は、冪等性キーまたは明示的なクライアントリトライポリシーを使用します。
4. ロールアウト、オブザーバビリティ、およびロールバック
オフピーク時に1台のAPIサーバーをアップグレードし、プロキシのヒット率、フォワーディングレイテンシ、未知バージョンエラー、5xxレスポンス、監査の完全性、およびディスカバリの収束を監視してからバッチを拡大します。Mixed Version Proxyはv1.36でBetaとなりデフォルトで有効化されていますが、ディストリビューションのバージョン偏差マトリクスを検証する必要がなくなるわけではありません。シグナルが悪化した場合、置換を停止し、互換性が確認されているピアにトラフィックを維持し、サポートされている場合はフィーチャーゲートを無効化してコントロールプレーンをロールバックします。監査レコードには転送チェーンと元のIDを保持します。
模範回答
私はMixed Version Proxyを新しいAPIゲートウェイとしてではなく、一時的なコントロールプレーンの互換性レイヤーとして扱います。エントリサーバーはリクエストを認証、認可、分類します。ローカルで把握しているリソースはローカルパスに従い、ローカルで未知のリソースバージョンはピアが明示的にアドバタイズしている場合にのみ転送されます。接続には既存のコントロールプレーンIDを使用し、元のユーザーおよび監査コンテキストを伝播し、ループを防ぐためにシングルホップマーカーを追加します。ピアのステータスとレスポンスのセマンティクスは保持されます。タイムアウトはフェイルファストし、書き込みに対して無制限の自動リトライは行いません。
このパスを段階的なアップグレードで検証します。ローカルヒット、プロキシヒット、ターゲットバージョン、レイテンシ、エラー分類、監査相関IDを記録します。ヒット率や5xxがしきい値を超えた場合はバッチを一時停止します。v1.36でのデフォルトBeta化は、ディストリビューションの偏差ポリシーやAggregated APIおよびCRDのカバレッジ確認の代わりにはなりません。ロールバックとは、置換を停止し、コントロールプレーンのメンバーセットを復元し、サポートされている場合はフィーチャーゲートを無効化し、クライアントが古い機能を使い続けないようにディスカバリキャッシュを確認することを意味します。
よくある間違い
- プロキシを未知のリソースバージョンのルートとしてではなく、任意のAPIバージョン変換機能として説明してしまう。
- ピアディスカバリ、ID伝播、ループ保護に触れず、「新しいノードに転送する」とだけ言ってしまう。
- すべての404を転送してしまい、純粋に存在しないリソースをコントロールプレーントラフィックに変えてしまう。
- 条件なしに書き込みをリトライし、重複した副作用を引き起こしてしまう。
- ディスカバリの収束、監査の整合性、偏差の制約を見落とし、平均レイテンシのみを監視してしまう。
フォローアップの質問と回答
フォローアップ 1: Aggregated APIサーバーやCRDは自動的にプロキシされますか？
そのリソースが実装されているMixed Version Proxyのスコープ内にあるかどうかを確認してください。Aggregated APIサーバーには独自のディスカバリ、認証、および可用性の境界があります。組み込みリソースのサポートがそれらのサポートを意味するわけではありません。機能マトリクスと、サポートされていないリソースに対する明示的なフェイルファストパスを提示してください。
フォローアップ 2: 転送処理がコントロールプレーンの障害を増幅するのを防ぐにはどうすればよいですか？
シングルホップマーカー、デッドライン、同時実行制限、およびサーキットブレーカーを使用します。送信元で無制限にリトライしないでください。プロキシヒット率、ターゲットエラー、キュースタックに対してアラートを設定し、これらのシグナルがしきい値を超えた場合にアップグレードコントローラーがバッチを一時停止できるようにします。
フォローアップ 3: クライアントのディスカバリキャッシュが古い場合はどうなりますか？
クライアントは引き続きKubernetesのディスカバリとバージョン偏差ルールに従います。サーバー側の転送は、ローリングアップグレード中の誤った404を減らすことができますが、クライアントのために新しいリソースを永続的にキャッシュしたり、APIバージョンの移行を代替したりすることはできません。必要に応じて、クライアントに再ディスカバリを実行させ、明示的なAPIバージョンを使用させてください。