Introduction

MetalLB depends on the Kubernetes API to watch services, endpoints, and its own configuration resources. If MetalLB cannot reach the API server, the controller and speakers cannot reconcile state correctly, which means LoadBalancer services may stop getting assigned or advertised.

This kind of failure is rarely about Layer 2 or BGP first. It is usually a more basic cluster problem: the MetalLB pods cannot authenticate to the API, cannot route to it, or are being blocked by policy or host networking.

Check the Pod Logs First

Start by looking at the MetalLB controller and speaker logs:

kubectl -n metallb-system get pods
kubectl -n metallb-system logs deploy/controller
kubectl -n metallb-system logs daemonset/speaker

The error text usually points in one of three directions:

• TLS or certificate validation problems,
• unauthorized or forbidden API requests,
• simple connection timeouts or resets to the API server.

That split is useful because each category suggests a different fix path.

Verify Basic API Reachability

From inside the namespace, test whether the Kubernetes service is reachable:

kubectl -n metallb-system run api-test --rm -it --image=busybox -- sh

Inside the shell:

wget -qO- https://kubernetes.default.svc

You may not get a friendly response without credentials, but a timeout or connection failure is still valuable evidence that networking to the API service is broken.

Common Causes

The usual causes are:

• network policies blocking egress from MetalLB to the API server,
• broken or missing service-account token mounts,
• RBAC rules that allow the connection but deny the requests,
• host firewall or CNI routing issues,
• cluster DNS or service networking problems.

These are more fundamental than MetalLB's own IP advertisement mode.

RBAC and Service Account Checks

If the logs show forbidden or similar authorization errors, check the service account and its bindings:

kubectl -n metallb-system get sa
kubectl -n metallb-system get rolebinding,clusterrolebinding | grep metallb

If the pods can reach the API but are denied access, the fix is usually RBAC, not network routing.

In practice, this means you should separate "can MetalLB reach the API server socket" from "can MetalLB perform the API operations it needs." Connection success does not imply authorization success.

That distinction saves a lot of wasted debugging time.

Network Policies and CNI Issues

If the logs show timeouts or connection refusals, inspect network policies and cluster networking. MetalLB pods need to talk to the API server service, which usually means egress to the API server port and working cluster DNS and service routing.

A restrictive policy can break this silently. So can a CNI problem that affects service-to-pod routing or DNS resolution inside the cluster.

Common Pitfalls

• Debugging ARP or BGP first when the pods cannot even talk to the API server.
• Looking only at service objects and ignoring controller and speaker logs.
• Confusing RBAC denial with raw network failure.
• Forgetting that network policies can block MetalLB's API access just like any other workload.
• Assuming the Kubernetes service account is mounted and valid without checking.

Summary

• MetalLB needs stable Kubernetes API access to function.
• Start with controller and speaker logs to see whether the problem is auth, TLS, or connectivity.
• Test basic reachability to kubernetes.default.svc from the MetalLB namespace.
• Check RBAC for forbidden errors and network policy or CNI health for timeout errors.
• Solve API connectivity first, then return to MetalLB-specific advertisement behavior if needed.