Kubernetes: discutir cómo debe kubeadm init tratar el archivo que ya existe

Eché un vistazo a la parte init de kubeadm. En la ejecución inicial de kubeadm, dejamos que kubeadm haga lo suyo y cree todos los activos necesarios.
Los usuarios pueden proporcionar sus propios archivos de claves y certificados, en cuyo caso analizaríamos los valores de los archivos y continuaríamos con la ejecución.

Durante cada ejecución posterior (el objetivo es hacerlo idempotente):

• Manifiestos de pod estáticos : lo que hice fue mirar los activos recién generados si algunos / todos los manifiestos cambiaron debido a que el usuario proporcionó nuevas configuraciones, le preguntamos al usuario si desea sobrescribir.
• Activos de PKI : complicado. Si nada ha cambiado, entonces no necesitamos hacer nada y podemos simplemente analizar los valores e intentar comunicarnos con el servidor api y dejar que kubeadm termine su ejecución. Si el usuario creó nuevos activos de pki y quiere usarlos, el sistema kubelet deberá detenerse, se deben escribir nuevas confs, etc., y kubelet se reiniciará.

_Este es mi primer esfuerzo con kubeadm, por lo que agradecería recibir comentarios si mi pensamiento va en la dirección correcta. Aparte de detener el kubelet escribiendo las confs, ya terminé de codificar mi solución sugerida y la probé en su mayor parte.

Ok, entonces hemos decidido requerir kubeadm reset entre dos ejecuciones kubeadm init/join con comprobaciones previas al vuelo. Es posible que los archivos que crea kubeadm no existan de antemano

perdón por abrir esto de nuevo, no lo entiendo. ¿Alguien puede dar un ejemplo de cómo puedo hacer que kubeadm init actúe de forma idempotente o me indique la dirección correcta, por ejemplo, cuando uso Ansible para automatizar la creación de clústeres?