Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Ad22fcf5773b906c08330f4d57242212?s=47 Kohei Ota
September 30, 2021

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

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

Ad22fcf5773b906c08330f4d57242212?s=128

Kohei Ota

September 30, 2021
Tweet

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. おわり