inductor's blog

nothing but self note :)

久々に社内勉強会で発表するので資料を公開します

はじめに

HPE(Hewlett Packard Enterprise)にてアーキテクトをやっているinductorです。久しぶりに社内勉強会というやつに参加して発表することになったので、発表資料を共有します。

なお、発表資料自体10分で話すためにぎゅっと圧縮してしまっているので、このブログでは、LTで話しきれなかったクラウド実装についてもう少しだけ細くを書いておこうと思います。

speakerdeck.com

コンテナネイティブロードバランシングについて

Kubernetesではいわゆる外の世界とKubernetes内部の世界で大きくネットワークの仕組みが分かれています。これをつなぎこむための仕組みとして、3つのネットワークとそれぞれをつなぎこむコンポーネントが存在します。

  • Node network(VMや物理マシンがNICでつながるデータセンター/VPCのネットワーク)
  • Service network(Kubernetesが提供するサービスディスカバリや内部ロードバランサーで使われるネットワーク)
  • Pod network(各Pod[コンテナ]にエンドポイントとなるIPアドレスを付与するネットワーク)

  • CNI(実世界のネットワークとKubernetesネットワークをつなぎ込む役割を持つインターフェース)

  • kube-proxy(Kubernetesの中でネットワークの管理を行うシステムコンポーネント、また、Serviceの実態)

簡単にまとめてしまうと、Kubernetesでは設計の疎結合性のためにKubernetesの外と中で2箇所別々にロードバランス及びルーティングを行うデザインになっているのですが、これは潜在的にボトルネックになりうる構造にもなっています。実際、kube-proxyの実態の1つであるiptablesがボトルネックになるケースはKubeConやコミュニティでも話題として触れられており、主要なCNI実装であるCalicoやCiliumではそれを取り除くための代替策としてeBPFを利用するなどといったアプローチも提案されています。

このボトルネックを取り除くためのもう1つのアプローチとして、AWSやGCPで実現されているコンテナネイティブロードバランシングという仕組みがあります。この仕組を使うと、クラウドのロードバランサーがPodのネットワークに直接ルーティングできるようになり、ホップの回数が減ります。ターゲットに直接(あるいは抽象化レイヤを挟んで間接的に)接続できるようになるため、たらい回しにされづらくなるメリットがあるわけです。

f:id:inductor:20210930142306p:plain

上記はGCPでの例ですが、KubernetesのServiceあるいはIngressにてNEGを指定してあげることでこれが実現されています。AWSではVPC CNIの持つIPAMとVPCのアドレス範囲がうまいこと連携され、EC2のENIが持つセカンダリアドレスプール(ノード上のPodにアタッチできるアドレス)だったり、Fargateに割り当てられるVPCのアドレスがターゲットグループに指定できるようになります。便利ですね。

実装の詳細が知りたい場合

AWSとGCPではデザインからして大きく違うアプローチをとっているので、両方をいきなり理解するのは難しいと思います。まずはより使い込んでいる側の仕組みから理解して見るよう心がけるとよさそうです。

なお、AWS VPC CNIはGitHub上に公開されているので実装の詳細を追うことができます。

github.com

GCPは実装詳細がわからないので、GCEのIngressでインターフェースレベルまで理解するか、Google Cloudのドキュメントや日本人のソリューションエンジニアが書いてくれたブログを読むのが一番深くまで知ることができると思います。

github.com

medium.com

それでは、今日はこのへんで。