Oracle Cloud Hangout Cafe Season 4 #2「Kubernetesのネットワーク」(2021年5月12日開催)

Kubernetesのネットワークの仕組み

ここからは、Kubernetesのネットワークについて見ていきます。

はじめに、結論としてKubernetesが求めるネットワークモデルを下図に示します。ネットワークモデルについては「Kubernetes公式ドキュメント: Cluster Networking」で定義されています。

kubernetes-network-model

図に記載している番号に沿って説明します。

①Pod内通信^*1：
すべてのPodは自分自身のIPアドレスを持ち、Podの中のコンテナはIPを共有していてlocalhost経由で相互に通信できる
②kubelet-Pod間通信：
systemdやkubeletなどノード上にあるエージェントが、そのノード上のすべてのPodと通信できる
③Pod間通信(Node跨ぎも含む)：
ノード上のPodがNATなしですべてのノード上(クラスタ内)のすべてのPodと通信できる

これらのうち、①はネットワーク名前空間(Network Namespace)、②③はCNIプラグインで実現されます。

それぞれ詳しく見ていきます。

Pod内通信

Pod間通信は、Linuxカーネルの機能であるネットワーク名前空間(Network Namespace)で実現されます。それぞれのネットワーク名前空間(Network Namespace)がPodに対応し、IPアドレスが付与されます。つまり、IP:ネットワーク名前空間(Pod)=1:1の関係が成り立ちます。これをIP-per-Podモデルと呼びます。

Pod内のコンテナは同一ネットワーク名前空間(Network Namespace)上で実行され、お互いはlocalhostでアクセスできます。

internal-pod

kubelet-Pod間通信

kubelet-Pod間通信は、CNI(Container Network Interface、以下CNI)によって実現されます。CNIはコンテナネットワークを構築するプラグインを作成するための仕様(ライブラリ)になっており「GitHub:CNI - the Container Network Interface」で公開されています。

CNIはCoreOS社(現Red Hat社)によって提唱され、現在はCNCFが管理しています。CNIが主に実行することは、以下の通りです。

• コンテナをネットワークへ追加/削除
• コンテナが動作しているかの確認
• バージョン情報の返却

このCNIを実装したものがCNIプラグインです。CNIプラグインは、コンテナに適切なネットワークの設定を適用したり、割り当てるIPアドレスを返却します。CNIプラグインによりKubernetesクラスタを任意のネットワーク上に構築でき、複数のプラグインを組み合わせることで網羅的に機能を提供できます。

例えば、NetworkPolicy(後述)は単体のCNIプラグインではNetworkPolicyがサポートされていなくても、NetworkPolicyをサポートするCNIプラグインと併用することで利用できます。

kubelet-pod

Pod間通信(Node跨ぎも含む)

Pod間通信(Node跨ぎも含む)はCluster Networkingと呼ばれ、先ほどの「Dockerのネットワークにおける課題」で紹介した課題を解消できる手法で設計されています。Cluster NetworkingはNodeのネットワーク上に構成される論理的なネットワークです。

Cluster NetworkingもCNIプラグインによって実現され、NAT(Dockerネットワークでの課題)を利用しないネットワークモデルで構築されています。具体的にはLinux Bridge/VXLAN/BGPなど、様々なレイヤー/ソリューションを利用して実現されます。何を利用するかは採用するCNIプラグインによって決定しますが、採用するCNIプラグインによってはオーバヘッドが高い場合もあるので、注意が必要です。

between-pods

CNIプラグインの動き

ここで、CNIプラグインの動きを見ておきます。CNIプラグインの動きを説明するにあたっては、kubeletとCNIプラグインが登場します。

kubeletはクラスタの各Worker Nodeに常駐するエージェントで、設定ファイルの内容(詳細は後述)に基づいてCNIプラグインを実行します。CNIプラグインはPodがCluster Networkingに参加するために必要な処理を実行する役割を持ち、kubeletがコンテナ起動時にバイナリを実行します。

cni

設定ファイルについて説明します。ここではOracle Cloud Infrastructure(OCI)が提供するマネージドのKubernetesサービスであるOracle Container Engine for Kubernetes(OKE)を例に挙げます。OKEではCNIプラグインとしてflannelを利用でき、下図のような設定ファイルになっています。

cni-setting

flannelはデフォルトで内部的に下位CNIプラグインとなるbridge CNIプラグインを利用しており、delegateフィールドにbridge CNIプラグインに引き渡すパタメータが設定されています。簡単に動きを説明すると、以下になります。

• bridge CNIプラグインがPodのNICの払い出し
• Linux Bridgeへのアタッチ
• IPAM(IP Address Management)CNIプラグインの呼び出し
  • IPAM CNIプラグインがPodへのIPアドレスを払い出し

bridge CNIプラグインの詳細は「GitHub:Plugins」、前述したCNIプラグインのさらなる詳細は「整理しながら理解するKubernetesネットワークの仕組み」を参照ください。

ここまでの内容を整理すると、Kubernetesのネットワークモデルはネットワーク名前空間(Network Namespace)とCNIプラグインによって実現されていることが分かりました。

①Pod内通信 -> ネットワーク名前空間(Network Namespace)
②kubelet-Pod間通信 -> CNIプラグイン
③Pod間通信(Node跨ぎも含む) -> CNIプラグイン

Node NetworkとService Network

ここで、Kubernetesのネットワークにおける構成要素であるNode NetworkとService Networkについて補足します。

・Node Network
Node Networkは、Kubernetesクラスタを構成するWorker Nodeが接続するネットワークです。これはKubernetesクラスタを構築する環境によって実現形態が異なり、基本的にはベアメタルやVM/クラウドプロバイダーが提供する仮想ネットワークになります。

具体的には、以下が挙げられます。

• Amazon VPC
• Azure Virtual Network
• Google Cloud VPC
• Oracle Cloud Infrastructure VCN
• 各種SDNサービス

node-network

・Service Network
Service Networkは、Podの論理的なセットを管理する抽象的なネットワークです。複数のPodをまとめて単一のエンドポイントで管理(Node/Podを抽象化)し、Podの論理的なセットに対するサービスディスカバリや負荷分散などを提供します。このような機能が必要になるのは、KubernetesではPodが複数のNodeに散らばり、IPアドレスも一定ではないためです。Service Networkにより、Service NetworkのバックエンドとなるPodが変更されても、呼び出し元が意識する必要はありません。

service-network