GKE on VMware verwendet Zertifikate und private Schlüssel, um die Kommunikation zwischen Kubernetes-Systemkomponenten in einem Administratorcluster zu authentifizieren. Wenn Sie einen Administratorcluster erstellen, werden neue Zertifizierungsstellenzertifikate erstellt. Diese Root-Zertifikate werden zur Ausgabe zusätzlicher Blattzertifikate für Kubernetes-Systemkomponenten verwendet.
Dieser Leitfaden gilt nur für die Rotation von CA-Zertifikaten von Administratorclustern. Informationen zu Nutzerclustern finden Sie unter CA-Zertifikate von Nutzerclustern rotieren.
Im Kubernetes-System in einem Administratorcluster gibt es drei CA-Zertifikate:
Das etcd-CA-Zertifikat sichert die Kommunikation vom Kubernetes API-Server zu den etcd-Replikaten sowie die Kommunikation zwischen etcd-Replikaten. Dieses Zertifikat ist selbst signiert.
Das Cluster-CA-Zertifikat sichert die Kommunikation zwischen dem Kubernetes API-Server und allen internen Kubernetes API-Clients, z. B. dem Kubelet, dem Controller-Manager und dem Planer. Dieses Zertifikat ist selbst signiert.
Das Front-Proxy-CA-Zertifikat schützt die Kommunikation mit aggregierten APIs. Dieses Zertifikat ist selbst signiert.
Mit gkectl können Sie eine Zertifikatsrotation auslösen. Während einer Rotation ersetzt gkectl die Kernsystem-CA-Zertifikate für den Administratorcluster durch neu generierte Zertifikate. Anschließend werden die neuen CA-Zertifikate, Blattzertifikate und privaten Schlüssel auf die Systemkomponenten des Administratorclusters verteilt. Die Rotation erfolgt schrittweise, damit Systemkomponenten während der Rotation weiterhin kommunizieren können. Beachten Sie jedoch, dass Arbeitslasten und Knoten während der Rotation neu gestartet werden.
Ohne Rotation laufen Zertifikate von Zertifizierungsstellen und Steuerungsebenen fünf Jahre nach dem Datum ab, an dem der Cluster erstellt wurde. Die Zertifikate der Steuerungsebene werden während eines Clusterupgrades automatisch rotiert. Die CAs werden jedoch nicht automatisch rotiert. Das bedeutet, dass mindestens alle fünf Jahre eine CA-Rotation zusätzlich zu den regelmäßigen Versionsupgrades durchgeführt werden muss.
Beschränkungen
Die Rotation von CA-Zertifikaten ist auf die zuvor genannten etcd-, Cluster- und Front-Proxy-Zertifikate beschränkt.
Die Rotation von CA-Zertifikaten ist auf Zertifikate beschränkt, die automatisch von GKE on VMware ausgestellt werden. Zertifikate, die von einem Administrator manuell ausgestellt wurden, werden nicht aktualisiert, auch wenn sie von den System-CAs signiert sind.
Durch die Rotation des CA-Zertifikats werden der Kubernetes API-Server, andere Prozesse der Steuerungsebene und jeder Knoten im Administratorcluster mehrmals neu gestartet. Jede Phase der Rotation verläuft ähnlich wie ein Clusterupgrade. Auch wenn der Administratorcluster und die vom Administratorcluster verwalteten Nutzercluster während der Zertifikatsrotation funktionsfähig bleiben, sollten Sie davon ausgehen, dass die Arbeitslasten im Administratorcluster neu gestartet und neu geplant werden. Sie sollten auch kurze Ausfallzeiten für die Steuerungsebene des Administratorclusters und die Steuerungsebene der Nutzercluster erwarten.
Sie müssen die kubeconfig-Datei des Administratorclusters in der Mitte einer Zertifikatsrotation und noch einmal, nachdem die Rotation abgeschlossen ist, aktualisieren. Das liegt daran, dass das alte Clusterzertifikat widerrufen wird und die Anmeldedaten in der kubeconfig-Datei nicht mehr funktionieren.
Nach der Initiierung kann die Rotation eines CA-Zertifikats nicht mehr rückgängig gemacht werden.
Eine CA-Zertifikatsrotation kann je nach Größe des Clusters viel Zeit in Anspruch nehmen.
Wenn die Rotation des Zertifikats fortgesetzt werden soll, wenn sie unterbrochen wird, können Sie den gleichen Befehl noch einmal ausführen. Sie müssen jedoch darauf achten, dass jeweils nur ein Rotationsbefehl ausgeführt wird.
Rotation starten
Führen Sie den folgenden Befehl aus, um die Zertifikatsrotation zu starten. Dies führt die erste Hälfte der Rotation aus und stoppt an einem Pausenpunkt.
Starten Sie die Rotation:
gkectl update credentials certificate-authorities rotate \
--admin-cluster \
--config ADMIN_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
Ersetzen Sie Folgendes:
ADMIN_CLUSTER_CONFIG: der Pfad Ihrer Administratorcluster-Konfigurationsdatei.
ADMIN_CLUSTER_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters
Wenn der Befehl unterbrochen wird, setzen Sie ihn mit dem gleichen Befehl fort.
kubeconfig-Datei aktualisieren
Wenn der vorherige Befehl pausiert, aktualisieren Sie die kubeconfig-Datei für den Administratorcluster. Dadurch wird ein neues Clientzertifikat und ein neues CA-Zertifikat in der kubeconfig-Datei abgelegt. Das alte Clientzertifikat wird aus der kubeconfig-Datei entfernt und das alte CA-Zertifikat bleibt in der kubeconfig-Datei.
gkectl update credentials certificate-authorities update-kubeconfig \
--admin-cluster \
--config ADMIN_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
Rotation fortsetzen
Führen Sie den folgenden Befehl aus, um die zweite Hälfte des Verfahrens auszuführen. Der Befehl wird erst fortgesetzt, wenn gkectl kontrolliert hat, dass sich die aktualisierte kubeconfig-Datei im aktuellen Verzeichnis befindet.
gkectl update credentials certificate-authorities rotate \
--admin-cluster \
--complete \
--config ADMIN_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
Wenn der Befehl unterbrochen wird, setzen Sie ihn mit dem gleichen Befehl fort.
Wenn die Rotation abgeschlossen ist, wird die aktuelle CA-Version gemeldet.
kubeconfig-Datei noch einmal aktualisieren
Aktualisieren Sie nach Abschluss der zweiten Hälfte der Rotation die kubeconfig-Datei noch einmal. Dadurch wird das alte CA-Zertifikat aus der kubeconfig-Datei entfernt.
gkectl update credentials certificate-authorities update-kubeconfig \
--admin-cluster \
--config ADMIN_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
Neue kubeconfig-Datei verteilen
Verteilen Sie die neue kubeconfig-Datei des Administratorclusters an alle Clusternutzer.