Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

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

Kohei Ota
September 30, 2021

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

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

Kohei Ota

September 30, 2021
Tweet

More Decks by Kohei Ota

Other Decks in Technology

Transcript

  1. 自己紹介 名前: 太田 航平 (@inductor) 所属: HPE GreenLake Global COE

    役職: アーキテクト Kubernetes SIG-Docs Japanese localization owner CNCF Ambassador Docker Meetup Tokyo、CloudNative Days運営
  2. アジェンダ • Kubernetesのネットワーク • Kubernetesのネットワークを形作るコンポーネントとその役割 ◦ kube-proxy ◦ CNI ▪

    よく使われるCNIの特徴 • Kubernetesネットワークにおける1つの課題 • コンテナネイティブロードバランシングの話 ◦ AWS、GCPでの解決法 • まとめ
  3. Kubernetesの仕組み Pod Pod Pod Pod network(overlay) Service Network(overlay) Node Network(not

    overlay) 普通のサーバーがつながる ネットワーク ClusterIPなどサービス間の 通信で使うネットワーク コンテナ(Pod)自体に IPアドレスを持たせるためのネッ トワーク kube-proxy CNI 各ホスト上のiptables/eBPF による ルーティング
  4. 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 による ルーティング
  5. 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にならない
  6. 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にならない
  7. 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でコンテナ外 からの通信を流す
  8. いろいろなCNI • Calico ◦ 最も人気&歴史がある ◦ BGP(L3)ベースのネットワークでスケールしやすい • Cilium ◦

    eBPFを用いた高パフォーマンス &スケーラブルなプラグイン ◦ 最近人気になってきた ◦ GKEでも最近導入がアナウンスされた • Weave Net • Amazon VPC CNI plugin
  9. 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 外部からのアクセス
  10. 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 外部からのアクセス
  11. 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
  12. 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
  13. 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内部の ネットワークで負荷分散
  14. 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 外部からのアクセス
  15. 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 外部からのアクセス 必ずしも最適化された ネットワーク経路になると は限らないんだなぁ
  16. 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とうまく連携すれば さっきの問題が解決できる
  17. 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の資産で管理
  18. 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への経路 情報を直接管理できる!
  19. 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への経路 情報を直接管理できる! これができる
  20. コンテナネイティブロードバランシングの実装例 • AWS ◦ AWS VPC CNIがIPAMを内包しており、VPCと連携できる ◦ ノードが持つENI(EC2の仮想NIC)に仮想アドレスプールがあって、 Podへのアドレスを複数持た

    せることができる(オンプレでいうと仮想 NICみたいなもの、ただしもっと動的に扱えるやつ ) ◦ インスタンスタイプごとにアドレスプールの数は決まっているので、同一ノード上で動く Pod数に 制限があるというデメリットがある ◦ https://docs.aws.amazon.com/eks/latest/userguide/pod-networking.html
  21. コンテナネイティブロードバランシングの実装例 • 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
  22. まとめ • Kubernetesが複数マシンを束ねて動かすためにはOverlay networkが重要 ◦ CNIとkube-proxyの動作原理について理解すると捗る • 一般的な構成のKubenretesを使うと、Node networkからPodに通信が到達す るまでに2ホップ必要なので、通信経路が複雑になる

    • AWSやGCPではVPCとうまく連携させることでPodにVPCアドレスを直接アタッチ し、ネットワーク経路が最適化されるように設定できる 完全に理解できましたか?🤔🤔