I recently built a kubeadm Kubernetes cluster on Proxmox with one control-plane node and three workers. The nodes run a mix of Debian, AlmaLinux, and Ubuntu, with containerd as the runtime and Calico as the CNI. Kubernetes reports every node as Ready, and nearly all Calico components are healthy, but the Calico node pod on the control-plane node remains 0/1 Ready. Its readiness probe reports that BIRD has not established BGP sessions with any of the worker nodes at 192.168.0.43, 192.168.0.44, and 192.168.0.45. I installed the Calico components through the operator but only installed the calicoctl binary on the control-plane machine. Is calicoctl required on every node, and what should I check to fix or diagnose the failed BGP sessions?
4 Answers
You do not need to install calicoctl on every node. It is a client utility for inspecting or changing Calico configuration, not a daemon that establishes the node-to-node sessions. The error is specifically saying that BGP has not formed between the control-plane Calico node and the workers. Check the Calico BGPConfiguration and BGPPeer resources, then inspect the node logs and BIRD status with commands such as kubectl logs -n calico-system and calicoctl node status. Also verify that TCP port 179 is allowed between all node addresses and that the nodes are using the intended interface and IP autodetection method.
Calico does not require you to manually install anything on the hosts beyond the components deployed by Kubernetes. I would compare the control-plane node with a healthy worker: inspect the Calico node resource, the pod environment variables, selected host IP, and the logs from BIRD and felix. Also check host firewalls and any Proxmox or bridge filtering. A mixed operating-system cluster can work, but differences in firewall defaults, routing, and network interface names often explain why one node cannot form its sessions.
The readiness message is the important part: the control-plane node has zero established BGP peers. Confirm that Calico is configured for the routing mode you intended. If you are using the operator, inspect the Installation and BGPConfiguration objects instead of assuming an iptables setting disables BGP. iptables is mainly about how service traffic is handled; it does not automatically turn off Calico’s node-to-node BGP routing. Check for a missing or overly restrictive BGPPeer configuration, incorrect node IP selection, and blocked TCP/179 traffic.
The other nodes being Ready does not prove that the control-plane node has working peering. Each calico-node instance has its own BIRD sessions, so the control-plane pod can fail independently even while the workers appear healthy.
For a new cluster, it is also worth considering another CNI such as Cilium, especially if you want eBPF-based networking and policy. However, switching CNIs will not fix the current issue by itself. Calico is perfectly capable of running this topology; first determine whether the problem is peer configuration, IP autodetection, or connectivity on TCP port 179.
I’m sticking with Calico for now because I’m familiar with it and want to understand the networking failure. I’ll keep Cilium in mind for a later rebuild.
That makes sense. I was assuming the binary had to be present everywhere. I’ll check the BGP resources, interface detection, and firewall rules rather than reinstalling calicoctl.