手当たり次第に書くんだ

飽きっぽいのは本能

Kubernetes に LoadBalancer はないのか – Service、MetalLB、CNI BGP を分けて考える

作者: si62512548投稿日: カテゴリー: Kubernetesタグ: , , , , , , , Kubernetes に LoadBalancer はないのか – Service、MetalLB、CNI BGP を分けて考える へのコメントはまだありません

Kubernetes のネットワーク設計では、「Kubernetes には LoadBalancer がないので MetalLB を入れる」という説明が出てくることがあります。言いたいことは分かりますが、この表現は少し雑です。

Kubernetes には Service という負荷分散の抽象があり、Service の公開方式として type: LoadBalancer も存在します。問題は、Kubernetes がそれ単体で物理ネットワーク上のロードバランサやクラウドロードバランサを自動的に用意するわけではない、という点です。

つまり、「LoadBalancer がない」のではありません。Kubernetes には LoadBalancer Service という抽象はあります。ただし、オンプレ環境では、その抽象に対して外部 IP を払い出し、外部ネットワークから到達できるようにする実装を別途用意する必要があります。ここを分けて考えないと、Service、MetalLB、CNI、BGP が一つの話として混ざります。

Kubernetes にあるのは Service の抽象である

Kubernetes の Service は、Pod 群に対して安定した名前、IP、ポートを提供するためのリソースです。Pod は作り直されるたびに IP が変わりますが、Service を挟むことで、利用者は背後の Pod の増減や入れ替わりを直接意識しなくて済みます。

Service には ClusterIP、NodePort、LoadBalancer などの公開方式があります。LoadBalancer は、外部ロードバランサを前提に Service を公開する方式です。クラウド環境であれば、クラウドコントローラが外部ロードバランサを作成し、Service に外部 IP やホスト名を割り当てるのが一般的です。

apiVersion: v1
kind: Service
metadata:
  name: example
spec:
  type: LoadBalancer
  selector:
    app: example
  ports:
    - name: http
      port: 80
      targetPort: 8080

この YAML の type: LoadBalancer は、「Kubernetes に外部公開用のロードバランサを要求する」という宣言です。しかし、その要求に誰が応答するかは環境によって変わります。AWS、Azure、Google Cloud のような環境ではクラウド側のロードバランサが作られます。オンプレでは、その役割を担う仕組みを自分で用意する必要があります。

MetalLB はオンプレで LoadBalancer Service を成立させる実装である

MetalLB は、オンプレ Kubernetes で type: LoadBalancer の Service に外部 IP を割り当て、外部ネットワークからその IP に到達できるようにするための実装です。

MetalLB は、単に IP アドレスを配るだけではありません。L2 モードであれば、特定ノードがその IP を受け持つように振る舞います。BGP モードであれば、外部ルーターに対して Service の外部 IP への経路を広告します。どちらも、Kubernetes の Service 抽象をオンプレのネットワークに接続するための方法です。

そのため、MetalLB を「Kubernetes に LoadBalancer を追加するもの」とだけ言うと少し浅くなります。より正確には、MetalLB は LoadBalancer Service に対して、オンプレ環境で必要になる外部 IP の割り当てと到達性を提供する部品です。

CNI は Pod ネットワークの土台である

CNI は、Pod にネットワークを与えるための仕組みです。Calico、Cilium、Flannel、Kube-OVN などは、それぞれ異なる設計思想で Pod ネットワーク、NetworkPolicy、経路制御、データプレーンを実装します。

ここで重要なのは、CNI は Service の外部公開そのものだけを担当するものではない、という点です。CNI は Pod 間通信やノード間経路、NetworkPolicy、場合によっては kube-proxy 代替や eBPF データプレーンまで担当します。

一方で、Calico や Cilium のように BGP 機能を持つ CNI もあります。この場合、Pod CIDR や Service IP、LoadBalancer IP の経路広告まで CNI 側で扱えることがあります。すると、MetalLB の BGP と CNI の BGP のどちらで外部到達性を作るのか、という設計判断が必要になります。

BGP はロードバランサではなく経路広告である

BGP はロードバランサではありません。BGP は、どの IP プレフィックスにどの経路で到達するかを外部ネットワークへ伝えるための経路制御プロトコルです。

MetalLB の BGP モードや CNI の BGP 機能は、外部ネットワークに対して「この Service IP または Pod ネットワークには、このノード経由で到達できる」と知らせるために使われます。

そのため、BGP を使ったからといって、それだけでアプリケーションレベルのロードバランシングが完成するわけではありません。BGP は到達性を作ります。実際にどの Pod に流すか、ノードでどのように振り分けるか、送信元アドレスを維持するか、障害時にどのように経路を引っ込めるかは、Service、kube-proxy 代替、CNI、MetalLB、外部ルーターの組み合わせで決まります。

Service、MetalLB、CNI BGP を分ける

要素役割注意点
ServicePod 群に対する安定した到達点を作る Kubernetes の抽象Service 自体は外部ネットワーク機器ではない
type: LoadBalancer外部向けロードバランサを要求する Service の公開方式外部 IP の払い出しと到達性は実装側が必要
MetalLBオンプレ環境で LoadBalancer Service に外部 IP を割り当て、L2 または BGP で到達性を作る実装クラウド LB そのものではなく、Kubernetes と外部ネットワークをつなぐ部品
CNIPod ネットワーク、NetworkPolicy、経路、データプレーンを担当する領域CNI の BGP 機能と MetalLB の BGP 機能は役割が重なる場合がある
BGP外部ネットワークに経路を伝えるための経路制御プロトコルBGP はロードバランサではなく、到達性を作る手段

このように分けると、「Kubernetes に LoadBalancer はない」という表現がどこでずれているかが見えます。Kubernetes には LoadBalancer Service という抽象があります。ないのは、オンプレ環境でそれを現実のネットワークに接続する外部ロードバランサ実装です。

MetalLB はその実装の一つです。CNI BGP は、Pod ネットワークや Service 到達性を外部ネットワークへ広告する別の設計要素です。BGP はそのための経路制御の手段です。

オンプレ Kubernetes で設計すべきこと

オンプレ Kubernetes では、次の点を明確にしておく必要があります。

  • Service の外部 IP を誰が払い出すのか
  • その IP への到達性を L2 で作るのか、BGP で作るのか
  • MetalLB と CNI の BGP 機能をどちらが担当するのか
  • 外部ルーターはどの経路を受け取るのか
  • 送信元アドレスを維持する必要があるのか
  • ノード障害時に経路や ARP/NDP の収束をどう扱うのか

ここを曖昧にしたまま MetalLB や CNI を入れると、動いているように見えても、障害時や経路変更時に説明できない構成になります。特に BGP を使う場合は、Kubernetes 内部だけではなく、外部ルーター側の設計も含めて考える必要があります。

まとめ

Kubernetes に LoadBalancer がない、という言い方は正確ではありません。Kubernetes には Service の公開方式として type: LoadBalancer があります。

ただし、Kubernetes が単体で外部ロードバランサや物理ネットワーク上の到達性を作ってくれるわけではありません。クラウド環境ではクラウド側のロードバランサがその役割を担い、オンプレ環境では MetalLB や CNI の BGP 機能などを組み合わせて設計します。

Service は Kubernetes の抽象、MetalLB はオンプレで LoadBalancer Service を成立させる実装、CNI は Pod ネットワークの土台、BGP は経路広告の手段です。この4つを分けて考えると、Kubernetes の外部公開設計はかなり見通しがよくなります。

参考情報

参考書籍

参考
書籍
参考書籍
Kubernetes完全ガイド 第2版

Kubernetes の Service、ネットワーク、リソース設計を体系的に確認したい場合の参考書籍です。価格や在庫はリンク先で確認してください。

Amazon で見る

このリンクは Amazon アソシエイトリンクです。

関連する記事

Kubernetes に LoadBalancer はないのか – Service、MetalLB、CNI BGP を分けて考える

関連記事

Kubernetes MetalLB の導入 – LoadBalancer Service をオンプレ環境で成立させる Kubernetes Nginx コンテナと Service LoadBalancer – MetalLB で外部 IP を確認する Kubernetes MetalLB を Helm で導入する – オンプレ環境で LoadBalancer Service を使う Kubernetes で送信元アドレスが変わる問題 – externalTrafficPolicy、hostNetwork、BGP 経路広告で考える Kubernetes Multus がうまく動かない時に考えること – CNI を複数持つ難しさ Kubernetes MetalLB を Helm で導入する – Harbor で Chart を管理する考え方 Kubernetes クラスター構築 – kubeadm で controlPlaneEndpoint と CNI を整理する Ubuntu 22.04 MicroK8s kube-ovn 有効化の検証 – CNI を後から切り替える難しさ

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。（スパム対策）

トップへ戻る