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

Kubernetes の Service type: LoadBalancer は、クラウド環境ではロードバランサーの払い出しと結びついています。一方で、自宅環境やオンプレミス環境では、同じ Service を作っても外部 IP アドレスは自動的には割り当てられません。

MetalLB は、この不足部分を補うための実装です。この記事では、MetalLB を単なる追加コンポーネントとしてではなく、オンプレミス Kubernetes で LoadBalancer Service を成立させるためのネットワーク部品として整理します。

MetalLB が必要になる理由

Kubernetes の Service は、Pod の入れ替わりを隠蔽し、安定した接続先を提供します。ただし ClusterIP はクラスタ内部向けであり、NodePort は各 Node のポートを直接開ける方式です。

外部から自然にアクセスさせたい場合は LoadBalancer が扱いやすいのですが、これはクラウドプロバイダーのロードバランサー連携を前提にしているため、ベアメタルや自宅基盤では別途 IP アドレスを払い出す仕組みが必要になります。

• ClusterIP はクラスタ内部向けの Service
• NodePort は Node のポートを外部に見せる方式
• LoadBalancer は外部 IP アドレスを持つ Service
• オンプレミス環境では、その外部 IP アドレスを割り当てる実装が必要

MetalLB の考え方

MetalLB は、あらかじめ定義したアドレスプールから Service に外部 IP アドレスを割り当て、その IP アドレスへの到達性をネットワーク側に知らせます。

重要なのは、MetalLB がロードバランサーそのものを巨大なアプライアンスとして提供するわけではないことです。MetalLB は、Kubernetes の Service とオンプレミスネットワークの間にある IP アドレス通知の役割を担います。

L2 モードと BGP モード

MetalLB には大きく L2 モードと BGP モードがあります。小規模な検証環境や自宅環境では L2 モードが扱いやすく、ルータと経路制御を組み合わせたい場合は BGP モードが候補になります。

• L2 モードは、同一セグメント内で ARP / NDP により Service IP の所在を知らせる
• BGP モードは、ルータに対して Service IP への経路を広告する
• 単純さを優先するなら L2 モードが始めやすい
• 冗長性や経路制御を設計するなら BGP モードを検討する

家庭内ラボや小規模なオンプレミス Kubernetes では、まず L2 モードで LoadBalancer Service の動きを確認し、その後に必要であれば BGP を検討する流れが現実的です。

IPAddressPool と L2Advertisement

現在の MetalLB では、外部 IP アドレスの範囲を IPAddressPool で定義し、そのアドレスをどの方式で広告するかを L2Advertisement などで定義します。

IPAddressPool の例

kubectl apply -f - <<'EOF'
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: default-pool
  namespace: metallb-system
spec:
  addresses:
    - 192.168.10.240-192.168.10.250
EOF

L2Advertisement の例

kubectl apply -f - <<'EOF'
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: default-l2
  namespace: metallb-system
spec:
  ipAddressPools:
    - default-pool
EOF

ここで指定する IP アドレス範囲は、既存の DHCP 配布範囲や固定 IP アドレスと衝突しないように設計する必要があります。MetalLB が便利だからといって、ネットワーク全体のアドレス管理を曖昧にしてよいわけではありません。

Service LoadBalancer の確認

MetalLB が動作している状態で type: LoadBalancer の Service を作成すると、EXTERNAL-IP にアドレスプール内の IP アドレスが割り当てられます。

kubectl apply -f - <<'EOF'
apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  type: LoadBalancer
  selector:
    app: nginx
  ports:
    - name: http
      port: 80
      targetPort: 80
EOF

kubectl get service nginx

ここで外部 IP アドレスが付与されていれば、Kubernetes 側の Service と MetalLB 側のアドレス割り当ては成立しています。疎通できない場合は、Pod、Service、MetalLB、Node のネットワーク、上位ネットワークの順に切り分けます。

運用上の注意点

MetalLB は便利ですが、Kubernetes の外側にあるネットワーク設計を不要にするものではありません。むしろ、Kubernetes の Service IP を物理ネットワークへ出すため、アドレス設計や障害時の切り分けが重要になります。

• MetalLB 用の IP アドレス範囲を明確に分離する
• DHCP 範囲や既存の固定 IP アドレスと重複させない
• L2 モードでは同一 L2 セグメントでの動作を前提にする
• 複数 Node 構成では、どの Node が応答しているかを確認できるようにする
• 本格運用では BGP、冗長化、監視、障害時の切り戻しも設計する

関連する記事

MetalLB を Helm で導入し、Chart を Harbor で管理する構成については、次の記事で整理しています。

• Kubernetes MetalLB を Helm で導入する – Harbor で Chart を管理する考え方
• Kubernetes 上に Harbor を構築する – Helm で内部コンテナレジストリを運用する意味
• MicroK8s MetalLB speaker が socket permission denied を出す原因 – L2 / 権限 / ホストネットワークを切り分ける

まとめ

MetalLB は、オンプレミス Kubernetes で LoadBalancer Service を扱うための重要な部品です。ただし、MetalLB を入れればクラウドのロードバランサーと同じものがそのまま得られる、という理解は少し雑です。

MetalLB の役割は、Kubernetes の Service に外部 IP アドレスを割り当て、その到達性をネットワークに知らせることです。つまり、Kubernetes と物理ネットワークの境界をどう設計するかが本質になります。

自宅環境や小規模なオンプレミス基盤では、まず L2 モードで仕組みを理解し、必要に応じて BGP や冗長化へ広げていくのが扱いやすい進め方です。

関連記事

Kubernetes MetalLB を Helm で導入する – オンプレ環境で LoadBalancer Service を使う Kubernetes Nginx コンテナと Service LoadBalancer – MetalLB で外部 IP を確認する Kubernetes MetalLB を Helm で導入する – Harbor で Chart を管理する考え方 Kubernetes Nginx コンテナと Service ClusterIP – クラスタ内部通信の入口を作る Kubernetes Nginx コンテナと Service NodePort – Node のポート経由でアクセスする MicroK8s MetalLB speaker が socket permission denied を出す原因 – L2 / 権限 / ホストネットワークを切り分ける Kubernetes Helm の導入 – Chart でアプリケーション構成を管理する Kubernetes kubectl の導入 – リモートクラスタを操作する基本