Kubernetes: discuta como o kubeadm init deve tratar o arquivo que já existe

Eu dei uma olhada na parte init do kubeadm. Na execução inicial do kubeadm, deixamos o kubeadm fazer seu trabalho e criar todos os ativos necessários.
Os usuários podem fornecer seus próprios arquivos de certificado e chave, caso em que analisaríamos os valores dos arquivos e continuaríamos a execução.

Durante cada execução subsequente (o objetivo é torná-lo idempotente):

• Manifestos de pod estáticos : o que fiz foi olhar para os ativos recém-gerados, se alguns / todos os manifestos mudassem devido ao usuário fornecer novas configurações, avisamos ao usuário se ele gostaria de substituir.
• Ativos de PKI : complicado. Se nada mudou, não precisamos fazer nada e podemos apenas analisar os valores e tentar nos comunicar com o servidor API e deixar o kubeadm terminar sua execução. Se o usuário criou novos recursos pki e deseja usá-los, o kubelet do sistema precisará ser interrompido, novos confs, etc ... escritos e o kubelet inicializado novamente.

_Este é meu primeiro esforço com o kubeadm, então gostaria de receber um feedback se meu pensamento estiver indo na direção certa. Com exceção de parar o kubelet de escrever os confs, já terminei de codificar minha solução sugerida e testei-a em sua maior parte._

Ok, então decidimos exigir um kubeadm reset entre duas execuções de kubeadm init/join com verificações de comprovação. Os arquivos que o kubeadm está criando podem não existir antes

desculpe por abrir de novo, não entendi. Alguém pode dar um exemplo de como posso fazer o kubeadm init agir de forma idempotente ou me apontar a direção certa, por exemplo, quando eu uso o Ansible para automatizar a criação do cluster?