podCIDR not populated on node

I’ve been playing with juju, specifically with the kubernetes-core (Flannel) and kubernetes-calico bundles, and neither of them result in the podCIDR showing up against the node despite a CIDR being allocated.

I can fix this by manually patching the node with kubectl patch node -p ‘{“spec”:{“podCIDR”:""}}’, but this is less than ideal for obvious reasons.

An external Load Balancer I am using for Ingress/LB service types relies on this information being populated to create static routes for the pod CIDR’s to the worker nodes. Any reason why this might be occuring?

K8S version is 1.9.3.

The podCIDR field of the node is only set if kube-controller-manager is configured to manage pod addresses via --allocate-node-cidrs=true. Since Charmed Kubernetes relies on a CNI to manage pod addresses, that field isn’t set. In general, it’s not really a reliable field and there’s a proposal to remove it entirely, so it’s unclear to me why the LB implementation you’re using would depend on it being set.

What LB are you working with specifically? Perhaps there’s a way to inform it about whichever CNI you’re using and have it get the CIDR from that instead.

Here’s another discussion about podCIDR not being reliable: https://www.reddit.com/r/kubernetes/comments/ax9vey/is_podcidr_something_we_should_expect_within_the/ehs65oo/?context=8&depth=9

1 Like

Just wanted to follow up on this in case there’s anything further I can do to help unblock your external LB use-case? It might also be worth filing a feature-request bug on CK to see if we can determine whether it would be worthwhile to have the CNI charms populate this field.

I’m actually going to try out kubernetes-calico bundle instead, as the external LB supports a few different CNI’s (Flannel, Calico, Canal, Antrea).

Apparently the way they look for Calico podCIDR is different, so I will see how this one goes.

The use case is that the LB is outside the K8S cluster, and will look for the podCIDR to set static routes on the egress side of the LB, therefore allowing pool members in the LB config to be the pod IP’s as opposed to needing NodePort. Of course you could use BGP to announce the routes with something like Calico, but not every application team is great with routing and static is just easier to deal with.