はじめに

4回に分けてDockerとAzure Kubernetes Service（以下、AKS）の内部ネットワーク構造に注目し、深堀りしていきます。最終回では、両者を比較し共通点・相違点についてまとめます。
第3回目は、AKSのAzure CNIネットワークモデルにおける内部構造について整理していきます。
なお、検証環境は以下の通りです。

検証環境（Azure VM）

OS：Linux (ubuntu 20.04)
Size：Standard D2s v3 (2 vcpus, 8 GiB memory)

前回の記事

注意点

この記事の検証時点でのAKSのネットワークモデルは「kubenet」と「Azure CNI」の2つでしたが、それぞれ2024年6月頃に名称が変更になり技術要素も（微妙に）変わりました。それぞれ現在では「Azure CNIオーバーレイ」と「フラットネットワーク」という名前になりました。

よって「Azure CNI」ネットワークモデルはレガシなモードとなりましたが、根本的な考え方は同じですし、Dockerとの比較という意味で検証内容自体は参考になると思いますので、以下に整理していきます。

参考

Kubernetesとは

コンテナ化されたアプリケーションのデプロイメント、スケーリング、および管理を自動化するオープンソースのコンテナオーケストレーションプラットフォームです。以下、k8sと記載します。
クラウドではサーバ機器や回線など物理的な要素が抽象化されていますが、kubernetesでは負荷分散やIaaSとしてのサーバ、ルーティングテーブルなどのコンポーネントが抽象化されています（ServiceやNode、Podなど）。
AKSの裏ではAzure Load Balancer、仮想マシンスケールセット（VMSS）、OSのiptablesなどのコンポーネントが組み合わさってk8sの機能が実装されています。

詳しくは以下の以前の記事を参考にしてください。

AKSとは

AKSはフルマネージドKubernetesサービスです。AKSは、Kubernetesクラスタのデプロイ、管理、スケーリングを簡素化することを目的としています。

詳しくは以下の以前の記事を参考にしてください。

AKSにおけるネットワークモデル

AKSには2つのネットワークモデルがありました（先述の通り下記の画像は検証時点でのものです）。

Azure CNIとは

元々CNIという標準的なContainer Networkのモデルがあり、k8sはこれに対応しています。CNIはサードパーティ製のものが割りと多くあり、これはAzure版のCNIというイメージです。
NodeのサブネットとPodのサブネットが同じです（Podが直接VNetに接続されているイメージ）。
図にすると以下のようなイメージです。

ポイント

Dockerのbridgeネットワークモデルやkubenetネットワークモデルにはあった仮想ブリッジが存在しません。 詳しくは後述します
Podごとに異なるネットワーク名前空間が割り当てられます。これにより、Pod間やPod‐Node間のネットワークを隔離しています
PodのサブネットとNodeのサブネットはレンジが同じです

実際に情報を取得して上記が本当か、検証してみます。

検証

AKSをkubenetネットワークモデルで作成します。

az aks create --name azfooaks03 --resource-group AZ-foo --node-count 2 --kubernetes-version 1.26.3 --node-vm-size Standard_DS2_v2 --generate-ssh-keys --service-principal $APP_ID --client-secret $SP_PWD --network-plugin azure --vnet-subnet-id [事前に作成したsubnetのリソースID] --dns-service-ip [“service-cidr”オプションで指定する範囲内でDNSサーバのIPアドレスを指定] --service-cidr [他のVNet/subnetと重複しないCIDR]

色々と情報を取得すると以下のようになりました。

1～3のポイントについて全てその通りになっていますね。
次にホスト間通信について見てみます。

ホスト間通信

前回までと同様に左から右へpingをしてみると、NATされていないことがわかりますね

解決

ブリッジが存在しない件ですが、Azure CNIには2つのモードが関わっています。

bridge mode
transparent mode

bridge mode

“azure0”というbridgeがNode内に作成され、Node内のPodはこのbridgeによってL2ブリッジングされる
Kubernetesバージョン1.2.0以降、選ぶことのできないモード

transparent mode

bridgeは作成されず、L3ルーティングされる（Azure VNetのSDNの世界）
Kubernetesバージョン1.2.0以降、Azure CNIにおける唯一のモード

デフォルトではtransparent modeが選択されていたためにブリッジが存在しなかった、ということになります。
また、NATされていなかったのも、transparent modeの仕様でSDNの世界でL3ルーティングされていたのです。

まとめ

Azure CNIネットワークモデルにおける特徴をまとめると以下の通りとなります。

bridgeモードの場合、Node内にbridgeが作られる
transparentモードの場合、bridgeは作成されない。
PodごとにNW namespaceが異なる
PodのサブネットとNodeのサブネットは、レンジが同じ
bridgeモードの場合、bridgeからNodeのeth0に転送されるときにNATされる
transparentモードの場合、L3ルーティングされる

次回は最終回でDocker、AKSのネットワークモデルについて比較した結果をまとめます。