Kubernetes: diskutieren, wie kubeadm init eine Datei behandeln soll, die bereits beendet ist

Ich habe mir den kubeadm-Init-Teil angesehen. Im ersten Durchlauf von kubeadm lassen wir kubeadm sein Ding machen und alle notwendigen Assets erstellen.
Benutzer können ihre eigenen Zertifikats- und Schlüsseldateien bereitstellen. In diesem Fall würden wir die Werte aus den Dateien analysieren und die Ausführung fortsetzen.

Bei jedem weiteren Lauf (Ziel ist es, ihn idempotent zu machen):

• Statische Pod-Manifeste : Ich habe mir die neu generierten Assets angesehen, wenn sich einige/alle Manifeste geändert haben, weil der Benutzer neue Konfigurationen bereitstellt. Wir fragen den Benutzer, ob er überschreiben möchte.
• PKI-Assets : knifflig. Wenn sich nichts geändert hat, müssen wir nichts tun und können einfach die Werte analysieren und versuchen, mit dem API-Server zu kommunizieren und kubeadm seinen Lauf beenden lassen. Wenn der Benutzer neue pki-Assets erstellt und diese verwenden möchte, muss das System-Kubelet gestoppt werden, neue confs usw. geschrieben werden und Kubelet neu gestartet werden.

_Dies ist mein erster Versuch mit kubeadm, daher würde ich mich über Feedback freuen, wenn meine Denkweise in die richtige Richtung geht. Abgesehen davon, dass das Kubelet das Schreiben der confs gestoppt hat, habe ich meine vorgeschlagene Lösung bereits fertig codiert und größtenteils getestet._

Okay, wir haben uns entschieden, zwischen zwei kubeadm init/join Läufen mit Preflight-Checks ein kubeadm reset zu fordern. Die Dateien, die kubeadm erstellt, sind möglicherweise vorher nicht vorhanden

Entschuldigung, dass ich das nochmal öffne, ich verstehe es nicht. Kann mir jemand ein Beispiel geben, wie ich kubeadm init dazu bringen kann, idempotent zu handeln oder mich in die richtige Richtung zu weisen, z. B. wenn ich Ansible verwende, um die Clustererstellung zu automatisieren?