コンテナネットワークの基礎知識【第8回】

Kubernetesクラスタの“Pod間通信”の基本　「3つのService」はなぜ必要か？

Kubernetesクラスタの動作にはPod間で通信するための仕組みが必要です。「ClusterIP」「NodePort」「LoadBalancer」の3つの「Service」の仕組みをそれぞれ紹介します。

公開 2021年10月01日 05時00分

著者

奈良昌紀

細谷典弘

千葉豪

[ネットワンシステムズ]

印刷する連載新着通知を受け取る Googleで優先するソースとして追加

　コンテナオーケストレーター「Kubernetes」では複数のコンテナ実行ホストがクラスタ（以下、Kubernetesクラスタ）を構成します。これはコンテナ管理ツール「Docker」の一般的な環境において、コンテナ間通信がコンテナ実行ホスト内で完結することとは異なります。そのためKubernetesの場合、Kubernetesクラスタ内のホストを跨（また）がる「Pod」（Kubernetesクラスタにおけるアプリケーションの実行単位）間で通信する仕組みが必要になります。Kubernetesクラスタの外部からPodに接続するための仕組みも必要です。

併せて読みたいお薦め記事

コンテナの基礎知識

ネットワーク仮想化の話題

Pod間ネットワークを実現するCNI

　KubernetesクラスタでPodが起動すると、Kubernetesは各Podに固有のIPアドレスを付与します。各Podが相互に通信するための仕組みとしてCNI（Container Network Interface）プラグインがあります。CNIプラグインは、コンテナ間の通信を定義するCNI（コンテナネットワークインタフェース）を実装したものです。代表的なものとして「Calico」や「Flannel」の他、SDN（ソフトウェア定義ネットワーク）製品を利用するためのCNIプラグインなどがあります。

Calico
- 経路制御プロトコル「BGP」（Border Gateway Protocol）を用いたL3（レイヤー3）のルーティングを構築する、OSS（オープンソースソフトウェア）のCNIプラグイン
Flannel
- 仮想ネットワーク用のプロトコル「VXLAN」（Virtual eXtensible Local Area Network）を用いたL2（レイヤー2）のオーバレイネットワークを構築する、OSSのCNIプラグイン
Cisco ACI CNI Plug-in
- Cisco SystemsのSDN製品「Cisco ACI」のCNIプラグイン
NSX Container Plug-in（NCP）
- VMwareのSDN製品「VMware NSX-T Data Center」のCNIプラグイン
OpenShift SDN
- Red Hatのコンテナ管理製品群「Red Hat OpenShift」のCNIプラグイン

　Kubernetesのセキュリティ機能「Network Policy」のサポート状況がCNIプラグインによって異なります。例えばCalicoでは、Network PolicyによりPod間通信を細かく制御することができますが、FlannelではNetwork Policyを利用できません。このような違いがあるため、要件に合ったCNIプラグインを選択してKubernetesのコンテナネットワークを構成することになります。

ServiceによるPodの公開

　Podグループ（複数のPod）にアクセスするための「Service」というリソースを利用することで、Podグループに対するアクセスを効率良く管理することが可能です。Serviceには幾つかのタイプが存在します。本稿では「ClusterIP」「NodePort」「LoadBalancer」の3つを取り上げます。

Kubernetesクラスタ内ロードバランサーを提供するClusterIP

　Kubernetesクラスタ内だけで使えるServiceがClusterIPです。これを構成することで、単一のPodからPodグループ宛ての通信をロードバランシング（負荷分散）することが可能になります。ClusterIPのIPアドレスは、Podグループに対して、ロードバランサーのVIP（Virtual IP）のような働きをするIPアドレスになります。VIPとは、各アクセス対象が持つIPアドレスとは別の仮想的なIPアドレスであり、ClusterIPにおいては、このVIPにアクセスするとVIPの背後にあるPodにアクセスすることが可能になります。

図1　PodネットワークとClusterIP《クリックで拡大》

　ClusterIPはKubernetesクラスタ内でのみ利用する負荷分散機能です。Kubernetesクラスタ外部からの接続にはNodePortとLoadBalancerというタイプのService（後述）を利用することが可能です。

ノードIPアドレスを利用してPodを公開するNodePort

　NodePortはKubernetesクラスタを構成する「ノード」のIPアドレスにPodグループを公開するためのポート番号を割り当てて、クラスタの外部からアクセスを可能にするServiceです。NodePortはPodグループ向けのServiceにポート番号を割り当てます。Podグループに対しては、ノードのIPアドレスと割り当てられたポート番号を組み合わせてアクセスします。ポート番号の範囲はデフォルトでは30000～32767となり、アクセスしたいPodグループごとに異なるポート番号が割り当てられます。

　PodグループをKubernetesクラスタ内で起動する場合、各Podはクラスタ内のいずれかのノードで起動します。Kubernetesクラスタ外からこれらのPodにアクセスする際の宛先ノードのIPアドレスは、Podを実行しているノードのIPアドレスである必要はありません。もしアクセス先のノードにアクセスしたいPodグループのPodが存在しなくても、NodePortはそのPodが存在しているノードに転送します。Podグループの各Podが複数のノードに存在している場合でも、PodごとにノードのIPアドレスを変える必要はなく、1つのノードのIPアドレスで、Podグループの各Podにアクセスすることが可能です。設定により、指定したノードのIPアドレスのPodだけに負荷分散を許可することも可能です。

　NodePortの次の問題には注意が必要です。

アクセス先として指定したノードがダウンしていた場合、Podグループにアクセスできなくなる
通常KubernetesクラスタのノードのIPアドレスは外部に公開しないが、ノードIPアドレスを外部に公開する必要があることから、利用が難しい場合もある

　これらの問題を解決するためには、これから紹介するServiceのLoadBalancerや、「Ingress」というリソースを使う必要があります。

図2　NodePortの仕組み《クリックで拡大》

外部のロードバランサーと連携してPodを外部向けに公開するLoadBalancer

　ServiceのタイプとしてLoadBalancerを指定することで、Kubernetesクラスタ外部に公開するIPアドレスをパブリックなものにすることが可能になります。NodePortの場合はPodグループに対してアクセスする際にポート番号を使用しますが、LoadBalancerの場合はポート番号を意識する必要がありません。

　LoadBalancerを使用する場合、Kubernetesクラスタ内でNodePortを利用する構成が一般的です。Kubernetesクラスタ外部のロードバランサーは、図3のようにNodePortに負荷分散します。

　実際にオンプレミスインフラでKubernetesクラスタ外部のロードバランサーを構築する場合はハードウェア型のロードバランサーや、「MetalLB」といったソフトウェア型のロードバランサーが用いられます。MetalLBはGoogleが開発したオンプレミスでも使えるソフトウェア型のロードバランサーです。BGPモードとL2モードがあり、モードごとに動作が変わります。BGPモードではKubernetesクラスタ外部のルーターとBGPにより連携して、各ノードに負荷分散してパケットを転送します。L2モードはシンプルにノード間で代表を決定し、代表ノードがリクエストを処理する動作になります。

図3　LoadBalancerの仕組み《クリックで拡大》

レイヤー7の負荷分散によりPodへのアクセスを提供するIngress

　IngressはServiceと同じように、Kubernetesのリソースの一つです。ここまで紹介してきたServiceはL4（レイヤー4）のロードバランシングを提供しますが、IngressはHTTP/HTTPS通信に対するL7（レイヤー7）のロードバランシングを提供します。オンプレミスインフラでは「NGINX Ingress Controller」を用いて構築する方法があります。NGINX Ingress ControllerはWebサーバやプロキシサーバとして開発されているオープンソースのNGINXを、Kubernetesクラスタと連携して利用するためのソフトウェアです。

　同じFQDN（完全修飾ドメイン名：ドメイン名やホスト名を省略しない名称）に対するアクセスであっても、Ingressは「http://AAA.co.jp/red」と「http://AAA.co.jp/blue」のようにパスごとに異なるPodグループにアクセスさせることが可能です。図4のように「/red」用の「Service red」と「/blue」用の「Service blue」を定義することで、アクセス先のパスに応じて異なるServiceに負荷分散することが可能です。

図4　IngressとService《クリックで拡大》

　パブリッククラウドのKubernetesサービスでは、IngressやLoadBalancerとしてクラウドサービスのロードバランサーサービスを利用することができます。そうした仕組みをオンプレミスで構築するのは簡単ではありません。ただし第7回で紹介したオンプレミスインフラ向けKubernetes製品や、次回紹介するSDN製品のCNIを使うことで、オンプレミスインフラにおいてもパブリッククラウドのようにKubernetesのネットワークを構築することが可能になります。

　次回は、Cisco ACIとVMware NSX-Tを使ったKubernetesのネットワークを紹介します。Cisco ACIとVMware NSX-Tを使って、仮想マシンとコンテナを接続する方法も説明します。

執筆者紹介

奈良昌紀（なら・まさのり）　ネットワンシステムズ　ビジネス開発本部第1応用技術部

通信事業者のデータセンターにおいてネットワークやサーバの運用を経験後、ネットワンシステムズに入社。帯域制御やWAN高速化製品、仮想化関連製品を担当後、主にクラウドや仮想インフラの管理、自動化、ネットワーク仮想化の分野に注力している。

細谷典弘（ほそや・のりひろ）　ネットワンシステムズ　ビジネス開発本部第3応用技術部

データセンターネットワークの他、マルチクラウド向けのハードウェアやソフトウェアの最先端技術に関する調査・検証、技術支援などを担当。注目分野は「Kubernetes」。放送システムのIP化に向けた技術調査・検証も担当している。

千葉豪（ちば・ごう）　ネットワンシステムズ　ビジネス開発本部第1応用技術部

IaaS（Infrastructure as a Service）をはじめとしたクラウド基盤技術および管理製品を担当。コンテナ技術を中心とした開発・解析基盤の構築から運用、コンテナに関連した自動化技術や監視製品の技術検証などに注力している。

印刷する

コンテナネットワークの基礎知識

連載新着通知を受け取る

この連載の記事をもっと見る

この記事の著者

奈良昌紀

細谷典弘

千葉豪

Kubernetesクラスタの“Pod間通信”の基本　「3つのService」はなぜ必要か？