Azure Container Networking
Deep Dive
真壁 徹
日本マイクロソフト株式会社
クラウドソリューションアーキテクト
2021/02
細かすぎて伝わらないかもしれない

この資料の目的と前提
なぜ細かい話をするのか
Azure Kubernetes ServiceにおけるAzure CNIを題材に、Azureのコン
テナネットワーキングの構造や特徴を解説する
マネージドサービスであっても、内部構造の理解は最適化や問題解決
の助けとなる
2021/2時点で公開されている、もしくはユーザが取得可能な情報にも
とづく (GitHub、公式ドキュメント、Azure実環境、etc)
公式ドキュメントを補完する (あわせて読むと理解が深まる)
解説範囲はLinuxノード、Azure CNI関連要素とする

想定読者
Azure Kubernetes Service (AKS)を利用したことがある
Azureの他コンテナ関連サービスを利用したことがある
AKS/Azureは利用したことがないが、そのコンテナネットワーク実装
に関心がある
Linuxのネットワーク機能と、それがKubernetesでどのように活用され
ているかに関心がある

お品書き
Kubernetesネットワーキング基礎
AKSネットワークモデル (KubenetとAzure CNI)
Azure CNI Deep Dive
ロードマップと将来の方向性
あわせて読みたい

Kubernetesネットワーキング
基礎

PodとIPアドレス
Podはコンテナとボリュームをまと
める単位
1つのPodに複数のコンテナやボ
リュームを含められる
PodごとにIPアドレスを持つ
https://kubernetes.io/ja/docs/tutorials/kubernetes-
basics/explore/explore-intro/

Node、PodとIPアドレス
NodeはPodを動かすサーバ
(一般的には仮想マシンやベアメタ
ルサーバ)
Nodeで複数のPodを動かせる
https://kubernetes.io/ja/docs/tutorials/kubernetes-
basics/explore/explore-intro/

なぜPodがIPを持つのか
“すべてのPodは独自のIPアドレスを持ちます。これは、Pod間のリン
クを明示的に作成する必要がなく、コンテナポートをホストポートに
マッピングする必要がほとんどないことを意味します。
こうすることで、ポート割り当て、名前解決、サービスディスカバ
リー、負荷分散、アプリケーション設定、および移行の観点から、
PodをVMまたは物理ホストと同様に扱うことができる、クリーンで後
方互換性のあるモデルを生み出しています”
https://kubernetes.io/ja/docs/concepts/cluster-administration/networking/

Kubernetesのネットワーク要件
ネットワーク実装はプラグインで拡張可能だが、守るべき要件がある
ノード上のPodが、NATなしですべてのノード上のすべてのPodと通信
できること
systemdやkubeletなどノード上にあるエージェントが、そのノード上
のすべてのPodと通信できること
ノードのホストネットワーク内のPodは、NATなしですべてのノード上
のすべてのPodと通信できること
https://kubernetes.io/ja/docs/concepts/cluster-administration/networking/
[補足]KubernetesでNATが使われるケースはあります(Service -> Endpoint DNATなど)。ただしNATが認められな
い通信パターンがありますよ、ということです

2種類のプラグイン
Kubernetesネットワーク
[Kubenet Plugin]
基本的なコンテナとネットワーク
の接続機能を提供
Kubernetes/Linux限定
Nodeを超えた通信は範囲外とする
ため、別途トンネリングなどを組
み合わせる必要がある
[CNI Plugin]
CNI = Container Network
Interface
多様なコンテナランタイム、オー
ケストレータとネットワークの接
続を標準化する仕様、リファレン
ス実装
CNCFプロジェクト

CNI
https://github.com/containernetworking/cni
Kubernetes向けが活発だが、
Kubernetes限定ではない
クラウドサービス、 OSS、商用
SDN製品などネットワーク実装に
合わせたプラグインがある
(Azure、AWS VPC、Calico、
Flannel、Cilium、NSX-Tなど）

CNIの責務
https://github.com/containernetworking/cni/blob/master/SPEC.md
“A CNI plugin is responsible for inserting a network interface into the
container network namespace (e.g. one end of a veth pair) and
making any necessary changes on the host (e.g. attaching the other
end of the veth into a bridge).
It should then assign the IP to the interface and setup the routes
consistent with the IP Address Management section by invoking
appropriate IPAM plugin”

CNI Specification
https://github.com/containernetworking/cni/blob/master/SPEC.md
CNIプラグインは、コンテナ作成/
削除などに合わせ、仮想NICをはじ
めとするネットワーク要素の操作
を行う
4つの操作(ADD、DEL、CHECK、
VERSION)が定義されている
必要に応じてIPAMと連動し、IPア
ドレスの割り当てや開放を行う

Kubernetes/containerdの実装例
https://github.com/containerd/cri/blob/release/1.4/docs/architecture.md

AKSネットワークモデル

2種類のネットワークモデル
Azure Kubernetes Service ネットワーク
[Kubenet]
Kubernetesの基本モデル
Node間通信などKubenetの足りな
い機能をAzure SDNで補完
PodはPod CIDR範囲のIPを持つが、
他Node向け通信はAzure VNetの
ユーザ定義ルート(UDR)を使う
[Azure CNI]
Azure SDN向けCNI Plugin
PodはAzure VNet/SubnetのIPを
持つ
ネットワークポリシなどAzure
VNetの機能と統合しやすい
この資料でDeep Diveする対象

(参考: Azure Kubernetes ServiceにおけるKubenet実装)
Pod CIDRはAzure VNetか
ら隠蔽されている(VNet
がIPを管理しない)

どちらのモデルを選択するか
https://docs.microsoft.com/ja-jp/azure/aks/concepts-network
決め手になることもある(後述)

どちらのモデルを選択するか
https://docs.microsoft.com/ja-jp/azure/aks/concepts-network
機能ではAzure CNI >
Kubenet
経験上、 Azure CNIのほ
うがAzure VNetとの統合、
新機能への対応が早い傾
向はある

どちらのモデルを選択するか
https://mehighlow.medium.com/aks-kubenet-vs-azure-cni-363298dd53bf
iperfによるNode間ス
ループットの測定結果に
大きな差はなし
若干Azure CNIのスルー
プットが高い
ベンチマークの他にワー
クロードがない条件での
測定だが、参考に
AKS Standard_DS2_v2 Node

どちらのモデルを選択するか
Azure CNIが機能と性能でやや優れるが、IPアドレス空間が決め手で
Kubenetを選択するケースもある
オンプレミスや他VNetとの接続など、AKSのIPアドレス空間を分離で
きない、十分なIPアドレスを確保できないユースケースで顕著
ただしAzure CNIでIPアドレス数の問題を解決する取り組みはあるため、
後述のロードマップも確認のうえ、ご検討を

Azure CNI Deep Dive

実環境で確認していきます
AKS version: v.1.20.2
Node pool: Standard_F2s_v2 * 3
Container Runtime: containerd
Max Pods per Node: 100
Network Plugin: Azure (Azure CNI)
Network Policy: Azure
Network Mode: Transparent
VNet Address Space: 10.0.0.0/8
Node pool subnet: 10.240.0.0/16
Service CIDR: 10.0.0.0/16

既定はブリッジモードからL3透過モードへ
この資料はL3透過モード(Transparent)を説明
従来、AKSではPodネットワーク名
前空間をL2ブリッジに接続する
モードが既定
よりシンプルなL3透過(Transparent)
モードへのシフト
2021/1/4リリースからTransparent
モードが既定に
https://docs.microsoft.com/ja-jp/azure/aks/faq#what-
is-azure-cni-transparent-mode-vs-bridge-mode

Master Node
State store
(etcd)
Scheduler
kubelet
Container
Runtime
API Server
APIs
Controller Manager
Controllers
Azure
API
Node
Features/
Configs
kube-proxy
Developer/
Admin
(**)DaemonSetなど上位オブジェクトの表現は割愛
Admission
Webhook(*)
(*)Podに配置されるケースもある
AKS ハイレベルアーキテクチャとネットワーク関連コンポーネント
Pods(**)
Azure
CNI
iptables/ebtables
(Netfilter) など

Azure CNI Plugin
kubelet設定
root@aks-default-40839087-vmss000000:/# cat /etc/default/kubelet
KUBELET_FLAGS=--address=0.0.0.0 --anonymous-auth=false --authentication-token-webhook=true --authorization-
mode=Webhook --azure-container-registry-config=/etc/kubernetes/azure.json --cgroups-per-qos=true --client-
ca-file=/etc/kubernetes/certs/ca.crt --cloud-config=/etc/kubernetes/azure.json --cloud-provider=azure --
cluster-dns=10.0.0.10 --cluster-domain=cluster.local --dynamic-config-dir=/var/lib/kubelet --enforce-node-
allocatable=pods --event-qps=0 --eviction-
hard=memory.available<750Mi,nodefs.available<10%,nodefs.inodesFree<5% --feature-
gates=RotateKubeletServerCertificate=true --image-gc-high-threshold=85 --image-gc-low-threshold=80 --image-
pull-progress-deadline=30m --keep-terminated-pod-volumes=false --kube-reserved=cpu=100m,memory=1024Mi --
kubeconfig=/var/lib/kubelet/kubeconfig --max-pods=100 --network-plugin=cni --node-status-update-
frequency=10s --non-masquerade-cidr=0.0.0.0/0 --pod-infra-container-
image=mcr.microsoft.com/oss/kubernetes/pause:1.3.1 --pod-manifest-path=/etc/kubernetes/manifests --pod-max-
pids=-1 --protect-kernel-defaults=true --read-only-port=0 --resolv-conf=/run/systemd/resolve/resolv.conf --
rotate-certificates=false --streaming-connection-idle-timeout=4h --tls-cert-
file=/etc/kubernetes/certs/kubeletserver.crt --tls-cipher-
suites=TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_C
HACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA
_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256 --tls-private-key-
file=/etc/kubernetes/certs/kubeletserver.key
[snip]
CNIを使う宣言

Azure CNI Plugin
設定
root@aks-default-40839087-vmss000000:/# cat /etc/cni/net.d/10-azure.conflist
{
"cniVersion":"0.3.0",
"name":"azure",
"plugins":[
{
"type":"azure-vnet",
"mode":"transparent",
"ipsToRouteViaHost":["169.254.20.10"],
"ipam":{
"type":"azure-vnet-ipam"
}
},
{
"type":"portmap",
"capabilities":{
"portMappings":true
},
"snat":true
}
]
}
どのCNI Pluginを、
どのように使うか

Azure CNI Plugin
バイナリの置き場所
root@aks-default-40839087-vmss000000:/# ll /opt/cni/bin/
total 136816
drwxr-xr-x 2 root root 4096 Feb 22 00:31 ./
drwxr-xr-x 3 root root 4096 Feb 22 00:31 ../
-rwxr-xr-x 1 root root 27844608 Dec 15 16:13 azure-vnet*
-rwxr-xr-x 1 root root 28065792 Dec 15 16:13 azure-vnet-ipam*
-rwxr-xr-x 1 root root 28065792 Dec 15 16:13 azure-vnet-ipamv6*
-rwxr-xr-x 1 root root 5926912 Dec 15 16:13 azure-vnet-telemetry*
-rwxr-xr-x 1 root root 184 Dec 15 16:17 azure-vnet-telemetry.config*
-rwxr-xr-x 1 root root 4028260 Aug 13 2019 bridge*
-rwxr-xr-x 1 root root 10232415 Aug 13 2019 dhcp*
-rwxr-xr-x 1 root root 2856252 Aug 13 2019 flannel*
-rwxr-xr-x 1 root root 3127363 Aug 13 2019 host-device*
-rwxr-xr-x 1 root root 3036768 Aug 13 2019 host-local*
-rwxr-xr-x 1 root root 3572685 Aug 13 2019 ipvlan*
[snip]

(補足)Azure CNI Plugin以外のコンポーネント
Pod – Deployment として動くコンポーネント
% k get deploy --all-namespaces -o name
deployment.apps/flux
deployment.apps/flux-memcached
deployment.apps/helm-operator
deployment.apps/gatekeeper-audit
deployment.apps/gatekeeper-controller
deployment.apps/aks-link
deployment.apps/azure-policy
deployment.apps/azure-policy-webhook
deployment.apps/coredns
deployment.apps/coredns-autoscaler
deployment.apps/metrics-server
deployment.apps/omsagent-rs
[aks-link]
マネージドサービス空間にあるMasterとNode
の間とVPNを張り、kubectl execなど、Master
側からのインバウンド通信を実現する

(補足) Azure CNI Plugin以外のコンポーネント
Pod – DaemonSet として動くコンポーネント
% k get ds --all-namespaces -o name
daemonset.apps/azure-cni-networkmonitor
daemonset.apps/azure-ip-masq-agent
daemonset.apps/azure-npm
daemonset.apps/kube-proxy
daemonset.apps/omsagent
daemonset.apps/omsagent-win
[azure-cni-networkmonitor]
ネットワーク定義と現状のチェックを行う
(NATルールなど)
[azure-ip-masq-agent]
iptablesを操作し、IPマスカレード対象/除外ア
ドレス範囲を指定する
[azure-npm]
ネットワークポリシを実現する(ポリシエンジ
ンとしてCalicoも選択可能)
[kube-proxy]
API Serverを継続的にウォッチし、ネットワー
ク関連イベントをNodeに適用する(iptablesへ
のEndpoint追加/削除など）
[Source Code]
azure-cni-networkmonitor https://github.com/Azure/azure-container-networking/tree/master/cnms
azure-npm https://github.com/Azure/azure-container-networking/tree/master/npm
ip-masq-agentとkube-proxyはkubernetes upstream

(補足)iptables IP-MASQ-AGENT チェイン
クラスタ内通信はIPマスカレードしない
root@aks-default-40839087-vmss000000:/# iptables -t nat -L IP-MASQ-AGENT
Chain IP-MASQ-AGENT (1 references)
target prot opt source destination
RETURN all -- anywhere 10.0.0.0/8 /* ip-masq-agent: local traffic
is not subject to MASQUERADE */
RETURN all -- anywhere 10.240.0.0/16 /* ip-masq-agent: local traffic
is not subject to MASQUERADE */
RETURN all -- anywhere 10.0.0.0/16 /* ip-masq-agent: local traffic
is not subject to MASQUERADE */
MASQUERADE all -- anywhere anywhere /* ip-masq-agent: outbound
traffic is subject to MASQUERADE (must be last in chain) */

構成要素を
ひとつずつ
確認していきましょう

Node一覧
調査対象を決定
% k get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE
KERNEL-VERSION CONTAINER-RUNTIME
aks-default-40839087-vmss000000 Ready agent 7h48m v1.20.2 10.240.0.4 <none> Ubuntu
18.04.5 LTS 5.4.0-1036-azure containerd://1.4.3+azure
aks-default-40839087-vmss000001 Ready agent 7h48m v1.20.2 10.240.0.105 <none> Ubuntu
18.04.5 LTS 5.4.0-1036-azure containerd://1.4.3+azure
aks-default-40839087-vmss000002 Ready agent 7h48m v1.20.2 10.240.0.206 <none> Ubuntu
18.04.5 LTS 5.4.0-1036-azure containerd://1.4.3+azure
このNodeにsshして
調査します

対象Nodeで実行中のPod
PodとIPの一覧
% k get po --all-namespaces -o "custom-columns=:.metadata.name,:.spec.nodeName,:.status.podIP"|grep
default-40839087-vmss000000
nsenter-xan42b aks-default-40839087-vmss000000 10.240.0.4
aks-link-6f99b65544-v6d8v aks-default-40839087-vmss000000 10.240.0.6
azure-cni-networkmonitor-99gfr aks-default-40839087-vmss000000 10.240.0.4
azure-ip-masq-agent-4wdg4 aks-default-40839087-vmss000000 10.240.0.4
azure-npm-njjp4 aks-default-40839087-vmss000000 10.240.0.4
azure-policy-5c5b4c689b-m5qqr aks-default-40839087-vmss000000 10.240.0.104
azure-policy-webhook-f64bcd58b-xl8xc aks-default-40839087-vmss000000 10.240.0.86
coredns-autoscaler-5b6cbd75d7-v8f6t aks-default-40839087-vmss000000 10.240.0.83
coredns-b94d8b788-gdlcz aks-default-40839087-vmss000000 10.240.0.79
kube-proxy-76tlh aks-default-40839087-vmss000000 10.240.0.4
metrics-server-77c8679d7d-4tfcc aks-default-40839087-vmss000000 10.240.0.53
omsagent-hkm7d aks-default-40839087-vmss000000 10.240.0.88
omsagent-rs-5c55d9bcc8-sf82n aks-default-40839087-vmss000000 10.240.0.78
[snip]
NodeのプライマリIP
で動くPodもある
(.spec.hostNetwork:
true)

ネットワーク名前空間
.spec.hostNetwork: false なPodの数だけ ネットワーク名前空間ができる
root@aks-default-40839087-vmss000000:/# ip netns ls
cni-32f79230-cba3-f2d7-10e2-3f3708ed515c (id: 10)
cni-2eb82ed4-bf11-2e72-90ef-3d7a2373f719 (id: 11)
cni-50a741fc-041a-1272-bef8-7bcb5b966f2e (id: 12)
cni-74b75555-a1bc-494e-bfd9-845b22164eb9 (id: 9)
cni-4232f09c-2549-eb26-c4a9-4c576b6a420b (id: 8)
cni-1ac8daf0-60f5-bcfc-f317-92da73f908d8 (id: 7)
cni-746c299d-03eb-17cc-42da-5027c5957b6d (id: 6)
cni-ab01c222-18a6-b002-2c5d-1965a6450cb3 (id: 5)
cni-098c1e60-bf8d-c9bf-1646-47f8e608e3db (id: 4)
cni-e55890ee-8a42-f19d-ec95-da325db177c8 (id: 0)
[snip]

?
10.240.0.4/16
Network namespace: cni-e55890ee-
8a42-f19d-ec95-da325db177c8 (id: 0)
Network namespace: host
Pod
Other Namespaces
Pod
Pod
Pod
Pod
ホストネットワーク名前空間とは
別のネットワークスタックを持つ
(ルート、iptablesチェインなど）

ホスト名前空間のIPアドレス
IPv4
root@aks-default-40839087-vmss000000:/# ip -f inet a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
qlen 1000
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default
qlen 1000
inet 10.240.0.4/16 brd 10.240.255.255 scope global eth0
valid_lft forever preferred_lft forever
NodeのプライマリIPアドレス

eth0
10.240.0.4/16
Network namespace: cni-e55890ee-
8a42-f19d-ec95-da325db177c8 (id: 0)
Network namespace: host
Pod
Other Namespaces
Pod
Pod
Pod
Pod

ホスト名前空間のインタフェイス
インタフェイスとリンク
root@aks-default-40839087-vmss000000:/# ip -f link a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default
qlen 1000
link/ether 00:0d:3a:ce:6f:5a brd ff:ff:ff:ff:ff:ff
4: azvbdb1c4944b1@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UP group default qlen 1000
link/ether ea:18:de:a3:29:10 brd ff:ff:ff:ff:ff:ff link-netnsid 0
[snip]
ネットワーク名前空間ID: 0とリン
クしている

eth0
10.240.0.4/16
azvbdb1c4944b1@if3
ea:18:de:a3:29:10
Network namespace: cni-e55890ee-
8a42-f19d-ec95-da325db177c8 (id: 0)
Network namespace: host
Pod
Other Namespaces
Pod
Other IF
Pod
Pod
Pod
?

Pod名前空間のIPアドレス
root@aks-default-40839087-vmss000000:/# ip netns exec cni-e55890ee-8a42-f19d-ec95-da325db177c8 ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: eth0@if4: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether f6:a9:08:d9:cb:2a brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 10.240.0.88/16 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::f4a9:8ff:fed9:cb2a/64 scope link
valid_lft forever preferred_lft forever
Podのネットワーク名前空間で
コマンドを実行

eth0
10.240.0.4/16
azvbdb1c4944b1@if3
ea:18:de:a3:29:10
Network namespace: cni-e55890ee-
8a42-f19d-ec95-da325db177c8 (id: 0)
eth0@if4
f6:a9:08:d9:cb:2a
10.240.0.88/16
Network namespace: host
Pod
Other Namespaces
Pod
Other IF
Other IF
Pod
Pod
Pod

ホスト名前空間のルート
root@aks-default-40839087-vmss000000:/# ip r
default via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
10.240.0.0/16 dev eth0 proto kernel scope link src 10.240.0.4
10.240.0.6 dev azva9397a1bc49 proto static
10.240.0.7 dev azv8eed0080cd7 proto static
10.240.0.15 dev azvb8eb335c1b9 proto static
10.240.0.20 dev azv2e65b540f01 proto static
[snip]
10.240.0.78 dev azvf7167fe07b1 proto static
10.240.0.79 dev azv72bac978d69 proto static
10.240.0.83 dev azvb33dc95ce90 proto static
10.240.0.86 dev azvb4f8cd7ad4c proto static
10.240.0.88 dev azvbdb1c4944b1 proto static
10.240.0.104 dev azva76d1269bcf proto static
168.63.129.16 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
169.254.169.254 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
各Podへの静的L3ルートを
持っている

Pod名前空間のルート
root@aks-default-40839087-vmss000000:/# ip netns exec cni-e55890ee-8a42-f19d-ec95-da325db177c8 ip r
default via 169.254.1.1 dev eth0 proto static
169.254.1.1 dev eth0 proto static scope link
リンクローカルアドレスが
デフォルトゲートウェイ

Pod名前空間のARPキャッシュ
root@aks-default-40839087-vmss000000:/# ip netns exec cni-e55890ee-8a42-f19d-ec95-da325db177c8 ip n
10.240.0.4 dev eth0 lladdr ea:18:de:a3:29:10 STALE
169.254.1.1 dev eth0 lladdr ea:18:de:a3:29:10 PERMANENT
ホスト名前空間側インタフェ
イスのMACアドレス

Proxy ARP
ホスト名前空間側インタフェイスはProxy ARPを行う
root@aks-default-40839087-vmss000000:/# cat /proc/sys/net/ipv4/conf/azvbdb1c4944b1/proxy_arp
1
https://github.com/Azure/azure-container-
networking/blob/v1.2.2_hotfix/network/transparent_endpointclient_linux.go

eth0
10.240.0.4/16
azvbdb1c4944b1@if3
ea:18:de:a3:29:10
Proxy ARP 有効
Network namespace: cni-e55890ee-
8a42-f19d-ec95-da325db177c8 (id: 0)
eth0@if4
f6:a9:08:d9:cb:2a
10.240.0.88/16
Network namespace: host
Pod
Other Namespaces
Pod
Other IF
Other IF
Pod
Pod
Pod
ホスト側インタフェイスに
IPアドレスは設定不要
デフォルトルートはリンク
ローカルアドレス169.254.1.1
(すべてのPodで共通)

ホスト名前空間のARPキャッシュ
root@aks-default-40839087-vmss000000:/# ip n
10.240.1.29 dev eth0 lladdr 12:34:56:78:9a:bc REACHABLE
10.240.0.44 dev azvdb9fa0de861 lladdr fa:85:b2:1c:3e:f9 REACHABLE
10.240.0.83 dev azvb33dc95ce90 lladdr 8e:09:66:32:69:34 REACHABLE
10.240.0.86 dev azvb4f8cd7ad4c lladdr 92:13:97:a0:64:d9 STALE
10.240.0.206 dev eth0 lladdr 12:34:56:78:9a:bc REACHABLE
10.240.0.53 dev azv3c2e0bf260a lladdr a6:03:58:76:30:b4 REACHABLE
10.240.0.1 dev eth0 lladdr 12:34:56:78:9a:bc REACHABLE
10.240.0.158 dev eth0 lladdr 12:34:56:78:9a:bc REACHABLE
10.240.0.241 dev eth0 lladdr 12:34:56:78:9a:bc STALE
10.240.0.88 dev azvbdb1c4944b1 lladdr f6:a9:08:d9:cb:2a REACHABLE
10.240.0.78 dev azvf7167fe07b1 lladdr 72:bb:37:02:5a:0f REACHABLE
[snip]
Nodeを超える場合、宛先MAC
アドレスはAzure SDNになる

IPアドレスの事前割り当て
Node pool作成時に指定した Max podsの数だけ、Node作成時に割り当てられる

Podがなくても パケットはNodeへ届く
Azure SDNは事前割り当てしたIPアドレスとNodeの対応を把握している
% k get po –all-namespaces –o wide|grep 10.240.1.50
root@aks-default-40839087-vmss000000:/# arping 10.240.1.50
ARPING 10.240.1.50
42 bytes from 12:34:56:78:9a:bc (10.240.1.50): index=0 time=385.605 usec
42 bytes from 12:34:56:78:9a:bc (10.240.1.50): index=1 time=551.108 usec
42 bytes from 12:34:56:78:9a:bc (10.240.1.50): index=2 time=322.404 usec
[snip]
root@aks-default-40839087-vmss000000:/# arping 10.240.1.51
ARPING 10.240.1.51
Timeout
[snip]
10.240.1.50はNode aks-default-
40839087-vmss000002に割り当てられ
ているが、Podには未割り当て
Azure SDNが事前割り当てしたNode
のインタフェイスまで届けている
まだNodeに割り当てられてい
ないIPアドレスには届かない

ロードマップと
将来の方向性

IPアドレス空間に余裕がなくても 使いやすく
Pod用VNet/Subnetの分離、動的IPアドレス割り当て
https://github.com/Azure/AKS/issues/1788
NodeのVNet/Subnetとは別にPod向けVNet/Subnetを指定できるように
また、事前割り当てではなく、必要な時に割り当てられるように

IPアドレスの事前静的割り当て(現在)
Azure CNI IPAM PluginがNodeに事前割り当てされたIPアドレスを利用する
Network Control Plane
Azure Server
Cluster Orchestrator
Network Host Agent
Azure Server
Network Host agent
CNI
Container 1
Container n
OrchAgent
…
https://github.com/Azure/azure-container-
networking/blob/v1.2.2_hotfix/ipam/azure.go
シンプルで権限管理も容易だが、
Nodeに事前割り当てされた範囲を
超えて割り当てができない

動的割り当てを支える技術
Delegated Network Controller
Network Control Plane
Azure Server
Cluster Orchestrator
DNC (Delegated Network Controller)
Network Host Agent
Azure Server
Network Host agent
CNS
Container 1
Container n
OrchAgent
…
同様の技術はAzure App Serviceなどで、すでに使われている
クラスタ全体で利用可能なPod IP
アドレス空間の管理を、AKSマス
タに委任(Delegation)する
利用可能なIPアドレスを動的
に取得、開放するDaemonSet
https://github.com/Azure/azure-container-
networking/blob/v1.2.2_hotfix/cns/azure-cns.yaml

他ネットワークモデルの提供
継続的に検証中
https://github.com/Azure/AKS/issues/1846
IPVSやCiliumなどの要望があり、継続的に検証を行っている
現時点では大規模環境での検証で明らかになった課題が残っている

AKS 全体ロードマップ
https://github.com/Azure/AKS/projects/1

あわせて読みたい

関連ドキュメント、リポジトリのリンク
あわせて読みたい
Azure Kubernetes Service (AKS) でのアプリケーションに対するネッ
トワークの概念
Azure Kubernetes Service (AKS) クラスターのベースライン アーキテ
クチャ
Azure Kubernetes Service (AKS) でのネットワーク接続とセキュリ
ティに関するベスト プラクティス
Azure Kubernetes サービス (AKS) で Azure CNI ネットワークを構成
する

関連ドキュメント、リポジトリのリンク
あわせて読みたい
クラスターのネットワーク
CNI - the Container Network Interface
Microsoft Azure Container Networking

© Copyright Microsoft Corporation. All rights reserved.