MicroK8s MetalLB speaker が socket permission denied を出す原因 – L2 / 権限 / ホストネットワークを切り分ける

MicroK8s 環境で MetalLB の VIP が応答しなくなり、speaker のログに socket: permission denied が出たときの切り分けメモです。単なる疎通不良ではなく、L2 モードで speaker が ARP / NDP に応答できているかを見る必要があります。

MetalLB は Kubernetes の Service を外部へ公開するための仕組みですが、L2 モードではホストネットワーク、インターフェース、権限、CNI の状態に強く依存します。MicroK8s では snap 環境や addon 構成も絡むため、通常の kubeadm クラスターとは見え方が少し違う場合があります。

症状

• 同一セグメントから VIP に接続しても応答しない
• ip neigh show <VIP> が FAILED になる
• ノード自体への SSH や Kubernetes API は生きている
• MetalLB speaker のログに socket: permission denied が出る
• Service は LoadBalancer として IP を持っている

まず見るべき状態

まず、MetalLB の Pod、Service、割り当てられている VIP を確認します。

microk8s kubectl get pods -n metallb-system -o wide
microk8s kubectl get svc -A
microk8s kubectl get events -A --sort-by=.lastTimestamp

speaker Pod が起動していても、L2 応答ができなければ VIP は外部から使えません。Pod の Running だけで判断しない方がよいです。

speaker のログを確認する

speaker のログで socket: permission denied が出ていないか確認します。

microk8s kubectl -n metallb-system logs -l app=metallb,component=speaker --tail=100

MetalLB speaker は L2 モードで ARP / NDP 応答を行います。そのため、通常の Pod よりもホスト側ネットワークへのアクセスや権限の影響を受けます。

L2 モードで何が起きているか

L2 モードの MetalLB では、VIP 宛の ARP または NDP に対して、選ばれたノード上の speaker が応答します。つまり、VIP は Kubernetes 内部だけで完結するアドレスではなく、同一 L2 セグメント上で見える必要があります。

• VIP がクライアントと同じ L2 セグメントにある
• speaker が ARP / NDP に応答できる
• ノードのインターフェースが該当セグメントに接続している
• ホスト側の権限や制約で raw socket が阻害されていない
• CNI や MicroK8s addon の状態が壊れていない

クライアント側から確認する

クライアント側では、VIP の近隣解決ができているか確認します。

ip neigh show <VIP>
ping <VIP>
curl -v http://<VIP>/

ip neigh が FAILED になる場合、IP レベルのアプリケーション以前に、L2 の応答が成立していない可能性があります。

ノード側で確認する

ノード側では、MetalLB speaker が動いているノード、インターフェース、VIP の割り当てを確認します。

microk8s kubectl get pods -n metallb-system -o wide
ip addr
ip route
journalctl -u snap.microk8s.daemon-kubelite --no-pager | tail -100

MicroK8s では snap 管理のサービスが関係するため、通常の kubelet ログだけではなく MicroK8s 側のサービスログを見る必要があります。

復旧手順の考え方

一時的な不整合であれば、MetalLB speaker や MicroK8s の再起動で復旧することがあります。ただし、根本原因が権限、CNI、addon の破損であれば再発します。

microk8s kubectl -n metallb-system rollout restart daemonset speaker
microk8s kubectl -n metallb-system get pods -o wide

MicroK8s 全体の状態が怪しい場合は、影響を理解した上で MicroK8s の再起動を検討します。

sudo snap restart microk8s

判断基準

• Service に VIP が割り当てられているか
• speaker Pod が各ノードで動いているか
• speaker ログに権限エラーが出ているか
• クライアント側で ARP / NDP が解決できているか
• CNI や MicroK8s addon を直前に変更していないか

まとめ

socket: permission denied が出て MetalLB の VIP が応答しない場合、単なる Service 設定ミスではなく、speaker が L2 応答を行える状態かを確認します。特に L2 モードでは、Kubernetes 内部の状態とホストネットワークの状態を分けて見る必要があります。

MicroK8s では CNI、MetalLB、DualStack、snap 管理のサービスが絡むため、VIP が割り当てられていることと外部から到達できることは別です。Service、speaker、ARP / NDP、ホスト側ログを順に確認すると、原因を切り分けやすくなります。

関連記事

• MicroK8s で IPv6/IPv4 デュアルスタックが動かない時に見ること
• MicroK8s kube-ovn 有効化の検証 – CNI を後から切り替える難しさ
• Kubernetes Calico eBPF の設計メモ – kube-proxy 代替、DualStack、高可用性をどう見るか
• Kubernetes クラスター構築 – kubeadm で controlPlaneEndpoint と CNI を整理する
• Ubuntu 22.04 Kubernetes 管理ツールのインストール – kubectl / Helm / calicoctl を整理する

Related posts:

MicroK8s kube-ovn 有効化の検証 – CNI を後から切り替える難しさ Kubernetes MetalLB の導入 – LoadBalancer Service をオンプレ環境で成立させる Kubernetes MetalLB を Helm で導入する – Harbor で Chart を管理する考え方 Ubuntu 20.04 MicroK8s の初期設定と DNS addon の確認 Ubuntu 20.04 MicroK8s MicroK8s で IPv6/IPv4 デュアルスタックが動かない時に見ること Ubuntu 26.04 MicroK8s の基本 古い Kubernetes クラスター構築メモ – kubeadm 手順を現在の記事へ読み替える Kubernetes Helmの導入 Kubernetes マニフェストを理解する apiVersion Kubernetes 1 つの Pod 内で複数の CentOS コンテナを実行する Kubernetes Nginx コンテナと Service ClusterIP