VPN 利用者向けの Pod IP、ClusterIP、内部ロードバランサー

VPC CNI を使うと、Pod は VPC のアドレスを持てるため、正しいルートを持つ VPN 利用者はそこへ直接到達できます。そのため Pod への直接アクセスは最も簡単な選択肢に見えますが、それは Pod が置き換えられるまでの話です。利用者が覚えるアドレスは、レプリカではなくアプリケーションに属すべきものです。三つの入口の比較は、どのオブジェクトがアドレスを所有し、ワークロードが移動したときに何が動き続ける必要があるかという点に集約されます。

まずライフサイクルで選び、次に入口を到達可能にするためにネットワークが何をする必要があるかで選びます。

三つの入口、三つのライフサイクル

Pod IP は Pod が所有し、Pod とともに割り当てられ、終了すると解放されます。ClusterIP は Service が所有し、仮想的なもので、クラスタのサービスルーティングが存在する場所でだけ意味を持ちます。内部ロードバランサーは、クラスタのコントローラがバックエンドで構成するクラウドリソースが所有します。これらの所有モデルは、古いアドレス、到達できない名前、古くなったバックエンドの集合という、得られる障害を予測します。

選ぶ前に比較を書き留めてください。所有者と障害に名前を付ければ、選択はたいてい自然に決まります。

Pod への直接アクセス：有用だが一時的

直接アクセスは、管理者一人、短いセッション一回、特定のポート一つという管理された確認には確かに有用です。しかし、アドレスはデプロイのたびに変わる実装の詳細であるため、利用者にとっては悪い契約です。それをウィキに記録することは、動いているサービスが噂になる道です。

また、広いルールを招きます。管理者一人が一つの Pod に到達する許可はノードのサブネット内のすべてのアドレスへの許可ではなく、普通に書かれるのは後者です。

ClusterIP：設計上クラスタ内に限定

ClusterIP が機能するのは、クラスタのデータプレーンがクラスタ内でそのルーティングを構成するからです。VPN 上のノート PC からは、何かが意図的に公開しない限り、そのアドレスに意味はありません。svc.cluster.local で終わる名前はクラスタの DNS に属するため、別のリゾルバを持つクライアントにコピーすると、ルーティングエラーではなく存在しない名前になります。

クラスタ内の呼び出し元、他のワークロードを含めて、ClusterIP は正しい入口のままです。ただし、クラスタのルーティングドメインの外にいる利用者への公開の仕組みではありません。

内部ロードバランサー：公開された経路

内部ロードバランサーは、安定したプライベートアドレスと自分のゾーンが指せる名前を提供し、コントローラはバックエンドの集合を最新に保ちます。これは EKS のロードバランシングのガイドが説明するとおりです。誰かが文書を編集しなくても通常の Pod の置き換えを生き延びる入口がこれであり、コストはクラウドリソース、コントローラの設定、VPN からのルートで、人が過小評価するのはこの部分です。

クラスタが実際に実行しているコントローラのモデルを使ってください。ある統合向けに書かれた注釈は、別の統合には適用されません。

送信元アドレスは誰か

セキュリティグループが見るのは境界に届く送信元であり、VPN とロードバランシングの経路によって、接続したクライアントか変換されたアドレスになります。EC2 ベースのノードでは、通常の VPC CNI の Pod は既定でノードの ENI のグループを継承しますが、対応する構成では Pod 専用のグループを付けられます。推測したノート PC のアドレスではなく、文書化された経路に対してルールを書いてください。

アプリケーション自身のリスナーと認証は別の制御として保ってください。フローを許可するネットワークルールは承認の判断ではなく、そのように扱うべきではありません。

利用者に何を渡すか

利用者にはアドレスではなくサービス名を渡してください。名前をプライベートゾーンで公開し、内部の入口に向け、そのうえでクライアントが同じ名前を開いたままバックエンドの Pod を置き換えてテストします。この演習は、日常的なデプロイの後でも同じアプリケーションに到達できるという、重要な性質を確かめます。

Pod への直接アクセスは、独自の範囲を持つ文書化された運用上の例外として、利用者向けの手順から遠くに保ってください。