はじめに

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

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

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

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のアドレスがターゲットグループに指定できるようになります。便利ですね。