Kubernetes ネットワーキングとは？概要と仕組みを解説
SHARE:
Content
Kubernetes クラスター内には、クラスター内のすべてのコンポーネントが相互に通信できるようにする Kubernetes ネットワーキングがあります。
ネットワーキングは、世界中の多くのエンジニアが使用しているツールであり、Kubernetes ネットワーキングモデルを理解すれば、Kubernetes で実行されるアプリケーションを最適な方法で実行、監視、トラブルシューティングできます。
この記事では、ネットワーキングの概要や仕組みなど、基本をわかりやすく解説します。
関 連 記 事
| Kubernetesとは？ | Kubernetesセキュリティ の基礎 | Kubernetesアーキテクチャの 設計方法 |
| AWSのEKS （Elastic Kubernetes Service） | Kubernetesの クラスターとは？ | Kubernetes のノードとは？ |
| KubernetesのPodとは？ | KubernetesのHelmとは？ | クラウドセキュリティと ランタイムインサイト |
Kubernetes ネットワーキングとは？
Kubernetesネットワーキングとは、Kubernetesクラスター内のコンポーネントが相互に通信できるようにすることをいいます。
そもそもKubernetesは、マシンのクラスター上で分散システムを実行するために開発されました。分散システムにより、ネットワーキングは実装に必要な中心的なコンポーネントになります。よって、このモデルを理解すれば、Kubernetesで実行されるアプリケーションを最適な方法で実行、監視、トラブルシューティングしやすくなるはずです。
Kubernetesネットワーキングの仕組み
Kubernetes がどのように機能するかを理解するには、ネットワーキングの理解が不可欠です。ネットワーキングは、さまざまな方法でクラスター内で常に実行されています。以下は、Kubernetes クラスター内の 4 つの主な通信モードです:
- Pod 間
- Pod – サービス間
- インターネット – サービス間
- コンテナ間
静的ポート割り当て
Kubernetes では、アプリケーション間でマシンを共有することで、コンピューティングリソースを最適化しますが、2 つのアプリケーションが同じネットワーキングポートを使用していないことが必要です。2 つのポートが交差しないように、ポートを手動で設定しても、この問題は解決できません。もぐらたたきゲームのように一日中設定し直すことになり、クラスターを完全に稼働させることはできません。別の方法として、動的ポート割り当てを使用することもできますが、この方法には特有の複雑さが伴います。
動的ポート割り当て
動的ポート割り当てにより、すべてのアプリケーションがポートをフラグとして使用できるようになりますが、動的ポート番号を構成ブロックに挿入する方法をAPI サーバーが認識する必要があります。Kubernetes では、異なるネットワーキングのアプローチを採用しているため、相互通信にどのポートを探す必要があるかをサービスが認識する必要はありません。
Kubernetes で使われるネットワーキングモデル
Kubernetes では、すべての Pod に独自の IP アドレスが割り当てられるネットワーキングモデルを使用します。単一の Pod 内のすべてのコンテナは、同じネットワークネームスペースと IP アドレスを共有します。Pod と IP アドレスは一時的なものであることに注意してください。Pod が停止するか、何らかの理由で再起動する必要がある場合、新しい IP アドレスが割り当てられますが、これを管理する必要はなく、Pod 間の通信を作成したり、コンテナポートをホストポートにマップしたりする必要はありません。
このネットワーキングモデルでは、ポートの割り当て、命名、負荷分散、移行に関して、Pod を仮想マシン（VM）のように扱うことができます。Kubernetes では、ネットワーキング実装の要件を次のように規定しています:
- すべての Pod は、ネットワークアドレス変換（NAT）を使用せずに他のすべての Pod と通信できます。
- すべてのノードは、NAT なしですべての Pod と通信できます。
Kubernetes ではNATが使用されるか？
Kubernetes では、ネットワークアドレス変換（NAT）を使用しません。クラスター内のすべての Pod は他の Pod と通信できます。
また、すべてのノードは NAT を使用せずにクラスター内のすべての Pod と通信できます。
Kubernetesネットワーキングモデルのコンポーネント
Kubernetes クラスター内のさまざまなネットワーキングコンポーネントについて詳しく見ていきましょう。
Pod 間ネットワーキング
Kubernetes では、各 Pod にそれぞれ独自の IP アドレスが割り当てられ、独自のネットワークネームスペースがあります。Pod は、IP アドレス経由で相互に通信できます。このモデルは VM に非常に似ており、各 Pod はネットワークポートを公開し、IP アドレスとポート番号によってネットワーク上の他の VM をアドレス指定できます。
Pod 間ネットワーキング – 同じノードの Pod
Pod が稼働するために実行されているノードを考慮せずに、Pod 間の通信を完全に理解することはできません。この通信は、Pod が実行されているノードで仮想イーサネットデバイス経由で実行されます。Pod が別のノードの IP アドレスにリクエストを送信すると、ノードの仮想イーサネットデバイスをトンネリングします。この接続には両面があります。Pod 側の名前は eth0、仮想コンポーネントであるノード側の名前は vethx（仮想イーサネット）で、その後にインデックス 0 から始まる数値が続きます。
この接続は、ネットワークブリッジを使用して 2 つのネットワークを接続することで可能になります。Pod からのリクエストがブリッジに到達すると、ブリッジでは、同じノード経由でアクセスできるすべての Pod に、リクエストを処理するための正しい IP アドレスがあるかどうかを判断し、存在する場合は、同じノードを使用している 2 つの Pod 間でネットワーク接続が確立されます。
Pod 間ネットワーキング – 異なるノードの Pod
他の種類の Pod 間通信では、Pod は異なるノードにあります。このタイプの通信にネットワークブリッジ方式を使用しようとすると、失敗します。ただし、これは、クラスターに使用しているクラウドプロバイダとネットワークプラグインによって異なる場合があることに注意してください。
異なるノード上の Pod 間の通信操作は、クラスターレベルで実行する必要があります。各クラスターには、IP アドレス範囲をノードにマップするテーブルがあります。これらのノードの Pod には、それらの範囲から割り当てられる IP アドレスがあります。次の図に示すように、Kubernetes はノード 1 とノード 2 の Pod にアドレスを割り当てます:
各ノードには、クラスターの他のノードと通信するためのそれぞれ独自の方法があります。この点からも、Pod 間の通信は、同じノードの Pod が相互に通信する方法と似ています。
Pod – サービス間ネットワーキング
Pod は一時的なものであるため、Pod の IP アドレスは変化する可能性があります。別の Pod と直接通信するように Pod を構成することもできますが、バックエンドの IP アドレスを追跡する必要があり、Pod が再起動されるたびに IP アドレスが変化する場合は、注意が必要です。この問題を解決するには、Service と呼ばれる Kubernetes リソースを使用して 2 つの Pod をリンクします。
Kubernetes Service を使用すると、clusterIP と呼ばれる単一の一意の IP アドレスを Pod のグループに割り当てることができます。単一の clusterIP エンドポイントにリクエストを実行できます。サービスは Service に属する Pod にリクエストをプロキシします。
この通信は、Kubernetes がすべてのノード内で実行する小さなプロセスである kube-proxy 経由で実行されます。このプロセスは、Service の仮想 IP アドレスを Pod IP アドレスのグループにマップします。kube-proxy プロセスが Service の仮想 IP を Pod の IP にマップすると、リクエストプロセスは上記のように実行されます。
インターネット – サービス間ネットワーキング
外部とやり取りできるアプリケーションを実行できる Kubernetes クラスターを管理するには、インターネット接続が不可欠です。1）Kubernetes Service からインターネット、2）インターネットから Kubernetes Service のトラフィックを取得できるようにする必要があります。
クラウドプロバイダでは、このタイプの通信を開始するために必要な NAT ゲートウェイを提供しています。NAT ゲートウェイでは、公開 IP アドレスを持たないクラウドリソースが着信インターネット接続に公開されることなく、インターネットにアクセスできます。
例として、AWS クラウド プロバイダを使用してみましょう。AWS では、Kubernetes クラスターは VPC 内で実行されます。すべてのノードには、Kubernetes クラスター内からアクセスできるプライベート IP アドレスが割り当てられます。クラスターの外部からトラフィックにアクセスできるようにするには、インターネットゲートウェイを VPC にアタッチする必要があります。
外部アクセスの設定はイングレスとエグレスの両方でサポートされます。
- エグレスでは、トラフィックをノードから外部接続にルーティングします。
- イングレスでは、外部クライアントが Kubernetes Services と通信できるようにします。
エグレスがノードから外部アプリケーションにトラフィックを正常にルーティングするには、インターネットゲートウェイが不可欠です。ゲートウェイは、パブリッククラウド内でホストされる安全で分離されたプライベートクラウドコンピューティング環境である仮想プライベートクラウド（VPC）にアタッチされます。
イングレスは、事前定義された一連のルールに基づいて、一部の接続を許可し、他の接続が Kubernetes Services と通信できないようにブロックできます。ルールは、クラスターと Services へのアクセスを許可または拒否する IP テーブルとして確立されます。
コンテナ間ネットワーキング
コンテナは、同じ Pod を共有し、同じ IP アドレスを共有するため、別のコンテナと通信できます。コンテナは、localhost をアドレス指定することで相互に通信します。コンテナが同じ Pod 内の別のコンテナと通信する必要がある場合は、アドレス localhost:8080 を使用してポート 8080 で通信できます。
Kubernetes では、ネットワークアドレス変換（NAT）を使用しません。クラスター内のすべての Pod は他の Pod と通信できます。また、すべてのノードは NAT を使用せずにクラスター内のすべての Pod と通信できます。
Calico ネットワーキングとは
Kubernetes ネットワーキングを考えるなら、Calicoについても押さえておきましょう。
Calico は、2016 年に開発されたオープンソースのネットワーキングとネットワークセキュリティツールです。その人気の高まりにより、Kubernetes ネットワーキングスペースのリーダーになっています。
Calico は、マシン上のワークロード間のネットワーク接続を提供し、ワークロード間にネットワークセキュリティポリシーを適用します。Calico には、プラグインを使用して幅広いデプロイオプションをサポートする柔軟なアーキテクチャがあります。
Calico CNI（Container Network Interface）
Calico は、独自の Container Network Interface（CNI）プラグイン、クラウドプロバイダ統合、多数のサードパーティ CNI プラグインで利用できます。Calico CNI は、仮想イーサネットデバイスペア（veth ペア）を使用して、Pod をホストネットワークネームスペースの L3 ルーティングに接続します。OSI モデルの L2 レイヤーから操作している場合、ネットワークブリッジにさらなるオーバーヘッドが発生しますが、L3 アーキテクチャを使用すると、これらを回避できます。
詳細については、こちらの GitHub リポジトリを参照してください。
まとめ
Kubernetesのネットワーキングは複雑です。最初は理解が難しいかもしれませんが、状況ごとにコンポーネント単位で切り分けて考えることで、理解しやすくなるでしょう。
Kubernetes クラスター内部のさまざまなネットワーキングを把握できれば、環境の課題解決の糸口もつかめるはずです。