Don't use join tokens to bootstrap embedded kubelet #5487
Conversation
bc75178 to
8809af1
Compare
|
This pull request has merge conflicts that need to be resolved. |
8809af1 to
9ef2e71
Compare
There's a small caveat: kubelet will always connect to only the local API server instance and not via LB/CPLB to all API servers, right? In worst case, if say etcd is having issues on one controller, the local kubelet will also go down. |
|
This pull request has merge conflicts that need to be resolved. |
This is only true for the bootstrapping process. After the certificates are in place, kubelet will use NLLB just fine. Moreover, the k0s controller was basically doing the same before (connecting to the local API server only) to generate the bootstrap token. |
Signed-off-by: Tom Wieczorek <[email protected]>
It has to be always of type controller-bootstrap. Integrate that check into the join client creation function instead. Signed-off-by: Tom Wieczorek <[email protected]>
This will be handled by the upstream client config loading code just fine. Signed-off-by: Tom Wieczorek <[email protected]>
Instead of doing it once during the bootstrapping process. This eliminates the need for another persistent flle in k0s's data directory, allows the use of arbitrary kubelet bootstrap kubeconfigs (as long as they're valid), and removes a potential panic for bootstrap kubeconfigs that don't have a cluster called "k0s". Signed-off-by: Tom Wieczorek <[email protected]>
Use a structured logger, remove "kubelet" from log and error messages, as that's now obvious from the context. Signed-off-by: Tom Wieczorek <[email protected]>
When a controller bootstraps its embedded kubelet, it doesn't have to use a join token at all. Instead, it can just bootstrap the kubelet configuration using its own admin kubeconfig. Add a new KubeconfigGetter argument to the worker start method. If running from a controller, this will simply point to the admin kubeconfig. When running as a standalone worker, this will actually be backed by the join token, if any. Signed-off-by: Tom Wieczorek <[email protected]>
9ef2e71 to
bf2a8e2
Compare
Description
When a controller bootstraps its embedded kubelet, it doesn't have to use a join token at all. Instead, it can just bootstrap the kubelet configuration using its own admin kubeconfig.
Add a new KubeconfigGetter argument to the worker start method. If running from a controller, this will simply point to the admin kubeconfig. When running as a standalone worker, this will actually be backed by the join token, if any.
Extract kubelet's CA from its kubeconfig, instead of doing it once during the bootstrapping process. This eliminates the need for another persistent flle in k0s's data directory, allows the use of arbitrary kubelet bootstrap kubeconfigs (as long as they're valid), and removes a potential panic for bootstrap kubeconfigs that don't have a cluster called "k0s".
Improve logging during kubelet config bootstrapping: Use a structured logger, remove "kubelet" from log and error messages, as that's now obvious from the context.
Remove the explicit initialization of the kubelet cert directory. This will be handled by the upstream client config loading code just fine.
Remove the join client's token type. It has to be always of type controller-bootstrap. Integrate that check into the join client creation function instead.
Introduce constants for join token auth names.
Type of change
How Has This Been Tested?
Checklist: