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

A talk at CloudNative Days Tokyo 2021

Transcript

1. Kubernetesネットワーキング初級者脱 出ガイド -基本から最新動向まで- Kohei Ota, Architect at HPE/CNCF Ambassador
2. © 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 運営
3. © 2021 Cloud Native Computing Foundation 3 Table of Contents Dockerネットワークの基本 DockerとKubernetesのネットワーク的な違い Kubernetesネットワークの構成要素 kube-proxyのはたらきと、Kubernetes Networkingの スケーラビリティに関する議論 Service APIとCloud Provider コンテナネイティブ・ロードバランシング Gateway APIについて
4. Dockerネットワークの基本
5. © 2021 Cloud Native Computing Foundation 5 Dockerのよくあるユースケース Docker Compose 80:80 3000 3306
6. © 2021 Cloud Native Computing Foundation 6 Dockerのよくあるユースケース Docker Compose 80:80 3000 3306 Webなので公開 アプリは 内部だけ DBは 内部だけ
7. © 2021 Cloud Native Computing Foundation 7 Dockerのよくあるユースケース 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
8. © 2021 Cloud Native Computing Foundation 8 ネットワークとボリュームは外部割り当て? 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
9. © 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が 繋がらないモード
10. © 2021 Cloud Native Computing Foundation 10 Dockerコンテナとネットワークの関係 • コンテナはさまざまなリソースを隔離した結果生まれるもの ◦ ネットワークもその１要素で、NICは付けたり付けなかったりできる • Noneドライバーを用いた場合、ネットワーク的に隔離された コンテナができあがる • ブリッジの場合は仮想スイッチに順次接続されて相互接続ができる ◦ Dockerの内部DNSも勝手に参加するので、コンテナ名がついていれば 名前でDNSも引ける ◦ 設定ファイルでdb:3306とかweb:80とかapp:3000みたいなことが 書けるのはそのおかげ ◦ 簡易的ではあるがいわゆる「サービスディスカバリ」の一種
11. DockerとKubernetesのネットワーク的な違い
12. © 2021 Cloud Native Computing Foundation 12 手元のKubernetesの中身を覗いてみる • 外部に公開しているLonghornのWeb UIは、TCPの80番で LoadBalancerがアタッチされている • でも、Dockerではポートの割り当てが発生していない ◦ なんで？
13. © 2021 Cloud Native Computing Foundation 13 手元のKubernetesの中身を覗いてみる • 外部に公開しているLonghornのWeb UIは、TCPの80番で LoadBalancerがアタッチされている • でも、Dockerではポートの割り当てが発生していない ◦ なんで？ こたえ: Dockerのネットワークを使っていないから！！！
14. © 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やリソース • 大きなコミュニティとエコシステム
15. © 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やリソース • 大きなコミュニティとエコシステム 自立型の分散システム
16. © 2021 Cloud Native Computing Foundation 16 Kubernetesにおける自己復旧の仕組み Pod Pod Pod Pod network(overlay) Service Network(overlay) Node Network(not overlay) 普通のサーバーがつながる ネットワーク ClusterIPなどサービス間の 通信で使うネットワーク コンテナ(Pod)自体に IPアドレスを持たせるためのネッ トワーク
17. © 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アドレスを持たせるためのネッ トワーク
18. © 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) どのノードで動いても同じように動作 するためには、オーバーレイネット ワークの存在がとても重要なので す！
19. © 2021 Cloud Native Computing Foundation 19 DockerとKubernetesのネットワーク的な違い • Dockerのネットワークはシングルホスト前提 • Kubernetesは複数ホストをまとめ上げて動作する事が前提の 「分散システム」である • コンテナや内部ロードバランサが透過的に動くための「オーバーレイネッ トワーク」が重要
20. Kubernetesネットワークの構成要素
21. © 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
22. © 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 ここからどうやって中に繋がっていく のかよくわからんな🤔🤔🤔🤔
23. © 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
24. © 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アドレスを割当
25. © 2021 Cloud Native Computing Foundation 25 CNIについて • 外の世界のネットワークとKubernetesのネットワークをつなげる役割 ◦ クラウドのVPCやノードの制御に使うBGP、あるいはVXLANなどのホストレベルの ネットワークを認識できる • 各Podに割り当てる仮想NICの管理 ◦ コンテナ作成時にランタイムが作ったNW namespaceに対してvNICをアタッチ • 各PodのIPアドレス管理(要するにIPAM) ◦ コンテナは揮発性が高いので、CNIがIPAMのデーモンを管理してIPアドレスを管理し、Service のエンドポイント情報を書き換える
26. © 2021 Cloud Native Computing Foundation 26 いろいろなCNI • kubenet ◦ 参照実装なので利用例はまずない • Flannel ◦ VXLANによるオーバーレイネットワーク ◦ 本番で使われるCNIの中では一番シンプル ◦ NetworkPolicyの実装がない • Calico ◦ 最も人気&歴史がある ◦ BGP(L3)ベースのネットワークでスケールしやすい • Cilium ◦ eBPFを用いた高パフォーマンス&スケーラブルなCNI ◦ GKEでもサポートされている • Amazon VPC CNI plugin
27. © 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実装)
28. © 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の情報が 出てくる
29. kube-proxyに関する議論
30. © 2021 Cloud Native Computing Foundation 30 kube-proxyはボトルネックになることが知られている • kube-proxyで主流のiptables modeは、 クラスター規模に比例してパフォーマンスが劣 化することが知られている • IPVSはハッシュテーブルのためスケーラビリ ティの問題は解消される • eBPFによる代替実装が提案され、実際に 一部のCNIで利用が始まっている
31. © 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
32. Service APIとクラウドプロバイダー
33. © 2021 Cloud Native Computing Foundation 33 Kubernetesにおけるクラウドリソースの管理
34. © 2021 Cloud Native Computing Foundation 34 Kubernetesにおけるクラウドリソースの管理 クラウドのAPIと通信して、LBaaSやIaaSなどを 管理するためのコントローラー
35. © 2021 Cloud Native Computing Foundation 35 c-c-mのわかりやすい利用例 • LoadBalancer ServiceをAmazon EKS上で作成すると、内部でCloud Provider AWSが作用してELBが作成される
36. © 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に行 きたい
37. © 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に行 きたい
38. © 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に行 きたい
39. © 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による経路制御/フィルタ) を順番にたどっていることがわかる
40. コンテナネイティブ・ロードバランシング
41. © 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に行 きたい
42. © 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に行 きたい
43. © 2021 Cloud Native Computing Foundation 43 type: LoadBalancer標準実装の問題点 • Node NetworkとService/Pod Networkが論理的に分断されている ◦ ホップが余計に発生する ◦ ロードバランサーがPodの所在を認識しないので、常に最適な経路を選択するのはムリ • 外部LBを利用するケースの場合、Cluster IPによるルーティングを介さずに 外部ネットワークからPodの所在が直接認識できるような経路制御が したい・・・
44. © 2021 Cloud Native Computing Foundation 44 type: LoadBalancer標準実装の問題点 • Node NetworkとService/Pod Networkが論理的に分断されている ◦ ホップが余計に発生する ◦ ロードバランサーがPodの所在を認識しないので、常に最適な経路を選択するのはムリ • 外部LBを利用するケースの場合、Cluster IPによるルーティングを介さずに 外部ネットワークからPodの所在が直接認識できるような経路制御が したい・・・ そこでコンテナネイティブ・ロードバランシングですよ奥 さん！
45. © 2021 Cloud Native Computing Foundation 45 コンテナネイティブ・ロードバランシングとは • クラウドのVPCが持つCIDRブロックを用いてService Network範囲とPod Network範囲を管理 • それぞれのルーティングテーブルもクラウド側で管理 ◦ ロードバランサーから直接Podに通信を向けることができる • でもそんなのKubernetesのアーキテクチャ的に可能なの？ ◦ CNIの図を思い出してみてください
46. © 2021 Cloud Native Computing Foundation 46 コンテナネイティブ・ロードバランシングとは • クラウドのVPCが持つCIDRブロックを用いてService Network範囲とPod Network範囲を管理 • それぞれのルーティングテーブルもクラウド側で管理 ◦ ロードバランサーから直接Podに通信を向けることができる • でもそんなのKubernetesのアーキテクチャ的に可能なの？ ◦ CNIの図を思い出してみてください
47. © 2021 Cloud Native Computing Foundation 47 コンテナネイティブ・ロードバランシングとは • クラウドのVPCが持つCIDRブロックを用いてService Network範囲とPod Network範囲を管理 • それぞれのルーティングテーブルもクラウド側で管理 ◦ ロードバランサーから直接Podに通信を向けることができる • でもそんなのKubernetesのアーキテクチャ的に可能なの？ ◦ CNIの図を思い出してみてください できそう
48. パブリッククラウドにおける コンテナネイティブ・ロードバランシングの実装例
49. © 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による拡張
50. © 2021 Cloud Native Computing Foundation 50 GCPでの実装 • GKEのCNIは公開されていないが、IPAMの仕組みを持っている ◦ VPC Native clusterを指定して作るとVPCのサブネット範囲からService/Pod addressを割り 当てられる • LoadBalancer利用時にGCPのNEGを指定することでPodの向き先をNEGに管理 させることができる
51. © 2021 Cloud Native Computing Foundation 51 オンプレではどうなの？ • SDNによるOverlay networkを使えば技術的には可能 ◦ 現実的にできるとは言ってない • 現状やろうとしているベンダーがいるのか未調査 ◦ F5 + Nginx ingressとかだといけるんだろうか・・・？
52. Gateway APIについて
53. © 2021 Cloud Native Computing Foundation 53 Gateway APIとは • 外部からのアクセスやトラフィックを管理するためのネットワークモデルを 定義したKubernetesの拡張仕様 • SIG-Networkが主導となって現在進行系で仕様を決めている • イメージとしては既存のServiceリソース、Ingressリソースをより分かりやすく体系化 しまとめなおしたもの ◦ GatewayClass、Gateway、TCPRoute、HTTPRoute、Service などからなり、Istioなどが 作ってきた仕組みもふまえつつKubernetesの外部ネットワーク周りを再整理
54. © 2021 Cloud Native Computing Foundation 54 Gateway APIとは • 外部からのアクセスやトラフィックを管理するためのネットワークモデルを 定義したKubernetesの拡張仕様 • SIG-Networkが主導となって現在進行系で仕様を決めている • イメージとしては既存のServiceリソース、Ingressリソースをより分かりやすく体系化 しまとめなおしたもの ◦ GatewayClass、Gateway、TCPRoute、HTTPRoute、Service などからなり、Istioなどが 作ってきた仕組みもふまえつつKubernetesの外部ネットワーク周りを再整理
55. © 2021 Cloud Native Computing Foundation 55 なぜ再定義？ • 既存のIngress、Serviceは基盤運用者と利用者(開発者やSRE)の棲み分けが曖昧 ◦ 基盤運用者: トラフィックの入り口であるLoadBalancer自体の管理 ◦ 利用者: 利用可能なLBを使って特定プロトコルでサービスへ流入したい • IngressClassだけではロードバランサーのライフサイクルや細かいプロトコルの制御 まで柔軟に管理していくのが難しい ◦ そもそもIngressだけデフォでまともに使えないということ自体が今となっては厄介 → そこで、SIG-Networkを率いるGoogleのエンジニアなどを中心にGateway APIとい う名前でより拡張性の高い機能を提供できるようにしているのがこれ
56. © 2021 Cloud Native Computing Foundation 56 Gateway API利用の流れ 基盤の運用者がGatewayClassをプロバイダと して提供 (既存のIngress controllerやCCMに含まれる Service controllerが等価) クラスタ管理者が、そのクラスタで利用可能な Gatewayを定義し作っておく(LBの フロントエンド部分だけ生やしておく) 開発者が利用可能なGatewayから特定のホスト名 やパスに該当する通信をTCP/HTTPなどの プロトコルで自分のサービスに向ける
57. © 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では未対応 ◦ ただし、大規模組織では導入のメリットも大きいので、デザインについて知るのは大事
58. © 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では未対応 ◦ ただし、大規模組織では導入のメリットも大きいので、デザインについて知るのは大事
59. まとめ
60. © 2021 Cloud Native Computing Foundation 60 まとめ • Kubernetesは分散システムを実現するために様々なコンポーネントを組み合わせ て使っている • Kubernetes側と基盤技術側で関心の分離を行うための仕組みがネットワークにも 用意されている • アップデートとともに、ボトルネックになる部分を解消すべく様々な取り組みが行われ ている • 既存規格の再設計は難しい
61. © 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周り
62. 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.