Kubernetesネットワーキング初級者脱出ガイド / Kubernetes networking beginner's guide

by Kohei Ota

Slide 1

Slide 1 text

Kubernetesネットワーキング初級者脱出ガイド -基本から最新動向まで- Kohei Ota, Architect at HPE/CNCF Ambassador

Slide 2

Slide 2 text

© 2021 Cloud Native Computing Foundation 2 自己紹介 Kohei Ota (@inductor) •アーキテクト@HPE •CNCF Ambassador •Google Developer Expert (GCP) •CloudNative Days Tokyo 運営 •Container Runtime Meetup 運営 •Kubernetes SIG-Docs Japanese owner •Docker Meetup Tokyo 運営

Slide 3

Slide 3 text

© 2021 Cloud Native Computing Foundation 3 Table of Contents Dockerネットワークの基本 DockerとKubernetesのネットワーク的な違い Kubernetesネットワークの構成要素 kube-proxyのはたらきと、Kubernetes Networkingのスケーラビリティに関する議論 Service APIとCloud Provider コンテナネイティブ・ロードバランシング Gateway APIについて

Slide 4

Slide 4 text

Dockerネットワークの基本

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

© 2021 Cloud Native Computing Foundation 9 ネットワークとボリュームは外部割り当て? Volume Volume Volume Docker Volume Docker Container Docker Network docker0 bridge ローカルの80 仮想NIC 仮想NIC 仮想NIC 10.0.0.0/24 172.16.0.0/24 主に2つのモードがある - bridge - 指定がない場合にデフォルトで使用 - 所属するコンテナが直接通信でき、お手軽 - none - 「何も繋がない」ができる - loopback(127.0.0.1)デバイス以外に仮想 NICが繋がらないモード

Slide 10

Slide 10 text

© 2021 Cloud Native Computing Foundation 10 Dockerコンテナとネットワークの関係 ● コンテナはさまざまなリソースを隔離した結果生まれるもの ○ ネットワークもその１要素で、NICは付けたり付けなかったりできる ● Noneドライバーを用いた場合、ネットワーク的に隔離されたコンテナができあがる ● ブリッジの場合は仮想スイッチに順次接続されて相互接続ができる ○ Dockerの内部DNSも勝手に参加するので、コンテナ名がついていれば名前でDNSも引ける ○ 設定ファイルでdb:3306とかweb:80とかapp:3000みたいなことが書けるのはそのおかげ ○ 簡易的ではあるがいわゆる「サービスディスカバリ」の一種

Slide 11

Slide 11 text

DockerとKubernetesのネットワーク的な違い

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

© 2021 Cloud Native Computing Foundation 14 Kubernetesの3つの顔 Marketing Committee Technical Oversight Committee Governing Board End User Community Container Orchestration Distributed system Platform for Platforms • 複数の「ノード」を束ねるクラスタリング • 柔軟なジョブスケジューリング • Raftベースの分散KVS • 高速で簡単なスケーリング • ロードバランサーとの統合 • 柔軟で簡単なデプロイ手段 • インフラ基盤との強力な連携 • 拡張を前提に作られた APIやリソース • 大きなコミュニティとエコシステム

Slide 15

Slide 15 text

© 2021 Cloud Native Computing Foundation 15 Kubernetesの3つの顔 Marketing Committee Technical Oversight Committee Governing Board End User Community Container Orchestration Distributed system Platform for Platforms • 複数の「ノード」を束ねるクラスタリング • 柔軟なジョブスケジューリング • Raftベースの分散KVS • 高速で簡単なスケーリング • ロードバランサーとの統合 • 柔軟で簡単なデプロイ手段 • インフラ基盤との強力な連携 • 拡張を前提に作られた APIやリソース • 大きなコミュニティとエコシステム自立型の分散システム

Slide 16

Slide 16 text

© 2021 Cloud Native Computing Foundation 16 Kubernetesにおける自己復旧の仕組み Pod Pod Pod Pod network(overlay) Service Network(overlay) Node Network(not overlay) 普通のサーバーがつながるネットワーク ClusterIPなどサービス間の通信で使うネットワークコンテナ(Pod)自体に IPアドレスを持たせるためのネットワーク

Slide 17

Slide 17 text

© 2021 Cloud Native Computing Foundation 17 Kubernetesにおける自己復旧の仕組み Pod Pod Service Network(overlay) Node Network(not overlay) 普通のサーバーがつながるネットワーク ClusterIPなどサービス間の通信で使うネットワーク Nodeが障害を起こすと Podは自動で退避 Pod Podが入れ替わっても同じように動作する Pod network(overlay) コンテナ(Pod)自体に IPアドレスを持たせるためのネットワーク

Slide 18

Slide 18 text

© 2021 Cloud Native Computing Foundation 18 Kubernetesにおける自己復旧の仕組み Pod Pod Service Network(overlay) Node Network(not overlay) 普通のサーバーがつながるネットワーク ClusterIPなどサービス間の通信で使うネットワークコンテナ(Pod)自体に IPアドレスを持たせるためのネットワーク Nodeが障害を起こすと Podは自動で退避 Pod Podが入れ替わっても同じように動作する Pod network(overlay) どのノードで動いても同じように動作するためには、オーバーレイネットワークの存在がとても重要なのです！

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Kubernetesネットワークの構成要素

Slide 21

Slide 21 text

© 2021 Cloud Native Computing Foundation 21 Node Node Node Pod Pod Pod Pod Kubernetesネットワークの構成要素 Pod network(overlay) Service Network(overlay) Node Network(not overlay) 普通のサーバーがつながるネットワーク ClusterIPなどサービス間の通信で使うネットワークコンテナ(Pod)自体に IPアドレスを持たせるためのネットワーク veth veth veth veth eth0 eth0 eth0

Slide 22

Slide 22 text

© 2021 Cloud Native Computing Foundation 22 Node Node Node Pod Pod Pod Pod Kubernetesネットワークの構成要素 Pod network(overlay) Service Network(overlay) Node Network(not overlay) 普通のサーバーがつながるネットワーク ClusterIPなどサービス間の通信で使うネットワークコンテナ(Pod)自体に IPアドレスを持たせるためのネットワーク veth veth veth veth eth0 eth0 eth0 ここからどうやって中に繋がっていくのかよくわからんな🤔🤔🤔🤔

Slide 23

Slide 23 text

© 2021 Cloud Native Computing Foundation 23 AWS VPC LB経由のユーザートラフィックの流れ Node Node Node Pod Pod Pod Pod Pod network(overlay) Service Network(overlay) Load Balancer veth veth veth veth eth0 eth0 eth0 kube-proxy kube-proxy kube-proxy Service type: LoadBalancerで作成赤色のPodに行きたい CNI

Slide 24

Slide 24 text

© 2021 Cloud Native Computing Foundation 24 Node Node Node Pod Pod Pod Pod Kubernetesネットワークの構成要素: CNI Pod network(overlay) Service Network(overlay) Node Network(not overlay) veth veth veth veth eth0 eth0 eth0 CNI (Container Network Interface) 1. ノードネットワークの疎通性を担保 (VXLAN/BGP/クラウドのVPCなどのSDN) 2. Podに仮想NICを割当 3. PodのIPアドレスを割当

Slide 25

Slide 25 text

© 2021 Cloud Native Computing Foundation 25 CNIについて ● 外の世界のネットワークとKubernetesのネットワークをつなげる役割 ○ クラウドのVPCやノードの制御に使うBGP、あるいはVXLANなどのホストレベルのネットワークを認識できる ● 各Podに割り当てる仮想NICの管理 ○ コンテナ作成時にランタイムが作ったNW namespaceに対してvNICをアタッチ ● 各PodのIPアドレス管理(要するにIPAM) ○ コンテナは揮発性が高いので、CNIがIPAMのデーモンを管理してIPアドレスを管理し、Service のエンドポイント情報を書き換える

Slide 26

Slide 26 text

© 2021 Cloud Native Computing Foundation 26 いろいろなCNI ● kubenet ○ 参照実装なので利用例はまずない ● Flannel ○ VXLANによるオーバーレイネットワーク ○ 本番で使われるCNIの中では一番シンプル ○ NetworkPolicyの実装がない ● Calico ○ 最も人気&歴史がある ○ BGP(L3)ベースのネットワークでスケールしやすい ● Cilium ○ eBPFを用いた高パフォーマンス&スケーラブルなCNI ○ GKEでもサポートされている ● Amazon VPC CNI plugin

Slide 27

Slide 27 text

© 2021 Cloud Native Computing Foundation 27 Node Node Node Pod Pod Pod Pod Kubernetesネットワークの構成要素: kube-proxy Pod network(overlay) Service Network(overlay) Node Network(not overlay) veth veth veth veth eth0 eth0 eth0 kube-proxy kube-proxy kube-proxy コンテナ間の通信を制御する kube-proxy(iptables/ipvs/eBPF実装)

Slide 28

Slide 28 text

© 2021 Cloud Native Computing Foundation 28 kube-proxyについて ● ClusterIP Service(Kubernetesの内部LB)の実態 ○ Linuxの機能であるiptables/ipvsのいずれかを使ってNWを制御する ● 各ホスト(ノード)に流入した通信をPodに通すかどうかの経路制御 ○ iptables実装の場合はフィルタや転送を組み合わせて使う ● NodePortやLoadBalancerによって外部から流入してきた通信を Endpoints(EndpointSlice)リソースに登録されたPod IPに転送 ○ kubectl describe svcで引くとサービスに紐付いたEndpointsの情報が出てくる

Slide 29

Slide 29 text

kube-proxyに関する議論

Slide 30

Slide 30 text

© 2021 Cloud Native Computing Foundation 30 kube-proxyはボトルネックになることが知られている ● kube-proxyで主流のiptables modeは、クラスター規模に比例してパフォーマンスが劣化することが知られている ● IPVSはハッシュテーブルのためスケーラビリティの問題は解消される ● eBPFによる代替実装が提案され、実際に一部のCNIで利用が始まっている

Slide 31

Slide 31 text

© 2021 Cloud Native Computing Foundation 31 eBPFによるkube-proxyの代替実装 ● Calico ○ リソース消費が減り、レイテンシが抑えられることが示されている ○ kube-proxyなしでDSRなどが実現できる ○ ただし現状はx86-64のみ利用可能でIPv6は未対応 ○ floating IPやSCTPなども使えない Ref. Enable the eBPF dataplane - Calico ● Cilium ○ カーネルのXDPを用いた高速化や、LoadBalancer Serviceのビルトインサポートがある ○ SCTPは使えない ○ kube-proxy代替実装を有効にするとClusterIPを外部に公開することができない ■ 最新版ではいけた Ref. Kubernetes Without kube-proxy — Cilium Ref. Replacing iptables with eBPF in Kubernetes with Cilium

Slide 32

Slide 32 text

Service APIとクラウドプロバイダー

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

© 2021 Cloud Native Computing Foundation 36 AWS VPC LB経由のユーザートラフィックの流れ Node Node Node Pod Pod Pod Pod Pod network(overlay) Service Network(overlay) ELB veth veth veth veth eth0 eth0 eth0 kube-proxy kube-proxy kube-proxy Service type: LoadBalancerで作成 1. LBに到達し任意のノードに振り分け赤色のPodに行きたい

Slide 37

Slide 37 text

© 2021 Cloud Native Computing Foundation 37 AWS VPC LB経由のユーザートラフィックの流れ Node Node Node Pod Pod Pod Pod Pod network(overlay) Service Network(overlay) ELB veth veth veth veth eth0 eth0 eth0 kube-proxy kube-proxy kube-proxy Service type: LoadBalancerで作成 2. kube-proxyに振り分けられ Podの所在を確認赤色のPodに行きたい

Slide 38

Slide 38 text

© 2021 Cloud Native Computing Foundation 38 AWS VPC LB経由のユーザートラフィックの流れ Node Node Node Pod Pod Pod Pod Pod network(overlay) Service Network(overlay) ELB veth veth veth veth eth0 eth0 eth0 kube-proxy kube-proxy kube-proxy Service type: LoadBalancerで作成 3. kube-proxyが通信を許可し Podに到達赤色のPodに行きたい

Slide 39

Slide 39 text

© 2021 Cloud Native Computing Foundation 39 AWS VPC LB経由のユーザートラフィックの流れ Node Node Node Pod Pod Pod Pod Pod network(overlay) Service Network(overlay) ELB veth veth veth veth eth0 eth0 eth0 kube-proxy kube-proxy kube-proxy Service type: LoadBalancerで作成 3. kube-proxyが通信を許可し Podに到達赤色のPodに行きたい Serviceリソースの type: LoadBalancer(外部LBとの連携) type: NodePort(どのノードからアクセスしても目的の Pod にアクセスできる) type: ClusterIP(kube-proxyによる経路制御/フィルタ) を順番にたどっていることがわかる

Slide 40

Slide 40 text

コンテナネイティブ・ロードバランシング

Slide 41

Slide 41 text

© 2021 Cloud Native Computing Foundation 41 AWS VPC LB経由のユーザートラフィックの流れ Node Node Node Pod Pod Pod Pod Pod network(overlay) Service Network(overlay) ELB veth veth veth veth eth0 eth0 eth0 kube-proxy kube-proxy kube-proxy Service type: LoadBalancerで作成さっきのこれ赤色のPodに行きたい

Slide 42

Slide 42 text

© 2021 Cloud Native Computing Foundation 42 AWS VPC LB経由のユーザートラフィックの流れ Node Node Node Pod Pod Pod Pod Pod network(overlay) Service Network(overlay) ELB veth veth veth veth eth0 eth0 eth0 kube-proxy kube-proxy kube-proxy Service type: LoadBalancerで作成本当だったらこうありたいですよね！赤色のPodに行きたい

Slide 43

Slide 43 text

© 2021 Cloud Native Computing Foundation 43 type: LoadBalancer標準実装の問題点 ● Node NetworkとService/Pod Networkが論理的に分断されている ○ ホップが余計に発生する ○ ロードバランサーがPodの所在を認識しないので、常に最適な経路を選択するのはムリ ● 外部LBを利用するケースの場合、Cluster IPによるルーティングを介さずに外部ネットワークからPodの所在が直接認識できるような経路制御がしたい・・・

Slide 44

Slide 44 text

© 2021 Cloud Native Computing Foundation 44 type: LoadBalancer標準実装の問題点 ● Node NetworkとService/Pod Networkが論理的に分断されている ○ ホップが余計に発生する ○ ロードバランサーがPodの所在を認識しないので、常に最適な経路を選択するのはムリ ● 外部LBを利用するケースの場合、Cluster IPによるルーティングを介さずに外部ネットワークからPodの所在が直接認識できるような経路制御がしたい・・・そこでコンテナネイティブ・ロードバランシングですよ奥さん！

Slide 45

Slide 45 text

© 2021 Cloud Native Computing Foundation 45 コンテナネイティブ・ロードバランシングとは ● クラウドのVPCが持つCIDRブロックを用いてService Network範囲とPod Network範囲を管理 ● それぞれのルーティングテーブルもクラウド側で管理 ○ ロードバランサーから直接Podに通信を向けることができる ● でもそんなのKubernetesのアーキテクチャ的に可能なの？ ○ CNIの図を思い出してみてください

Slide 46

Slide 46 text

© 2021 Cloud Native Computing Foundation 46 コンテナネイティブ・ロードバランシングとは ● クラウドのVPCが持つCIDRブロックを用いてService Network範囲とPod Network範囲を管理 ● それぞれのルーティングテーブルもクラウド側で管理 ○ ロードバランサーから直接Podに通信を向けることができる ● でもそんなのKubernetesのアーキテクチャ的に可能なの？ ○ CNIの図を思い出してみてください

Slide 47

Slide 47 text

© 2021 Cloud Native Computing Foundation 47 コンテナネイティブ・ロードバランシングとは ● クラウドのVPCが持つCIDRブロックを用いてService Network範囲とPod Network範囲を管理 ● それぞれのルーティングテーブルもクラウド側で管理 ○ ロードバランサーから直接Podに通信を向けることができる ● でもそんなのKubernetesのアーキテクチャ的に可能なの？ ○ CNIの図を思い出してみてくださいできそう

Slide 48

Slide 48 text

パブリッククラウドにおけるコンテナネイティブ・ロードバランシングの実装例

Slide 49

Slide 49 text

© 2021 Cloud Native Computing Foundation 49 AWSでの実装 ● AWSのVPC CNIが持つL-IPAMがPodのIP CIDRを管理してENIのセカンダリアドレスプールにアタッチ ● ALB(L7)とNLB(L4)のIPモードを使うとVPCのアドレスに直接ターゲットグループを向けられる ○ AWS LoadBalancer Controllerによる拡張

Slide 50

Slide 50 text

© 2021 Cloud Native Computing Foundation 50 GCPでの実装 ● GKEのCNIは公開されていないが、IPAMの仕組みを持っている ○ VPC Native clusterを指定して作るとVPCのサブネット範囲からService/Pod addressを割り当てられる ● LoadBalancer利用時にGCPのNEGを指定することでPodの向き先をNEGに管理させることができる

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Gateway APIについて

Slide 53

Slide 53 text

© 2021 Cloud Native Computing Foundation 53 Gateway APIとは ● 外部からのアクセスやトラフィックを管理するためのネットワークモデルを定義したKubernetesの拡張仕様 ● SIG-Networkが主導となって現在進行系で仕様を決めている ● イメージとしては既存のServiceリソース、Ingressリソースをより分かりやすく体系化しまとめなおしたもの ○ GatewayClass、Gateway、TCPRoute、HTTPRoute、Service などからなり、Istioなどが作ってきた仕組みもふまえつつKubernetesの外部ネットワーク周りを再整理

Slide 54

Slide 54 text

© 2021 Cloud Native Computing Foundation 54 Gateway APIとは ● 外部からのアクセスやトラフィックを管理するためのネットワークモデルを定義したKubernetesの拡張仕様 ● SIG-Networkが主導となって現在進行系で仕様を決めている ● イメージとしては既存のServiceリソース、Ingressリソースをより分かりやすく体系化しまとめなおしたもの ○ GatewayClass、Gateway、TCPRoute、HTTPRoute、Service などからなり、Istioなどが作ってきた仕組みもふまえつつKubernetesの外部ネットワーク周りを再整理

Slide 55

Slide 55 text

© 2021 Cloud Native Computing Foundation 55 なぜ再定義？ ● 既存のIngress、Serviceは基盤運用者と利用者(開発者やSRE)の棲み分けが曖昧 ○ 基盤運用者: トラフィックの入り口であるLoadBalancer自体の管理 ○ 利用者: 利用可能なLBを使って特定プロトコルでサービスへ流入したい ● IngressClassだけではロードバランサーのライフサイクルや細かいプロトコルの制御まで柔軟に管理していくのが難しい ○ そもそもIngressだけデフォでまともに使えないということ自体が今となっては厄介 → そこで、SIG-Networkを率いるGoogleのエンジニアなどを中心にGateway APIという名前でより拡張性の高い機能を提供できるようにしているのがこれ

Slide 56

Slide 56 text

© 2021 Cloud Native Computing Foundation 56 Gateway API利用の流れ基盤の運用者がGatewayClassをプロバイダとして提供 (既存のIngress controllerやCCMに含まれる Service controllerが等価) クラスタ管理者が、そのクラスタで利用可能な Gatewayを定義し作っておく(LBのフロントエンド部分だけ生やしておく) 開発者が利用可能なGatewayから特定のホスト名やパスに該当する通信をTCP/HTTPなどのプロトコルで自分のサービスに向ける

Slide 57

Slide 57 text

© 2021 Cloud Native Computing Foundation 57 Gateway APIはService/Ingress v2なのか？ ● 現時点でGateway APIが既存のService/Ingressを置き換える予定はない ○ ただし、GKEではAlphaのGateway APIを既に導入しており、かなり利用のモチベーションが高そうであることが分かる ○ Ingress実装の一つであるContourもGateway APIに追従している ○ その他いくつかのIngress controllerなどでも実装予定がありそう ● 現状すぐに導入しないといけないというわけではない ○ そもそもまだAlphaなので・・・ ○ Ingressとしては最大手のNginx Ingressでは未対応 ○ ただし、大規模組織では導入のメリットも大きいので、デザインについて知るのは大事

Slide 58

Slide 58 text

© 2021 Cloud Native Computing Foundation 58 Gateway APIはService/Ingress v2なのか？ ● 現時点でGateway APIが既存のService/Ingressを置き換える予定はない ○ ただし、GKEではAlphaのGateway APIを既に導入しており、かなり利用のモチベーションが高そうであることが分かる ○ Ingress実装の一つであるContourもGateway APIに追従している ○ その他いくつかのIngress controllerなどでも実装予定がありそう ● 現状すぐに導入しないといけないというわけではない ○ そもそもまだAlphaなので・・・ ○ Ingressとしては最大手のNginx Ingressでは未対応 ○ ただし、大規模組織では導入のメリットも大きいので、デザインについて知るのは大事

Slide 59

Slide 59 text

まとめ

Slide 60

Slide 60 text

© 2021 Cloud Native Computing Foundation 60 まとめ ● Kubernetesは分散システムを実現するために様々なコンポーネントを組み合わせて使っている ● Kubernetes側と基盤技術側で関心の分離を行うための仕組みがネットワークにも用意されている ● アップデートとともに、ボトルネックになる部分を解消すべく様々な取り組みが行われている ● 既存規格の再設計は難しい

Slide 61

Slide 61 text

© 2021 Cloud Native Computing Foundation 61 参考資料 ● Kubernetes The Hard Way ○ https://github.com/kelseyhightower/kubernetes-the-hard-way ○ 主にNodeごとにPod CIDRを分けないとiptables的にまずいみたいなところとか ● Kubernetesネットワーク徹底解説 ○ https://zenn.dev/taisho6339/books/fc6facfb640d242dc7ec ○ 主にGKEのネットワーク周り ● Kubernetes完全ガイド ○ 主にEndpointリソース周り ● SIG-Network Intro & Deep-dive ○ https://static.sched.com/hosted_files/kccncna20/57/KubeCon_NA_Virtual_2020-si g-net.pdf ○ https://static.sched.com/hosted_files/kccncna2021/ea/%5BPUBLIC%5D%20KubeC on_NA_2021_%20SIG-NETWORK%20update%20and%20directions.pdf ○ 主にGateway API周り

Slide 62

Slide 62 text

Thank you for your attention! The CNCF aims to help end users connect with other end users, recruit talent, and adopt cloud native successfully in a vendor neutral environment.