MetalLB と Azure Load Balancer の比較｜KubernetesのLoadBalancerをオンプレとAKSでどう用意するか

MetalLB と Azure Load Balancer は、どちらも Kubernetes の type: LoadBalancer の Service に外部IPを与える仕組みですが、前提が違います。MetalLB はオンプレミスやベアメタルなど「クラウドのLBが無い環境」で自分たちが運用するもの、Azure Load Balancer は AKS で Azure が提供・管理するものです。この記事では、両者の仕組み、できることと苦手なこと、SSL/TLS をどこで終端するか、WordPress を載せるときの注意点を比べ、どちらを選ぶべきかを判断できるようにします。

そもそも何を比べるのか

Kubernetes では、Service を type: LoadBalancer にすると、クラスターの外から到達できるIPが割り当てられます。ただし Kubernetes 本体はそのIPを用意しません。クラウドではクラウドコントローラーがその役を担い、AKS なら Azure Load Balancer が自動で作られます。オンプレミスではその役を担う部品が無いため、Service は外部IPが <pending> のまま止まります。ここを埋めるのが MetalLB です。

つまり「どちらが優れているか」ではなく、「クラスターをどこで動かすか」でほぼ決まります。比較が意味を持つのは、オンプレと Azure のハイブリッド構成や、オンプレから AKS への移行を検討している場面です。

MetalLB の仕組み

MetalLB は、あらかじめ決めたアドレス範囲から Service にIPを割り当て、そのIPをネットワークへ広告します。広告方式は2つあります。

• L2 モード：ARP（IPv6 では NDP）で「このIPは自分のノードにある」と応答します。特別なルーターが不要で導入しやすい反面、1つのIPに対する通信はその時点で選ばれた1台のノードに集中します。複数ノードに分散されるのはノードに入った後（kube-proxy による Pod への振り分け）です。ノード障害時は別ノードが引き継ぎますが、切り替えにはクライアント側の ARP キャッシュ更新を待つ数秒程度の断が出ることがあります
• BGP モード：上流ルーターと BGP で経路を交換し、ECMP によって複数ノードへ通信を分散します。本来の意味での負荷分散ができますが、BGP に対応したルーターとネットワーク担当者の協力が必要です

MetalLB はバージョン 0.13 以降、設定を CRD（カスタムリソース）で行う方式になっています。L2 モードの最小構成は次のとおりです。アドレス範囲は DHCP の配布範囲と重ならない空きアドレスを使ってください。

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: web-pool
  namespace: metallb-system
spec:
  addresses:
  - 192.168.10.240-192.168.10.250
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: web-l2
  namespace: metallb-system
spec:
  ipAddressPools:
  - web-pool

MetalLB 自体はヘルスチェックを行いません。どの Pod が正常かは Kubernetes の readinessProbe と Endpoints に任せる設計です。readinessProbe を設定していないと、起動途中の Pod にも通信が流れます。

Azure Load Balancer の仕組み

AKS では、type: LoadBalancer の Service を作ると、クラウドコントローラーが Azure Load Balancer にフロントエンドIP、負荷分散規則、正常性プローブを自動で追加します。現在の AKS は Standard SKU を使い、Basic SKU は提供終了しています（2026年10月現在）。

Azure 側でネットワーク機器を用意する必要はなく、可用性ゾーンをまたぐ構成や、外向き通信（SNAT）の管理も Azure の仕組みに乗せられます。挙動は Service の注釈（annotation）で調整します。たとえば VNet 内からだけ使う内部LBにするには次のように書きます。

apiVersion: v1
kind: Service
metadata:
  name: wordpress
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
spec:
  type: LoadBalancer
  selector:
    app: wordpress
  ports:
  - port: 80
    targetPort: 80

注釈の種類は多く、AKS のバージョンで追加や変更があります。使う前に AKS の公式ドキュメントで現行の名前を確認してください。

比較の観点

費用の考え方も異なります。MetalLB はソフトウェア自体は無償ですが、アドレス、ルーター、運用の手間が自分たちの負担になります。Azure Load Balancer は規則数や処理量などに応じた従量課金なので、Azure の料金ページで構成ごとに試算してください。

SSL/TLS はどこで終端するか

ここが見落とされやすい点です。MetalLB も Azure Load Balancer も L4 で動くため、証明書を持ってTLSを終端する機能はありません。HTTPS で公開するには、その手前か後ろに L7 の部品を置きます。

• 共通の方法：LoadBalancer の後ろに Ingress コントローラー、または Gateway API の実装を置き、そこで証明書を扱う。証明書の発行と更新は cert-manager で自動化するのが一般的です
• Azure ならではの方法：L7 の Application Gateway（AKS 向けの Application Gateway for Containers を含む）や Front Door でTLSを終端する。この場合 Azure Load Balancer を外部公開に使わない構成もあります

Ingress コントローラーの選定では、プロジェクトの保守状況を確認してください。広く使われてきた ingress-nginx は、Kubernetes プロジェクトから保守終了が告知されています（2026年10月現在）。新規に組むなら Gateway API 対応の実装も含めて比較するのが無難です。

WordPress を載せるときの注意

どちらの方式でも、WordPress 側で気をつける点は共通です。

• HTTPS の判定：Ingress などでTLSを終端すると、WordPress には HTTP で届きます。wp-config.php で X-Forwarded-Proto を見て $_SERVER['HTTPS'] = 'on' を立てる設定が必要です。このヘッダーを信用してよいのは、Pod に外部から直接届かない構成のときだけです
• 訪問者IP：既定の externalTrafficPolicy: Cluster ではノード間転送の際に送信元IPが書き換わります。ログイン試行制限などで本当の訪問者IPが必要なら Local を検討します。ただし Local にすると、Pod が無いノードには通信が流れなくなる点、MetalLB の L2 モードでは Pod があるノードだけが広告する点を理解しておいてください
• メディアの共有：Pod を複数にするなら、wp-content/uploads を複数 Pod から読み書きできるストレージに置くか、オブジェクトストレージへオフロードします
• データベース：MySQL/MariaDB はクラスター内で動かすより、マネージドDBや専用サーバーに分けるほうが運用しやすいことが多いです

どちらを選ぶか

• オンプレやベアメタルで Kubernetes を動かすなら MetalLB。小規模なら L2 モード、トラフィックが多くネットワーク担当者と連携できるなら BGP モード
• AKS で動かすなら Azure Load Balancer をそのまま使う。AKS に MetalLB を入れる必要は基本的にありません
• ハイブリッド構成では、Service 定義は共通にして、注釈や LB の部分だけ環境ごとに差し替えられるよう Helm や Kustomize で分けておくと移行が楽になります

どちらを選んでも、検証用クラスターで障害ノードを1台止めてみて、切り替わりにかかる時間と、その間のエラーを確認しておくと本番で慌てずに済みます。

まとめ

• MetalLB は「クラウドLBが無い環境」向け、Azure Load Balancer は AKS で自動管理される L4 LB。比較の前提は動かす場所
• MetalLB の L2 モードは導入しやすいが1ノード集中、BGP モードは分散できるがルーターが必要
• どちらも L4 なので、HTTPS は Ingress／Gateway API の実装や Application Gateway で終端する
• WordPress では HTTPS 判定、訪問者IP、メディアの共有を構成に合わせて設定する

• MetalLB の構築手順（オンプレのKubernetesでLoadBalancerにIPを割り当てる）
• Kubernetes の Ingress で HTTP ルーティングを設定する方法