Abgelaufene Clusterzertifikate manuell verlängern

In diesem Dokument wird beschrieben, wie Sie abgelaufene Zertifikate für Ihre Google Distributed Cloud manuell verlängern. TLS-Zertifikate (Transport Layer Security) werden von den Steuerungsebenenkomponenten der Google Distributed Cloud verwendet. Wenn diese Zertifikate ablaufen, können Sie Arbeitslasten und Clusterlebenszyklen erst wieder verwalten, wenn die Zertifikate verlängert wurden. Weitere Informationen zu den Auswirkungen abgelaufener Zertifikate finden Sie unter Ablauf von Zertifikaten.

Diese Seite richtet sich an Administratoren, Architekten und Betreiber, die den Lebenszyklus der zugrunde liegenden technischen Infrastruktur verwalten und auf Benachrichtigungen und Seiten reagieren, wenn Service Level Objectives (SLOs) nicht erfüllt werden oder Anwendungen ausfallen. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud-Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und ‑Aufgaben.

TLS-Zertifikate, einschließlich etcd-Zertifikate, haben standardmäßig eine Gültigkeitsdauer von einem Jahr. Diese Zertifikate werden in Google Distributed Cloud bei Cluster-Upgrades und beim Rotieren von Zertifizierungsstellen verlängert. Diese Zertifikate werden nicht regelmäßig automatisch aktualisiert. Wir empfehlen, Ihre Cluster regelmäßig zu aktualisieren, damit sie sicher und unterstützt bleiben und TLS-Zertifikate nicht ablaufen.

Fehler aufgrund abgelaufener Zertifikate

Wenn die TLS-Zertifikate in Ihrem Cluster ablaufen, können die Kerncontroller keine TLS-Verbindungen zum Kubernetes API-Server herstellen. Diese fehlende Verbindung führt zu den folgenden Fehlern:

• Serververbindung kann nicht hergestellt werden: x509

  Wenn Sie Ihre Clusterknoten mit kubectl abrufen, enthält die Antwort einen Fehler, dass Ihre Zertifikate abgelaufen sind, ähnlich wie in der folgenden Beispielausgabe:

  Unable to connect to the server: x509: certificate has expired or is not yet valid
  

• could not connect: x509 oder rejected connection

  Abgelaufene Zertifikate blockieren den Zugriff auf den etcd-Cluster, da Peers nicht miteinander kommunizieren können. Die etcd-Logs können Fehlereinträge wie die folgenden enthalten:

  W | rafthttp: health check for peer 6221a1d241bb2d0a could not connect: x509: certificate
  has expired or is not yet valid
  I | embed: rejected connection from "10.200.0.4:46108" (error "remote error: tls: bad
  certificate", ServerName "")
  

Ablaufzeiträume von Zertifikaten prüfen

Führen Sie die folgenden Schritte auf jedem Knoten der Steuerungsebene aus, um die Ablaufzeiten von Zertifikaten zu prüfen:

1. Melden Sie sich auf einer der Maschinen der Steuerungsebene an und führen Sie den folgenden Befehl aus:

   sudo kubeadm certs check-expiration
   

   Die Befehlsausgabe enthält die von kubeadm für die Komponenten der Kontrollebene erstellten Zertifikate und deren Ablaufdatum, wie in der folgenden Beispielausgabe zu sehen:

   CERTIFICATE                EXPIRES                  RESIDUAL TIME   CERTIFICATE AUTHORITY   EXTERNALLY MANAGED
   admin.conf                 Nov 28, 2021 19:09 UTC   53m                                     no
   apiserver                  Nov 28, 2021 19:09 UTC   53m             ca                      no
   apiserver-etcd-client      Nov 28, 2021 19:09 UTC   53m             etcd-ca                 no
   apiserver-kubelet-client   Nov 28, 2021 19:09 UTC   53m             ca                      no
   controller-manager.conf    Nov 28, 2021 19:09 UTC   53m                                     no
   etcd-healthcheck-client    Nov 28, 2021 19:09 UTC   53m             etcd-ca                 no
   etcd-peer                  Nov 28, 2021 19:09 UTC   53m             etcd-ca                 no
   etcd-server                Nov 28, 2021 19:09 UTC   53m             etcd-ca                 no
   front-proxy-client         Nov 28, 2021 19:09 UTC   53m             front-proxy-ca          no
   scheduler.conf             Nov 28, 2021 19:09 UTC   53m                                     no
   
   CERTIFICATE AUTHORITY   EXPIRES                  RESIDUAL TIME   EXTERNALLY MANAGED
   ca                      Nov 26, 2031 18:06 UTC   9y              no
   etcd-ca                 Nov 26, 2031 18:06 UTC   9y              no
   front-proxy-ca          Nov 26, 2031 18:06 UTC   9y              no
   

2. Führen Sie den folgenden Befehl aus, um die Ablaufzeiten für kubelet-Zertifikate zu prüfen:

   sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -text | grep Validity -A2
   sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-server-current.pem -text | grep Validity -A2
   

   Die Antwort für jeden Befehl sieht in etwa so aus:

   Validity
       Not Before: Sep 17 22:27:53 2021 GMT
       Not After : Sep 17 22:33:16 2022 GMT
   

   Wenn alle Knoten der Kontrollebene gleichzeitig gestartet wurden, liegen die Ablaufzeiten der Zertifikate innerhalb weniger Minuten voneinander. Diese Zeitbeziehung gilt für alle Knoten der Steuerungsebene. Sie können die Ablaufzeiten überprüfen, indem Sie die vorherigen Befehle auf jedem Knoten der Steuerungsebene ausführen.

3. Führen Sie den folgenden Befehl auf der Administratorworkstation aus, um das Ablaufdatum des Clientzertifikats in der kubeconfig-Datei des Clusters zu prüfen:

   grep 'client-certificate-data' KUBECONFIG_PATH | \
       awk '{print $2}' | base64 -d | openssl x509 -text | grep Validity -A2
   

   Die Antwort sieht in etwa so aus:

   Validity
       Not Before: Sep 17 22:27:53 2021 GMT
       Not After : Sep 17 22:33:16 2022 GMT
   

4. Führen Sie den folgenden Befehl aus, um das Ablaufdatum des Zertifikats für die Cluster-Kubeconfig im Administratorcluster abzurufen:

   kubectl get secret/CLUSTER_NAME-kubeconfig \
       -n CLUSTER_NAMESPACE \
       --kubeconfig ADMIN_KUBECONFIG \
       -o jsonpath='{.data.value}' | base64 --decode | grep client-certificate-data | \
       awk '{print $2}' | base64 -d | openssl x509 -text | grep Validity -A2
   

   Ersetzen Sie Folgendes:

   • ADMIN_KUBECONFIG: Der Pfad der kubeconfig-Datei des Administratorclusters.

   • CLUSTER_NAME: der Name des Clusters, für den Sie die Zertifikate erneuern.

   • CLUSTER_NAMESPACE: der Namespace des Clusters, für den Sie die Zertifikate erneuern.

   Die Antwort sieht in etwa so aus:

   Validity
       Not Before: Sep 17 22:27:53 2021 GMT
       Not After : Sep 17 22:33:16 2022 GMT
   

   Das kubeconfig-Zertifikat im Admin-Cluster und das Zertifikat in der kubeconfig-Datei auf der Administrator-Workstation sind identisch. Daher müssen die Ausgabe dieses Befehls und der Befehl aus dem vorherigen Schritt übereinstimmen.

Zertifikate manuell verlängern

Folgen Sie der Anleitung in den folgenden Abschnitten, um TLS-Zertifikate für einen Cluster manuell zu verlängern.

Wichtiger Hinweis: Mit der folgenden Anleitung können Sie sowohl abgelaufene als auch nicht abgelaufene Zertifikate erneuern. In beiden Fällen wird die Gültigkeitsdauer der verlängerten TLS-Zertifikate in Ihrem Cluster auf ein Jahr zurückgesetzt. Wir empfehlen dringend, Clusterzertifikate vor Ablauf zu verlängern, um längere Clusterausfälle zu vermeiden. Die empfohlene Methode zum Verlängern von Zertifikaten, bevor sie ablaufen, ist ein regelmäßiges Upgrade Ihrer Cluster.

Zertifikate auf jedem Knoten der Steuerungsebene verlängern

Führen Sie die folgenden Schritte auf jedem Steuerungsebenenknoten des betroffenen Clusters aus:

Wichtig :Sie können Zertifikate nur auf einem Knoten gleichzeitig erneuern. Führen Sie alle Schritte aus, bevor Sie mit einem neuen Knoten der Steuerungsebene beginnen.

1. Sichern Sie den Ordner /etc/kubernetes.

2. Führen Sie den folgenden kubeadm-Befehl aus, um alle Zertifikate zu erneuern. Mit diesem Befehl werden die Zertifikate mit den vorhandenen Zertifizierungsstellen (Certificate Authorities, CAs) auf dem Computer erneuert:

   sudo kubeadm certs renew all
   

   Die Befehlsausgabe sieht dann ungefähr so aus:

   certificate embedded in the kubeconfig file for the admin to use and for kubeadm itself renewed
   certificate for serving the Kubernetes API renewed
   certificate the apiserver uses to access etcd renewed
   certificate for the API server to connect to kubelet renewed
   certificate embedded in the kubeconfig file for the controller manager to use renewed
   certificate for liveness probes to healthcheck etcd renewed
   certificate for etcd nodes to communicate with each other renewed
   certificate for serving etcd renewed
   certificate for the front proxy client renewed
   certificate embedded in the kubeconfig file for the scheduler manager to use renewed
   

3. Prüfen Sie mit dem folgenden Befehl, ob die Zertifikate eine neue Ablaufzeit haben:

   sudo kubeadm certs check-expiration
   

4. Nicht alle Komponenten der Steuerungsebene unterstützen das dynamische Neuladen von Zertifikaten. Um die erneuerten Zertifikate abzurufen, starten Sie die folgenden Container neu: kube-apiserver, etcd, kube-scheduler und kube-controller-manager.

   Wiederholen Sie die folgenden Schritte für jeden der vier Container:

   Hinweis :Wenn Ihre Zertifikate abgelaufen sind, empfehlen wir, zuerst den folgenden Schritt für die Container kube-apiserver und etcd auszuführen. Beenden Sie dann die kube-scheduler- und kube-controller-manager-Container.

   1. Ermitteln Sie die Container-ID für jeden Container:

      sudo crictl ps | grep CONTAINER_NAME
      

      Ersetzen Sie CONTAINER_NAME durch den Namen eines der folgenden Container: kube-apiserver, etcd (nicht etcd-defrag), kube-scheduler oder kube-controller-manager.

      Die Antwort ähnelt dem folgenden Output:

      c331ade490cb6       28df10594cd92      26 hours ago       Running          kube-apiserver ...
      

      Die Container-ID ist der Wert in der ersten Spalte.

   2. Beenden Sie jeden Container:

      sudo crictl stop CONTAINER_ID
      

      Ersetzen Sie CONTAINER_ID durch die Container-ID aus dem vorherigen Schritt.

      Wenn der angehaltene Container beendet wird, erstellt das Kubelet an seiner Stelle einen neuen Container und löscht den angehaltenen. Wenn ein Fehler auftritt, z. B. context deadline exceeded (Fehlercode DeadlineExceeded), führen Sie den Befehl noch einmal aus.

Prüfen, ob die Verbindung wiederhergestellt wurde

Die kubeadm-Zertifikate sollten jetzt auf allen Knoten der Steuerungsebene erneuert werden. Wenn Sie abgelaufene Zertifikate erneuern, gehen Sie so vor:

• Führen Sie den folgenden kubectl-Befehl auf einem beliebigen Knoten der Steuerungsebene aus, um die Verbindung mit dem Kubernetes API-Server zu prüfen:

  kubectl get nodes --kubeconfig /etc/kubernetes/admin.conf
  

Die Antwort sollte die Liste der Knoten für den Cluster zurückgeben. Wenn Ihre Zertifikate ordnungsgemäß verlängert werden, werden keine TLS- oder Zertifikatsfehler zurückgegeben.

kubeconfig-Secret im Cluster aktualisieren

In den folgenden Schritten werden die erneuerten Zertifikate aus der Datei admin.conf verwendet, um das kubeconfig-Secret für Ihren Cluster zu aktualisieren. Die Inhalte der aktualisierten Datei admin.conf können jedoch nicht unverändert verwendet werden. Sie müssen zuerst eine Kopie der Datei admin.conf mit einigen erforderlichen Änderungen erstellen.

So aktualisieren Sie das Secret mit der neuen kubeconfig-Datei:

1. Ersetzen Sie mit sed kubernetes in der Datei admin.conf durch den Namen Ihres Clusters und schreiben Sie die Änderungen in eine neue Datei, kubeconfig_secret.conf:

   sed "s/kubernetes/CLUSTER_NAME/g" \
       /etc/kubernetes/admin.conf > /etc/kubernetes/kubeconfig_secret.conf
   

2. Prüfen Sie mit diff, ob die Datei kubeconfig_secret.conf aktualisiert wurde:

   diff /etc/kubernetes/admin.conf /etc/kubernetes/kubeconfig_secret.conf
   

   In der Antwort werden alle Stellen angezeigt, an denen sich die kubeconfig_secret.conf-Datei von der aktualisierten admin.conf-Datei unterscheidet. Wenn Sie den vorherigen Schritt beispielsweise für einen Cluster mit dem Namen demo-cluster ausgeführt haben, sieht die Ausgabe so aus:

   6c6
   <   name: kubernetes
   ---
   >   name: demo-cluster
   9,12c9,12
   <     cluster: kubernetes
   <     user: kubernetes-admin
   <   name: kubernetes-admin@kubernetes
   < current-context: kubernetes-admin@kubernetes
   ---
   >     cluster: demo-cluster
   >     user: demo-cluster-admin
   >   name: demo-cluster-admin@demo-cluster
   > current-context: demo-cluster-admin@demo-cluster
   16c16
   < - name: kubernetes-admin
   ---
   > - name: demo-cluster-admin
   

3. Führen Sie die folgenden Befehle aus, um das kubeconfig-Secret in Ihrem Cluster zu aktualisieren:

   CLUSTER_KUBECONFIG_BASE64=$(base64 /etc/kubernetes/kubeconfig_secret.conf -w 0)
   
   kubectl get secret/CLUSTER_NAME-kubeconfig \
       -n CLUSTER_NAMESPACE \
       --kubeconfig /etc/kubernetes/admin.conf -o json | jq \
       --arg conf "${CLUSTER_KUBECONFIG_BASE64}" '.data."value" |= $conf' | kubectl apply \
       --kubeconfig /etc/kubernetes/admin.conf -f -
   

Kubeconfig-Datei des Clusters ersetzen

So ersetzen Sie die kubeconfig-Datei Ihres Clusters durch eine Datei mit den erneuerten Zertifikaten:

1. Kopieren Sie die Datei admin.conf von einem der Knoten der Steuerungsebene des Clusters auf die Administrator-Workstation.

   Wie in den vorherigen Abschnitten beschrieben, befindet sich die Datei admin.conf auf den Knoten der Clustersteuerungsebene im Verzeichnis etc/kubernetes.

2. Führen Sie den folgenden kubectl-Befehl auf der Administrator-Workstation aus, um die neue kubeconfig-Datei zu erstellen:

   kubectl --kubeconfig ADMIN_CONF_PATH get secret/CLUSTER_NAME-kubeconfig  \
       -n "CLUSTER_NAMESPACE" -o jsonpath='{.data.value}'  | \
       base64 --decode > new_kubeconfig.conf
   

   Ersetzen Sie Folgendes:

   • ADMIN_CONF_PATH: der Pfad der admin.conf-Datei, die von einem Steuerungsebene-Knoten auf die Administrator-Workstation kopiert wurde.

   • CLUSTER_NAME: der Name des Clusters, für den Sie die Zertifikate erneuern.

   • CLUSTER_NAMESPACE: der Namespace des Clusters, für den Sie die Zertifikate erneuern.

   Die Datei new_kubeconfig.conf enthält die aktualisierten Zertifikatsdaten.

3. Prüfen Sie, ob die neue kubeconfig funktioniert, indem Sie einen beliebigen kubectl-Befehl mit den neuen Anmeldedaten ausführen:

   kubectl get nodes --kubeconfig new_kubeconfig.conf
   

4. Ersetzen Sie den Inhalt der alten kubeconfig-Datei, die im Clusterverzeichnis auf der Administrator-Workstation gespeichert ist, durch den Inhalt der neuen kubeconfig-Datei new-kubeconfig.conf.

   Der Pfad zur Clusterkonfigurationsdatei lautet standardmäßig bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig.

Kubelet-Zertifikate prüfen und etcd-defrag neu starten

Führen Sie die folgenden Schritte für jeden Knoten der Steuerungsebene aus, um die Clusterzertifikate manuell zu erneuern:

1. Melden Sie sich beim Knoten der Steuerungsebene an und prüfen Sie mit den folgenden Befehlen, ob das Ablaufdatum des kubelet-Clients und des ausgestellten Zertifikats nicht überschritten wurde:

   Kubelet-Zertifikate werden automatisch rotiert, solange die Steuerungsebene erreichbar ist. Die Frist für die automatische Verlängerung von kubelet-Zertifikaten ist kürzer als die Gültigkeitsdauer der Zertifikate der Steuerungsebene. Daher ist es wahrscheinlich, dass die kubelet-Zertifikate bereits verlängert wurden:

   sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -text | grep Validity -A2
   sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-server-current.pem -text | grep Validity -A2
   

   Die Ausgabe eines der beiden Befehle sieht in etwa so aus:

   Validity
       Not Before: Nov 28 18:04:57 2022 GMT
       Not After : Nov 28 19:04:57 2023 GMT
   

2. Verwenden Sie den folgenden Befehl, um den etcd-defrag-Container neu zu starten:

   Der etcd-defrag-Container verwendet das apiserver-etcd-Clientzertifikat, um mit etcd zu kommunizieren, und muss neu gestartet werden, damit die aktualisierten Zertifikate übernommen werden.

   kubectl rollout restart daemonset etcd-defrag -n kube-system --kubeconfig KUBECONFIG_PATH
   

Nachdem Sie diese manuellen Schritte zum Erneuern von Clusterzertifikaten ausgeführt haben, prüfen Sie, ob alle Pods ordnungsgemäß ausgeführt werden und für Container der Kontrollebene keine TLS-Fehler gemeldet werden.

Nächste Schritte

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care. Weitere Informationen zu Supportressourcen finden Sie unter Support. Dazu gehören:

• Anforderungen für das Eröffnen eines Supportfalls.
• Tools zur Fehlerbehebung, z. B. Ihre Umgebungskonfiguration, Logs und Messwerte.
• Unterstützte Komponenten.