I was wondering - after having used

--egress-selector-mode=disabled

on nodes in a cluster. What is one not getting? What’s the downside? In the docs it says:

The apiserver does not use agent tunnels to communicate with nodes. Requires that servers run agents, and have direct connectivity to the kubelet on agents, or the apiserver will not be able to function access service endpoints or perform kubectl exec and kubectl logs.

So sounds fine to me. I wasn’t disabling the agent on

servers

anyway. So not loosing anything there. Are there any downsides or considerations one should have? Thank you very much

K3s has always used a tunnel between the agents and apiservers so that the server does not have to open connections back to the kubelet port on the agents. Previously that was done via a patch to the kubelet code, and couldn’t be disabled. Now it’s done differently, and can be disabled.

Wonderful … so we can keep on going in the direction that we start … by using

--egress-controller-mode=disabled

- it shouldn’t make any difference at all on newer K3s versions. Thank you!

The default (agent) mode is optimal as it allows you to avoid having to expose more ports on your agents. There was an issue with the egress proxy code that caused occasional errors, that will be fixed in our next release cycle.

Okay we’ll switch back then. Want optimal all the way. Haven’t had to open up any extra ports after setting the egress to disabled though. I guess that might say something about how open communication is between nodes in the cluster

yeah if they already have all the ports open to each other it probably matters less

Oh yeah. So this would be an issue if it’s a tightly regulated / hardened environment. The tunneling feature here is indeed nice.