Eirini uses 127.0.0.1:32123 (or a different configurable NodePort) for images that it stages via buildpacks; this is the only endpoint a kubelet can natively access. Unfortunately, with ipvsadm, we are seeing that kube-proxy only binds the node IP for the NodePort traffic forwarding, so kubecf doesn't seem to work with ipvsadm.
With this loaded, you should be able to curl http://<node-ip>:<node-port> and get back the text pong. If you then SSH onto one of the kubelets, and curl http://127.0.0.1:<node-port>, one of the following will happen:
You get back pong, in which case the NodePort is bound on all interfaces and the bug is fixed.
You get a connection refused, in which case the NodePort is only binding on the node IP, and the bug persists.
Fix the Kubernetes such that we get case 1, not case 2.
Eirini uses
127.0.0.1:32123
(or a different configurable NodePort) for images that it stages via buildpacks; this is the only endpoint a kubelet can natively access. Unfortunately, with ipvsadm, we are seeing that kube-proxy only binds the node IP for the NodePort traffic forwarding, so kubecf doesn't seem to work with ipvsadm.Steps to Reproduce
Here's a daemonset that shows off the problem:
With this loaded, you should be able to
curl http://<node-ip>:<node-port>
and get back the textpong
. If you then SSH onto one of the kubelets, andcurl http://127.0.0.1:<node-port>
, one of the following will happen:pong
, in which case the NodePort is bound on all interfaces and the bug is fixed.Fix the Kubernetes such that we get case 1, not case 2.