今こそ学びたいKubernetesネットワーク ～CNIが繋ぐNWとプラットフォームの「フラッと」な対話

2026/2/12 JANOG57 Meeting in Osakaにて登壇した際の資料です。

Transcript

1. Takuto Nagami @logica0419 Kotaro Kawasaki @n4mlz 今こそ学びたい Kubernetesネットワーク ～CNIが繋ぐNWとプラット フォームの「フラッと」な対話
2. 自己紹介 • Takuto Nagami (@logica0419) • 千葉工業大学 情報科学部 情報ネットワーク学科 4年 ◦ 研究: 合意アルゴリズム (Raft) × 暗号 (秘密分散) • 得意技術: Go言語 / コンテナ / Kubernetes • JANOG歴 ◦ JANOG56 若者支援で参加 ◦ JANOG57 初登壇！
3. 自己紹介 • Kotaro Kawasaki (@n4mlz) • 筑波大学 情報学群情報科学類 3年 • 趣味: コンテナランタイム自作、OS 自作、車輪の再発明 • 最近 という Linux コンテナをネイティブ実 行できる自作 OS を Rust で書いています
4. モダンなインフラ チェックしてますか？
5. クラウドからクラウドネイティブへ • ここ十数年で、クラウドビジネスは大躍進を遂げた • クラウドの設計思想はクラウドネイティブへと昇華 ◦ クラウドで一般的になった、スケールしやすい開発 アプローチをあらゆる場所で活用する ◦ オンプレ (プライベートクラウド) でも、この思想が 導入されつつある • このクラウドネイティブなエコシステムの 中心にいるのがKubernetes (K8s)
6. K8s、正直わからないですよね • 「難しい」というイメージが先行している • やはり「プラットフォームは我々の管轄外」という考え をしている人が多いのでは
7. プラットフォームチームも気持ちは同じ • プラットフォーム「ネットワーク？守備範囲じゃない」 • ネットワーク「K8s？守備範囲じゃない」
8. ところで: 架け橋は用意されている • K8sのネットワークは差し替え可能な設計 ◦ K8sのオリジナル開発者はGoogle ◦ 自身のクラウドのネットワークに最適化できるよう あえてどんなネットワーク技術も取り込めるように 設計している • プラットフォームとネットワークを繋ぐ開かれた門かつ 共通言語の役割を担う部品がいくつかある
9. しかしそれらの部品の実態は… • ネットワークもプラットフォームもお互いが忌避し、 両者の断絶を生む閉じた門になっている
10. しかしそれらの部品の実態は… • ネットワークもプラットフォームもお互いが忌避し、 両者の断絶を生む閉じた門になっている なんて もったいない！
11. OSSも銀の弾丸ではない • オンプレであっても、OSSを組み合わせてK8sのネット ワークを構成している現場がほとんど ◦ ネットワークチームはアンダーレイのみ管理し、 K8sのネットワークは別チームがOSSで運用 • OSSは汎用性のため、SDNベース • しかし、SDNより物理機材ベースの方が効率が良いはず ◦ OSSに頼り切るのではなく、ネットワークチームが 介入して自作・改造することで効率化が図れる
12. K8sネットワークの自社開発・改造例 • Google Cloud: GKE Dataplane V1 / V2 • AWS: Amazon VPC CNI • Microsoft Azure: Azure CNI • Cybozu: Coil on Neko基盤 ◦ 国内のクラウドでの例はこれしか見たことがない (公開されていないだけかもしれません) ◦ ↑ この状況を変えよう！というのが今回の目的
13. プラットフォームとフラッと対話する • ネットワークとプラットフォームの対話なしに、真に 効率の良いネットワークはあり得ない • 今回のテーマ「フラッとJANOG」に合わせ、フラッと 気兼ねない対話に必要な共通言語を身につけましょう！
14. 「プラットフォームと ネットワークの フラットな対話」を作る これを今回のゴールとします！一緒に頑張りましょう
15. アジェンダ • イントロダクション ←イマココ • Kubernetesを知る • Kubernetesとネットワーク • Linuxのネットワークスタック • L2/L3ネットワーク: CNI • L4ロードバランサー: kube-proxy • プラットフォームとの対話で広がる可能性 • まとめ
16. アジェンダ • イントロダクション • Kubernetesを知る ←イマココ • Kubernetesとネットワーク • Linuxのネットワークスタック • L2/L3ネットワーク: CNI • L4ロードバランサー: kube-proxy • プラットフォームとの対話で広がる可能性 • まとめ
17. Kubernetesを知る
18. K8sは難しく思われがちだが ポイントを絞れば そこまで難しくない！ ひとまずKubernetesの世界を旅してみましょう
19. Kubernetesの 提供するリソース
20. Pod Pod Pod • 便利になったコンテナ、K8sの最小単位 • 1つのワークロードを構成する単位 ◦ ≒ 1つのIPアドレスでくくって良い範囲
21. ReplicaSet ReplicaSet / Deployment • Podをまとめて管理するための仕組み • ReplicaSet: 同じ内容のPodを指定個数立てる • Deployment: ReplicaSetを使い安全にバージョン移行 Pod Pod
22. Deployment ReplicaSet / Deployment • Podをまとめて管理するための仕組み • ReplicaSet: 同じ内容のPodを指定個数立てる • Deployment: ReplicaSetを使い安全にバージョン移行 ReplicaSet Pod Pod
23. ReplicaSet / Deployment • Podをまとめて管理するための仕組み • ReplicaSet: 同じ内容のPodを指定個数立てる • Deployment: ReplicaSetを使い安全にバージョン移行 Deployment ReplicaSet (旧) Pod Pod ReplicaSet (新) Pod Pod
24. ReplicaSet / Deployment • Podをまとめて管理するための仕組み • ReplicaSet: 同じ内容のPodを指定個数立てる • Deployment: ReplicaSetを使い安全にバージョン移行 Deployment ReplicaSet (旧) Pod Pod ReplicaSet (新) Pod Pod
25. ReplicaSet / Deployment • Podをまとめて管理するための仕組み • ReplicaSet: 同じ内容のPodを指定個数立てる • Deployment: ReplicaSetを使い安全にバージョン移行 Deployment ReplicaSet (新) Pod Pod ReplicaSet (旧) Pod Pod
26. ReplicaSet / Deployment • Podをまとめて管理するための仕組み • ReplicaSet: 同じ内容のPodを指定個数立てる • Deployment: ReplicaSetを使い安全にバージョン移行 Deployment ReplicaSet (新) Pod Pod
27. ReplicaSet Service • 同じ内容のPod群に、均等に通信を振り分ける (L4LB) • Pod群を1つのIPアドレスでまとめることができる Pod Pod Pod Service
28. ReplicaSet Service • 同じ内容のPod群に、均等に通信を振り分ける (L4LB) • Pod群を1つのIPアドレスでまとめることができる Pod Pod Pod Service
29. ReplicaSet Service • 同じ内容のPod群に、均等に通信を振り分ける (L4LB) • Pod群を1つのIPアドレスでまとめることができる Pod Pod Pod Service Podの入れ替わりで 各PodのIPが変わっても 安定した仮想IPで アクセスできる
30. Serviceのタイプ Pod Pod Service ClusterIP Service NP / LB クラスタ外 クラスタ内 • ClusterIP: クラスタ内からの通信のみ受け付ける • NodePort / LoadBalancer: クラスタ外からの通信も 受け付ける
31. Kubernetesの実態: 宣言的API と Reconciliation Loop
32. 宣言的なAPI • 「これをして下さい」でなく「この状態にして下さい」 ◦ 「マニフェスト」で理想の状態を書く • 暗黙知のない 安定した稼働
33. Reconciliation Loop • リソースを理想の状態に持っていくための操作 理想の状態 実際の状態 Controller 比較 変更
34. Reconciliation Loop • 以下の操作を一定時間ごとに繰り返す ◦ 理想の状態 (宣言されたマニフェスト) を取得 ◦ 実際の状態を観測 ◦ 理想の状態と実際の状態を比較 ◦ 2つの差を埋めるように、実際の状態を変更する • Controllerと呼ばれる部品がこれを担当する • Self-Healingが簡単に実装できる
35. 例: DeploymentがPodになるまで • 単純なReconciliation Loopの積み重ねで複雑性を実現 Deployment ReplicaSet 比較 変更 Pod ReplicaSet Controller 変更 比較 Deployment Controller
36. 宣言された理想の状態を保存し Reconciliation Loopを回す ただそれだけのシステム ベースのアイデアは非常に単純
37. 覚えておいてもらいたいこと • K8sは拡張性が高いが、ネットワークの視点で見たとき 重要なリソースは少ない ◦ ほとんどの内部通信は、PodからServiceを経由し Podへ流れる • 宣言的APIとReconciliation LoopがK8sの核 ◦ K8sのネットワークもこの二つに準じて設定される 必要がある ◦ 手続き的な物を宣言的にする実装が必要
38. アジェンダ • イントロダクション • Kubernetesを知る ←イマココ • Kubernetesとネットワーク • Linuxのネットワークスタック • L2/L3ネットワーク: CNI • L4ロードバランサー: kube-proxy • プラットフォームとの対話で広がる可能性 • まとめ
39. アジェンダ • イントロダクション • Kubernetesを知る • Kubernetesとネットワーク ←イマココ • Linuxのネットワークスタック • L2/L3ネットワーク: CNI • L4ロードバランサー: kube-proxy • プラットフォームとの対話で広がる可能性 • まとめ
40. Kubernetesと ネットワーク
41. Pod Kubernetesを流れる通信 3種 • Pod → Service → Pod ◦ クラスタ内通信 ◦ ノード内とノード間を考慮する必要がある Service Pod
42. Kubernetesを流れる通信 3種 • 外部 → Service → Pod ◦ クラスタ外からのIngress通信 ◦ Gateway API (L7LB) というリソースとの関わりが 深いが、本プログラムでは割愛 Service クラスタ外 Pod
43. Kubernetesを流れる通信 3種 • Pod → 外部 ◦ クラスタ外へのEgress通信 ◦ Podからのインターネット疎通を保証する クラスタ外 Pod
44. Kubernetesを構成する部品たち https://kubernetes.io/docs/concepts/overview/components/ より引用 k
45. Kubernetesを構成する部品たち • K8sがデフォルトで用意してないものもある k CNI コンテナランタイム
46. ネットワークを担当する部品たち • CNI と kube-proxy k コンテナランタイム CNI
47. ネットワークを担当する部品たち • CNI ◦ Pod → Pod / Pod → 外部 を担当 ◦ PodのL2/L3ネットワーク疎通を担保する ◦ Kubernetesのデフォルト実装はない • kube-proxy ◦ Service → Pod / 外部 → Service を担当 ◦ 複数Podに対するL4LB (Service) を実装する ◦ Kubernetesがデフォルト実装を用意している
48. ここからは それぞれの部品の詳細と 実装を見ていきます どのように「架け橋」が用意されているかにご注目下さい
49. アジェンダ • イントロダクション • Kubernetesを知る • Kubernetesとネットワーク ←イマココ • Linuxのネットワークスタック • L2/L3ネットワーク: CNI • L4ロードバランサー: kube-proxy • プラットフォームとの対話で広がる可能性 • まとめ
50. アジェンダ • イントロダクション • Kubernetesを知る • Kubernetesとネットワーク • Linuxのネットワークスタック ←イマココ • L2/L3ネットワーク: CNI • L4ロードバランサー: kube-proxy • プラットフォームとの対話で広がる可能性 • まとめ
51. Linuxの ネットワークスタック
52. それぞれの詳細を見る前に まずは前提知識となる Linuxのネットワークをおさらい LinuxのSDNを一度俯瞰してみましょう
53. Network Namespace (netns) • Linuxの機能のうちの一つ • 1台のマシンの中に独立した仮想のホストを作る • netns1つにつき、1マシンと考えてよい ◦ Podの (ネットワーク的な) 実体 ◦ それぞれ個別に、NICを生やしたりIP/MACアドレス を持たせたりできる
54. Network Namespace (netns) Node NIC
55. Network Namespace (netns) Node Pod1 NIC
56. Network Namespace (netns) Node Pod1 Pod2 NIC
57. Network Namespace (netns) Node Pod1 Pod2 これら全てが ホストと異なるNICリストや ネットワーク設定を持つ NIC
58. 実は、親マシンのネットワークも… Node Host Namespace Pod1 Pod2 NIC
59. 実は、親マシンのネットワークも… Node Root Namespace Pod1 Pod2 NIC 親マシンというHWの枠に (親マシン自身のNWも含め) 区切られたネットワークが たくさんあるイメージ
60. 実は、親マシンのネットワークも… Node Root Namespace Pod1 Pod2 NIC 親マシンというHWの枠に (親マシン自身のNWも含め) 区切られたネットワークが たくさんあるイメージ ハードウェアの境界線と ネットワークの境界線が 別物になるということ
61. veth • Linux内で仮想的に作られるイーサネットケーブル ◦ 繋がったNICのペアとして生成される • これによりnetns同士を接続することが可能になる NIC NIC
62. veth Node Host Namespace Pod1 Pod2 NIC
63. veth Node Host Namespace Pod1 Pod2 NIC
64. veth Node Host Namespace Pod1 Pod2 NIC 移動
65. Linux Bridge • 仮想L2スイッチ ◦ 複数のvethを接続すると、接続されたnetns同士の Ethernet疎通・ARP解決ができるようになる • Linuxの都合で、host namespaceと接続されたNICが あらかじめ生成される bridge
66. Linux Bridge Node Host Namespace Pod1 Pod2 NIC
67. Linux Bridge Node Host Namespace Pod1 Pod2 NIC bridge
68. Linux Bridge Node Host Namespace Pod1 Pod2 NIC bridge
69. ip-route • netnsが持つルーティングテーブル ここまでの機能を合わせて使うと、1台の親マシンの中で 複雑なサブネット構造も作ることができる
70. Node ex) 複雑なサブネット構造 Host NS 192.168.1.0/24 192.168.2.0/24 NIC1 NIC2 NIC0 destiation next hop 192.168.1.0/24 NIC1 192.168.2.0/24 NIC2 0.0.0.0/0 NIC0
71. netfilter • パケットをフィルタ・加工・転送できる仕組み ◦ Filter ▪ 特定のIPアドレス・ポート宛のパケットを落とす ◦ NAT ▪ 送り元・送り先のIPアドレス・ポートを変更する • 操作方法 (フロントエンド) ◦ 長らくiptablesを使って設定されていたが、非推奨に ◦ 後継のnftablesへの移行が進んでいる
72. アジェンダ • イントロダクション • Kubernetesを知る • Kubernetesとネットワーク • Linuxのネットワークスタック ←イマココ • L2/L3ネットワーク: CNI • L4ロードバランサー: kube-proxy • プラットフォームとの対話で広がる可能性 • まとめ
73. アジェンダ • イントロダクション • Kubernetesを知る • Kubernetesとネットワーク • Linuxのネットワークスタック • L2/L3ネットワーク: CNI ←イマココ • L4ロードバランサー: kube-proxy • プラットフォームとの対話で広がる可能性 • まとめ
74. L2/L3ネットワーク: CNI
75. CNI • Container Network Interface • Podを何らかのネットワークに参加させるための仕組み
76. CNIはKubernetesだけじゃない！ • 意外と多くのコンテナ基盤がCNIにネットワーク機能を 移譲している
77. CNIはKubernetesだけじゃない！ • 意外と多くのコンテナ基盤がCNIにネットワーク機能を 移譲している Containerd (ただの コンテナランタイム) からもCNIは使える！
78. 余談: CNIは (実質) Kubernetesだけ • DockerやPodmanなど、多くの人がローカルで使うコン テナランタイムは、独自のドライバを使って管理する ◦ Containerd (Dockerの中身) を直接触る人は少ない • 実際のユースケースは、ほぼKubernetesか類似のオー ケストレーションサービス • Kubernetesのネットワークのメンテナーも「CNIはK8s に特化した仕組みじゃないのに、ほぼK8sからしか使わ れない」と言っている
79. 広義「CNI」 とは • CNI仕様 (containernetworkinterface/cni) ◦ コンテナ基盤がどのようにプラグインを呼び出すか の定義 • 基盤の要件定義 ◦ 基盤としてどんなネットワークが欲しいのか • CNIプラグイン ◦ CNI仕様を通して操作が可能で、基盤の要件定義を 満たす実際のネットワーク実装
80. CNI仕様
81. CNI仕様 • プラグインが満たすべきユーザーとのインターフェース が定められている ◦ 設定方法 ◦ 操作方法 ◦ 複数CNIの連携
82. CNI仕様 - 操作コマンド • CNIプラグインは5つのサブコマンドを備えたバイナリ として実装される必要がある ◦ ADDコマンド ◦ DELコマンド ◦ CHECKコマンド - 現在の状態を確認 ◦ GCコマンド - いらないリソースを掃除 ◦ VERSIONコマンド • 特に大事なのがADDとDEL
83. CNI仕様 - 操作コマンド • ADDコマンド ◦ コンテナにIPアドレスを割り当てる ◦ 指定されたコンテナを、用意されたコンテナネット ワークの中に参加させる Pod Pod Pod Pod
84. CNI仕様 - 操作コマンド • DELコマンド ◦ 指定されたコンテナをネットワークから削除する Pod Pod Pod Pod
85. CNI仕様 • 逆に言えば、この2つのコマンドが処理できればCNI プラグインとして動く ◦ BashでCNIプラグインを作った人もいます • Kubernetesの場合CNIのコア機能をデーモンで作動させ エントリーポイントになるバイナリを別途用意し、そこ からデーモンのAPIを叩きにいく構成が多い ◦ 複雑なネットワークライフサイクルに対処するため
86. 基盤の要件定義
87. 基盤側の要件定義 • コンテナ基盤によって必要な要件は違う • 例: ローカル環境 ◦ 同一ホスト内でコンテナ同士の疎通が取れる ◦ コンテナから外部ネットワークに出られる
88. The Kubernetes network model • 各Podはクラスタ内で唯一のIPアドレスを持つ • ホストの同じ/異なるに関わらず、NAT無しでPod同士 の通信ができる • Podから外部ネットワークに出れる https://kubernetes.io/docs/concepts/services-networking/
89. The Kubernetes network model すなわち、CNIがやらなければいけないことは • PodにユニークなIPアドレスを割り当てる • 同じクラスターのPod同士が、ホストの同じ/異なるに関 わらず、NATなしで通信できるようにする • Podから外部ネットワークに通信できるようにする
90. CNIという仕様が担保する「自由」 • 逆に、これらが実現できれば使う手法はなんでも良い ◦ これからいくつか例を見ていくが、千差万別 • CNI仕様はどんなネットワーク技術でも受け入れる広い 受け皿 ◦ クラウド事業者が元々のネットワーク基盤を活用し やすいなど、様々なメリットがある
91. CNIプラグインとその実装
92. メジャーなOSSプラグイン • Flannel ◦ ノードを跨ぐPod間通信にVXLANを使用したCNI • Calico ◦ 各ノードの持つPod CIDRをBGPで広報するCNI • Cilium ◦ ノード内の通信にeBPFを活用したCNI この3つを例に、それぞれのデフォルトの通信方式がどのよ うに疎通性を実現しているか見ていきましょう
93. Flannel - 同じノード内 下準備 Node Host NS
94. Flannel - 同じノード内 下準備: Linux Bridgeを作る Node Host NS bridge
95. Node Flannel - 同じノード内 Pod作成時 Host NS bridge Pod
96. Node Flannel - 同じノード内 Pod作成時: Linux Bridgeに接続 Host NS bridge Pod
97. Node Flannel - 同じノード内 通信時: L2で接続されるので、NAT無しでL3疎通が通る Host NS Pod Pod bridge
98. Flannel - 異なるノード間 下準備: 同じノード内の下準備が終わった段階 Node1 Host NS Node2 Host NS
99. Flannel - 異なるノード間 下準備: 各ノードでVTEPを作り、VXLANで接続 Node1 Host NS Node2 Host NS VXLAN VXLAN
100. Flannel - 異なるノード間 下準備: 各ノードに固有のサブネットを割り当てる Node1 - 10.1.1.0/24 Host NS Node2 - 10.1.2.0/24 Host NS VXLAN VXLAN
101. Flannel - 異なるノード間 下準備: 各ノードに固有のサブネットを割り当てる Node1 - 10.1.1.0/24 Host NS Node2 - 10.1.2.0/24 Host NS VXLAN VXLAN Pod全体のIPレンジは 10.1.0.0/16とする
102. Flannel - 異なるノード間 下準備: 各ノードに固有のサブネットを割り当てる Node1 - 10.1.1.0/24 Host NS Node2 - 10.1.2.0/24 Host NS VXLAN VXLAN このサブネットで どのノードにいるPodなのか 判別する
103. Flannel - 異なるノード間 下準備: ルーティングテーブルにエントリを追加 Node1 - 10.1.1.0/24 Host NS Node2 - 10.1.2.0/24 Host NS VXLAN VXLAN destiation next hop 10.1.1.0/24 Bridge 10.1.0.0/16 VTEP destiation next hop 10.1.2.0/24 Bridge 10.1.0.0/16 VTEP
104. Flannel - 異なるノード間 Pod作成時 Node1 - 10.1.1.0/24 Host NS Node2 - 10.1.2.0/24 Host NS VXLAN VXLAN Pod Pod
105. Flannel - 異なるノード間 Pod作成時: ノードのIPレンジからアドレスを割り当てる Node1 - 10.1.1.0/24 Host NS Node2 - 10.1.2.0/24 Host NS VXLAN VXLAN Pod - 10.1.1.1 Pod - 10.1.2.1
106. Flannel - 異なるノード間 通信時: 10.1.1.1から10.1.2.1へ送る時 Node1 - 10.1.1.0/24 Host NS Node2 - 10.1.2.0/24 Host NS VXLAN VXLAN Pod - 10.1.1.1 Pod - 10.1.2.1
107. Flannel - 異なるノード間 通信時: デフォルトゲートウェイとなっているHost NSへ Node1 - 10.1.1.0/24 Host NS Node2 - 10.1.2.0/24 Host NS VXLAN VXLAN Pod - 10.1.1.1 Pod - 10.1.2.1
108. Flannel - 異なるノード間 通信時: ルーティングテーブルを確認 Node1 - 10.1.1.0/24 Host NS Node2 - 10.1.2.0/24 Host NS VXLAN VXLAN Pod - 10.1.1.1 Pod - 10.1.2.1 destiation next hop 10.1.1.0/24 Bridge 10.1.0.0/16 VTEP
109. Flannel - 異なるノード間 通信時: next hopのVTEPからVXLAN経由でNode2へ送信 Node1 - 10.1.1.0/24 Host NS Node2 - 10.1.2.0/24 Host NS VXLAN VXLAN Pod - 10.1.1.1 Pod - 10.1.2.1
110. Flannel - 異なるノード間 通信時: ルーティングテーブルを確認 Node1 - 10.1.1.0/24 Host NS Node2 - 10.1.2.0/24 Host NS VXLAN VXLAN Pod - 10.1.1.1 Pod - 10.1.2.1 destiation next hop 10.1.2.0/24 Bridge 10.1.0.0/16 VTEP
111. Flannel - 異なるノード間 通信時: next hopのBridgeを経由し、宛先に到達 Node1 - 10.1.1.0/24 Host NS Node2 - 10.1.2.0/24 Host NS VXLAN VXLAN Pod - 10.1.1.1 Pod - 10.1.2.1
112. Flannel - Podから外部ネットワーク Node NetfilterでIPマスカレードをして外部に出す Pod Pod bridge Host NS
113. Flannel - Podから外部ネットワーク Node NetfilterでIPマスカレードをして外部に出す Pod Pod bridge Host NS
114. Flannel - Podから外部ネットワーク Node NetfilterでIPマスカレードをして外部に出す Pod Pod bridge Host NS netfilter
115. Flannel - Podから外部ネットワーク Node NetfilterでIPマスカレードをして外部に出す Pod Pod bridge Host NS
116. Flannel - 特徴まとめ • 同じノード内でのL3疎通 ◦ Linux Bridgeで全てのPodをL2接続する • 異なるノード間のL3疎通 ◦ VXLANを用いて別ノードにパケットを丸ごと輸送す るオーバーレイネットワーク ▪ 余談) WireguardなどVPNで輸送するモードも • サブネットでノードを見分ける • netfilterでIPマスカレードする
117. Calico - 同じノード内 下準備: Flannelと同じくノードにサブネットを割り当て Node1 - 10.1.1.0/24 Host NS
118. Node1 - 10.1.1.0/24 Calico - 同じノード内 Host NS Pod 10.1.1.1 Pod作成時
119. Node1 - 10.1.1.0/24 Calico - 同じノード内 Host NS Pod 10.1.1.1 Pod作成時: vethでHost Namespaceと直接接続 NIC1
120. Node1 - 10.1.1.0/24 Calico - 同じノード内 Host NS Pod 10.1.1.1 Pod作成時: ルーティングテーブルにエントリを追加 NIC1 destiation next hop 10.1.1.1/32 NIC1
121. Calico - 同じノード内 通信時: スタティックルーティングでL3疎通が通る Node1 - 10.1.1.0/24 Host NS Pod 10.1.1.1 NIC1 destiation next hop 10.1.1.1/32 NIC1 10.1.1.2/32 NIC2 Pod 10.1.1.2 NIC2
122. Calico - 異なるノード間 下準備: 同じノード内の下準備が終わった段階 Node1 - 10.1.1.0/24 Host NS Node2 - 10.1.2.0/24 Host NS
123. Calico - 異なるノード間 下準備: BIRD (ルーターソフトウェア) でBGPピアを張る Node1 - 10.1.1.0/24 Host NS Node2 - 10.1.2.0/24 Host NS BIRD BIRD
124. Calico - 異なるノード間 下準備: BIRD (ルーターソフトウェア) でBGPピアを張る Node1 - 10.1.1.0/24 Host NS Node2 - 10.1.2.0/24 Host NS BIRD BIRD デフォルトでは全てのノードが フルメッシュで張る 別途ルーターを用意すれば ハブ & スポークもOK
125. Calico - 異なるノード間 下準備: 自分のノードのPodサブネットを互いに広報する Node1 - 10.1.1.0/24 Host NS Node2 - 10.1.2.0/24 Host NS BIRD BIRD destiation next hop 10.1.1.0/24 lo destiation next hop 10.1.2.0/24 lo
126. Calico - 異なるノード間 下準備: 自分のノードのPodサブネットを互いに広報する Node1 - 10.1.1.0/24 Host NS Node2 - 10.1.2.0/24 Host NS BIRD BIRD destiation next hop 10.1.1.0/24 lo destiation next hop 10.1.2.0/24 lo
127. Calico - 異なるノード間 下準備: 自分のノードのPodサブネットを互いに広報する Node1 - 10.1.1.0/24 Host NS Node2 - 10.1.2.0/24 Host NS BIRD BIRD destiation next hop 10.1.1.0/24 lo 10.1.2.0/24 Node2 destiation next hop 10.1.2.0/24 lo 10.1.1.0/24 Node1
128. Calico - 異なるノード間 Pod作成時: 追加操作は特になし Node1 - 10.1.1.0/24 Node2 - 10.1.2.0/24 Pod - 10.1.1.1 Pod - 10.1.2.1 Host NS Host NS BIRD BIRD NIC1 NIC1
129. Calico - 異なるノード間 Node1 - 10.1.1.0/24 Node2 - 10.1.2.0/24 Pod - 10.1.1.1 Pod - 10.1.2.1 Host NS Host NS BIRD BIRD NIC1 NIC1 通信時: 10.1.1.1から10.1.2.1へ送る時
130. Calico - 異なるノード間 Node1 - 10.1.1.0/24 Node2 - 10.1.2.0/24 Pod - 10.1.1.1 Pod - 10.1.2.1 Host NS Host NS BIRD BIRD NIC1 NIC1 通信時: デフォルトゲートウェイとなっているHost NSへ
131. Calico - 異なるノード間 Node1 - 10.1.1.0/24 Node2 - 10.1.2.0/24 Pod - 10.1.1.1 Pod - 10.1.2.1 Host NS Host NS BIRD BIRD 通信時: ルーティングテーブルを確認 NIC1 NIC1 destiation next hop 10.1.1.1/32 NIC1 10.1.1.0/24 lo 10.1.2.0/24 Node2
132. Calico - 異なるノード間 Node1 - 10.1.1.0/24 Node2 - 10.1.2.0/24 Pod - 10.1.1.1 Pod - 10.1.2.1 Host NS Host NS BIRD BIRD 通信時: アンダーレイから直接、next hopのNode2へ送信 NIC1 NIC1
133. Calico - 異なるノード間 Node1 - 10.1.1.0/24 Node2 - 10.1.2.0/24 Pod - 10.1.1.1 Pod - 10.1.2.1 Host NS Host NS BIRD BIRD 通信時: ルーティングテーブルを確認 NIC1 NIC1 destiation next hop 10.1.2.1/32 NIC1 10.1.2.0/24 lo 10.1.1.0/24 Node1
134. Calico - 異なるノード間 Node1 - 10.1.1.0/24 Node2 - 10.1.2.0/24 Pod - 10.1.1.1 Pod - 10.1.2.1 Host NS Host NS BIRD BIRD NIC1 NIC1 通信時: next hopのNIC1から宛先に到達
135. Calico - Podから外部ネットワーク Flannel同様、NetfilterでIPマスカレードをして外部に出す Node1 - 10.1.1.0/24 Host NS Pod 10.1.1.1 NIC1 Pod 10.1.1.2 NIC2 netfilter
136. Calico - 特徴まとめ • 同じノード内でのL3疎通 ◦ スタティックルーティングする • 異なるノード間のL3疎通 ◦ BGPで経路を広報、直接相手ノードに送るPure L3 ▪ オーバーレイよりも高効率 ◦ 【制約】ノード間が1hopで繋がる必要がある ▪ ノード間接続がL2かIPIPのどちらか • それ以外はFlannel同様
137. Cilium - 同じノード内 下準備: 前二つと同じくノードにサブネットを割り当て Node1 - 10.1.1.0/24 Host NS
138. Node1 - 10.1.1.0/24 Cilium - 同じノード内 Host NS Pod 10.1.1.1 Pod作成時
139. Node1 - 10.1.1.0/24 Cilium - 同じノード内 Host NS Pod 10.1.1.1 Pod作成時: vethでHost Namespaceと直接接続 NIC1
140. Node1 - 10.1.1.0/24 Cilium - 同じノード内 Host NS Pod 10.1.1.1 Pod作成時: Host側のNICにeBPFがアタッチされる NIC1
141. Node1 - 10.1.1.0/24 Cilium - 同じノード内 Host NS Pod 10.1.1.1 Pod作成時: 別Podも同様 NIC1 Pod 10.1.1.2 NIC2
142. Node1 - 10.1.1.0/24 Cilium - 同じノード内 Host NS Pod 10.1.1.1 NIC1 Pod 10.1.1.2 NIC2 通信時: 10.1.1.1から10.1.1.2へ送る時
143. Node1 - 10.1.1.0/24 Cilium - 同じノード内 Host NS Pod 10.1.1.1 NIC1 Pod 10.1.1.2 NIC2 通信時: デフォルトゲートウェイとなっているHost NSへ
144. Node1 - 10.1.1.0/24 Cilium - 同じノード内 Host NS Pod 10.1.1.1 NIC1 Pod 10.1.1.2 NIC2 通信時: パケットがNICに着くとeBPFプログラムが起動
145. Node1 - 10.1.1.0/24 Cilium - 同じノード内 Host NS Pod 10.1.1.1 NIC1 Pod 10.1.1.2 NIC2 通信時: 宛先MACを宛先PodのMACに書き換える
146. Node1 - 10.1.1.0/24 Cilium - 同じノード内 Host NS Pod 10.1.1.1 NIC1 Pod 10.1.1.2 NIC2 通信時: eBPFの機能でNIC2に直接転送
147. Node1 - 10.1.1.0/24 Cilium - 同じノード内 Host NS Pod 10.1.1.1 NIC1 Pod 10.1.1.2 NIC2 通信時: あとはそのまま宛先Podへ
148. Cilium - 異なるノード間 • Ciliumは、同じノードのPod宛でなければ、eBPFプログ ラムを抜けてLinux側に処理を投げる • Ciliumはあらかじめ、異なるノード間のパケット転送の ために以下のいずれかを用意する ◦ Overlayモード: Flannelと同じVXLANを使う転送 ◦ Nativeモード: Calicoと同じBGP広報を使う転送 • すなわち、Ciliumの異なるノード間疎通はFlannelか Calicoと全く同じ仕組みで行われる
149. Cilium - Podから外部ネットワーク eBPFでIPマスカレードをして外部に出す Node1 - 10.1.1.0/24 Host NS Pod 10.1.1.1 NIC1 Pod 10.1.1.2 NIC2 NIC0
150. • 同じノード内でのL3疎通 ◦ eBPFを使って高速にルーティングを行う • 異なるノード間のL3疎通 ◦ Flannel / Calicoと同じ仕組みを使う ◦ 外からノードに入ってきたパケットは「同じノード 内での疎通」と同じくeBPFでPodまで運ばれる • eBPFでIPマスカレードする Cilium - 特徴まとめ
151. ところで: 汎用的 ≠ それだけでいい • これらのOSSは汎用を目指している ◦ どんな環境でも動くように、一般的な仕組みのみを 利用して実装をしている • メジャーなOSSプラグインは、どんな所でも使える汎用 性の代わりにオーバーヘッドを許容している ◦ 特にオーバーレイは顕著に遅い ◦ SDNはそれなりにノードに処理を要求する
152. 環境によって効率の良い形は違う • なぜCNIはKubernetesにデフォルトで組み込まれずわざ わざインターフェースになっているのか ◦ クラウドベンダーが自社のネットワークに合わせて 効率の良い処理基盤を組むため • CNIの魅力は、実装が完全にユーザー依存であること ◦ オンプレ環境でネットワークが全部わかるなら、 それに効率化するに越したことはない
153. 環境特化なCNIのインセンティブ • 既存のアンダーレイネットワークに最適化したい ◦ 既にBGP/EVPN/VRF等、成熟した基盤があるとき • 既存の運用・監視・障害対応フローに合わせたい ◦ 既存の監視基盤に乗せられる形でメトリクス・イベ ント・トレースを最初から設計したい • Podをもっとシームレスに繋ぎたい ◦ 既存のネットワークと深く統合するとVMとPodが シームレスに繋がったりする
154. 環境特化なCNIプラグインの例 • GKE Dataplane V2 ◦ GKEでデフォルトになっているプラグイン • AWS VPC CNI ◦ EKSで使える、VPCをベースにしたプラグイン • Coil on Neko ◦ Cybozuが開発しているプラグイン それぞれの概要を軽く見ていきましょう
155. GKE Dataplane V2 • GKEの開発チームがCiliumをカスタマイズしたもの • 同じノード内でのL3疎通 ◦ Ciliumの仕組みをそのまま用いる • 異なるノード間のL3疎通 ◦ 準備: アンダーレイネットワークに設定を流し込む ◦ 同ノード内のPod宛でなければそのまま外に出す ◦ アンダーレイネットワークがルーティングする
156. GKE Dataplane V2 - 異なるノード間 Pod作成時: アンダーレイネットワークに設定を流し込む Node1 Pod1 Host NS NIC1 Node1 Pod2 Host NS NIC1
157. GKE Dataplane V2 - 異なるノード間 Pod作成時: アンダーレイネットワークに設定を流し込む Node1 Pod1 Host NS NIC1 Node1 Pod2 Host NS NIC1 Pod1、Pod2の 経路情報をCNIが教える
158. GKE Dataplane V2 - 異なるノード間 Pod作成時: アンダーレイネットワークに設定を流し込む Node1 Pod1 Host NS NIC1 Node1 Pod2 Host NS NIC1 Pod1、Pod2の 経路情報をCNIが教える このような仕組みで ただパケットを外に出すだけで 勝手に相手がいるノードに 届く状態が実現される
159. Amazon VPC CNI • AWS VPCとの連携に非常に強いCNI • VPCの中からPodのIPアドレスが割り当てられる ◦ ノードの固定サブネットが無いので、アドレス空間 の効率良い利用ができる • 疎通性の確保もVPCを通して行われる ◦ 詳細はあまり公開されていない • 同じVPC内にいれば、VM等と直接通信ができる
160. Coil • CybozuでNeko基盤を作っているチームが開発している オープンソースのCNI • Neko基盤内では、Cilium & BIRDと組み合わせて運用 • 同じノード内でのL3疎通 ◦ Ciliumの仕組みをそのまま用いる • 異なるノード間のL3疎通 ◦ Calicoと同じくBIRDからBGPで経路広報するが、 アンダーレイネットワークに経路を流す
161. Coil - 異なるノード間 Node1 Host NS Node1 Host NS 下準備: BIRDでアンダーレイネットワークとBGPピアを張る BIRD BIRD
162. Coil - 異なるノード間 Node1 Host NS Node1 Host NS 下準備: Podサブネットを全体で互いに広報する BIRD BIRD
163. CNIはどんな実装も受け入れる 柔軟な思想の表れであり 様々な実装がある 皆さんも馴染みのある技術が多かったのでは
164. アジェンダ • イントロダクション • Kubernetesを知る • Kubernetesとネットワーク • Linuxのネットワークスタック • L2/L3ネットワーク: CNI ←イマココ • L4ロードバランサー: kube-proxy • プラットフォームとの対話で広がる可能性 • まとめ
165. アジェンダ • イントロダクション • Kubernetesを知る • Kubernetesとネットワーク • Linuxのネットワークスタック • L2/L3ネットワーク: CNI • L4ロードバランサー: kube-proxy ←イマココ • プラットフォームとの対話で広がる可能性 • まとめ
166. L4ロードバランサー: kube-proxy
167. ReplicaSet 【復習】Service • 同じ内容のPod群に、均等に通信を振り分ける (L4LB) • Pod群を1つのIPアドレスでまとめることができる Pod Pod Pod Service
168. kube-proxy • Serviceを担当するコンポーネント • Kubernetesがデフォルトで持っている • kube-proxyのやる事 ◦ 宛先IPアドレスがServiceの通信があったら、所属 する任意PodのIPでDNATする ◦ 書き換え先のPodのバランスをいい感じにする
169. kube-proxyの実装方式 • 基本的にはnetfilterを利用してNATしている ◦ kube-proxyは保存されているServiceの定義を監視 してNATルールを流し込むだけ ◦ 実際にプロキシしているわけではない • 現在のデフォルト: iptablesを通して設定 • これから: nftablesへの移行が進む (現在ベータ)
170. kube-proxy Node Pod Pod A Pod B Service
171. kube-proxy Node Pod A Pod B Pod src: Pod dst: Service Service
172. kube-proxy Node Pod A Pod B Pod でも実際の マシンは無い src: Pod dst: Service Service
173. kube-proxy Node Pod A Pod B Pod src: Pod dst: Service Service netfilter なんとか します！
174. kube-proxy Node Pod A Pod B Pod Service src: Pod dst: Service Pod A netfilter 監視
175. kube-proxy Node Pod A Pod B Pod Service src: Pod dst: Pod A
176. kube-proxy Node Pod A Pod B Service src: Pod dst: Pod A Pod ここまでやれば あとはCNIの仕事
177. kube-proxy Node Pod A Pod B Service Pod src: Pod dst: Pod B
178. kube-proxy Node Pod A Pod B Service src: Pod dst: Pod B Pod kube-proxyの役目は Serviceに属するどこかの PodにDNATするだけ
179. 【復習】Serviceのタイプ Pod Pod Service ClusterIP Service NP / LB クラスタ外 クラスタ内 • ClusterIP: クラスタ内からの通信のみ受け付ける • NodePort / LoadBalancer: クラスタ外からの通信も 受け付ける
180. 外部から通信を受け付けるService • NodePort ◦ 30000-32767のうち1つのポートを割り当て、全 ノードでそのポート宛の通信を受け取る • LoadBalancer ◦ Nodeportと同じ環境をそろえる ◦ 外部L4LBと連携しクラスタ外からアクセスできるIP アドレスを割り当て、LBから ↑ で用意したポート にロードバランシングする
181. Type: NodePort Service LB 監視 Pod netfilter Pod netfilter
182. Type: NodePort Service LB ポートを1つ 割り当て そこからの通信を キャッチする 監視 Pod Pod netfilter netfilter
183. Type: NodePort Service LB 監視 Pod Pod netfilter netfilter クラスタ外
184. Type: LoadBalancer Service LB 監視 Pod Pod netfilter netfilter 外部L4LB
185. Type: LoadBalancer Service LB 監視 Pod Pod netfilter netfilter 外部L4LB
186. Type: LoadBalancer Service LB 監視 Pod Pod netfilter netfilter 外部L4LB クラスタ外から アクセス可能な IPアドレスを 割り当て
187. Type: LoadBalancer Service LB 監視 Pod Pod netfilter netfilter 外部L4LB クラスタ外
188. 外部L4LB • Type: LoadBalancer用の外部L4LBは、Kubernetesが デフォルトで用意していないコンポーネント ◦ 既存の基盤に合わせて選定 or 自作の必要がある • 実装例 ◦ MetalLB ▪ オンプレ環境を想定した汎用OSS ◦ AWS Load Balancer Controller ▪ AWSのNLBを使った実装
189. アジェンダ • イントロダクション • Kubernetesを知る • Kubernetesとネットワーク • Linuxのネットワークスタック • L2/L3ネットワーク: CNI • L4ロードバランサー: kube-proxy ←イマココ • プラットフォームとの対話で広がる可能性 • まとめ
190. アジェンダ • イントロダクション • Kubernetesを知る • Kubernetesとネットワーク • Linuxのネットワークスタック • L2/L3ネットワーク: CNI • L4ロードバランサー: kube-proxy • プラットフォームとの対話で広がる可能性 ←イマココ • まとめ
191. プラットフォームとの 対話で広がる可能性
192. 環境特化なネットワークを選択肢に！ • メジャーなOSSは、どんな所でも使える汎用性の代わり にオーバーヘッドや複雑性を許容している ◦ SDNはそれなりにノードに処理を要求する ◦ 設定項目も多くなりがち • K8sのネットワークは差し替え可能な部分が多い ◦ 自分たちのネットワークの状態に合わせて、最適な ものを選ぶ/作ることができる！ • この実現のためには、対話が不可欠
193. プラットフォームと対話しよう • 特にCNIはお互いの責任を分割するツール • ブラックボックスから対話のための共通言語へ • 「どちらも触れない」から「どちらも触る」にしたい
194. 実はプラットフォーム方面の活動も… • 昨年11月にあった、Kubernetes等クラウドネイティブ なインフラに関するカンファレンスCNDW2025にて 「CNI徹底解説」というタイトルで登壇 • プラットフォームとネットワーク双方から「共通言語」 を広めるのが目標 ◦ 何か良いアイデアがあればぜひ教えて下さい
195. まとめ
196. 今日はこんなお話をしました • イントロダクション • Kubernetesを知る • Kubernetesとネットワーク • Linuxのネットワークスタック • L2/L3ネットワーク: CNI • L4ロードバランサー: kube-proxy • プラットフォームとの対話で広がる可能性 • まとめ
197. プラットフォームとの 「フラっと」な対話で 共にスケールする基盤を！ もっとたくさんの詳細があります、入口になれば幸い
198. ありがとう ございました 参考になれば幸いです
199. 【最後に】議論ポイント • 我々はプラットフォーム側の人間なので、ネットワーク エンジニアの視点を分かり切れていない • ネットワークとプラットフォームはどのように関われる かについて色んな意見が聞きたい ◦ ex) CNI選定の補助 ◦ ex) CNI改造・自作の判断基準、協力の仕方 ◦ ex) 責任分界点はどこに置くべきか ◦ ex) コンテナネットワークの未来のビジョン