Kubernetes: discuss how should kubeadm init treat file that already exits

[errordeveloper]

For example, we do need to allow importing PKI assets... having an asset abstraction could help with this and an dry-run mode etc, however let's discuss this from user's perspective. Some users said they'd like to kubeadm init and kubeadm join to be idempotent.

[kenan435]

I had a look at the kubeadm init part. In the initial run of kubeadm we let kubeadm do its thing and create all the necessary assets.
Users can provide their own cert and key files in which case we would parse the values from the files and continue execution.

During each subsequent run (goal is to make it idempotent):

• Static pod manifests: what I did is look at the newly generated assets if some/all manifests changed due to user providing new configurations, we promt the user if they would like to overwrite.
• PKI assets: tricky. If nothing has changed then we don't need to do anything and we can just parse the values and attempt to communicate with api server and let kubeadm finish its run. If the user created new pki assets and wants to use those, system kubelet would need to be stopped new confs etc... written and kubelet started up again.

_This is my first endeavor with kubeadm so I would appreciate feedback if my thinking is heading in the right direction. Short of stopping the kubelet writing the the confs, I have already finished coding my suggested solution and tested it for the most part._

[luxas]

Ok, so we have decided to require a kubeadm reset in between two kubeadm init/join runs with preflight checks. The files that kubeadm is creating may not exist in beforehand

[616b2f]

sorry for opening this again I don't get it. Can someone make an example how I can get kubeadm init to act idempotent or point me to the right direction e.g. when I use Ansible to automate cluster creation?