KubernetesのPod VPNと外向きゲートウェイ：トンネルの所有者は誰か

vpn-gateway という名前のPodをデプロイし、テストクライアントをそのアドレスに向けるとパケットが消えていくのは、マニフェストの誤りでもkubeletの苦情でもありません。理由は設定ではなく構造にあります。KubernetesはPodごとに独自のネットワーク名前空間を与えるため、名前やラベル、共有API名前空間をどう変えてもパケットの行き先は変わりません。したがってVPNトラフィックをどうクラスタから出すかは、コンテナイメージではなく所有権の問いから始まります。

実際のデプロイの大半は二つの仕組みでカバーされ、両者は交換可能ではありません。一方はトンネルをワークロード自身のネットワーク名前空間に置きます。もう一方はCNIに、選択したトラフィックを指定のゲートウェイノード経由で流すよう求めます。失敗の仕方もスケールの仕方も異なり、責任を持つチームも違うため、コンテナの問いは決着しない議論を生みがちです。

Podの境界は名前空間であり、ジャンプホストではない

Linuxのネットワーク名前空間は自身のインターフェース、アドレス、ルート、ファイアウォール規則を所有し、各Podは一つを受け取ります。そのPod内のコンテナはそこに参加するため、補助コンテナがルートを書き換えればアプリケーションもそれに従います。隣のPodは見た目が同じでも完全に別のスタックです。ゲートウェイPodが継承できる共有テーブルはなく、名前空間から別の名前空間へトラフィックが暗黙に引き渡されることもありません。

だからこそゲートウェイPodのパターンは、上流の何か（Service、ノード上の静的ルート、CNIのステアリングポリシー）が実際にパケットを送り込んで初めて機能します。アドレスだけでは何も引き寄せません。

Podごとのトンネルがもたらすものと、そのコスト

ワークロードの名前空間で動くトンネルは、そのワークロードに独自のクライアントIDを与えます。多くのリモートアクセスサービスはセッションを認可・課金する前にそれを要求し、影響範囲も局所にとどまって、壊れたトンネルはすべてが使う共有経路ではなく一つのDeploymentを止めるだけです。どう動くかは実装次第で、ここで人は誤解します。

カーネル状態だけで足りるセットアップはinitコンテナで完了して終了できます。Podの寿命の間ずっと生き続ける必要があるユーザースペースのデーモンは、Kubernetes 1.29でネイティブなサイドカーとして導入された再起動可能なinitコンテナ形式を必要とし、この違いは好みではなくトンネルの実装から来ます。このモデルのコストは重複で、各レプリカが認証し、独自のトンネルアドレスを受け取り、リモートセッションの枠を消費するため、オートスケールのイベントは回線の向こう側の容量イベントになります。一つの資格情報を全レプリカにコピーしてもコストは消えず、監査証跡が消えるだけです。権限も同じ検討に値し、自分の名前空間で NET_ADMIN を求めるトンネルが privileged: true の例にあるホスト全体の権限を継承する理由はありません。

CNIが外向き通信を所有する場合

CNIが対応していれば、外向きゲートウェイはワークロードと宛先範囲でトラフィックを選び、選んだノードを通して単一の予測可能な送信元アドレスの下で送ります。Ciliumの実装が一般的な参照であり、そのドキュメントは、この機能に特定のCilium設定と、正しいインターフェースとアドレスを備えたゲートウェイノードが必要だと明言しています。また、Pod作成後の初期期間はステアリングがまだ適用されないことも記しており、これは脚注ではなく設計上の入力です。

その遅延を自分の約束に照らして読んでください。他の経路でトラフィックを出してはならないという規則なら、隙間の間に送信する新しいPodはすでにそれを破っているので、ポリシーが適用されるまでアプリケーションを止めるか、その窓を受け入れて文書化するかのどちらかが必要です。

主張は狭く保ってください。外向きゲートウェイは経路を選び、変換します。VPNを終端するものではなく、背後にサポートされた接続がなければクラスタをリモートネットワークのクライアントにはしません。

変換はリモート側の見え方を静かに変える

ゲートウェイが送信元を書き換えた時点で、Podごとのアドレスは消えるため、IDに基づく許可リストは一つの共有アドレスに基づくリストになります。これは欠陥ではなく交換で、維持する規則は減り、何かが誤動作したときの帰属は粗くなります。

アプリケーション層の認証とリクエストログが、ネットワークがもう報告しないものを担う必要があります。ゲートウェイの容量と交換は共有インフラとして扱い、単一ノードの再起動が背後にあるすべてのワークロードを中断すること、そして戻り経路を早めに確認し、リモート側が変換後のアドレスにどう到達するか（通常はマニフェストではなく人が所有するルートやNAT）を知る必要があることを前提にしてください。アドレス計画もここに属し、クラスタとリモートの範囲が重なればどちらのモデルも壊れ、IPv6の採用は矛盾する計画の言い訳にはなりません。

所有権で決め、次に約束した障害を試す

リモートサービスが個々のワークロードを認証する場合、リンクを必要とするDeploymentが少数の場合、障害を局所にとどめたい場合は、Podごとのトンネルを選びます。ネットワークチームがすでに経路を所有している場合、多くのワークロードが一つの宛先を共有する場合、安定した送信元アドレスが演習の目的そのものである場合は、ゲートウェイを選びます。

いずれにせよ、定常状態ではなく、売った性質を検証してください。Podを作成し、すぐに送信させ、トンネルから何も逃げないという約束なら最初の数秒を観察します。五つのレプリカにスケールし、ワークロードごとのIDという約束ならリモート側が報告するセッション数を数えます。この二つの確認は、マニフェストのレビューよりはるかに速く仕組みの限界を露わにし、次のインシデントがどのチームのものかを教えてくれます。