vSphere IaaS control plane verwendet TLS-Verschlüsselung (Transport Layer Security), um die Kommunikation zwischen Komponenten zu sichern. TKG auf Supervisor enthält mehrere TLS-Zertifikate, die diese kryptografische Infrastruktur unterstützen. Die Supervisor-Zertifikatrotation erfolgt manuell. Die TKG-Zertifikatrotation erfolgt automatisiert, kann aber bei Bedarf manuell durchgeführt werden.
Informationen zu TLS-Zertifikaten für TKG-Dienstcluster
vSphere IaaS control plane verwendet TLS-Zertifikate zur Sicherung der Kommunikation zwischen den folgenden Komponenten:
Weitere Informationen und vollständige Listen der einzelnen TLS-Zertifikate, die in der
vSphere IaaS control plane-Umgebung verwendet werden, finden Sie im KB-Artikel
vSphere with Tanzu Certificate Guide.
- vCenter Server
- Supervisor-Knoten der Steuerungsebene
- ESXi-Hosts funktionieren als Worker-Knoten für vSphere-Pods
- TKG-Clusterknoten, sowohl Steuerungsebene als auch Worker
| Vertrauenswürdige Domäne | Beschreibung |
|---|---|
| Vertrauenswürdige Domäne von vCenter | Der Standardsignierer für TLS-Zertifikate in dieser vertrauenswürdigen Domäne ist die in vCenter Server integrierte VMware Certificate Authority (VMCA). |
| Vertrauenswürdige Domäne von Kubernetes | Der Standardsignierer für TLS-Zertifikate in dieser vertrauenswürdigen Domäne ist die Kubernetes-Zertifizierungsstelle (CA). |
TLS-Zertifikatrotation
Das Verfahren zum Rotieren von TLS-Zertifikaten unterscheidet sich je nachdem, ob die Zertifikate für
Supervisor oder für TKG-Dienstcluster verwendet werden.
- Supervisor-Zertifikatrotation
-
TLS-Zertifikate für Supervisor werden vom VMCA-Zertifikat abgeleitet. Weitere Informationen zu Supervisor Zertifikaten finden Sie im KB-Artikel vSphere with Tanzu Certificate Guide.
Die Zertifikatrotation für Supervisor erfolgt manuell. Im KB-Artikel Replace vSphere with Tanzu Supervisor Certificates finden Sie Anweisungen zum Ersetzen von Supervisor Zertifikaten mithilfe des WCP-Tools Cert Manager.
- TKG 2.0-Cluster-Zertifikatrotation
-
In der Regel müssen Sie die TLS-Zertifikate für einen TKG-Cluster nicht manuell rotieren, da die TLS-Zertifikate beim Aktualisieren eines TKG-Clusters beim Registrierungs-Aktualisierungsvorgang die TLS-Zertifikate automatisch für Sie rotiert.
Wenn die TLS-Zertifikate für einen TKG-Cluster nicht abgelaufen sind und Sie diese Zertifikate manuell rotieren müssen, können Sie dies tun, indem Sie die Schritte im folgenden Abschnitt ausführen.
Manuelles Rotieren der TLS-Zertifikate für einen TKG-Dienstcluster
Diese Anweisungen setzen fortgeschrittene Kenntnisse und Erfahrungen mit der TKG-Clusterverwaltung voraus. Diese Anweisungen setzen darüber hinaus voraus, dass die TLS-Zertifikate nicht abgelaufen sind. Wenn die Zertifikate abgelaufen sind, führen Sie diese Schritte nicht aus.
- Melden Sie sich per SSH bei einem der Supervisor-Knoten an, um diese Schritte auszuführen. Weitere Informationen finden Sie unter Herstellen einer Verbindung zu TKG-Dienst-Clustern als Kubernetes-Administrator und Systembenutzer.
- Rufen Sie den Namen des TKG-Clusters ab.
export CLUSTER_NAMESPACE="tkg-cluster-ns" kubectl get clusters -n $CLUSTER_NAMESPACE NAME PHASE AGE VERSION tkg-cluster Provisioned 43h
- Rufen Sie die kubeconfig-Datei des TKG-Clusters ab.
export CLUSTER_NAME="tkg-cluster" kubectl get secrets -n $CLUSTER_NAMESPACE $CLUSTER_NAME-kubeconfig -o jsonpath='{.data.value}' | base64 -d > $CLUSTER_NAME-kubeconfig - Rufen Sie den SSH-Schlüssel des TKG-Clusters ab.
kubectl get secrets -n $CLUSTER_NAMESPACE $CLUSTER_NAME-ssh -o jsonpath='{.data.ssh-privatekey}' | base64 -d > $CLUSTER_NAME-ssh-privatekey chmod 600 $CLUSTER_NAME-ssh-privatekey - Überprüfen Sie vor der Zertifikatrotation die Umgebung.
export KUBECONFIG=$CLUSTER_NAME-kubeconfig
kubectl get nodes -o wide
kubectl get nodes \ -o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}' \ -l node-role.kubernetes.io/master= > nodesfor i in `cat nodes`; do printf "\n######\n" ssh -o "StrictHostKeyChecking=no" -i $CLUSTER_NAME-ssh-privatekey -q vmware-system-user@$i hostname ssh -o "StrictHostKeyChecking=no" -i $CLUSTER_NAME-ssh-privatekey -q vmware-system-user@$i sudo kubeadm certs check-expiration done;Beispielergebnis der vorherigen Befehle:
tkg-cluster-control-plane-k8bqh [check-expiration] Reading configuration from the cluster... [check-expiration] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml' CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY EXTERNALLY MANAGED admin.conf Oct 04, 2023 23:00 UTC 363d no apiserver Oct 04, 2023 23:00 UTC 363d ca no apiserver-etcd-client Oct 04, 2023 23:00 UTC 363d etcd-ca no apiserver-kubelet-client Oct 04, 2023 23:00 UTC 363d ca no controller-manager.conf Oct 04, 2023 23:00 UTC 363d no etcd-healthcheck-client Oct 04, 2023 23:00 UTC 363d etcd-ca no etcd-peer Oct 04, 2023 23:00 UTC 363d etcd-ca no etcd-server Oct 04, 2023 23:00 UTC 363d etcd-ca no front-proxy-client Oct 04, 2023 23:00 UTC 363d front-proxy-ca no scheduler.conf Oct 04, 2023 23:00 UTC 363d no CERTIFICATE AUTHORITY EXPIRES RESIDUAL TIME EXTERNALLY MANAGED ca Oct 01, 2032 22:56 UTC 9y no etcd-ca Oct 01, 2032 22:56 UTC 9y no front-proxy-ca Oct 01, 2032 22:56 UTC 9y no
- Rotieren Sie die TLS-Zertifikate für den TKG 2.0-Cluster.
Führen Sie einen Kontextwechsel zurück zum Supervisor durch, bevor Sie mit den folgenden Schritten fortfahren.
unset KUBECONFIG kubectl config current-context kubernetes-admin@kubernetes
kubectl get kcp -n $CLUSTER_NAMESPACE $CLUSTER_NAME-control-plane -o jsonpath='{.apiVersion}{"\n"}' controlplane.cluster.x-k8s.io/v1beta1kubectl get kcp -n $CLUSTER_NAMESPACE $CLUSTER_NAME-control-plane NAME CLUSTER INITIALIZED API SERVER AVAILABLE REPLICAS READY UPDATED UNAVAILABLE AGE VERSION tkg-cluster-control-plane tkg-cluster true true 3 3 3 0 43h v1.21.6+vmware.1
kubectl patch kcp $CLUSTER_NAME-control-plane -n $CLUSTER_NAMESPACE --type merge -p "{\"spec\":{\"rolloutAfter\":\"`date +'%Y-%m-%dT%TZ'`\"}}" kubeadmcontrolplane.controlplane.cluster.x-k8s.io/tkg-cluster-control-plane patchedMaschinen-Rollout gestartet:kubectl get machines -n $CLUSTER_NAMESPACE NAME CLUSTER NODENAME PROVIDERID PHASE AGE VERSION tkg-cluster-control-plane-k8bqh tkg-cluster tkg-cluster-control-plane-k8bqh vsphere://420a2e04-cf75-9b43-f5b6-23ec4df612eb Running 43h v1.21.6+vmware.1 tkg-cluster-control-plane-l7hwd tkg-cluster tkg-cluster-control-plane-l7hwd vsphere://420a57cd-a1a0-fec6-a741-19909854feb6 Running 43h v1.21.6+vmware.1 tkg-cluster-control-plane-mm6xj tkg-cluster tkg-cluster-control-plane-mm6xj vsphere://420a67c2-ce1c-aacc-4f4c-0564daad4efa Running 43h v1.21.6+vmware.1 tkg-cluster-control-plane-nqdv6 tkg-cluster Provisioning 25s v1.21.6+vmware.1 tkg-cluster-workers-v8575-59c6645b4-wvnlz tkg-cluster tkg-cluster-workers-v8575-59c6645b4-wvnlz vsphere://420aa071-9ac2-02ea-6530-eb59ceabf87b Running 43h v1.21.6+vmware.1
Maschinen-Rollout abgeschlossen:kubectl get machines -n $CLUSTER_NAMESPACE NAME CLUSTER NODENAME PROVIDERID PHASE AGE VERSION tkg-cluster-control-plane-m9745 tkg-cluster tkg-cluster-control-plane-m9745 vsphere://420a5758-50c4-3172-7caf-0bbacaf882d3 Running 17m v1.21.6+vmware.1 tkg-cluster-control-plane-nqdv6 tkg-cluster tkg-cluster-control-plane-nqdv6 vsphere://420ad908-00c2-4b9b-74d8-8d197442e767 Running 22m v1.21.6+vmware.1 tkg-cluster-control-plane-wdmph tkg-cluster tkg-cluster-control-plane-wdmph vsphere://420af38a-f9f8-cb21-e05d-c1bcb6840a93 Running 10m v1.21.6+vmware.1 tkg-cluster-workers-v8575-59c6645b4-wvnlz tkg-cluster tkg-cluster-workers-v8575-59c6645b4-wvnlz vsphere://420aa071-9ac2-02ea-6530-eb59ceabf87b Running 43h v1.21.6+vmware.1
- Überprüfen Sie die manuelle Zertifikatrotation für den TKG 2.0-Cluster.
Führen Sie zur Überprüfung der Zertifikatrotation die folgenden Befehle aus:
export KUBECONFIG=$CLUSTER_NAME-kubeconfig kubectl get nodes -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME tkg-cluster-control-plane-m9745 Ready control-plane,master 15m v1.21.6+vmware.1 10.244.0.55 <none> VMware Photon OS/Linux 4.19.198-1.ph3-esx containerd://1.4.11 tkg-cluster-control-plane-nqdv6 Ready control-plane,master 21m v1.21.6+vmware.1 10.244.0.54 <none> VMware Photon OS/Linux 4.19.198-1.ph3-esx containerd://1.4.11 tkg-cluster-control-plane-wdmph Ready control-plane,master 9m22s v1.21.6+vmware.1 10.244.0.56 <none> VMware Photon OS/Linux 4.19.198-1.ph3-esx containerd://1.4.11 tkg-cluster-workers-v8575-59c6645b4-wvnlz Ready <none> 43h v1.21.6+vmware.1 10.244.0.51 <none> VMware Photon OS/Linux 4.19.198-1.ph3-esx containerd://1.4.11 kubectl get nodes \ -o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}' \ -l node-role.kubernetes.io/master= > nodes for i in `cat nodes`; do printf "\n######\n" ssh -o "StrictHostKeyChecking=no" -i $CLUSTER_NAME-ssh-privatekey -q vmware-system-user@$i hostname ssh -o "StrictHostKeyChecking=no" -i $CLUSTER_NAME-ssh-privatekey -q vmware-system-user@$i sudo kubeadm certs check-expiration done;Beispielergebnis mit den aktualisierten Ablaufdaten.###### tkg-cluster-control-plane-m9745 [check-expiration] Reading configuration from the cluster... [check-expiration] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml' CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY EXTERNALLY MANAGED admin.conf Oct 06, 2023 18:18 UTC 364d no apiserver Oct 06, 2023 18:18 UTC 364d ca no apiserver-etcd-client Oct 06, 2023 18:18 UTC 364d etcd-ca no apiserver-kubelet-client Oct 06, 2023 18:18 UTC 364d ca no controller-manager.conf Oct 06, 2023 18:18 UTC 364d no etcd-healthcheck-client Oct 06, 2023 18:18 UTC 364d etcd-ca no etcd-peer Oct 06, 2023 18:18 UTC 364d etcd-ca no etcd-server Oct 06, 2023 18:18 UTC 364d etcd-ca no front-proxy-client Oct 06, 2023 18:18 UTC 364d front-proxy-ca no scheduler.conf Oct 06, 2023 18:18 UTC 364d no CERTIFICATE AUTHORITY EXPIRES RESIDUAL TIME EXTERNALLY MANAGED ca Oct 01, 2032 22:56 UTC 9y no etcd-ca Oct 01, 2032 22:56 UTC 9y no front-proxy-ca Oct 01, 2032 22:56 UTC 9y no
- Überprüfen Sie das Kubelet-Zertifikat.
Sie müssen das Kubelet-Zertifikat nicht rotieren, vorausgesetzt, der Parameter
rotateCertificatesin der kubelet-Konfiguration ist auftruefestgelegt, was der Standardkonfiguration entspricht.Diese Konfiguration kann mithilfe der folgenden Befehle überprüft werden:kubectl get nodes \ -o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}' \ -l node-role.kubernetes.io/master!= > workernodes for i in `cat workernodes`; do printf "\n######\n" ssh -o "StrictHostKeyChecking=no" -i $CLUSTER_NAME-ssh-privatekey -q vmware-system-user@$i hostname ssh -o "StrictHostKeyChecking=no" -i $CLUSTER_NAME-ssh-privatekey -q vmware-system-user@$i sudo grep rotate /var/lib/kubelet/config.yaml done;Beispielergebnis:###### tkg-cluster-workers-v8575-59c6645b4-wvnlz rotateCertificates: true
