Azure Kubernetes Service（旧Azure CNIネットワークモデル）の内部構造について

# はじめに
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)

### 前回の記事

https://qiita.com/maplejava/items/a70ef1a4e62b73085aa1

https://qiita.com/maplejava/items/a821fca27aa2e9e5d94e

### 注意点
この記事の検証時点でのAKSのネットワークモデルは「kubenet」と「Azure CNI」の2つでしたが、それぞれ2024年6月頃に名称が変更になり技術要素も（微妙に）変わりました。それぞれ現在では「Azure CNIオーバーレイ」と「フラットネットワーク」という名前になりました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2475719/b83d197e-b784-d1ce-20b5-8a6017f0a05a.png)

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

参考

https://learn.microsoft.com/ja-jp/azure/aks/concepts-network-cni-overview

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2475719/79035826-00fc-d3db-1289-80130522c66f.png)

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

https://qiita.com/maplejava/items/d56983a194c2448952c3

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

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

https://qiita.com/maplejava/items/f5e9ce8ba21afeb02d4b

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2475719/e3af872a-8d24-0fc4-964d-489a91e57bae.png)

# Azure CNIとは
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2475719/28fc222d-cb83-ef69-c581-e02c2cde9a07.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2475719/000bf024-f3f6-293b-9223-54a756b30368.png)

元々CNIという標準的なContainer Networkのモデルがあり、k8sはこれに対応しています。CNIはサードパーティ製のものが割りと多くあり、これはAzure版のCNIというイメージです。
NodeのサブネットとPodのサブネットが同じです（Podが直接VNetに接続されているイメージ）。
図にすると以下のようなイメージです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2475719/0100b0f8-ff9c-9913-ca77-3d5945bdfec9.png)

ポイント
1. Dockerのbridgeネットワークモデルやkubenetネットワークモデルにはあった**仮想ブリッジが存在しません。** 詳しくは後述します
2. Podごとに異なるネットワーク名前空間が割り当てられます。これにより、Pod間やPod‐Node間のネットワークを隔離しています
3. 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]
```

色々と情報を取得すると以下のようになりました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2475719/7fc3d8a1-48b4-7f5f-f520-ee1de12fe36e.png)

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

# ホスト間通信
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2475719/f981a0d0-3d8f-6ab4-aceb-ace31bd34572.png)
前回までと同様に左から右へpingをしてみると、**NATされていない**ことがわかりますね

# 解決
ブリッジが存在しない件ですが、Azure CNIには2つのモードが関わっています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2475719/9d136600-a80c-50f4-bb11-9ea6ad54dc88.png)
- 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における唯一のモード
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2475719/0ba8fe4b-7c08-41dd-c9f2-a1e0a199f8cd.png)

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

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

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

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