Kubernetes ネットワークのビジュアルガイド

Kubernetes 内のネットワークは、物理的な世界のネットワークとそれほど変わりません。ネットワークの基本的な知識があれば、コンテナポッドとサービス間の通信を簡単に実現できます。

スイッチ、ルーター、イーサネットケーブルを使用する物理ネットワークから、ソフトウェア定義ネットワーク (SDN) と仮想インターフェイスを使用する仮想ネットワークに移行するには、多少の学習が必要です。もちろん、原則は同じですが、規範やベストプラクティスは異なります。 Kubernetes には独自のルールセットがあり、コンテナやクラウドを扱う場合は、Kubernetes ネットワークの仕組みを理解しておくと役立ちます。

Kubernetes ネットワークモデルには、覚えておくべき一般的なルールがいくつかあります。

各ポッドには独自の IP アドレスがあります。ポッド間にリンクを作成する必要はなく、コンテナポートをホストポートにマップする必要もありません。
NAT は不要: ノード上の Pod は、NAT なしですべてのノード上のすべての Pod と通信できる必要があります。
エージェントはすべてのアクセス権を取得します。ノード上のエージェント (システムデーモン、Kubelet) は、そのノード内のすべての Pod と通信できます。
共有名前空間: Pod 内のコンテナはネットワーク名前空間 (IP アドレスと MAC アドレス) を共有するため、ループバックアドレスを使用して相互に通信できます。

Kubernetes ネットワークはどのような問題を解決しますか?

Kubernetes ネットワークは、Kubernetes 内のさまざまなエンティティタイプが通信できるように設計されています。 Kubernetes インフラストラクチャのレイアウトは、設計上、多くの分離が行われています。名前空間、コンテナ、およびポッドは、コンポーネントを互いに区別できるように設計されているため、高度に構造化された通信計画が重要です。

コンテナ間ネットワーク

コンテナ間のネットワークは、Pod ネットワーク名前空間を通じて行われます。ネットワーク名前空間を使用すると、システムの他の部分から分離され、独立して実行される独立したネットワークインターフェイスとルーティングテーブルを持つことができます。各ポッドには独自のネットワーク名前空間があり、コンテナは同じ IP アドレスとポートを共有します。これらのコンテナはすべて同じ名前空間の一部であるため、コンテナ間の通信はすべて localhost を介して行われます。（図では緑の線で示されています。）

ポッド間ネットワーク

Kubernetes では、各ノードにポッド用の指定された CIDR IP 範囲があります。これにより、各ポッドがクラスター内の他のポッドから認識できる一意の IP アドレスを受け取ることが保証されます。新しいポッドが作成されても、IP アドレスが重複することはありません。コンテナ間ネットワークとは異なり、Pod を同じノードにデプロイするか、クラスター内の異なるノードにデプロイするかに関係なく、Pod 間の通信は実際の IP を使用して行われます。

上の図は、ポッドが相互に通信するためには、ポッドネットワーク名前空間とルートネットワーク名前空間の間でトラフィックが流れる必要があることを示しています。これは、仮想イーサネットデバイスまたは veth ペア (図では veth0 を Pod 名前空間 1 に、veth1 を Pod 名前空間 2 に接続) を介して Pod 名前空間とルート名前空間を接続することによって実現されます。仮想ブリッジはこれらの仮想インターフェイスを接続し、アドレス解決プロトコル (ARP) を使用してそれらの間で通信が流れるようにします。

データが Pod 1 から Pod 2 に送信される場合、イベントフローは次のようになります。

Pod 1 のトラフィックは、eth0 を経由して、ルートネットワーク名前空間の仮想インターフェイス veth0 に流れます。
次に、トラフィックは veth0 を経由して veth1 に接続された仮想ブリッジに送られます。
トラフィックは仮想ブリッジを経由して veth1 に送られます。
最後に、トラフィックは veth1 を介して Pod 2 の eth0 インターフェースに到達します。

ポッドからサービスへのネットワーク

ポッドは動的です。需要に応じて規模を拡大または縮小する必要があるかもしれません。アプリケーションがクラッシュしたりノードに障害が発生した場合でも、再度作成できます。これらのイベントにより、Pod の IP アドレスが変更され、ネットワークの問題が発生する可能性があります。

Kubernetes は、次のことを実行するサービス機能を使用してこの問題を解決します。

サービスに関連付けられているバックエンドポッドに接続するには、フロントエンドに静的仮想 IP アドレスを割り当てます。
この仮想 IP 宛てのすべてのトラフィックは、バックエンドポッドのセットに負荷分散されます。
Pod の IP アドレスを追跡しておくと、Pod の IP アドレスが変更されても、クライアントはサービス自体の静的仮想 IP アドレスに直接接続するだけなので、問題は発生しません。

クラスター内で負荷を分散する方法は 2 つあります。

IPTABLES: このモードでは、kube-proxy は API サーバーの変更を監視します。新しいサービスごとに、サービスの clusterIP とポートへのトラフィックをキャプチャする iptables ルールをインストールし、トラフィックをサービスのバックエンドポッドにリダイレクトします。ポッドはランダムに選択されます。このモードは信頼性が高く、オーバーヘッドが低くなります。これは、Linux Netfilter がトラフィックを処理するときにユーザー空間とカーネル空間を切り替える必要がないためです。
IPV: IPV は Netfilter 上に構築され、トランスポート層の負荷分散を実装します。 IPVS は Netfilter フック関数を使用し、基礎となるデータ構造としてハッシュテーブルを使用し、カーネル空間で動作します。つまり、IPVS モードの kube-proxy は、iptables モードの kube-proxy よりもレイテンシが低く、スループットが高く、トラフィックのリダイレクトのパフォーマンスが優れています。

上の図は、Pod 1 から Pod 3 へのパケットフローを示しています。このフローは、サービスを経由してさまざまなノード (赤でマーク) に渡されます。仮想ブリッジ宛てのパケットは、ブリッジ上で実行されている ARP がそのサービスを理解しないため、デフォルトルート (eth0) を使用する必要があります。その後、パケットは iptables を介してフィルタリングされる必要があります。iptables は、kube-proxy によってノードに定義されたルールを使用します。したがって、図は現在のパスを示しています。

インターネットからサービスネットワークへ

これまで、クラスター内でトラフィックをルーティングする方法について説明しました。ただし、Kubernetes ネットワークには、アプリケーションを外部ネットワークに公開するという別の側面もあります。

アプリケーションを外部ネットワークに公開するには、2 つの方法があります。

出力: Kubernetes サービスからインターネットにトラフィックをルーティングする場合は、このオプションを使用します。この場合、iptables はソース NAT を実行するため、トラフィックは Pod ではなくノードから送信されたように見えます。
イングレス: これは外部からサービスへの着信トラフィックです。 Ingress は、接続ルールを使用して、サービスとの特定の通信を許可およびブロックします。通常、ネットワークスタックの異なる領域で実行される Ingress ソリューションには、サービスロードバランサと Ingress コントローラの 2 つがあります。

ディスカバリーサービス

Kubernetes は次の 2 つの方法でサービスを検出します。

環境変数: Pod が実行されるノードで実行されている kubelet サービスは、{SVCNAME}_service_HOST および {SVCNAME}_service_PORT の形式で各アクティブサービスの環境変数を設定する役割を担います。クライアントポッドが表示される前にサービスを作成する必要があります。そうしないと、これらのクライアント Pod に環境変数が設定されません。
DNS: DNS サービスは Kubernetes サービスとして実装され、1 つ以上の DNS サーバーポッドにマッピングされ、他のポッドと同様にスケジュールされます。クラスター内のポッドは DNS サービスを使用するように構成されており、DNS 検索リストにはポッド独自の名前空間とクラスターのデフォルトドメインが含まれています。 CoreDNS などのクラスター対応 DNS サーバーは、Kubernetes API で新しいサービスを監視し、各サービスの DNS レコードのセットを作成します。クラスター全体で DNS が有効になっている場合、すべてのポッドは DNS 名に基づいてサービスを自動的に解決できます。 Kubernetes DNS サーバーは、ExternalName サービスにアクセスする唯一の方法です。

公開されたサービスの ServiceTypes

Kubernetes サービスは、通常ラベルセレクターを使用して定義される一連の Pod にアクセスする方法を提供します。これは、クラスター内の他のアプリケーションにアクセスしようとするアプリケーションである場合もあれば、クラスター内で実行されているアプリケーションを外部に公開できるようにする場合もあります。クベネフィット
ServiceTypes を使用すると、必要なサービスのタイプを指定できます。

さまざまな ServiceTypes には次のものが含まれます。

ClusterIP: これはデフォルトの ServiceType です。これにより、サービスがクラスター内からのみアクセス可能になり、クラスター内のアプリケーションが相互に通信できるようになります。外部アクセス不可。
LoadBalancer: このサービスタイプは、クラウドプロバイダーのロードバランサーを使用してサービスを公開します。外部ロードバランサからのトラフィックはバックエンド Pod に送信されます。クラウドプロバイダーが負荷分散を実装する方法を決定します。
NodePort: これにより、すべてのノードで特定のポートを開いて、外部通信がサービスにアクセスできるようになります。このポートに送信されたトラフィックはすべてサービスに転送されます。
ExternalName: このタイプのサービスは、ExternalName フィールドの内容を使用して、CNAME レコードとその値を返すことで、サービスを DNS 名にマッピングします。いかなる種類のプロキシも設定されていません。