Kubernetes 外部 HTTP リクエストが Pod コンテナに到達するプロセス全体

Kubernetes クラスター外部からの HTTP/HTTPS リクエストはどのようにして Pod 内のコンテナに到達するのでしょうか?

HTTP リクエストフローの概要

上の図に示すように、全体のプロセスはおおよそ次のようになります。

（1）ユーザーはWeb/モバイル/PCクライアントからHTTP/HTTPSリクエストを送信します。

（２）アプリケーションサービスは通常、ドメイン名を通じて外部に公開されるため、要求はまずDNSドメイン名を通じて解決され、対応するパブリックIPアドレスが取得されます。

（3）パブリックIPアドレスは通常ロードバランサーにバインドされており、リクエストはこのロードバランサーに入ります。

ロードバランサはハードウェアまたはソフトウェアになります。 IP アドレスが切り替えられると、DNS キャッシュにより一定期間サービスにアクセスできなくなるため、通常は安定した状態 (固定パブリック IP アドレス) のままになります。
ロードバランサは、パブリックネットワークトラフィックを外部から受け入れ、トラフィックを内部で管理および転送する重要な中間層です。

（4）ロードバランサはリクエストをKubernetesクラスタ内のトラフィックエントリポイント（通常はイングレス）に転送します。

Ingress はクラスター内のルーティングと転送を担当し、クラスター内のゲートウェイと見なすことができます。
Ingress は単なる構成です。イングレスコントローラはトラフィックの転送を担当します。後者には、Nginx、HAProxy、Traefik、Kong など、多くのオプションがあります。

（５）イングレスは、ユーザー定義のルーティングルールに基づいてサービスにさらに転送されます。

たとえば、転送は要求されたパスまたはホストに基づいて行われます。

（6）サービスはセレクタ（ラベルに一致する）に基づいてリクエストをポッドに転送します。

サービスには多くの種類がありますが、クラスター内で最もよく使用されるタイプは ClusterIP です。
サービスは本質的には単なる構成であり、最終的にはノード上の kube-proxy コンポーネントに作用し、iptables/ipvs を設定することで実際のリクエスト転送を完了します。
サービスは複数のポッドに対応する場合がありますが、リクエストは最終的にランダムに 1 つのポッドにのみ転送されます。

（7）ポッドは最終的にその中のコンテナにリクエストを送信します。

同じポッド内に複数のコンテナが存在することは可能ですが、複数のコンテナが同じポートを共有することはできません。したがって、リクエストは特定のポート番号に応じて対応するコンテナに送信されます。

上記は、クラスター外の一般的な HTTP リクエストが Pod 内のコンテナに到達するまでのプロセス全体です。

柔軟で変更可能なネットワーク構成のため、上記のリクエストフロープロセスが唯一の方法ではないことに注意してください。たとえば、次のようになります。

クラウドサービスを使用している場合は、LoadBalancer タイプのサービスを使用して、クラウドサービスプロバイダーが提供するロードバランサーを直接バインドし、Ingress やその他のサービスに接続できます。

また、NodePort タイプのサービスを通じてノード上のポートを直接使用し、これらのノードを通じて独自のロードバランサーを構築することもできます。

サービスが非常にシンプルで、管理する内部トラフィックがない場合は、Ingress なしでもかまいません。

コンテナ技術の基礎

コンテナテクノロジーの基盤は、次の 3 つから構成されます。

名前空間（ここでは Linux システムカーネルの名前空間を指します）
Cグループ
ユニオンFS

リソースの分離を実装するのは Linux カーネルの名前空間です。各ポッドには独自の Linux 名前空間があるため、異なるポッドはリソースが分離されます。 PID、IPC、ネットワーク、マウント、時間など、多くの名前空間があります。 PID 名前空間はプロセス分離を実装するため、ポッドは独自のプロセス番号 1 を持つことができます。ネットワーク名前空間により、各ポッドは独自のネットワークを持つことができます。

ポッドには独自のネットワークがあり、ノードにも独自のネットワークがありますが、トラフィックはどのようにしてノードからポッドに流れるのでしょうか?

HTTP リクエストフロー処理補足

各ノードには次のものがあります:

（１）Kubelet：ノードのハウスキーパー。

（2）kube-proxy：ノードのiptables/ipvsを操作します。

（３）プラグイン：

CRI: コンテナランタイムインターフェース
CNI: コンテナネットワークインターフェイス
CSI (オプション): コンテナストレージインターフェイス

各ノードには独自のルート名前空間があり、これにはネットワーク関連のルート netns も含まれます。各ポッドには独自のポッドネットがあります。ノードは veth ペアを介してポッドに接続でき、トラフィックはこのチャネルを介して流れます。 veth ペアの構築、ポッドネットワーク名前空間の設定、ポッドへの IP アドレスの割り当てなどは、まさに CNI のタスクです。

これまでのところ、これは Kubernetes クラスター外部の一般的な HTTP/HTTPS リクエストが Pod 内のコンテナに到達するプロセス全体です。

参考文献: