Version 1.14. This version is no longer supported. For information about how to upgrade to version 1.15, see Upgrading Anthos on bare metal in the 1.15 documentation. For more information about supported and unsupported versions, see the Version history page in the latest documentation.

Abgelaufene Clusterzertifikate manuell verlängern

In diesem Dokument wird beschrieben, wie Sie abgelaufene Zertifikate für GKE on Bare Metal manuell verlängern. TLS-Zertifikate (Transport Layer Security) werden von den Komponenten der Steuerungsebene von GKE on Bare Metal verwendet. Wenn diese Zertifikate ablaufen, können Arbeitslasten und Clusterlebenszyklen nicht mehr verwaltet werden, bis die Zertifikate verlängert werden können. Weitere Informationen zu den Auswirkungen abgelaufener Zertifikate finden Sie unter Ablauf von Zertifikaten.

Standardmäßig sind TLS-Zertifikate ein Jahr lang gültig. GKE on Bare Metal verlängert diese Zertifikate automatisch bei Clusterupgrades und bei der Rotation von Zertifizierungsstellen. Wir empfehlen Ihnen, Ihre Cluster regelmäßig zu aktualisieren, um sie sicher und unterstützt zu halten und zu verhindern, dass TLS-Zertifikate ablaufen.

Durch das Ablaufdatum des Zertifikats verursachte Fehler

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 folgenden Fehlern:

Unable to connect to the server: x509: Unable to connect to the server

Wenn Sie kubectl zum Abrufen Ihrer Clusterknoten verwenden, enthält die Antwort einen Fehler, der auf den Ablauf des Zertifikats verweist:
```
kubectl get nodes --kubeconfig KUBECONFIG_PATH
```
Ersetzen Sie KUBECONFIG_PATH durch den Pfad zur kubeconfig-Datei für Ihren Cluster.

Wenn die Zertifikate abgelaufen sind, sieht die Antwort in etwa so aus:
```
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 diese 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 "")

Ablaufzeiten von Zertifikaten prüfen

Dieser Abschnitt enthält eine Anleitung zum Prüfen der Ablaufzeiten für die von Ihrem Cluster verwendeten Zertifikate. Führen Sie für jeden Knoten der Steuerungsebene die folgenden Schritte aus.

So prüfen Sie die Ablaufzeiten von Zertifikaten:

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

sudo kubeadm certs check-expiration

In der Befehlsausgabe werden die von kubeadm erstellten Zertifikate für die Komponenten der Steuerungsebene und ihr Ablaufdatum aufgelistet:

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

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 sieht auf jeden Befehl wie folgt aus:
```
Validity
    Not Before: Sep 17 22:27:53 2021 GMT
    Not After : Sep 17 22:33:16 2022 GMT
```
Wenn alle Knoten der Steuerungsebene gleichzeitig Bootstrapping ausgeführt haben, liegen die Ablaufzeiten des Zertifikats innerhalb von Minuten voneinander. Diese Zeitbeziehung gilt für alle Knoten der Steuerungsebene. Sie können die Ablaufzeiten prüfen, indem Sie die vorherigen Befehle auf jedem Knoten der Steuerungsebene ausführen.

Führen Sie den folgenden Befehl auf der Administratorworkstation aus, um die Ablaufzeit 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

Führen Sie den folgenden Befehl aus, um den Ablauf des Zertifikats für die Cluster-kubeconfig im Administratorcluster zu prüfen:
```
kubectl get secret/CLUSTER_NAME-kubeconfig -n CLUSTER_NAMESPACE -o --kubeconfig=ADMIN_KUBECONFIG jsonpath='{.data.value}' | base64 --decode | grep client-certificate-data | awk '{print $2}' | base64 -d | openssl x509 -text | grep Validity -A2
```
```
Validity
    Not Before: Sep 17 22:27:53 2021 GMT
    Not After : Sep 17 22:33:16 2022 GMT
```
Das kubeconfig-Zertifikat im Administratorcluster und das Zertifikat in der kubeconfig-Datei auf der Administratorworkstation sind identisch. Daher müssen die Ausgabe für diesen Befehl 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.

Zertifikate auf jedem Knoten der Steuerungsebene verlängern

Führen Sie für jeden Knoten der Steuerungsebene des betroffenen Clusters die folgenden Schritte aus:

Sichern Sie den Ordner /etc/kubernetes.

Führen Sie den folgenden kubeadm-Befehl aus, um alle Zertifikate zu verlängern:

Der Befehl erneuert die Zertifikate mithilfe der vorhandenen Zertifizierungsstellen (Certificate Authority, CAs) auf dem Computer.

sudo kubeadm certs renew all

Die Befehlsausgabe sieht in etwa 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

Prüfen Sie mit dem folgenden Befehl, ob die Zertifikate eine neue Ablaufzeit haben:
```
sudo kubeadm certs check-expiration
```
Starten Sie Container mit den folgenden Befehlen neu:

Nicht alle Komponenten der Steuerungsebene unterstützen die dynamische Aktualisierung von Zertifikaten. Daher werden mit diesem Schritt die folgenden Container neu gestartet: kube-apiserver, kube-scheduler, kube-controller-manager und etcd, um die verlängerten Zertifikate abzurufen.

Wiederholen Sie die folgenden Schritte für jeden der vier Container:
1. Suchen Sie die Container-ID für jeden Container:
```
sudo crictl ps | grep CONTAINER_NAME
```
  Ersetzen Sie CONTAINER_NAME durch den Namen der folgenden Container: kube-apiserver, kube-scheduler, kube-controller-manager oder etcd (nicht etcd-defrag).
  
  Die Antwort sieht in etwa so aus:
```
c331ade490cb6       28df10594cd92      26 hours ago       Running          kube-apiserver ...
```
  Die Container-ID ist der Wert in der ersten Spalte.
  
  Hinweis: Wenn Ihre Zertifikate abgelaufen sind, sollten Sie zuerst den folgenden Schritt für die Container kube-apiserver und etcd ausführen. Beenden Sie dann die Container kube-scheduler und kube-controller-manager.
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 Kubelet an seiner Stelle einen neuen Container und löscht den angehaltenen Container. Wenn ein Fehler wie context deadline exceeded (Fehlercode DeadlineExceeded) auftritt, führen Sie den Befehl noch einmal aus.

Prüfen, ob die Verbindung wiederhergestellt wurde

An dieser Stelle sollten kubeadm-Zertifikate auf allen Knoten der Steuerungsebene verlängert werden. Wenn Sie abgelaufene Zertifikate verlängern möchten, führen Sie den folgenden Schritt aus.

Führen Sie den folgenden kubectl-Befehl auf einem beliebigen Knoten der Steuerungsebene aus, um die Verbindung zum 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-Datei des Clusters ersetzen

So ersetzen Sie die kubeconfig-Datei für Ihren Cluster durch eine Datei mit den erneuerten Zertifikaten:

Führen Sie zum Erstellen der neuen kubeconfig-Datei den folgenden kubectl-Befehl auf der Administratorworkstation aus:
```
kubectl --kubeconfig="ADMIN_KUBECONFIG" get secret/CLUSTER_NAME-kubeconfig  \
    -n "CLUSTER_NAMESPACE"  -o jsonpath='{.data.value}'  | base64 --decode > new_kubeconfig.conf
```
Ersetzen Sie Folgendes:
- ADMIN_KUBECONFIG: der Pfad zur kubeconfig-Datei des Administratorclusters.
- CLUSTER_NAME: der Name des Clusters, für den Sie Zertifikate verlängern.
- CLUSTER_NAMESPACE: der Namespace des Clusters, für den Sie Zertifikate verlängern.
Die Datei new_kubeconfig.conf enthält die aktualisierten Zertifikatsdaten.
Prüfen Sie, ob die neue kubeconfig-Datei funktioniert. Führen Sie dazu einen kubectl-Befehl mit den neuen Anmeldedaten aus:
```
kubectl get nodes --kubeconfig new_kubeconfig.conf
```
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 manuelle Verlängerung der Clusterzertifikate abzuschließen:

Melden Sie sich beim Knoten der Steuerungsebene an und prüfen Sie die Ablaufzeit des kubelet-Clients und des Bereitstellungszertifikats. Führen Sie dazu die folgenden Befehle aus:

Kubelet-Zertifikate werden automatisch rotiert, solange die Steuerungsebene erreichbar ist. Der Zeitraum für die automatische Verlängerung von kubelet-Zertifikaten ist kürzer als der Ablaufzeitraum für Zertifikate von Komponenten der Steuerungsebene. Daher ist es wahrscheinlich, dass kubelet-Zertifikate vor der
```
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 jeden Befehls sieht ungefähr so aus:
```
Validity
    Not Before: Nov 28 18:04:57 2022 GMT
    Not After : Nov 28 19:04:57 2023 GMT
```
Verwenden Sie den folgenden Befehl, um den etcd-defrag-Container neu zu starten:

Der etcd-defrag-Container verwendet das Clientzertifikat apiserver-etcd für die Kommunikation mit etcd und muss neu gestartet werden, um die aktualisierten Zertifikate abzurufen.
```
kubectl rollout restart daemonset etcd-defrag -n kube-system --kubeconfig KUBECONFIG_PATH
```

Sie haben die manuellen Schritte zum Verlängern von Clusterzertifikaten abgeschlossen. Prüfen Sie, ob alle Pods ordnungsgemäß ausgeführt werden und keine TLS-Fehler für Container der Steuerungsebene gemeldet werden.