Pod・ノード・クラスター:VPNサイドカーが実際に振り向ける範囲
同じ Pod のコンテナはネットワーク名前空間を共有するため、経路を変えるサイドカーはアプリに影響しますが、他の Pod やノードには影響しません。
Kubernetes の Pod 内にある VPN サイドカーは、行儀のよいホストレベルの VPN のように見えますが、その類似は名前空間の境界で終わります。同じ Pod のコンテナはアドレスとポートの空間を含むネットワーク名前空間を共有するため、経路とポリシーを設定するサイドカーは、アプリのパケットがどこへ行くかを実際に変えます。ノード上の他の Pod には何も変えず、そう設定しない限りノード自身のスタックにも触れません。この境界を正しく理解することが、何を配備でき、何を検証すべきかを決めます。以下の節では名前空間から外側へ順に追います。
共有された名前空間、共有された結果
Pod 内の 二つのコンテナは loopback で通信し、同じインターフェースを見ます。サイドカーのパターンが成り立つのはそのためです。アプリはトンネルの存在を知る必要がありません。解決する経路が、使っている名前空間に設定されているからです。同じ性質は、サイドカーの誤りがアプリの誤りになることも意味します。取り込みすぎる経路や、トンネル内のリゾルバーを指す DNS 変更は、その Pod のすべてのプロセスに直ちに適用されます。共有名前空間ではコンテナごとのルーティングが存在しないため、サイドカーを 一つのプロセスに限定することはできません。
レビュー時に覚えておくべき仕組みはこれです。影響範囲は Pod であり、ノードでもクラスターでもありません。
サイドカーが届かない範囲
他の Pod はそれぞれの名前空間とルーティングを保つため、同じ外向き通信を必要とするワークロードには同じサイドカーか、代わりにノードレベルの設計が必要です。ノードの通信も Pod の名前空間の外にあり、ホストネットワークを使う Pod はこの分離から意図的に完全に外れます。都合よく何かに届くためにサイドカーをホストネットワークで動かすなら、範囲を 一つの Pod からノード全体に広げたことになり、それは明言すべきです。
クラスターのサービスへの通信がもう 一つのよくある驚きです。Pod 内の広いデフォルト経路は、API サーバーや ClusterIP サービス宛ての要求を捕まえてしまい、その後トンネルが壊れたかのような形で失敗します。
経路計画:Pod・サービス・ノード・VPN の範囲
四つの範囲を書き出し、何かを配備する前に重なりを確認してください。Pod の CIDR、サービスの CIDR、ノードのアドレス、VPN の背後の宛先です。VPN のプライベート範囲とクラスター自身の空間の重なりは珍しくなく、デフォルト経路はその正しい解決策ではありません。経路計画はマニフェストと同じリポジトリに置くべきです。次のクラスターがまったく別の Pod とサービスの範囲を割り当てるかもしれないからです。
DNS は計画の一部であり、別個の懸念ではありません。リゾルバーの設定を書き換えるサイドカーは、外部の問い合わせを完璧にしつつ、クラスター内のサービス検出を壊すことがあります。
起動と障害は明示的な状態
実行中のサイドカープロセスは外向き通信のポリシーではありません。トンネルが整う前にどの通信を流してよいか、その後で落ちたら 何が起きるか を決め、その決定を実装します。アプリコンテナを制御するプローブ、既定で拒否するネットワークポリシー、あるいはその両方です。どちらもなければ、トンネルがまだ接続中の間にアプリが起動し、名前解決し、ノードの通常経路から通信を送り出します。
その隙間は健全なクラスターでは短く、壊れたクラスターでは恒久的です。攻撃者や偶発的なデータ漏えいが好む性質は、まさにこれです。
順序を障害テストと組み合わせます。サイドカーを止め、アプリが黙って後退するのではなく、意図した外向き通信を失うことを確認します。
権限、ポリシー、アプリコンテナからの検証
インターフェースを作り経路を変えるために必要な権限を与えるかどうかは特権の判断であり、分離された Pod に適した特権がノードのスタックにも自動的に適切とは限りません。クラスターが対応するネットワークとセキュリティのポリシー機構を使い、すべての CNI やポリシーの実装が VPN インターフェースを同じように扱うと仮定しないでください。違いは、あなたが気にする障害ケースでこそ現れます。
実際のアプリコンテナから、プライベートな宛先、クラスターのサービス、公共のインターネットへ新しい要求を出して検証します。サイドカーからの検証はトンネルが動くことを示すだけで、アプリが必要なものに届くことは示しません。
クラスターのネットワーク前提を VPN の設定の隣に文書化します。そうすれば、ワークロードを別のクラスターへ移す作業は、黙って動かなくなるイメージ変更ではなく、経路計画を確認する作業になります。