はじめに

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間）通信