プロンプトとスコープ
移行にあたっては、Ingressリソースおよびコントローラー固有のアノテーションからGateway APIリソースへと移行しつつ、外部から観測されるステータスコード、パス、ヘッダー、およびバックエンド選択を維持しなければなりません。中核となるスキルはプロキシ境界における互換性エンジニアリングであるため、この質問はbackendに属します。Kubernetesの公式ブログでは、ホスト全体に及ぶ正規表現の影響、暗黙的なリダイレクト、正規化など、見落としがちなIngress-NGINXの動作がいくつか文書化されています。
面接官が評価するポイント
単なるYAMLの変換作業ではなく、実際のトラフィック動作のインベントリ（一覧化）を重視します。優秀な候補者は、ポータブルなGateway APIのセマンティクスと実装固有の正規表現を切り分け、明示的なフィルターが必要な暗黙の動作を特定し、ロールバックを備えた差分テストを提案します。また、所有権、証明書とリスナーの依存関係、可観測性、段階的なDNSまたはトラフィックの切り替えについても論じる必要があります。
最初に確認すべき明確化のための質問
- どのIngress-NGINXのバージョン、アノテーション、Gateway APIコントローラー、および適合性（conformance）レベルがデプロイされていますか？
- どのホストが
use-regex、rewrite-target、認証、カナリア、またはカスタムスニペットを使用していますか？ - クライアントは301リダイレクト、パスの大文字/小文字、連続するスラッシュ、またはエンコードされたセグメントに依存していますか？
- 新しいGatewayを並行して実行し、ミラーリングまたはサンプリングされたトラフィックを受信できますか？
- Gateway、HTTPRoute、バックエンドポリシー、およびTLSリソースの所有者は誰ですか？
- ロールバックのトリガーは何であり、トラフィックを以前のコントローラーへどのくらい迅速に戻せますか？
30秒回答フレームワーク
「まず、マニフェスト、アクセスログ、およびブラックボックステストから動作インベントリを収集します。アノテーションがそのまま変換されると仮定するのではなく、正規表現、リライト、リダイレクト、およびTLSを明示的にモデル化して、動作ごとにGateway APIリソースを生成します。次に、新旧のコントローラーに対して差分テストを実行し、シャドウまたはカナリアトラフィックを実施し、ステータス、ロケーション、選択されたバックエンド、レイテンシを比較し、DNSまたはルーティングのロールバックを準備しておきます。説明のつかない差分がゼロになって初めて、各ホストを移行します。」
ステップごとの回答
ステップ1：観測されたコントラクトのインベントリ作成
すべてのホストとパスを解析しますが、リクエストによってそれを検証します。Ingress-NGINXの正規表現マッチングは大文字/小文字を区別せずプレフィックスベースである場合があり、1つのアノテーションがIngressオブジェクトをまたいでホストのすべてのパスに影響を与える可能性があります。リダイレクト、正規化されたパス、ヘッダー、認証、タイムアウト、およびバックエンドの選択をテスト可能なコントラクトとして記録します。
ステップ2：ポータブルな動作とコントローラー固有の動作の分類
通常のホスト/パスルーティングをGatewayおよびHTTPRouteにマッピングします。正規表現マッチングは実装固有のものとして扱い、選択したコントローラーのセマンティクスを検証します。サポートされている場合は、リライトやリダイレクトの動作を明示的なHTTPRouteフィルターに変換します。サポートされていないアノテーションやスニペットは、所有者と代替設計を定めて移行ブロッカーとして扱います。
ステップ3：差分テストマトリックスの構築
各コントラクトについて、通常パスと敵対的（エッジケース）パスをテストします：大文字/小文字のバリエーション、末尾スラッシュ、.および..セグメント、重複スラッシュ、エンコード文字、存在しないルート、およびバックエンド障害。ステータス、Location、バックエンドが受信したパス、ヘッダー、選択されたサービス、およびエラーボディを比較します。両方のコントローラーに対して同一のフィクスチャとリクエストヘッダーを使用します。
ステップ4：コントローラーとポリシーの準備状況の証明
GatewayおよびHTTPRouteのステータス条件、リスナーのアタッチ状況、証明書の準備状況、クロスネームスペースの参照ポリシー、および各フィルターの実装サポートを確認します。APIによってリソースが受け入れられた（Accepted）からといって、データプレーンが要求されたすべての機能を実装していることの証明にはなりません。
ステップ5：カナリアとロールバック
小さなホストまたはトラフィックの一部を用いて、並行してGatewayを実行します。可能であれば安全な冪等リクエストをミラーリングし、そうでなければサニタイズされたフィクスチャをリプレイします。原因不明のルーティング差分、4xx/5xxの変化、リダイレクトのずれ、またはレイテンシの悪化が発生した場合は中止します。観測ウィンドウが閉じるまで、古いコントローラーとDNSまたはトラフィックの重みを変更せずに維持します。
模範回答
「現在のIngress-NGINXの動作を外部コントラクトとして扱います。マニフェスト、アノテーション、ログ、およびプローブのインベントリを作成した後、各コントラクトをGatewayおよびHTTPRouteリソースで明示的にモデル化します。正規表現、リライト、末尾スラッシュのリダイレクト、およびURLの正規化にはコントローラー固有の検証が必要です。一部の暗黙の動作は明示的なフィルターにする必要があります。ステータス、Location、バックエンドパス、ヘッダー、およびサービス選択を網羅する差分マトリックスを実行し、その後ロールバック用の重み付けを用いてカナリアリリースを行います。Gatewayのステータス条件や適合性の主張は必要条件であっても十分条件ではないため、DNSを変更する前にブラックボックスの証拠を確保します。」
よくある間違い
- YAMLを1対1で変換する → アノテーションがホスト全体に隠れた影響を与える可能性がある → ランタイムの動作をインベントリ化してテストする。
Exactが同一のマッチングを意味すると仮定する → 古いコントローラーには正規表現や正規化の副作用がある可能性がある → 大文字/小文字、スラッシュ、エンコードのバリエーションをテストする。- リソースのAcceptedステータスに依存する → データプレーンのサポートがまだ不完全な可能性がある → ステータス条件とブラックボックス応答を確認する。
- 最初にDNSを切り替える → ロールバックが遅く不透明になる → 古いパスを利用可能な状態に保ちながらトラフィックをカナリア展開する。
- バックエンドから見えるパスを無視する → リライトによってアプリケーションが破損する可能性がある → バックエンドが受信するパスとヘッダーを検証する。
- ハッピーパス（正常系）のみをテストする → 障害はリダイレクトや不正なURLに潜んでいる → ネガティブテストや敵対的フィクスチャを含める。
フォローアップ質問
フォローアップ1：正規表現の移行によってトラフィックが変わる可能性があるのはなぜですか？
Ingress-NGINXは、ホストのすべてのパスにわたって大文字/小文字を区別しないプレフィックスのような正規表現動作を適用することがあります。Gateway APIの正規表現は実装固有であり、ExactやPrefixが暗黙的に正規表現に変わることはありません。
フォローアップ2：末尾スラッシュのリダイレクトを維持するにはどうすればよいですか？
HTTPリダイレクトフィルターで明示的にモデル化し、両方のスラッシュパターンをテストします。Gatewayの実装が以前の301を自動的に追加すると仮定してはなりません。
フォローアップ3：安全なロールバックのシグナルとは何ですか？
固定されたベースラインと制限された観測ウィンドウに対して評価された、ステータス、Location、バックエンドパス、サービス選択、エラー率、またはレイテンシの未解明な差分を使用します。
フォローアップ4：移行ツールは何を証明できますか？
変換ツールはインベントリ作成を迅速化し候補リソースを生成できますが、コントローラー固有のセマンティクス、アノテーションの隠れた相互作用、またはアプリケーションの互換性を証明することはできません。リリースゲートとして差分テストを維持してください。