ネットワークトポロジー

AKS は Kubernetes のマネージドサービスです。前回にも紹介したように、AKS のクラスタのうち、API サーバ、スケジューラ、etcd などが含まれるコントロールプレーン部分は Azure による管理が行われる一方、 Pod が稼働する Node のリソース部分はユーザーの管理対象リソースとして扱われます。

Azure が管理するコントロールプレーンの保護に関しては、Kubernetes API のアクセス制限のためのオプションが AKS によって提供されていることを前回も紹介しました。

一方、Pod が稼働する Node に対する入力経路のアクセスについては、Node 自体はユーザーが管理可能なリソースとして仮想ネットワーク内に展開されることから、前述した Azure ネットワークの機能を活用してユーザー自身で適切に保護をすることになります。

Node のネットワークトポロジーとして、基本的には各仮想マシンへ直接アクセスを許可しておらず、上図に示すように、前段に配置される Azure Load Balancer を経由してユーザーリクエストを受信するしくみとなっています。

また、Pod や Node から外部に向けてアクセスする際の出力経路についても、デフォルトでは Azure Load Balancer にて設定される送信規則により許可され、このロードバランサ経由で外部アクセスを行います。

クラスタ内部ネットワーク

Kubernetes には、クラスタを構成するノードおよびコンテナのネットワーク接続性をユーザーに透過的に提供する目的から、いくつかのコンテナネットワークの実装が提供されています。

これらのコンテナネットワークのインタフェースが標準化されたものを CNI(Container Network Interface) と呼びます。Node にある Kubelet はこの標準インタフェースの API を使用して、ネットワークプラグインを呼び出し、ネットワーク環境を構成します。

CNI プラグインはこの標準APIインタフェースを実装したもので、このプラグインの選択によって k8s クラスタ内部ネットワークの構成が決まります。

現在 AKS を使う際には、以下2種類のプラグイン（ネットワークモデル）を選択できます。

kubenet

Kubernetes標準のシンプルなネットワークモデルです。Pod にはノードとは異なる IP アドレスレンジを持つ仮想 IP が割り当てられます。

同一ノード内の Pod 間は直接通信できますが、ノードをまたいだ Pod の接続には、AKS にて管理されるユーザー定義ルーティング (UDR) と IP 転送が使用されます。また、Podから外への通信には NAT 変換（ホストするノードのIPアドレスに変換）が行われます。

kubenet では各 Pod に対して VNet 内の IP アドレスを消費しない仕組みになっているため、IPアドレス空間を節約できるメリットがありますが、仮想ノードや Windows ノードプールなど一部サポートされていない機能もあります。

Azure CNI

Azure ネットワークと連携された高度なネットワークモデルです。すべての Pod に VNet からの IP アドレスが割り当てられ、接続されているネットワークから各Podへはルーティング等を利用せずに直接アクセスできます。

これらの IP アドレスは、仮想ネットワーク全体で一意となるため、ネットワーク設計時には展開する Pod の数を考慮して IP アドレスの範囲を計画する必要があります。

2種類のネットワークモデルにはそれぞれメリット、デメリットがあり、構成上の柔軟性や制約、ニーズを加味してどちらを使うかを判断します。

kubenet を使用する主な理由としては、「利用できる IP アドレス空間が限定されている」「必要な通信がおおむねクラスタに閉じている」などが挙げられます。

一方、Azure CNI を使用する動機となりうるものとして、仮想ノード等 Azure CNI のみでサポートされる機能の利用や外部接続に NAT 変換が不要である点、などが考えられます。