はじめに
4回に分けてDockerとAzure Kubernetes Service（以下、AKS）の内部ネットワーク構造に注目し、深堀りしていきます。最終回では、両者を比較し共通点・相違点についてまとめます。
最終回は、Dockerのbridgeネットワークモデル、AKSのkubenetネットワークモデル、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オーバーレイ」と「フラットネットワーク」という名前になりました。
よって「kubenet」「Azure CNI」ネットワークモデルはレガシなモードとなりましたが、根本的な考え方は同じですし、Dockerとの比較という意味で検証内容自体は参考になると思いますので、以下に整理していきます。
参考
Dockerとは
- アプリケーションとその依存関係を”コンテナ”と呼ばれる包装にパッケージ化できるプラットフォーム
- HyperVisorによるゲストOS仮想化と比べると、軽量でリソース効率的と言われている
インストール方法やコマンド等は以下の記事を参考にして下さい。
Kubernetesとは
- コンテナ化されたアプリケーションのデプロイメント、スケーリング、および管理を自動化するオープンソースのコンテナオーケストレーションプラットフォームです。以下、k8sと記載します。
- クラウドではサーバ機器や回線など物理的な要素が抽象化されていますが、kubernetesでは負荷分散やIaaSとしてのサーバ、ルーティングテーブルなどのコンポーネントが抽象化されています（ServiceやNode、Podなど）。
- AKSの裏ではAzure Load Balancer、仮想マシンスケールセット（VMSS）、OSのiptablesなどのコンポーネントが組み合わさってk8sの機能が実装されています。
詳しくは以下の以前の記事を参考にしてください。
AKSとは
AKSはフルマネージドKubernetesサービスです。AKSは、Kubernetesクラスタのデプロイ、管理、スケーリングを簡素化することを目的としています。
詳しくは以下の以前の記事を参考にしてください。
整理結果
bridgeとNAT
Docker、kubenet、Azure CNIのbridgeモード全てにおいて仮想ブリッジが作成され、コンテナ（もしくはPod）間の通信はこのbridgeを経由して行われます。また、基本的にはコンテナ（もしくはPod）からホスト（もしくはNode）への通信はブリッジにてNATされます。
しかし、kubenetにおいてAKSクラスタ内のNodeに対する通信は例外で、UDRによってIPフォワーディングされる仕様となっています。
また、Azure CNIのtransparentモードにおいては仮想ブリッジは作成されず、SDNの世界でL3ルーティングされます。
ネットワーク名前空間
どのネットワークモデルにおいて、コンテナ（もしくはPod）ごとに一つのネットワーク名前空間が与えられることで、これにより、コンテナ（もしくはPod）間やコンテナ-ホスト間（もしくはPod‐Node間）のネットワークを隔離しています。
サブネット
コンテナ（もしくはPod）のサブネットと、ホスト（もしくはNode）のサブネットは基本的には異なります。
しかし、Azure CNIにおいてはPodとNodeのサブネットが同じで、Podが直接VNetに接続されているイメージとなっています。
まとめ
上記をまとめると以下の表になります。
bridge、ネットワーク名前空間、サブネット
ホスト間（Node間）通信
