Cloud Native Developers JP 整理しながら理解する Kubernetesネットワークの仕組み @hhiroshell 1

Cloud Native Developers JP 宣伝 • COVID-19が収束したら遊舎⼯房に⾏くんだ…！ 2 遊舎⼯房さんの店舗はこちら→ ↓現在の@hhiroshellのキーボード #crkbd ⾃⼰紹介 @hhiroshell 早川 博 （はやかわ ひろし） • Cloud Nativeなインフラを開発 するエンジニア。 Yahoo Japan Corporation 所属 • エンジニアコミュニティ 「Cloud Native Developers JP」 オーガナイザー • Developers Summit 2018 Japan Container Days 12.18 CloudNative Days Tokyo 2019 / 2020 登壇 • ⾃作キーボード沼

Cloud Native Developers JP ⽬次 1. イントロダクション 2. Kubernetesのネットワークのアーキテクチャ 3. Cluster Network 4. kubeletとCNIプラグイン 5. Service Network 6. まとめ 3

Cloud Native Developers JP ⽬次 1. イントロダクション 2. Kubernetesのネットワークのアーキテクチャ 3. Cluster Network 4. kubeletとCNIプラグイン 5. Service Network 6. まとめ 4

Cloud Native Developers JP 5 いろいろな⽤語が出てきて把握しきれない…。 Kubernetesのネットワークは難しい Services Ingress Endpoints Endpoint Slices iptables Container Network Interface CNI Plugin veth Bridge Flannel Calico kube-proxy kubelet User Space Proxy Mode VXLAN BGP Cluster Networking Service Discovery NIC NAT VPC Network Namespace IPAM IP Address Cluster IP CoreDNS Headless Service Load Balancer NodePort IPVS proxy mode Network Policy

Cloud Native Developers JP Cluster Networking …? • Kubernetesのネットワークモデル いきなり読んでもなかなか⾟い…。 6 Kubernetes imposes the following fundamental requirements on any networking implementation (barring any intentional network segmentation policies): 1. pods on a node can communicate with all pods on all nodes without NAT 2. agents on a node (e.g. system daemons, kubelet) can communicate with all pods on that node Note: For those platforms that support Pods running in the host network (e.g. Linux): 3. pods in the host network of a node can communicate with all pods on all nodes without NA “ ” ...

Cloud Native Developers JP このセッションのゴール • Kubernetesのネットワークの全体像を理解する • 様々な構成要素の役割と関係性を整理して把握する • ネットワーク周りの挙動について、裏の仕組みをなんとなくでも説 明できるようになる • ネットワーク周りのドキュメントの⾔っていることが理解できる様 になる。⾃⼒で学習を進められるようになる Kubernetesのネットワークの仕組みを完全に理解する [^1] 7 [^1]: ネットスラング的な意味の「完全に理解」の意 (c.f. https://twitter.com/ito_yusaku/status/1042604780718157824)

Cloud Native Developers JP ⽬次 1. イントロダクション 2. Kubernetesのネットワークのアーキテクチャ 3. Cluster Network 4. kubeletとCNIプラグイン 5. Service Network 6. まとめ 8

Cloud Native Developers JP Kubernetesのネットワークを俯瞰して⾒てみる 1. Node Network 2. Pod Network / Cluster Network 3. kubeletとCNIプラグイン 4. Service Network ⼤雑把に4つに分けて考えるとよさそう 9 Node Node Node NIC NIC NIC Pod Pod Pod VNIC VNIC VNIC Pod Pod Pod VNIC VNIC VNIC Pod Pod Pod VNIC VNIC VNIC kubelet + CNI Plugin kubelet + CNI Plugin kubelet + CNI Plugin

Cloud Native Developers JP 1/4: Node Network • Kubernetesを構成するNodeが接続するネットワーク – インフラによって実態は異なる • ベアメタル、クラウドプロバイダが提供する仮想ネットワーク、...etc 10 Node Node Node NIC NIC NIC Pod Pod VNIC VNIC Pod Pod Pod VNIC VNIC VNIC Pod Pod Pod VNIC VNIC VNIC kubelet + CNI Plugin kubelet + CNI Plugin kubelet + CNI Plugin

Cloud Native Developers JP 2/4: Pod Network / Cluster Network • Node Network上にソフトウェア的に構成される論理ネットワーク – クラスター内の全Podが、互いのIPアドレスでNATなしで通信可能 • 他にも要件がある（後述） 11 Node Node Node NIC NIC NIC Pod Pod VNIC VNIC Pod Pod Pod VNIC VNIC VNIC Pod Pod Pod VNIC VNIC VNIC kubelet + CNI Plugin kubelet + CNI Plugin kubelet + CNI Plugin

Cloud Native Developers JP 3/4: kubeletとCNIプラグイン • PodをCluster Networkに接続(?)させる役割を持つコンポーネント – kubeletがPodを起動するときにCNIプラグインを実⾏することでこれを⾏って いる 12 Node Node Node NIC NIC NIC Pod Pod Pod VNIC VNIC VNIC Pod Pod Pod VNIC VNIC VNIC Pod Pod Pod VNIC VNIC VNIC kubelet + CNI Plugin kubelet + CNI Plugin kubelet + CNI Plugin 接続 !

Cloud Native Developers JP Node Node Node NIC NIC NIC Pod Pod VNIC VNIC Pod Pod Pod VNIC VNIC VNIC Pod Pod Pod VNIC VNIC VNIC Pod VNIC ? 4/4: Service Network • Podに対する通信において、以下のような機能を提供する – 名前解決 – ロードバランシング – サービスディスカバリ 13 kubelet + CNI Plugin kubelet + CNI Plugin kubelet + CNI Plugin 例:ホスト名を名前解決。複数のPodにロードバランシング ホスト名: backend.sockshop.svc にアクセス

Cloud Native Developers JP いったんまとめ: Kubernetesネットワークの4つの要素 1. Node Network – Kubernetesを構成するNodeが接続するネットワーク 2. Pod Network / Cluster Network – Node Network上にソフトウェア的に構成される論理ネットワーク 3. kubeletとCNIプラグイン – PodをCluster Networkに接続(?)させる役割を持つコンポーネント 4. Service Network – 名前解決、ロードバランシング、サービスディスカバリ ⼤雑把に4つに分けて考えるとよさそう 14

Cloud Native Developers JP ⽬次 1. イントロダクション 2. Kubernetesのネットワークのアーキテクチャ 3. Cluster Network 4. kubeletとCNIプラグイン 5. Service Network 6. まとめ 15

Cloud Native Developers JP Cluster Network • Node Network上にソフトウェア的に構成される論理ネットワーク – 公式ドキュメントの中で “Cluster Networking” と呼ばれているモノ – クラスターを⾃⼒構築する場合、Flannel, Calicoなどのソフトウェアを使って構 築するのが⼀般的（Kubernetesの指定のものがあるわけではない） 16 Node Node Node NIC NIC NIC Pod Pod VNIC VNIC Pod Pod Pod VNIC VNIC VNIC Pod Pod Pod VNIC VNIC VNIC kubelet + CNI Plugin kubelet + CNI Plugin kubelet + CNI Plugin Pod VNIC

Cloud Native Developers JP 【再掲】Cluster Networking …! • Kubernetesのネットワークモデル 少しわかったような気がしてくる…？ 17 Kubernetes imposes the following fundamental requirements on any networking implementation (barring any intentional network segmentation policies): 1. pods on a node can communicate with all pods on all nodes without NAT 2. agents on a node (e.g. system daemons, kubelet) can communicate with all pods on that node Note: For those platforms that support Pods running in the host network (e.g. Linux): 3. pods in the host network of a node can communicate with all pods on all nodes without NAT “ ” ...

Cloud Native Developers JP • Flannel – Linux BridgeとVXLANによるカプセル化を組 み合わせて、Nodeをまたぐ通信を抽象化 – シンプルな実装⽅式だが、カプセル化の オーバーヘッドが性能に不利に働く – Network Policyには⾮対応 – 現RedHat / CoreOS主体で開発されている • https://github.com/coreos/flannel • https://coreos.com/flannel/docs/latest/ • Calico – BGPを利⽤するなどしてNodeをまたぐ通信 を実現 – パケットのカプセル化を⾏わない – Network Policyに対応 – ⽶Tigera社メインで開発 • https://github.com/projectcalico/calico • https://docs.projectcalico.org/about/about-calico 18 Cluster Networkの代表的な実装（個⼈の⾒解です）

Cloud Native Developers JP FlannelがどのようにCluster Networkを実現しているか • 全てのPodの仮想NICをLinux Bridgeに接続 • 各NodeでLinux Bridgeによってサブネットが構成される • Nodeをまたがる通信は、Flannelのデーモンプロセスによってカプセ ル化されて他Nodeに透過的に送信される 19 Node NIC Pod Pod veth0 Linux Bridge veth1 veth0 veth1 Pod veth3 veth3 Flannel daemon Node NIC Pod Pod veth0 Linux Bridge veth1 veth0 veth1 Pod veth3 veth3 Flannel daemon Node NIC Pod Pod veth0 Linux Bridge veth1 veth0 veth1 Pod veth3 veth3 Flannel daemon kubelet + CNI Plugin kubelet + CNI Plugin kubelet + CNI Plugin

Cloud Native Developers JP Nodeをまたがる通信の流れ • 別のNode上のPodのIPアドレスに向けてパケットを送信 20 Node NIC Pod Pod veth0 Linux Bridge veth1 veth0 veth1 Pod veth3 veth3 Flannel daemon Node NIC Pod Pod veth0 Linux Bridge veth1 veth0 veth1 Pod veth3 veth3 Flannel daemon Node NIC Pod Pod veth0 Linux Bridge veth1 veth0 veth1 Pod veth3 veth3 Flannel daemon kubelet + CNI Plugin kubelet + CNI Plugin kubelet + CNI Plugin 192.168.1.2 192.168.2.2 192.168.2.2

Cloud Native Developers JP Nodeをまたがる通信の流れ • Flannelのデーモンプロセスによって、宛先のPodが起動している Node宛てとなるようにヘッダを追加する（VXLANのカプセル化） 21 Node NIC Pod Pod veth0 Linux Bridge veth1 veth0 veth1 Pod veth3 veth3 Flannel daemon Node NIC Pod Pod veth0 Linux Bridge veth1 veth0 veth1 Pod veth3 veth3 Flannel daemon Node NIC Pod Pod veth0 Linux Bridge veth1 veth0 veth1 Pod veth3 veth3 Flannel daemon kubelet + CNI Plugin kubelet + CNI Plugin kubelet + CNI Plugin 192.168.1.2 192.168.2.2 192.168.2.2 192.168.254.12

Cloud Native Developers JP Nodeをまたがる通信の流れ • 宛先のノードにパケットが送られる 22 Node NIC Pod Pod veth0 Linux Bridge veth1 veth0 veth1 Pod veth3 veth3 Flannel daemon Node NIC Pod Pod veth0 Linux Bridge veth1 veth0 veth1 Pod veth3 veth3 Flannel daemon Node NIC Pod Pod veth0 Linux Bridge veth1 veth0 veth1 Pod veth3 veth3 Flannel daemon kubelet + CNI Plugin kubelet + CNI Plugin kubelet + CNI Plugin 192.168.1.2 192.168.2.2 192.168.2.2 192.168.254.12

Cloud Native Developers JP Nodeをまたがる通信の流れ • 宛先Node側のFlannelのデーモンプロセスによって、カプセル化が解 除される 23 Node NIC Pod Pod veth0 Linux Bridge veth1 veth0 veth1 Pod veth3 veth3 Flannel daemon Node NIC Pod Pod veth0 Linux Bridge veth1 veth0 veth1 Pod veth3 veth3 Flannel daemon Node NIC Pod Pod veth0 Linux Bridge veth1 veth0 veth1 Pod veth3 veth3 Flannel daemon kubelet + CNI Plugin kubelet + CNI Plugin kubelet + CNI Plugin 192.168.1.2 192.168.2.2 192.168.2.2

Cloud Native Developers JP Nodeをまたがる通信の流れ • パケットが⽬的のPodに届く 24 Node NIC Pod Pod veth0 Linux Bridge veth1 veth0 veth1 Pod veth3 veth3 Flannel daemon Node NIC Pod Pod veth0 Linux Bridge veth1 veth0 veth1 Pod veth3 veth3 Flannel daemon Node NIC Pod Pod veth0 Linux Bridge veth1 veth0 veth1 Pod veth3 veth3 Flannel daemon kubelet + CNI Plugin kubelet + CNI Plugin kubelet + CNI Plugin 192.168.1.2 192.168.2.2 192.168.2.2

Cloud Native Developers JP Cluster Networkのまとめ • Cluster Networkは、Node Network上に構成される論理ネットワーク • Flannel, CalicoなどのCluster Networkソリューションを利⽤して実現 • フラットにクラスター内のPodが接続された状態を作るなど、いくつかの Kubernetesの要件を満たす必要がある 25 Node Node Node NIC NIC NIC Pod Pod VNIC VNIC Pod Pod Pod VNIC VNIC VNIC Pod Pod Pod VNIC VNIC VNIC kubelet + CNI Plugin kubelet + CNI Plugin kubelet + CNI Plugin Pod VNIC

Cloud Native Developers JP ⽬次 1. イントロダクション 2. Kubernetesのネットワークのアーキテクチャ 3. Cluster Network 4. kubeletとCNIプラグイン 5. Service Network 6. まとめ 26

Cloud Native Developers JP kubeletとCNIプラグイン • PodをCluster Networkに接続(?)させる役割を持つコンポーネント – kubeletがPodを起動するときにCNIプラグインを実⾏することでこれを⾏って いる 27 Node Node Node NIC NIC NIC Pod Pod Pod VNIC VNIC VNIC Pod Pod Pod VNIC VNIC VNIC Pod Pod Pod VNIC VNIC VNIC kubelet + CNI Plugin kubelet + CNI Plugin kubelet + CNI Plugin 接続 !

Cloud Native Developers JP kubeletとCNIプラグインについてもう少し詳しく • kubelet – Podの起動/停⽌処理を担う、Worker Node内で稼働するデーモン – 与えられた設定ファイルの内容に従って、Pod起動/停⽌時などに同じNode上 にあるCNIプラグインを実⾏する • CNIプラグイン – Container Network Interface(CNI)仕様を満たすバイナリ – PodをCluster Networkに参加させるために必要な処理（後述）を実⾏する – CNIプラグインを実装することによって、Kubernetesクラスターを任意の Cluster Networkで構築できる（Cluster Networkソリューションを交換可能にする） kuberletがCNIプラグインを実⾏することで、PodがCluster Networkに参加する 28

Cloud Native Developers JP kubelet、CNIプラグイン、Cluster Networkの関係 • kubelet – 与えられた設定ファイルの内容に従って、 所定のCNIプラグインを実⾏ • CNIプラグイン – PodがCluster Networkに参加するために必要 な処理を実⾏ – Cluster Networkソリューションに対応した プラグインがある • Flannelにはflannel plugin、Calicoにはcalico plugin... • Cluster Networkに対応しないgeneralなプラグインも （例: bridge plugin（後述）） 29 Node NIC Pod Pod Pod VNIC VNIC VNIC k kubelet 例: flannel plugin 設定ファイル 実行！ Flannelで構成された Cluster Network PodをCluster Networkに参加させる

Cloud Native Developers JP CNIプラグインが⾏う処理をもう少し具体的に • CNIのドキュメントの“Overview”より 30 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. “ ” • つまり、だいたい以下のようなことをやっている – PodにNICをinsertする – Node上で必要な処理を⾏う（FlannelではLinux Bridgeにvethをアタッチする） – NICにIPアドレスを割り当てる（PodのIPアドレス）

Cloud Native Developers JP とあるKubernetesクラスタの中を⾒てみる 1/3 • kubeletの起動フラグで設定ファイルとCNIプラグインの場所を指定 31 # Node内で実行 jitomee@k8s-node:~$ ps -fA | grep kubelet root 17055 1 1 11:33 ? 00:05:31 /usr/bin/kubelet ...(snip)... ¥ --network-plugin=cni ¥ # ←cniプラグインを使う場合に指定。デフォルトは”docker” --cni-conf-dir=/etc/cni/net.d ¥ # ←デフォルト値と同じ --cni-bin-dir=/opt/cni/bin # ←デフォルト値と同じ jitomee@k8s-node:~$ ls /etc/cni/net.d 10-flannel.conflist jitomee@k8s-node:~$ ls /opt/cni/bin bandwidth bridge dhcp firewall flannel host-device host-local ipvlan loopback macvlan portmap ptp sbr static tuning vlan

Cloud Native Developers JP 2/3 • kubeletの設定ファイル – flannelプラグインの実⾏を指⽰ – flannelプラグインは、Flannel Daemonの構成情報を読み込んで、 その内容に基づいて他のプラグイ ンを実⾏する – デフォルトではbridge pluginに delegateされる 32 jitomee@k8s-node:~$ cat /etc/cni/net.d/10-flannel.conflist { "name": "cbr0", "cniVersion": "0.3.1", "plugins": [ { “type”: “flannel”, # flannel pluginを実行 “delegate”: { # delegate先に渡す追加パラメータ # typeがないのでbridge pluginを実行 "hairpinMode": true, "isDefaultGateway": true } }, { "type": "portmap", "capabilities": { "portMappings": true } } ] }

Cloud Native Developers JP 3/3 • flannel pluginがbridge pluginに 渡している設定ファイル – デフォルトで/var/lib/cni/flannel/ に出⼒ – bridge pluginはPodにNICを払い出 してLinux Bridgeにアタッチする – 更にipamプラグインをよんでIPア ドレスの割当を⾏っている 33 jitomee@k8s-node:~$ cat sudo cat /var/lib/cni/flannel/8b..25 { "cniVersion": "0.3.1", “type”: “bridge” # bridge pluginを実行する "ipMasq": false, “ipam”: { # IPアドレスの割当て。内容はFlannel Daemonの # 構成情報をflannel pluginが渡してきたもの "routes": [ { "dst": "192.168.0.0/16" } ], "subnet": "192.168.1.0/24", "type": "host-local" }, “hairpinMode”: true, "isDefaultGateway": true, "isGateway": true, "mtu": 1450, "name": "cbr0", }

Cloud Native Developers JP Flannelプラグインの動き（ここまでの話を図解） • flannel pluginは、Flannel Daemonの設定を渡しながら、 他のCNIプラグインを実⾏して いくことでその役割を果たし ている 34 Node NIC Pod Pod Pod k kubelet flannel plugin 設定ファイル 実行！ bridge plugin ipam plugin (host-local) 実行! 実行! VNICを払い出して Bridgeに接続 Linux Bridge veth0 veth1 veth3 Flannel daemon IPアドレスを 割当て 設定ファイル 設定を 参照 veth0 veth1 veth3

Cloud Native Developers JP KubeletとCNIプラグインのまとめ • kubeletは与えられた設定ファイルの内容に 従って、所定のCNIプラグインを実⾏する • CNIプラグインはPodがCluster Networkに参加 するために必要な処理を実⾏ • Cluster Networkソリューションに対応したプ ラグインがある – Flannelにはflannel plugin – Calicoにはcalico plugin – 他にbridge pluginのようにGeneralなものも • 複数のプラグインが連鎖することで全機能が 実現される 35 Node NIC Pod Pod Pod VNIC VNIC VNIC k kubelet 例: flannel plugin 設定ファイル 実行！ Flannelで構成された Cluster Network PodをCluster Networkに参加させる

Cloud Native Developers JP ⽬次 1. イントロダクション 2. Kubernetesのネットワークのアーキテクチャ 3. Cluster Network 4. kubeletとCNIプラグイン 5. Service Network 6. まとめ 36

Cloud Native Developers JP Service Network • Service Networkがやってくれること – 所定のホスト名に対して名前解決して、ServiceのIPアドレスを得る – ServiceのIPアドレスに対してリクエストを送信するとロードバランスされる – ロードバランシングのメンバーは⾃動で追加・除外される 37 Node Node Node NIC NIC NIC Pod Pod VNIC VNIC Pod Pod Pod VNIC VNIC VNIC Pod Pod Pod VNIC VNIC VNIC Pod VNIC ホスト名: backend.sockshop.svc にアクセス ?

Cloud Native Developers JP Service Network • KubernetesのServiceリソース(Type: ClusterIP)によって以下のようなこ とが起きる 1. Serviceに対応するIPアドレスが払い出される 2. ServiceのIPアドレスに対して、所定のルールでホスト名が割り当てられ、ク ラスター内DNSにレコードが登録される 3. Serviceに対するアクセスが複数のPodに対してロードバランスされる 4. 配送先の追加、除外が⾃動的に⾏われる 38 [^1]: この資料中ではHeadless Service（ {.spec.clusterIP} に “none” を指定したService）は対象外としますmm

Cloud Native Developers JP Serviceによる配送の実態（iptablesプロキシモード）1/2 • kube-proxyがAPI Serverにある Endpoint / EndpointSliceリソース をウォッチ • Serviceリソースの記述内容に合 わせてNode上のiptablesを更新 – Service IPを、ロードバランス対象の PodのいずれかのIPに変換するように ルールを記述する – ロードバランスメンバーの追加・除 外もiptablesの更新で実現 kube-proxyとiptablesによってロードバランシングとサービスディスカバリを実現 39 Node NIC Pod Pod veth0 Linux Bridge veth1 veth0 veth1 Pod veth3 veth3 Flannel daemon kp kube-proxy iptables API Server edit 宛先変換ルール Endpoint or EndpointSlice watch

Cloud Native Developers JP Serviceによる配送の実態（iptablesプロキシモード）2/2 • Birdgeでiptableの宛先変換ルール が適⽤され、いずれかのPodに配 送される kube-proxyとiptablesによってロードバランシングとサービスディスカバリを実現 40 Node NIC Pod Pod veth0 Linux Bridge veth1 veth0 veth1 Pod veth3 veth3 Flannel daemon kp kube-proxy iptables API Server watch edit 宛先変換ルール 10.106.232.14 -> 192.168.2.2 Endpoint or EndpointSlice

Cloud Native Developers JP 【参考】Proxy mode • usersupace プロキシモード: – v1.1までのデフォルト – kube-proxyがトラフィックの配送に割り込む – userspace / kernelspaceのスイッチが発⽣するので、パフォーマンスと信頼性において iptableに⽐べて不利とされている • iptables プロキシモード: – v1.2+のデフォルト – iptablesを更新しておいて、あとのルーティングはカーネルに任せる • ipvs プロキシモード: – IPVSカーネルモジュールを利⽤する – iptablesに⽐べ⾼スループットで、⾼度なルーティングアルゴリズムをサポートする 41

Cloud Native Developers JP Node クラスター内DNSによる名前解決 • Kubernetesクラスターにはアドオ ンとしてDNSサーバーがデプロイ される • Serviceリソースを作成すると所 定のDNSレコードが作成される • Pod内のコンテナは、クラスター 内DNSで名前解決するように設定 されている（この設定はkubelet が⾏っている） Kubernetesクラスター内で起動しているDNSサーバーを利⽤ 42 Node NIC Pod Pod Pod VNIC VNIC VNIC CoreDNS VNIC NIC k kubelet container /etc/resolv.conf

Cloud Native Developers JP 【参考】Pod内のコンテナの名前解決設定 • /etc/resolv.conf にクラスター内DNSを使うように設定される 43 # クラスター内のコンテナ上で /ect/resolv.conf を確認 jitomee@k8s-node:~$ kubectl exec -it busybox-example – ash / # cat /etc/resolv.conf nameserver 10.96.0.10 search default.svc.cluster.local svc.cluster.local cluster.local options ndots:5

Cloud Native Developers JP ホスト名の命名規則 • [Service].[Namespace].svc.cluster.local. – .svc.cluster.local.は省略可 [^1] – 同じNamespace内から通信する場合は、[Namespace] 以降をすべて省略可 [^1] – クラスタ内DNSにはAレコード（IPv6の場合AAAAレコード）が作成される • _[Port]._[Protocol].[Service].[Namespace].svc.cluster.local. – Serviceの {spec.ports.name} を指定した場合に、そのPort毎に作成される – クラスタ内DNSにはSRVレコードが作成される 44 [^1]: 省略は可能ですが、パフォーマンスの観点では完全修飾名を指定するのが良いと⾔われています。 (c.f. https://pracucci.com/kubernetes-dns-resolution-ndots-options-and-why-it-may-affect-application-performances.html)

Cloud Native Developers JP Service Networkのまとめ • Serviceを経由する通信では、ク ラスター内DNSで名前解決する • kube-proxyがiptablesを更新する ことで、ロードバランシングと サービスディスカバリを実現 45 Node NIC Pod Pod veth0 Linux Bridge veth1 veth0 veth1 Pod veth3 veth3 Flannel daemon kp kube-proxy iptables API Server Service / Endpoint watch edit 宛先変換ルール 10.106.232.14 -> 192.168.2.2

Cloud Native Developers JP ⽬次 1. イントロダクション 2. Kubernetesのネットワークのアーキテクチャ 3. Cluster Network 4. kubeletとCNIプラグイン 5. Service Network 6. まとめ 46

Cloud Native Developers JP 今⽇話したかったけど話せなかったこと • クラスター外からの通信の受け⼊れ – Service • Type: NodePort • Type: LoadBalancer – Ingress • Network Policyによるクラスター内通信の制御 • 道のりは⻑い。 • Kubernetesのネットワークを完全に理解したい⼈⽣だった…。 47

Cloud Native Developers JP まとめ 1. Node Network 2. Pod Network / Cluster Network 3. kubeletとCNIプラグイン 4. Service Network Kubernetesの⼤雑把に4つに分けて考えるとよさそう 48 Node Node Node NIC NIC NIC Pod Pod Pod VNIC VNIC VNIC Pod Pod Pod VNIC VNIC VNIC Pod Pod Pod VNIC VNIC VNIC kubelet + CNI Plugin kubelet + CNI Plugin kubelet + CNI Plugin

Cloud Native Developers JP Appendix. 参考⽂献 49

Cloud Native Developers JP 【参考⽂献 1/3】 • Kubernetes公式ドキュメント – Cluster Networking • https://kubernetes.io/docs/concepts/cluster-administration/networking/ – Service • https://kubernetes.io/docs/concepts/services-networking/service/ – DNS for Services and Pods • https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/ – Network Plugins • https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/ 50

Cloud Native Developers JP 【参考⽂献 2/3】 • CNI 関連 – CNI Documentation • https://www.cni.dev/docs/ – CNI Spec • https://github.com/containernetworking/cni/blob/spec-v0.4.0/SPEC.md – CNI Plugins • https://github.com/containernetworking/plugins 51

Cloud Native Developers JP 【参考⽂献 3/3】 • 有志のブログなど – Kubernetes pods /etc/resolv.conf ndots:5 option and why it may negatively affect your application performances • https://pracucci.com/kubernetes-dns-resolution-ndots-options-and-why-it-may-affect-application- performances.html – わかった気になるflannelの仕組み • https://qiita.com/bbrfkr/items/0b0a787f2e3c81009c28 – Kubernetesネットワーク徹底解説 • https://zenn.dev/taisho6339/books/fc6facfb640d242dc7ec/viewer/166890 – 拡張性の⾼いCNIプラグインCoil v2の紹介 • https://speakerdeck.com/ymmt2005/kuo-zhang-xing-falsegao-i-cni-puraguin-coil-v2-falseshao-jie – Kubernetes CNI 結局どれを使えばいいのか • https://speakerdeck.com/line_developers/kubernetes-cni-which-should-we-choose 52