Kubernetes MetalLB を Helm で導入する – オンプレ環境で LoadBalancer Service を使う

この記事では、MetalLB を Helm で導入し、オンプレミス Kubernetes で type: LoadBalancer の Service を使える状態にする手順を確認します。

元の記事では Bitnami chart を前提にしていましたが、現在は MetalLB 公式の Helm chart を使う方が自然です。ここでは公式 chart を前提に、L2 モードで使い始めるところまでを扱います。

前提

Kubernetes クラスタが動作しており、Helm が利用できることを前提にします。また、MetalLB 用に割り当てる IP アドレス範囲は、DHCP や既存の固定 IP と衝突しないように事前に決めておきます。

• Kubernetes クラスタが稼働している
• Helm がインストール済みである
• MetalLB 用の IP アドレス範囲を確保している
• L2 モードで使う場合、クライアントと Node が到達できるネットワークに VIP を置く

kube-proxy の strictARP を確認する

kube-proxy を IPVS モードで使っている場合は、strictARP の設定が重要になります。環境によっては不要ですが、MetalLB 導入時の確認ポイントとして覚えておくとよいです。

kubectl get configmap kube-proxy -n kube-system -o yaml | grep -E 'mode:|strictARP'

必要であれば、kube-proxy の ConfigMap を修正して strictARP: true にします。変更の影響があるため、既存クラスタでは必ず現在の設定と運用方針を確認してから実施します。

MetalLB の Helm リポジトリを追加する

MetalLB 公式の Helm chart リポジトリを追加します。古い Bitnami chart を使う必要はありません。

helm repo add metallb https://metallb.github.io/metallb
helm repo update
helm search repo metallb

Namespace を作成する

MetalLB は通常 metallb-system Namespace に導入します。Pod Security Admission を使う環境では、speaker がネットワーク機能を扱えるように privileged 相当のラベルが必要になる場合があります。

kubectl create namespace metallb-system

kubectl label namespace metallb-system pod-security.kubernetes.io/enforce=privileged pod-security.kubernetes.io/audit=privileged pod-security.kubernetes.io/warn=privileged

Helm で MetalLB をインストールする

公式 chart を使って MetalLB をインストールします。インストール直後は MetalLB の Pod は起動しますが、アドレスプールを定義するまでは LoadBalancer Service に外部 IP は割り当てられません。

helm install metallb metallb/metallb --namespace metallb-system

kubectl -n metallb-system get pods -o wide
kubectl -n metallb-system get all

IPAddressPool を作成する

MetalLB が Service に割り当てる IP アドレス範囲を IPAddressPool として定義します。以下のアドレス範囲は例なので、実際の環境に合わせて変更します。

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

L2Advertisement を作成する

L2 モードで使う場合は、作成したアドレスプールを L2Advertisement で広告します。これにより、speaker が ARP / NDP 応答を行い、外部ネットワークから VIP に到達できるようになります。

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

設定を確認する

CRD と Pod の状態を確認します。ここまでで MetalLB 自体の導入と L2 モードの基本設定は完了です。

kubectl -n metallb-system get ipaddresspool,l2advertisement
kubectl -n metallb-system describe ipaddresspool default-pool
kubectl -n metallb-system describe l2advertisement default-l2
kubectl -n metallb-system get pods -o wide

LoadBalancer Service で確認する

導入後は、実際に type: LoadBalancer の Service を作成して EXTERNAL-IP が割り当てられるか確認します。確認用の Nginx Service については別記事で確認しています。

kubectl get svc -A
kubectl get events -A --sort-by=.lastTimestamp

アンインストール

検証環境で削除する場合は、Helm release と設定リソースを削除します。実運用環境では、LoadBalancer Service に影響するため慎重に実行します。

kubectl -n metallb-system delete l2advertisement default-l2
kubectl -n metallb-system delete ipaddresspool default-pool
helm uninstall metallb --namespace metallb-system
kubectl delete namespace metallb-system

古い Bitnami chart について

元の記事では bitnami/metallb を使っていました。当時の検証記録としては意味がありますが、現在の記事としては MetalLB 公式 chart を前提にした方が読み手にとって自然です。

また、古い MetalLB では ConfigMap にアドレスプールを記述する例が多く見られましたが、現在は IPAddressPool や L2Advertisement などの CRD を使う構成で確認した方が分かりやすいです。

まとめ

MetalLB を Helm で導入する場合は、公式 chart を使い、インストール後に IPAddressPool と L2Advertisement を作成する流れで確認すると分かりやすいです。

導入そのものより重要なのは、どの IP アドレス範囲を MetalLB に使わせるのか、その VIP が実ネットワーク側から到達可能なのかを設計しておくことです。

MetalLB は Kubernetes の外にあるネットワークと接続する部品なので、Helm でインストールできたかだけでなく、Service、speaker、L2 セグメント、クライアントからの到達性まで確認して初めて導入完了と考えるべきです。

関連する記事

次に進む

参考書籍

関連記事

Kubernetes MetalLB を Helm で導入する – Harbor で Chart を管理する考え方 Kubernetes MetalLB の導入 – LoadBalancer Service をオンプレ環境で成立させる Kubernetes Nginx コンテナと Service LoadBalancer – MetalLB で外部 IP を確認する Kubernetes に LoadBalancer はないのか – Service、MetalLB、CNI BGP を分けて考える MicroK8s MetalLB speaker が socket permission denied を出す原因 – L2 / 権限 / ホストネットワークを切り分ける Kubernetes Nginx コンテナと Service NodePort – Node のポート経由でアクセスする Kubernetes 上に Harbor を構築する – Helm で内部コンテナレジストリを運用する意味 Kubernetes Helm Chart を自作する意味 – 借り物の Chart と運用責任を分けて考える