#3066·metallb

Helm chart does not allow setting nodeselector and tolerations for metallb frrk8s pods

Author: wargamezCreated May 26, 2026Updated Jun 15, 2026
Labelsbug

MetalLB Version

0.16.0

Deployment method

Charts

Main CNI

canal

Kubernetes Version

No response

Cluster Distribution

No response

Describe the bug

I run metallb on 3 dedicated "loadbalancer"-nodes in my cluster, and i control that in the helm with the use of nodeselector, tolerations and affinity/podantiaffinity. Now with the move to frrk8s I find no such mechanism for the frr pods, and the result is that frr pods are deployed to all nodes in the cluster. Is it not so that ideally they would only run on the same nodes that runs speaker?

Considerations: Idle Pods: On the nodes where the MetalLB speaker is not running, the frrk8s pod will sit idle, consuming memory and CPU cycles (minimal, but non-zero) for no reason. Security/Compliance: frr-k8s runs as a privileged container because it needs to manage network interfaces and routing tables. If your nodeSelector was intended to keep privileged networking pods away from specific workloads, the default settings break that isolation?

To Reproduce

N/A

Expected Behavior

N/A

Additional Context

N/A

I've read and agree with the following

  • I've checked all open and closed issues and my request is not there.
  • I've checked all open and closed pull requests and my request is not there.

I've read and agree with the following

  • I've checked all open and closed issues and my issue is not there.
  • This bug is reproducible when deploying MetalLB from the main branch
  • I have read the troubleshooting guide and I am still not able to make it work
  • I checked the logs and MetalLB is not discarding the configuration as not valid
  • I enabled the debug logs, collected the information required from the cluster using the collect script and will attach them to the issue
  • I will provide the definition of my service and the related endpoint slices and attach them to this issue