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 内のコンテナに到達するプロセス全体です。

参考文献:

• https://kubernetes.io/docs/concepts/services-networking/
• https://learnk8s.io/kubernetes-network-packets