<p>kubeadm alpha phase certs erneuern alle sollten auch certs in KubeConfig-Dateien aktualisieren</p>

@ MalloZup
Natürlich, aber bitte beachten Sie, dass die Join-Phasen eine hohe Priorität haben.

klingt gut! Vielen Dank.

Hallo,

Zu diesem Thema gibt es noch etwas.

kubeadm alpha phase kubeconfig all zeigt diese Meldung an, wenn bei der Ausgabe des Befehls Conf-Dateien vorhanden sind:

[kubeconfig] Using existing up-to-date KubeConfig file: "/etc/kubernetes/admin.conf"
[kubeconfig] Using existing up-to-date KubeConfig file: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Using existing up-to-date KubeConfig file: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Using existing up-to-date KubeConfig file: "/etc/kubernetes/scheduler.conf"

Es wird nicht überprüft, ob Zertifikate abgelaufen sind, daher ist up-to-date meiner Meinung nach irreführend.

Um die aktualisierten Zertifikate in die Dateien zu bekommen, MÜSSEN Sie die Dateien im Voraus entfernen, da das Protokoll folgendermaßen aussieht:

[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"   

In meinem Fall geht es mir zwar gut, aber ein paar Tage später konnten statische Pods aufgrund veralteter Zertifikate nicht kommunizieren.

Freundliche Grüße
Andreas

Zugewiesen an @MalloZup

@MalloZup : GitHub hat mir nicht erlaubt, die folgenden Benutzer zuzuweisen: MalloZup.

Beachten Sie, dass nur kubernetes-Mitglieder und Repo-Mitarbeiter zugewiesen werden können und dass Issues / PRs nur 10 Beauftragte gleichzeitig haben können.
Weitere Informationen finden Sie im Leitfaden für Mitwirkende

Hallo @adoerler Danke für die Ausgabe. In Bezug auf die irreführenden Informationen habe ich eine PR https://github.com/kubernetes/kubernetes/pull/73798 gesendet

Ich werde mir den Rest der Ausgabe ansehen, sobald ich Zeit habe. Vielen Dank für die Zeit und Präzision des Problems

@adoerler Ich habe einen DOC-
(https://github.com/kubernetes/website/pull/12579)

Hallo @MalloZup ,

Danke für die PR!

Ich vermisse einen Satz über die kubeconfig-Dateien, weil certs renew nur ein Teil des Spiels ist.
Etwas wie:

Vergessen Sie nach der Erneuerung der Zertifikate nicht, die KubeConfig-Dateien mit kubeadm alpha phase kubeconfig ... neu zu erstellen

Danke. Ich habe das Dokument nicht hinzugefügt, weil ich dachte, dass wir tatsächlich auch kubeconfig-Dateien erneuern könnten. Den Rest starten wir Pods neu, die wir an den Benutzer delegieren und minimale Dokumente schreiben können. @fabriziopandini @lubomir @ereslibre Fehlt mir etwas an dieser Implementierung? Tia

@MalloZup Ich habe keine tiefen Kenntnisse darüber, wie die Erneuerung von Zertifikaten funktioniert.

Persönlich möchte ich ein wenig die gesamte Geschichte klären, bevor ich Maßnahmen ergreife - einschließlich der oben vorgeschlagenen -:

• Was sollte von kubeadm alpha phase certs renew verwaltet werden
• Was sollte während kubeadm upgrade automatisch verwaltet werden
• Was sollte dokumentiert (und von den Benutzern verwaltet) werden?
• wie dies auf HA-Cluster zutrifft
• wie dies durch Clustervarianten beeinflusst wird (wie z. B. External etcd, External CA)
• usw.

Aber ich überlasse das letzte Wort den Fachleuten auf diesem Gebiet

Ich denke, wir sollten Zeit für ein Meeting reservieren, um zu besprechen, wie unsere empfohlene Richtlinie zur Erneuerung von Zertifikaten lauten sollte. Die Seite über die Verwaltung von Zertifikaten benötigt möglicherweise einige zusätzliche Details:
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs

und wir müssen eine kleine Anleitung schreiben, zumindest für einzelne Steuerebenencluster als Anfang.

Was Benutzer getan haben, ist, die Dinge selbst herauszufinden:
https://github.com/kubernetes/kubeadm/issues/581#issuecomment -421477139
^ Dieser Kommentar und einer der oben genannten enthalten benutzerdefinierte Anleitungen.

Dies ist ein Zeichen dafür, dass wir einen offiziellen Leitfaden hinzufügen müssen.
cc @timothysc @liztio

/ @ereslibre zuweisen

Unser Cluster mit ein paar hundert Benutzern steckt derzeit fest. Könnte ich eine sehr kurze Anleitung haben, was ich mit abgelaufenen Zertifikaten tun soll?

@ dimm0

Was Benutzer getan haben, ist, die Dinge selbst herauszufinden:
# 581 (Kommentar)
^ Dieser Kommentar und einer der oben genannten enthalten benutzerdefinierte Anleitungen.

Dies sind die einzigen Führer, die wir Geldautomaten haben.

[root<strong i="5">@controller0</strong> ~]# kubeadm alpha phase certs apiserver --apiserver-advertise-address 1.2.3.4
Error: unknown flag: --apiserver-advertise-address
Usage:

Flags:
  -h, --help   help for phase

Global Flags:
      --log-file string   If non-empty, use this log file
      --rootfs string     [EXPERIMENTAL] The path to the 'real' host root filesystem.
      --skip-headers      If true, avoid header prefixes in the log messages
  -v, --v Level           log level for V logs

error: unknown flag: --apiserver-advertise-address
[root<strong i="6">@controller0</strong> ~]# kubeadm alpha phase certs apiserver
This command is not meant to be run on its own. See list of available subcommands.

In 1.13 sind die Init-Phasen zum übergeordneten Init-Befehl übergegangen:
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd -phase-certs

in 1.12 sollte die Flagge da sein:
https://v1-12.docs.kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd -phase-certs

1.11 wird bald nicht mehr unterstützt.

Entfernen des Lebenszyklus- / Aktivetiketts.
Bewegen auf 1.15.

Mögliche Dokumente aktualisieren Ideen hier:
https://github.com/kubernetes/kubeadm/issues/1361#issuecomment -463192631

@ neolit123
Frage: In 1.14 mit Master HA reicht es aus, dem https://github.com/kubernetes/kubeadm/issues/581#issuecomment -421477139 auf einem einzelnen Master zu folgen, oder wir müssen uns erneut den sekundären Mastern anschließen, um dies zu tun Zertifikate zurückholen?

Die Wiederverbindung mit den Knoten der sekundären Steuerebene scheint in 1,14 eine schnelle und praktikable Option zu sein.
Wir haben noch keine Dokumente in Bezug auf HA-Zertifizierungsrotationen.
(Ganz zu schweigen davon, dass wir noch keine richtigen Schritte hinzufügen müssen, wie dies https://github.com/kubernetes/kubeadm/issues/581#issuecomment-421477139 getan hat).

Bietet --experimental-upload-certs nicht die Grundlage für eine einfachere Lösung für die Zertifikatsrotation in HA?

Eine Möglichkeit zur Rotation von HA-Zertifikaten ist:

• Befolgen Sie auf einem einzelnen Steuerebenenknoten die oben genannten Schritte, um die Zertifikate zu aktualisieren
• auf demselben CP-Knotenaufruf:

kubeadm init phase upload-certs --experimental-upload-certs

Bewahren Sie den Zertifikatsschlüssel auf.

kubeadm token create --print-join-command

Speichern Sie den Join-Befehl mit dem Token.

Verbinden Sie den Rest der Steuerebenenknoten mit dem Token- und Certs-Schlüssel nacheinander mit --certs-key .... --experimental-control-plane-join

für die Arbeiter: abtropfen lassen, mit dem neuen Token wieder verbinden, uncordon, eins nach dem anderen.

Optional können Sie die resultierenden Token löschen.

@ neolit123
In einem 3-Master-Cluster funktioniert die etcd in dem Moment, in dem wir die Zertifikate auf dem "primären" Master ändern, nicht mehr, da die Zertifikate geändert werden (und das Quorum muss mindestens 51% betragen). Wenn ja, müssen wir vielleicht die 2 sekundären Master irgendwie absperren und erst dann die Zertifikate wechseln? Ist "Cordon Master" möglich?

Ich bin hier kein Experte, aber ich denke nicht, dass eine automatische Zertifikatskopie in dieses Bild gelangen sollte

Automatische Kopierzertifikate verarbeiten CA, Front-Proxy-CA, etcd-CA (mit 10 Jahren TTL) und SA-Schlüssel (ohne TTL).

Der Befehl zum Erneuern des Zertifikats berührt alle anderen Zertifikate (mit 1 Jahr TTL), die sich je nach Master unterscheiden.
AFAIK, derzeit gibt es nichts, was die Erneuerung von Zertifikaten für kubeconfig-Dateien regelt

ok, ich habe nicht darüber nachgedacht, was "certs copy" hier eigentlich macht.
Wir müssen in jedem Fall die richtigen Zertifikatsrotationsdokumente schreiben.

/zuordnen
/ Lebenszyklus aktiv

Ich fange an, an diesem Thema zu arbeiten.
Es gibt verschiedene Punkte, die angesprochen werden müssen (aktualisiert am 14. Mai 2019).

• Selbst wenn die Zertifikatsrotation aktiviert ist, verweist kubelet.conf auf veraltete Zertifikate (bereits von https://github.com/kubernetes/kubeadm/issues/1317 verfolgt).
• Durch die Zertifikatrotation werden die Zertifikate von apiserver / etcd / front-proxy-client nicht aktualisiert (behoben durch https://github.com/kubernetes/kubernetes/pull/76862).
• Der Befehl kubeadm alpha phase certs erneuert alle aktualisiert KubeConfig-Dateien nicht (behoben durch https://github.com/kubernetes/kubernetes/pull/77180)
• Dokumentation zur Erneuerung von Zertifikaten (mit detaillierteren Informationen darüber, wo der Befehl ausgeführt werden soll, wann, kubeconfig, HA)

Und ich werde sie alle in separaten PRs angehen

@ neolit123 @fabriziopandini
Sind die Schritte, die Sie erwähnt haben, auch zum Drehen des CA-Zertifikats? Kann das auch dokumentiert werden? Was ist mit dem Drehen der privaten Schlüssel, einschließlich des Schlüssels für die Zertifizierungsstelle?

Die @ tushar00jain- Rotation des CA-Zertifikats wird in einem anderen Problem verfolgt: https://github.com/kubernetes/kubeadm/issues/1350
Diese Ausgabe konzentriert sich nur auf signierte Zertifikate

@fabriziopandini Ich wollte dieses Ticket heute schließen, da Sie PRs für die Erneuerungsteile senden konnten. sollte das Ticket geschlossen sein?

Selbst wenn die Zertifikatsrotation aktiviert ist, verweist kubelet.conf auf veraltete Zertifikate (bereits von # 1317 verfolgt).

Ja, dies wird in einer separaten Ausgabe nachverfolgt. Möglicherweise sind Diskussionen / Dokumente erforderlich, um festzustellen, welche Problemumgehungen wir bereitstellen sollten.

Durch die Zertifikatsrotation werden die Zertifikate von apiserver / etcd / front-proxy-client nicht aktualisiert (behoben durch kubernetes / kubernetes # 76862).

Der Befehl kubeadm alpha phase certs erneuer alle aktualisiert KubeConfig-Dateien nicht (behoben durch kubernetes / kubernetes # 77180)

Dokumentation zur Erneuerung von Zertifikaten (mit detaillierteren Informationen darüber, wo der Befehl ausgeführt werden soll, wann, kubeconfig, HA)

Die 3 oben sollten gemacht werden.

/schließen
Wie oben erwähnt, sind die meisten Arbeiten bereits abgeschlossen. Das fehlende Bit wird in einem separaten / dedizierten Problem verfolgt

@fabriziopandini : Dieses Problem wird geschlossen.

Kann mir bitte jemand erklären, wie der Teil "Auch wenn die Zertifikatsrotation aktiviert ist, zeigt kubelet.conf auf veraltete Zertifikate" behandelt wurde? Das einzige verknüpfte Problem, das dies ausdrücklich erwähnt, wurde zugunsten eines anderen Problems geschlossen, das mit "Ich bin nicht sicher, ob dies ein Problem ist, also öffne ein neues Ticket, wenn es ist" geschlossen wird.
Ich bin auf 1.16 und sehe keine Erneuerung bei kubelet.conf mit sudo kubeadm alpha certs renew all . Was fehlt? @ neolit123

eine kurze Zusammenfassung einer sehr sehr langen Diskussion.

1. Zertifikatsrotation für alle Zertifikate außer kubelet.conf wird jetzt von kubeadm alpha cert erneuern verwaltet.
2. Die Zertifikatsrotation für kubelet.conf wird von kubelet selbst verwaltet (es sei denn, der Benutzer deaktiviert die automatische Zertifikatsrotation).

Dieser zweite Punkt funktioniert bereits ab heute für alle Knoten mit Ausnahme des Knotens, auf dem Sie kubeadm init ausführen. https://github.com/kubernetes/kubernetes/pull/84118 wird das beheben

@fabriziopandini Danke dafür, es macht Sinn.

Für alle anderen, die mit dem Problem konfrontiert sind, dass die Zertifikate in kubelte.conf zwischen jetzt und dem Zeitpunkt, an dem das oben Gesagte behoben wurde, nicht mehr aktuell sind, fand ich diesen Artikel hilfreich:

https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#check -certificate-expiration

Auf Knoten, die mit kubeadm init vor kubeadm Version 1.17 erstellt wurden, gibt es einen Fehler, bei dem Sie den Inhalt von kubelet.conf manuell ändern müssen. Nach Abschluss von kubeadm init sollten Sie kubelet.conf so aktualisieren, dass es auf die gedrehten kubelet-Clientzertifikate verweist, indem Sie Clientzertifikatsdaten und Clientschlüsseldaten durch Folgendes ersetzen:

client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem
client-key: /var/lib/kubelet/pki/kubelet-client-current.pem

@ AndrewSav Danke dafür. Ich habe den Promethes-Operator verwendet, um den Cluster zu überwachen. Ich habe kürzlich eine Warnung erhalten, dass das Kubernetes-API-Zertifikat in weniger als 7 Tagen abläuft. Ich denke, es hängt mit diesem Problem zusammen. Ich habe den Inhalt von kubelet.conf auf den Masterknoten aktualisiert. Aber ich bekomme immer noch den Alarm. Hast du irgendwelche Vorschläge? Tks.

@tannh Wenn Sie den Cluster mit kubeadm installiert haben, verwenden Sie kubeadm, um die Erfahrung mit Zertifikaten zu überprüfen. Andernfalls hängt Ihr Problem wahrscheinlich nicht zusammen.

Auf Knoten, die mit kubeadm init vor kubeadm Version 1.17 erstellt wurden, gibt es einen Fehler, bei dem Sie den Inhalt von kubelet.conf manuell ändern müssen. Nach Abschluss von kubeadm init sollten Sie kubelet.conf so aktualisieren, dass es auf die gedrehten kubelet-Clientzertifikate verweist, indem Sie Clientzertifikatsdaten und Clientschlüsseldaten durch Folgendes ersetzen:

Dies wird auch in den Versionshinweisen für 1.17 enthalten sein.

@adoerler Ich verwende immer noch die alte Version von kubeadm. Wie kann ich die Datei kubelet.conf, admin.con usw. nach der Erneuerung des Zertifikats aktualisieren?

Ich habe "kubeadm alpha certs erneuer alle" ausgeführt, wodurch neue Zertifikate generiert wurden. Dann muss ich alle .conf unter / etc / kubernetes bearbeiten. Wie? wo genau sollten sie zeigen?
und sollte ich bei Multi-Master-Knoten den Befehl in allen Mastern ausführen?

Hallo @SuleimanWA ,

Ich kann Ihnen nicht sagen, was Sie mit einer Multi-Master-Umgebung tun sollen. Ich hatte nur einen einzigen Master in meinem Setup.

Folgendes habe ich getan:

Stellen Sie zunächst sicher, dass vorhandene conf-Dateien aus dem Weg geräumt werden, da vorhandene Dateien nicht überschrieben werden!

mv /etc/kubernetes/admin.conf /backup
mv /etc/kubernetes/kubelet.conf /backup
mv /etc/kubernetes/controller-manager.conf /backup
mv /etc/kubernetes/scheduler.conf /backup

Aktualisieren Sie dann diese Dateien:

user<strong i="13">@master</strong>:~$ sudo kubeadm alpha phase kubeconfig all --apiserver-advertise-address=<INSERT-YOUR-APISERVER-IP-HERE>
I0124 21:56:14.253641   15040 version.go:236] remote version is much newer: v1.13.2; falling back to: stable-1.12
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"    

Um die neuen Zertifikate in den statischen System-Pods anzuwenden, war es für mich am einfachsten, den Master-Server einfach neu zu starten.

Vergessen Sie nicht, client-certificate-data und client-key-data von /etc/kubernetes/admin.conf auf Ihr lokales .kube/config kopieren.

Hoffe das hilft

Andreas

Irgendeine Idee, wie man diesen Befehl unter 1.14.10 ausführt? Alles was ich bekomme ist:

kubeadm alpha phase kubeconfig all --apiserver-advertise-address=192.168.102.170 Error: unknown flag: --apiserver-advertise-address

Dann sagen die Dokumente:
kubeadm alpha phase kubeconfig all
und ich bekomme:
This command is not meant to be run on its own. See list of available subcommands.

Vielen Dank

Hallo @provgregoryabdo ,

Was ist Ihre kubeadm version Ausgabe?

BR Andreas

@provgregoryabdo die phase -Befehle wurden aus Alpha verschoben und in späteren Versionen initiiert, damit Sie so etwas wie verwenden können

kubeadm init phase kubeconfig all --apiserver-advertise-address=<your_address>

@adoerler danke für die