Kubernetes: discuter de la façon dont kubeadm init doit traiter le fichier qui existe déjà

J'ai jeté un œil à la partie init de kubeadm. Dans la première exécution de kubeadm, nous laissons kubeadm faire son travail et créer tous les actifs nécessaires.
Les utilisateurs peuvent fournir leurs propres fichiers de certificat et de clé, auquel cas nous analyserons les valeurs des fichiers et poursuivrons l'exécution.

Lors de chaque run suivant (le but est de le rendre idempotent) :

• Manifestes de pod statiques : ce que j'ai fait, c'est regarder les actifs nouvellement générés si certains/tous les manifestes ont changé en raison de la fourniture de nouvelles configurations par l'utilisateur, nous demandons à l'utilisateur s'il souhaite les écraser.
• Actifs PKI : délicat. Si rien n'a changé, nous n'avons rien à faire et nous pouvons simplement analyser les valeurs et tenter de communiquer avec le serveur API et laisser kubeadm terminer son exécution. Si l'utilisateur a créé de nouveaux actifs pki et souhaite les utiliser, le système kubelet devra être arrêté, les nouvelles confs etc... écrites et kubelet redémarré.

_C'est ma première tentative avec kubeadm, donc j'apprécierais vos commentaires si ma réflexion va dans la bonne direction. À moins d'arrêter le kubelet d'écrire les confs, j'ai déjà fini de coder ma solution suggérée et l'ai testée pour la plupart._

D'accord, nous avons donc décidé d'exiger un kubeadm reset entre deux kubeadm init/join avec des vérifications en amont. Les fichiers créés par kubeadm peuvent ne pas exister auparavant

désolé de l'ouvrir à nouveau, je ne comprends pas. Quelqu'un peut-il donner un exemple sur la façon dont je peux faire en sorte que kubeadm init agisse de manière idempotente ou m'indique la bonne direction, par exemple lorsque j'utilise Ansible pour automatiser la création de clusters ?