-
Notifications
You must be signed in to change notification settings - Fork 385
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Single Node with NLLB leads to broken kube-proxy #4056
Comments
I'm not entirely sure if this is a k0sctl or k0s issue. |
Could you share the k0sctl yaml you used so we can have a look and test the same config |
yes: this is the fixed version:
this is the broken version:
this only difference is the |
Right. This is actually documented. But in contrast to the conflict with an external API address, this is checked, but not reported as an error. K0s should probably error out in this case. |
Despite k0s not being fail-fast here, this is kinda also another instance in which k0sproject/k0sctl#475 would have helped. |
Before creating an issue, make sure you've checked the following:
Platform
Version
v1.29.1+k0s.1
Sysinfo
`k0s sysinfo`
What happened?
I deployed a k0s single-node using k0sctl based on a config for a multi-node deployment. I adjusted the config but completely forgot, that NLLB doesn't make sense on a single node deployment.
the k0s deployment went through, but the network plugin (calico) didn't become ready and upon inspecting it and some googling I got the kube-proxy, which was trying to access the API server via the NLLB port, even though no NLLB pods have been started. Disabling NLLB and restarting kube-proxy fixed the issue.
So there is an inconsistency here:
Steps to reproduce
Expected behavior
Actual behavior
no NLLB pod is deployed, but kube-proxy is still configured to access the api server via envoy.
Screenshots and logs
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: