Kubernetesの世界へ足を踏み入れたとき、多くのエンジニアが最初に直面する「ちょっとした壁」がネットワークの仕組みです。
「コンテナって、中でそれぞれ独立しているはずなのに、どうやってお互いを見つけておしゃべりしているんだろう？」
「Dockerの頃にあった port: -p 80:80 みたいなポート転送の魔法が、Kubernetesではどう動いているの？」
そんな疑問を持ったことはありませんか？
今回は、クラウドインフラやKubernetesの裏側でパケットを奔走させているSREの視点から、KubernetesのPodネットワークモデルと、それを裏で支えるCNI（Container Network Interface）プラグインの基本概念を、身近な例えを交えて優しく紐解いていきたいと思います。
難しい専門用語や複雑なパケットの構造はいったん脇に置いて、一歩ずつ理解していきましょう！
—
1. Kubernetesネットワークの「絶対ルール」を知ろう
まずは、Kubernetesがネットワークに対してどんなルールを敷いているのか、大前提を確認しましょう。Kubernetesのネットワークモデルは、驚くほどシンプルで、かつ大胆です。
そのルールとはズバリ、以下の3つです。
1. すべてのPodは、NAT（ネットワークアドレス変換）なしで、他のすべてのPodと通信できること。
2. すべてのノード（物理・仮想マシン）は、NATなしで、すべてのPodと通信できること（およびその逆）。
3. Pod自身が見ているIPアドレスは、他のPodから見てもまったく同じIPアドレスであること。
「……ちょっと待って、それってどういうこと？」ですよね。
普段私たちが使っている自宅のWi-Fiやオフィスのルーターを思い出してみてください。ルーターの下にあるパソコンやスマホは、ルーターに隠れて「見えない裏の顔（プライベートIP）」を持っています。外部と通信するときは、ルーターが一度自分のIPアドレスに変換（NAT）して外へ送り出していますよね。
しかし、Kubernetesのクラスタ内では、この「コソコソ隠れる技（NAT）」が原則禁止されています。
郵便配達に例えてみよう
これを私たちの身近な「郵便配達」に例えてみましょう。
- 昔ながらの古いシステム（Dockerのデフォルトなど）：
アパート（＝ホストマシン）の入り口に管理人（＝NAT）がいて、届いた手紙の宛先をいちいち書き換えて部屋（＝コンテナ）に配っています。「部屋番号101号室宛てだけど、実際の中身は部屋の住人Aさんね」といった具合です。これだと、住人同士が直接手紙をやり取りするときに、いちいち管理人のところを通らなきゃいけないし、誰がどこにいるのか分かりづらいですよね。
- Kubernetesの世界：
アパートの各部屋（＝Pod）に、最初から世界中でユニークな本物の住所（＝IPアドレス）が割り振られています。郵便配達員（＝ネットワーク）は、宛先を見れば、管理人を通さなくてもダイレクトにその部屋のポストへ手紙を投函できます。住人同士も「〇号室の〇〇さんへ直接どうぞ」と手紙を渡せるわけです。
この「全員が固有の住所を持っていて、直接やり取りできる」という世界観こそが、Kubernetesのネットワークモデルの本質なのです。
—
2. だけど、コンテナは「何もない空間」に生まれたばかり…
ここで一つの疑問が浮かび上がります。
「Podやコンテナが作られた瞬間って、中身は空っぽのまっさらな状態なのに、どうやってそんな立派なIPアドレスをもらって、外の世界と繋がれるの？」
ここで登場するのが、今回の主役である CNI（Container Network Interface） という仕組みです。
CNIは、いわば「Kubernetesクラスタ専用の引っ越し屋さん兼、役所の住民登録係」です。
Kubernetes（正確にはKubelet）が「新しいPodを作るよ！」と号令をかけると、CNIプラグインが裏でこんな作業を瞬時に行っています。
1. 新しいPodのための「仮想的なネットワークケーブル」を用意する。
2. 空いている一意のIPアドレスを割り当てて、Podに「あなたの住所はこれね」と教える。
3. そのPodから出入りするパケットが、ちゃんとホストマシンの外へ（あるいは他のPodへ）届くように、道路や看板（ルーティングテーブル）を整備する。
このCNIという「共通のルール（インターフェース）」があるおかげで、Kubernetes本体はネットワークの細かい設定を気にせず、「ねぇCNIさん、このPod用のネットワークよろしく！」と丸投げできるのです。
—
3. 代表的なCNIプラグイン：FlannelとCalicoのキャラクターを知る
CNIプラグインにはいくつかの種類がありますが、現場でよく使われる代表的な2つ、「Flannel（フランネル）」と「Calico（キャリコ）」の個性を覗いてみましょう。
Flannel：優しくて直感的な「トンネル配達員」
Flannelは、Kubernetesのネットワーク入門として最もよく使われる、非常にシンプルなCNIプラグインです。
- 仕組みのイメージ：
別々のノードにいるPod同士が手紙を送るとき、Flannelは手紙をそのまま投げません。一度「封筒（カプセル）」の中に元の手紙をすっぽり包み込んで、宛先を「相手のノードの住所」に書き換えて送り出します。これをネットワークの専門用語でカプセル化（トンネルイング）と呼びます。
- メリット： とにかく設定が簡単で、どんな環境でもスルスル動きやすい。
- デメリット： 封筒に入れ直したり出したりする（カプセル化・非カプセル化の）ひと手間がかかるため、通信のパフォーマンスがほんの少しだけ落ちる。
Calico：道路網を完璧に整備する「プロの交通整理士」
Calicoは、大規模な本番環境や、セキュリティを厳しく管理したい現場で大人気の、ちょっぴりスパルタンで頼れるCNIプラグインです。
- 仕組みのイメージ：
Calicoは封筒に入れません。その代わり、ノードとPodの間に張り巡らされたネットワークの「道路網（ルーティングテーブル）」をめちゃくちゃ細かく、綺麗に整理します。まるで、すべての交差点に優秀な交通整理士が立っていて、「この宛先のパケットは、あっちの道路へ直進！」とダイレクトに導いてくれるようなイメージです。
- メリット： カプセル化をしないため、通信のパフォーマンスが非常に優れている。また、ネットワークのルール（ファイアウォール設定）を細かく書ける。
- デメリット： ネットワークの仕組みを少し深く理解していないと、トラブルが起きたときに沼にハマりやすい。
—
4. 実務で触れるCNI設定のリアル（Flannelの例）
百聞は一見に如かず。実際にKubernetesクラスタを作る際、CNIプラグインの設定ファイルがどのように記述されているか、その一端を覗いてみましょう。
以下のYAMLファイルは、Flannelをクラスタに導入する際によく使われる設定ファイルの断片です。
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: kube-flannel-ds
namespace: kube-system
labels:
tier: node
app: flannel
spec:
selector:
matchLabels:
app: flannel
template:
metadata:
labels:
tier: node
app: flannel
spec:
containers:
- name: kube-flannel
image: rancher/mirrored-flannel-cni:v0.21.5
command:
- /opt/bin/flanneld
args:
- --ip-masq
- --kube-subnet-mgr
resources:
requests:
cpu: "100m"
memory: "50Mi"
securityContext:
privileged: true # ←ネットワークの根底をいじるため、特権権限で動かしますここで注目してほしいのは、securityContext の中にある privileged: true という設定です。
CNIプラグインは、ホストマシンのネットワークインターフェースを直接操作したり、ルーティングを書き換えたりする「インフラの根幹」を担う仕事です。そのため、通常のコンテナよりも強い権限を持って、クラスタの各ノード（DaemonSet により全ノードに自動配置されます）で黙々と働き続けているのです。
現場のSREたちは、新しいクラスタを構築するときや、「あれ、Podから外部に通信できないぞ？」というトラブルシューティングに直面したとき、まさにこの kube-system ネームスペースにあるCNIのポッド（ログや設定）を真っ先に覗きにいきます。
—
まとめ
今回は、KubernetesのPodネットワークモデルと、それを裏で支えるCNIプラグインの基本概念について、郵便配達や引っ越し屋さんに例えて解説しました。
- Kubernetesのネットワークは「NATなしで全員が直接おしゃべりできる」のが大原則。
- その一意な住所の割り当てや道路の整備を裏で泥臭くやってくれているのが「CNIプラグイン」。
- プラグインには、手紙を封筒に包む「Flannel」や、道路網を完璧に整備する「Calico」など、それぞれ個性がある。
インフラやネットワークの世界に初めて触れるとき、見えないパケットの動きを想像するのは少し難しく感じるかもしれません。でも、「このPodにはどんな住所が振られていて、どのCＮＩという引越し屋さんがこの道を管理しているんだっけ？」と頭の中でキャラクターを思い浮かべられるようになると、Kubernetesのネットワークトラブルも怖くなくなります。
ぜひ、ご自身のローカル環境（MinikubeやKindなど）で、kubectl get pods -n kube-system を叩いて、今回お話ししたCNIの仲間たちが元気に働いている姿を覗いてみてくださいね。それでは、快適なKubernetesライフを！
コメント