kubeadm
kubeadm copied to clipboard
kubeadm init can't skip all phases
Is this a BUG REPORT or FEATURE REQUEST?
BUG REPORT
Versions
kubeadm version (use kubeadm version
):
v1.24.3
Environment:
-
Kubernetes version (use
kubectl version
): - Cloud provider or hardware configuration:
- OS (e.g. from /etc/os-release):
-
Kernel (e.g.
uname -a
): - Container runtime (CRI) (e.g. containerd, cri-o):
- Container networking plugin (CNI) (e.g. Calico, Cilium):
- Others:
What happened?
I ran
kubeadm init --skip-phases=preflight,certs,kubeconfig,kubelet-start,control-plane,etcd,wait-control-plane,upload-config,upload-certs,mark-control-plane,bootstrap-token,kubelet-finalize,addon
But, it prints
failed to print join command: failed to load kubeconfig: open /etc/kubernetes/admin.conf: no such file or directory
What you expected to happen?
Since all phaess are skipped, the kubeadm
shouldn't report error.
Or we cound make showJoinCommand()
into some phase or another phase, this way we can also skip it.
How to reproduce it (as minimally and precisely as possible)?
Anything else we need to know?
i am tempted to claim this as "won't fix" because the use case for skipping all phases is not realistic.
but overall printing the join command could have been a separate phase.
@SataQiu @pacoxu thoughts?
+1 for moving showJoinCommand
into a separate phase.
So we can also skip it.
Emm... But we also need to consider making similar changes to other commands( join/reset/upgrade )
In my case, when I want to print the join command
, I have to create a new token if there is no token and generate the command line by myself. If we have the phrase, it may help in this case.
Hence +1 to have a separate phase. To me, this is more like a small feature/refactor.
ok we seem to have agreement.
one problem is how to deal with the --skip-token-print flag of init if this becomes a phase. would the flag also effectively act like a phase skip? possibly, yes.
also code freeze is august 3rd in a few days.
Here's a tricky one problem. If user does not provide a CertificateKey
, kubeadm will generate a random key to encrypt the certs. Unfortunately, this key is not persisted. If we run showJoinCommand
phase alone, the CertificateKey
will be re-generated, which is wrong. @neolit123 thoughts?
https://github.com/kubernetes/kubernetes/blob/f6e163fe27f2d698af5309aa946515ee62d98e40/cmd/kubeadm/app/cmd/phases/init/uploadcerts.go#L63-L69
running show join command on its own does not make sense. but if we skipped the upload certs phase then it means we skipped encypting / uploading certs and generating a random key in the standalone show join command doesn't matter? i could be missing some points here.
with code freeze 2 days away i think we may want to hold this change.
Emm... Maybe we should establish dependencies between phases.
if the user is skipping all phases except the one for showing the print command i think its fair for that phase to fail. a couple of reasons would be - no token, no cert key and no admin.conf, because the phases that produce those were skipped. if we execute the required phases as dependencies i think it can create some cases that are difficult to maintain and will also conflict with the user intent of skipping the phases.
edit: also phases are CLI and the CLI is GA and everytime we change their behavior we have to be carefull.
Yeah, you are right, but some cases seem tricky.
For example, first execute all the init phases except show-join-command
, and then run show-join-command
phase alone.
In this scenario, show-join-command
phase will execute successfully, because all the needed resources exist.
But the join command is totally wrong, because the token and cert key is randomly generated every time.
i think we are rediscovering here why we did not make it into a phase from the beginning.
we could try detecting if the phase is executed standalone and show a warning that the secrets are not actual.
...or just fail the phase, which i think is better.