いずれのKubernetesサービスもコントロールプレーンはリージョン（データセンターが位置する地域）内の複数のアベイラビリティゾーン（または可用性ゾーン、ゾーン）で冗長化しており、ノードも複数のアベイラビリティゾーンに分散して配置することで可用性を高めることが可能です。AWSとGCPの場合はVPC（Virtual Private Cloud）、Azureの場合はVNet（Virtual Network）といった仮想ネットワーク機能と、Kubernetesサービスを連携させることができます。仮想ネットワーク内に存在する仮想マシンが直接Podと通信する仕組みにより、パケットをカプセル化（プロトコル用のヘッダ情報の付与）することなくインスタンスやデータベースなどの仮想ネットワーク内の機能を利用でき、通信が効率的になります。

Amazon EKSのCNI

　AWSのKubernetesサービス「Amazon Elastic Kubernetes Service」（Amazon EKS）は、VPCのKubernetes向けのネットワークインタフェースとなる「Amazon VPC CNI」をデフォルトで提供しています。Amazon EKSはノードに複数の「ENI」（Elastic Network Interface、VPCのネットワークインタフェース）を構成し、VPC内に作成するサブネット（ネットワークを小分けにした単位）からPodのIPアドレスを割り当てます。PodのIPアドレスはENIに対するセカンダリIPアドレス（同一ネットワークインタフェースに対する別のIPアドレス）となり、VPC内でPodのIPアドレスとして機能してパケットの転送を可能にします。Amazon EKSはCalicoをポリシーエンジンとして有効化することにより、Network Policy（Pod間通信を制御するKubernetesの機能）を利用することも可能です。

AKSのCNI

　AzureのKubernetesサービス「Azure Kubernetes Service」（AKS）は、Kubernetesクラスタ作成時にネットワークとして「kubenet」と「Azure CNI」のいずれかを選択することが可能です。Azure CNIはVNet内のサブネットアドレス（サブネットのIPアドレスの範囲）からPod向けのIPアドレスを割り当て、VNet内でパケットをカプセル化することなく転送することが可能です。Amazon EKSと同じように、各ノードにPodのIPアドレスをセカンダリIPアドレスとして割り当て、VNetによるルーティングを可能にします。AKSでNetwork Policyを利用する場合は、CalicoとAzure CNIのうちどちらかを選択することができます。

GKEのCNI

　GCPのKubernetesサービス「Google Kubernetes Engine」（GKE）も、Kubernetesクラスタ構成時のネットワークとしてVPCの機能を利用することが可能です。GKEで「VPCネイティブクラスタ」を作成すると、VPC内のサブネットをPodのネットワークとして利用することが可能になります。PodのIPアドレスはノードのエイリアスIPアドレス（1つのネットワークインタフェースに割り当てる複数のIPアドレス）となり、Pod間通信をVPCによってルーティングすることが可能になります（図1）。

図1　GKEにおけるVPCのKubernetesネットワーク（「eth0」はネットワークインタフェース。「veth」は仮想ネットワークインタフェース。「cbr0」はブリッジのインタフェース）《クリックで拡大》

　VPCネイティブクラスタは、コンテナ単位で負荷分散するロードバランサー機能を利用することができます。第8回「Kubernetesクラスタの“Pod間通信”の基本　『3つのService』はなぜ必要か？」で紹介した「Ingress」というリソースは通常、着信したパケットを各ノードに負荷分散し、ノード内でさらにPodに対して負荷分散します。一方、コンテナ単位で負荷分散するロードバランサーを利用してIngressを構成すると、Ingressに着信したパケットを負荷分散対象のPodに直接負荷分散することが可能になり、効率良く通信を処理できます。

　次回はオンプレミスインフラ向けのSDN（ソフトウェア定義ネットワーク）製品によるCNIプラグインを紹介します。