Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Google Distributed Cloud verwendet Zertifikate und private Schlüssel zur Authentifizierung und Verschlüsselung von Verbindungen zwischen Systemkomponenten in Clustern. Die Cluster-Zertifizierungsstelle (CA) verwaltet diese Zertifikate und Schlüssel. Wenn Sie den Befehl bmctl update credentials certificate-authorities rotate ausführen, führt Google Distributed Cloud die folgenden Aktionen aus:
Erstellt und lädt neue Clusterzertifizierungsstellen (Certificate Authorities, CA), die etcd-CA und die Front-Proxy-CA in den Nutzercluster-Namespace im Administratorcluster hoch.
Die Administratorcluster-Controller ersetzen die Zertifizierungsstellen des Nutzerclusters durch die neu generierten Zertifizierungsstellen.
Die Administratorcluster-Controller verteilen die neuen öffentlichen CA-Zertifikate und Blattzertifikat-Schlüsselpaare an Nutzercluster-Systemkomponenten.
Für eine sichere Clusterkommunikation sollten Sie die Zertifizierungsstelle Ihres Nutzerclusters regelmäßig und bei einem möglichen Sicherheitsverstoß rotieren.
Hinweise
Planen Sie vor dem Rotieren der Cluster-Zertifizierungsstelle entsprechend der folgenden Bedingungen und Auswirkungen:
Achten Sie darauf, dass die Administrator- und Nutzercluster mindestens Version 1.9.0 haben, bevor Sie die CA-Rotation starten.
Die Rotation von Cluster-CAs ist inkrementell, sodass Systemkomponenten während der Rotation kommunizieren können.
Durch die CA-Rotation werden der API-Server und die Prozesse der Steuerungsebene im nächsten Cluster neu gestartet.
Sie können davon ausgehen, dass Arbeitslasten während der CA-Rotation neu gestartet und neu geplant werden.
Bei Nicht-Hochverfügbarkeits-Clusterkonfigurationen sollten Sie kurze Zeiträume der Ausfallzeit der Steuerungsebene während der CA-Rotation erwarten.
Clusterverwaltungsvorgänge sind während der CA-Rotation nicht zulässig.
Die Dauer der CA-Rotation hängt von der Größe des Clusters ab. Beispielsweise kann die Rotation von Cluster-CAs für einen Nutzercluster mit einer einzigen Steuerungsebene und 50 Worker-Knoten fast zwei Stunden dauern.
Beschränkungen
Für die Funktion der CA-Rotation gelten die folgenden Einschränkungen:
Bei der CA-Rotation werden keine manuell von einem Administrator ausgestellten Zertifikate rotiert, auch dann nicht, wenn die Zertifizierungsstelle die Zertifikate signiert. Aktualisieren und verteilen Sie alle manuell ausgestellten Zertifikate nach Abschluss der Rotation der Cluster-CA
Nach dem Start kann die CA-Rotation nicht mehr angehalten und es kann kein Rollback durchgeführt werden.
Cluster-CA-Rotation starten
Verwenden Sie den folgenden Befehl, um den CA-Rotationsprozess zu starten:
CLUSTER_NAME: der Name des Clusters, für den Sie CAs rotieren möchten.
KUBECONFIG: der Pfad zur kubeconfig-Datei des Administratorclusters. Bei selbstverwalteten Clustern ist diese Datei die kubeconfig-Datei des Clusters.
Der Befehl bmctl wird beendet, nachdem die CA erfolgreich rotiert und eine neue kubeconfig-Datei generiert wurde. Der Standardpfad für die kubeconfig-Datei ist bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig.
Fehler bei einer Cluster-CA-Rotation beheben
Der Befehl bmctl update credentials zeigt den Fortschritt der CA-Rotation des Clusters an.
Die zugehörige Datei update-credentials.log wird im folgenden Verzeichnis mit Zeitstempel gespeichert:
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-01-31 (UTC)."],[],[],null,["Google Distributed Cloud uses certificates and private keys to authenticate and encrypt\nconnections between system components in clusters. The cluster certificate\nauthority (CA) manages these certificates and keys. When you run the `bmctl\nupdate credentials certificate-authorities rotate` command,\nGoogle Distributed Cloud performs the following actions:\n\n- The command creates and uploads new cluster certificate authorities (CAs)\n for the cluster CA, the etcd CA, and the front-proxy CA to the user cluster\n namespace in the admin cluster.\n\n- The admin cluster controllers replace the user cluster certificate\n authorities with the newly generated ones.\n\n- The admin cluster controllers distribute the new public CA certificates and\n leaf certificate key pairs to user cluster system components.\n\n- The command also updates the `stackdriver-prometheus-etcd-scrape` Secret,\n which was created by Google Distributed Cloud during cluster creation.\n Prometheus requires this secret to collect etcd metrics.\n\nTo maintain secure cluster communication, rotate your user cluster CA\nperiodically and whenever there is a possible security breach.\n| **Important:** If your cluster certificates have expired, you must renew them manually to regain cluster operation. For more information and instructions, see [Renew expired cluster certificates manually](/kubernetes-engine/distributed-cloud/bare-metal/docs/troubleshooting/expired-certs).\n\nBefore you begin\n\nBefore you rotate your cluster's certificate authority, plan according to the\nfollowing conditions and impacts:\n\n- Ensure admin and user clusters are at version 1.9.0 or higher before\n starting the CA rotation.\n\n- CA rotation is incremental, allowing system components to communicate during\n the rotation.\n\n- A CA rotation restarts the API server, other control-plane processes, and\n each node in the cluster multiple times. Each stage of a CA rotation\n progresses similarly to a cluster upgrade. While the user cluster does\n remain operational during a CA rotation, you should expect that workloads\n will be restarted and rescheduled.\n\n- If your user cluster doesn't have a [high-availability control plane](/kubernetes-engine/distributed-cloud/bare-metal/docs/reference/cluster-config-ref#controlplane-nodepoolspec-nodes),\n expect brief periods of control-plane downtime during CA rotation.\n\n- Cluster management operations aren't allowed during CA rotation.\n\n- CA rotation duration depends on the size of your cluster. For example, CA\n rotation may take close to two hours to complete for a cluster with one\n control plane and 50 worker nodes.\n\nLimitations\n\nThe certificate authority rotation capability has the\nfollowing limitations:\n\n- CA rotation doesn't update certificates issued manually by an administrator,\n even if the cluster CA signs the certificates. Update and redistribute any\n manually issued certificates after user cluster CA rotation is complete.\n\n- Once started, CA rotation can't be paused or rolled back.\n\nStart a cluster CA rotation\n\nBy default, TLS certificates have a 1-year expiration period.\nGoogle Distributed Cloud renews these certificates when you rotate certificate\nauthorities. Google Distributed Cloud also renews the TLS certificates during\ncluster upgrades. We recommend that you upgrade your clusters regularly to keep\nthem secure, supported, and to prevent TLS certificates from expiring.\n\nUse the following command to start the CA rotation process: \n\n bmctl update credentials certificate-authorities rotate --cluster \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e \\\n --kubeconfig \u003cvar translate=\"no\"\u003eKUBECONFIG\u003c/var\u003e\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e: the name of the cluster for which you want to rotate CAs.\n- \u003cvar translate=\"no\"\u003eKUBECONFIG\u003c/var\u003e: the path to the admin cluster kubeconfig file. For self-managing clusters, this file is the cluster's kubeconfig file.\n\nThe `bmctl` command exits after the CA is rotated successfully and a new\nkubeconfig file is generated. The standard path for the kubeconfig file is\n`bmctl-workspace/`\u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e`/`\u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e`-kubeconfig`.\n\nTroubleshoot a cluster CA rotation\n\nThe `bmctl update credentials` command displays the progress of the CA rotation.\nThe associated `update-credentials.log` file is saved to the following\ntimestamped directory: \n\n bmctl-workspace/\u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e/log/update-credentials-\u003cvar translate=\"no\"\u003eTIMESTAMP\u003c/var\u003e"]]
