コンテナネイティブロードバランシングの話 / A story about container native load balancing

HPEのOpenSource Professionという社内勉強会で発表したときの資料です

Transcript

1. コンテナネイティブ ロードバランシングの話 Presented by @inductor
2. 自己紹介 名前: 太田 航平 (@inductor) 所属: HPE GreenLake Global COE 役職: アーキテクト Kubernetes SIG-Docs Japanese localization owner CNCF Ambassador Docker Meetup Tokyo、CloudNative Days運営
3. Kubernetesのネットワークは複雑
4. ていうか、そもそもコンテナの ネットワークが複雑！
5. 今日のゴール • Kubernetesの基本的なネットワークデザインについて理解できる • ↑の問題となる箇所がわかる • パブリッククラウドがどのように解決しているかがわかる → コンテナネットワーク完全に理解した
6. アジェンダ • Kubernetesのネットワーク • Kubernetesのネットワークを形作るコンポーネントとその役割 ◦ kube-proxy ◦ CNI ▪ よく使われるCNIの特徴 • Kubernetesネットワークにおける1つの課題 • コンテナネイティブロードバランシングの話 ◦ AWS、GCPでの解決法 • まとめ
7. Kubernetesのネットワーク
8. Kubernetesの仕組み • コンテナを中心とした「分散システム」 ◦ 複数のマシンリソース (物理/仮想マシン)をクラスターにまとめて、アプリケーションをいい感じに 動かす ◦ （設定次第だけど）どのマシンでコンテナが動いても「同じように」動作する必要がある → マシンの持つネットワークに依存しない透過的なネットワークが必要 それが理由で、Kubernetesのネットワークの基本はOverlay network構成
9. Kubernetesの仕組み Pod Pod Pod Pod network(overlay) Service Network(overlay) Node Network(not overlay) 普通のサーバーがつながる ネットワーク ClusterIPなどサービス間の 通信で使うネットワーク コンテナ(Pod)自体に IPアドレスを持たせるためのネッ トワーク kube-proxy CNI 各ホスト上のiptables/eBPF による ルーティング
10. Kubernetesの仕組み Pod Pod Pod Node Network(not overlay) Pod network(overlay) Service Network(overlay) 普通のサーバーがつながる ネットワーク ClusterIPなどサービス間の 通信で使うネットワーク コンテナ(Pod)自体に IPアドレスを持たせるためのネッ トワーク Podが入れ替わっても 同じように動作する Nodeが障害を起こすと Podは自動で退避 kube-proxy CNI 各ホスト上のiptables/eBPF による ルーティング
11. Kubernetesのネットワークコンポーネント • kube-proxy - 各ノードで動作 ◦ 各ノードでコンテナネットワークへの入り口を作る役割 ▪ 無いと、コンテナの外と中の経路が通らない ◦ Linuxのiptablesやipvsを利用(最近ではeBPFベースの実装もある ) ◦ Serviceの実装 ▪ https://github.com/kubernetes/kubernetes/blob/master/pkg/proxy/service.go • CNI(Container Network Interface) - クラスター全体で動作 ◦ Docker network driver相当のプラグイン機構を提供 ◦ Overlay Networkを提供 ◦ 外のネットワーク(プロトコル)とKubernetesのネットワークをつなげる ◦ 無いと、NodeのステータスがReadyにならない
12. Kubernetesのネットワークコンポーネント • kube-proxy ◦ 各ノードでコンテナネットワークへの入り口を作る役割 ◦ Linuxのiptablesやipvsを利用(最近ではeBPFベースの実装もある ) ◦ Serviceの実装 ▪ https://github.com/kubernetes/kubernetes/blob/master/pkg/proxy/service.go • CNI(Container Network Interface) ◦ Docker network driver相当のプラグイン機構を提供 ◦ クラスター全体のOverlay Networkを提供 ◦ 外のネットワーク(プロトコル)とKubernetesのネットワークをつなげる ◦ 無いと、NodeのステータスがReadyにならない
13. Kubernetesのネットワークコンポーネント • kube-proxy ◦ 各ノードでコンテナネットワークへの入り口を作る役割 ◦ Linuxのiptablesやipvsを利用(最近ではeBPFベースの実装もある ) ◦ Serviceの実装 ▪ https://github.com/kubernetes/kubernetes/blob/master/pkg/proxy/service.go • CNI(Container Network Interface) ◦ Docker network driver相当のプラグイン機構を提供 ◦ クラスター全体のOverlay Networkを提供 ◦ 外のネットワーク(プロトコル)とKubernetesのネットワークをつなげる ◦ 無いと、NodeのステータスがReadyにならない CNIでアタッチしたNIC kube-proxyでコンテナ外 からの通信を流す
14. いろいろなCNI • Calico ◦ 最も人気&歴史がある ◦ BGP(L3)ベースのネットワークでスケールしやすい • Cilium ◦ eBPFを用いた高パフォーマンス &スケーラブルなプラグイン ◦ 最近人気になってきた ◦ GKEでも最近導入がアナウンスされた • Weave Net • Amazon VPC CNI plugin
15. ここまでのまとめ • Kubernetesは複数マシンを束ねて動かすためにはOverlay networkを採用 • CNIはOverlay networkの構築と、Pod(コンテナ)にネットワークの機能を 与えるためのコンポーネント • kube-proxyは、ノードに流れてきたPod向け通信を向き先のPodに流す
16. Kubernetesネットワークにおける 1つの課題点
17. 172.0.0.0/16 192.168.0.0/16 10.0.0.0/16 CNI Node Node Node Pod Node Network(not overlay) 普通のNIC kube-proxy (iptables) kube-proxy (iptables) kube-proxy (iptables) Service Network(overlay) Pod network(overlay) Pod Pod 外部からのアクセス
18. 172.0.0.0/16 192.168.0.0/16 10.0.0.0/16 CNI Node Node Node Pod Node Network(not overlay) 普通のNIC kube-proxy (iptables) kube-proxy (iptables) kube-proxy (iptables) Service Network(overlay) Pod network(overlay) Pod Pod 外部からのアクセス
19. 172.0.0.0/16 192.168.0.0/16 10.0.0.0/16 CNI Node Node Node Pod Node Network(not overlay) 普通のNIC kube-proxy (iptables) kube-proxy (iptables) kube-proxy (iptables) Service Network(overlay) Pod network(overlay) Pod Pod 外部からのアクセス 1.ノードネットワークでのルー ティングとLB
20. 172.0.0.0/16 192.168.0.0/16 10.0.0.0/16 CNI Node Node Node Pod Node Network(not overlay) 普通のNIC kube-proxy (iptables) kube-proxy (iptables) kube-proxy (iptables) Service Network(overlay) Pod network(overlay) Pod Pod 外部からのアクセス 1.ノードネットワークでのルー ティングとLB 2.サービスネットワークでの ルーティングとLB
21. 172.0.0.0/16 192.168.0.0/16 10.0.0.0/16 CNI Node Node Node Pod Node Network(not overlay) 普通のNIC kube-proxy (iptables) kube-proxy (iptables) kube-proxy (iptables) Service Network(overlay) Pod network(overlay) Pod Pod 外部からのアクセス 1.ノードネットワークでのルー ティングとLB 2.サービスネットワークでの ルーティングとLB ホップ数が多い・・・ そのうえ こっちはデータセンター側の ネットワークで負荷分散 こっちはKubernetes内部の ネットワークで負荷分散
22. 172.0.0.0/16 192.168.0.0/16 10.0.0.0/16 CNI Node Node Node Pod Node Network(not overlay) 普通のNIC kube-proxy (iptables) kube-proxy (iptables) kube-proxy (iptables) Service Network(overlay) Pod network(overlay) Pod Pod 外部からのアクセス
23. 172.0.0.0/16 192.168.0.0/16 10.0.0.0/16 CNI Node Node Node Pod Node Network(not overlay) 普通のNIC kube-proxy (iptables) kube-proxy (iptables) kube-proxy (iptables) Service Network(overlay) Pod network(overlay) Pod Pod 外部からのアクセス 必ずしも最適化された ネットワーク経路になると は限らないんだなぁ
24. そこで、コンテナネイティブ ロードバランシングが登場！
25. Kubernetesのネットワークコンポーネント • kube-proxy - 各ノードで動作 ◦ 各ノードでコンテナネットワークへの入り口を作る役割 ▪ 無いと、コンテナの外と中の経路が通らない ◦ Linuxのiptablesやipvsを利用(最近ではeBPFベースの実装もある ) ◦ Serviceの実装 ▪ https://github.com/kubernetes/kubernetes/blob/master/pkg/proxy/service.go • CNI(Container Network Interface) - クラスター全体で動作 ◦ Docker network driver相当のプラグイン機構を提供 ◦ Overlay Networkを提供 ◦ 外のネットワーク(プロトコル)とKubernetesのネットワークをつなげる ◦ 無いと、NodeのステータスがReadyにならない SDNとうまく連携すれば さっきの問題が解決できる
26. Node Node Node Pod クラウドのロードバランサー | Node Network(not overlay) kube-proxy (iptables) kube-proxy (iptables) kube-proxy (iptables) Service Network(overlay) Pod network(overlay) Pod Pod 外部からのアクセス クラウドのVPC 192.168.1.0/24 192.168.2.0/24 192.168.0.0/24 アドレスプールもルーティング テーブルも全部 VPCの資産で管理
27. Node Node Node Pod クラウドのロードバランサー | Node Network(not overlay) kube-proxy (iptables) kube-proxy (iptables) kube-proxy (iptables) Service Network(overlay) Pod network(overlay) Pod Pod 外部からのアクセス クラウドのVPC 192.168.1.0/24 192.168.2.0/24 192.168.0.0/24 アドレスプールもルーティング テーブルも全部 VPCの資産で管理 SDN(VPC)がPodへの経路 情報を直接管理できる！
28. Node Node Node Pod クラウドのロードバランサー | Node Network(not overlay) kube-proxy (iptables) kube-proxy (iptables) kube-proxy (iptables) Service Network(overlay) Pod network(overlay) Pod Pod 外部からのアクセス クラウドのVPC 192.168.1.0/24 192.168.2.0/24 192.168.0.0/24 アドレスプールもルーティング テーブルも全部 VPCの資産で管理 SDN(VPC)がPodへの経路 情報を直接管理できる！ これができる
29. コンテナネイティブロードバランシングの実装例 • AWS ◦ AWS VPC CNIがIPAMを内包しており、VPCと連携できる ◦ ノードが持つENI(EC2の仮想NIC)に仮想アドレスプールがあって、 Podへのアドレスを複数持た せることができる(オンプレでいうと仮想 NICみたいなもの、ただしもっと動的に扱えるやつ ) ◦ インスタンスタイプごとにアドレスプールの数は決まっているので、同一ノード上で動く Pod数に 制限があるというデメリットがある ◦ https://docs.aws.amazon.com/eks/latest/userguide/pod-networking.html
30. コンテナネイティブロードバランシングの実装例 • GCP ◦ CNIは非公開なので細かい実装詳細は不明 ◦ NEG(Network Endpoint Group)という実装が仮想アドレスプールのエンドポイントを管理 ◦ IngressやServiceリソースをNEG指定付きで作成すると NEGとPodの関係性が示され、 GCLB(L4/L7)からPodに直接ロードバランスされるようになる ◦ https://cloud.google.com/kubernetes-engine/docs/how-to/standalone-neg
31. まとめ • Kubernetesが複数マシンを束ねて動かすためにはOverlay networkが重要 ◦ CNIとkube-proxyの動作原理について理解すると捗る • 一般的な構成のKubenretesを使うと、Node networkからPodに通信が到達す るまでに2ホップ必要なので、通信経路が複雑になる • AWSやGCPではVPCとうまく連携させることでPodにVPCアドレスを直接アタッチ し、ネットワーク経路が最適化されるように設定できる
32. まとめ • Kubernetesが複数マシンを束ねて動かすためにはOverlay networkが重要 ◦ CNIとkube-proxyの動作原理について理解すると捗る • 一般的な構成のKubenretesを使うと、Node networkからPodに通信が到達す るまでに2ホップ必要なので、通信経路が複雑になる • AWSやGCPではVPCとうまく連携させることでPodにVPCアドレスを直接アタッチ し、ネットワーク経路が最適化されるように設定できる 完全に理解できましたか？🤔🤔
33. おわり