Kubernetes MetalLB の導入 – LoadBalancer Service をオンプレ環境で成立させる

Kubernetes の type: LoadBalancer は、クラウド環境ではクラウドロードバランサーの払い出しと結びついています。

一方で、オンプレミス Kubernetes や自宅ラボでは、同じ LoadBalancer Service を作っても、外部 IP アドレスが自動的に割り当てられるとは限りません。Kubernetes は Service の抽象を持っていますが、その抽象を物理ネットワークや既存ルーターへ接続する実装は、環境側で用意する必要があります。

MetalLB は、この不足部分を埋めるための代表的な実装です。

ただし、MetalLB を「オンプレ Kubernetes にロードバランサーを追加するもの」とだけ理解すると、少し粗くなります。より正確には、MetalLB は LoadBalancer Service に外部 IP を割り当て、その IP への到達性を L2 または BGP で外部ネットワークへ知らせる部品です。

MetalLB が必要になる理由

Kubernetes の Service は、Pod の入れ替わりを隠蔽し、安定した接続先を提供します。

しかし、Service の種類によって、どこまで外部公開できるかは変わります。

クラウド環境では、クラウドコントローラーが LoadBalancer Service を見て、クラウドロードバランサーを作成します。オンプレミス環境では、この役割を自動で担うクラウド基盤がないため、MetalLB のような実装が必要になります。

MetalLB の基本構成

MetalLB を見るときは、Controller、Speaker、IPAddressPool、Advertisement を分けると理解しやすくなります。

公式ドキュメントでも、MetalLB はインストールしただけでは設定なしの状態では待機し、IPAddressPool や広告用リソースを作成して初めて Service IP を扱えるようになります。

IPAddressPool はアドレス管理そのものである

IPAddressPool は、MetalLB が LoadBalancer Service に割り当てる外部 IP アドレスの範囲を定義します。

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: default-pool
  namespace: metallb-system
spec:
  addresses:
    - 192.168.10.240-192.168.10.250

ここで重要なのは、この IP 範囲が Kubernetes の中だけの話ではないという点です。

MetalLB が割り当てる IP は、外部ネットワークから実際に到達する IP です。そのため、DHCP 範囲、既存の固定 IP、ルーター、Firewall、DNS、監視設定と衝突しないように管理する必要があります。

MetalLB の導入で失敗しやすいのは、Kubernetes の YAML だけを見て、実ネットワーク上のアドレス管理を軽く扱ってしまうことです。LoadBalancer IP は Kubernetes リソースであると同時に、実ネットワーク上の IP アドレスでもあります。

L2 モードは ARP / NDP で到達性を作る

L2 モードは、MetalLB の中でも始めやすい方式です。

L2 モードでは、MetalLB の Speaker が Service IP に対する ARP / NDP に応答し、外部ネットワークから見て「この IP はこの Node の MAC アドレスにいる」と見えるようにします。

apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: default-l2
  namespace: metallb-system
spec:
  ipAddressPools:
    - default-pool

L2 モードは簡単ですが、何も考えなくてよいわけではありません。どの Node が Service IP を受け持っているのか、Node 障害時にどれくらいで切り替わるのか、上位スイッチや端末の ARP キャッシュがどう影響するのかは確認しておくべきです。

BGP モードは外部ルーターとの設計になる

BGP モードでは、MetalLB が外部ルーターと BGP ピアを張り、LoadBalancer IP への経路を広告します。

これは、Kubernetes の Service IP を既存の L3 ネットワークへ統合する設計です。

BGP モードは柔軟ですが、Kubernetes だけで完結しません。外部ルーター側の設定、経路フィルタ、AS 番号、障害時の経路 withdraw、ECMP の扱いまで含めて設計する必要があります。

小規模環境では L2 モードで始め、本格的に冗長化や L3 経路制御をしたくなった段階で BGP モードを検討する方が、理解しやすいと思います。

Service LoadBalancer の確認ポイント

MetalLB が動作している状態で type: LoadBalancer の Service を作成すると、EXTERNAL-IP に IPAddressPool から IP が割り当てられます。

kubectl get service -A
kubectl get ipaddresspool -n metallb-system
kubectl get l2advertisement -n metallb-system
kubectl get pods -n metallb-system -o wide

Service に外部 IP が付いたからといって、外部から必ず疎通できるとは限りません。Kubernetes 側の割り当て、MetalLB の広告、Node のネットワーク、上位ネットワーク、Firewall を分けて確認します。

運用上の注意点

MetalLB は便利ですが、Kubernetes の外側にあるネットワーク設計を不要にするものではありません。

MetalLB は Kubernetes とネットワークの境界にあります。そのため、Kubernetes 管理者だけでなく、ネットワーク側の設計者にも影響します。IP アドレス、VLAN、ルーター、Firewall、DNS、監視のどこに責任があるのかを曖昧にしないことが重要です。

まとめ

MetalLB は、オンプレミス Kubernetes で LoadBalancer Service を成立させるための重要な部品です。

ただし、MetalLB を入れればクラウドロードバランサーと同じものがそのまま得られる、という理解は雑です。MetalLB の役割は、Kubernetes の Service に外部 IP を割り当て、その到達性を L2 または BGP で外部ネットワークへ知らせることです。

つまり、MetalLB の本質は、Kubernetes と物理ネットワークの境界をどう接続するかにあります。

小規模環境では L2 モードで仕組みを理解し、必要に応じて BGP、冗長化、経路制御、監視へ広げる。そう考えると、MetalLB の導入は単なる手順ではなく、オンプレミス Kubernetes の入口設計として扱いやすくなります。

参考情報

• MetalLB Documentation – Installation
• MetalLB Documentation – Configuration
• MetalLB Documentation – Layer 2 mode
• MetalLB Documentation – BGP mode

関連記事

Kubernetes に LoadBalancer はないのか – Service、MetalLB、CNI BGP を分けて考える Kubernetes MetalLB を Helm で導入する – オンプレ環境で LoadBalancer Service を使う Kubernetes Nginx コンテナと Service LoadBalancer – MetalLB で外部 IP を確認する Kubernetes MetalLB を Helm で導入する – Harbor で Chart を管理する考え方 Kubernetes Nginx コンテナと Service NodePort – Node のポート経由でアクセスする MicroK8s MetalLB speaker が socket permission denied を出す原因 – L2 / 権限 / ホストネットワークを切り分ける Kubernetes Nginx コンテナと Service ClusterIP – クラスタ内部通信の入口を作る Kubernetes Multus の導入 – Pod に複数 NIC を接続する