Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Ein SAN (Subject Alternative Name) ist eine Funktion von SSL-Zertifikaten, mit der Sie die Domainnamen und Subdomains definieren können, die durch ein Zertifikat geschützt werden. In einem Google Distributed Cloud-Cluster umfassen die Standard-SANs für das Kubernetes API-Serverzertifikat die IP- und VIP-Adressen der Steuerungsebenenknoten und die Kubernetes-DNS-Namen. Mit der Funktion „Zusätzliche SANs für benutzerdefinierte API-Serverzertifikate“ können Sie dem Kubernetes API-Serverzertifikat für den Cluster zusätzliche Domains, Subdomains und IP-Adressen als SANs hinzufügen.
Wenn Sie benutzerdefinierte SANs für das API-Serverzertifikat angeben möchten, verwenden Sie das Feld controlPlane.apiServerCertExtraSANs in der Clusterkonfigurationsspezifikation. Dieses Feld nimmt eine Liste von Domainnamen und IP-Adressen auf. Dieses Feld ist optional und kann geändert werden. Sie können dieses Feld beim Erstellen eines Clusters oder jederzeit danach hinzufügen und aktualisieren.
Wenn Sie beim Erstellen eines Clusters zusätzliche SANs hinzufügen, enthält das Zertifikat des Kubernetes API-Servers die zusätzlich angegebenen Domains und IP-Adressen, sobald der Cluster verfügbar ist.
Domains für einen vorhandenen Cluster hinzufügen oder aktualisieren
Da das Feld apiServerCertExtraSANs veränderbar ist, können Sie es bei vorhandenen Clustern jederzeit hinzufügen oder aktualisieren. Wenn Sie das Feld apiServerCertExtraSANs im Cluster ändern, werden die folgenden Aktivitäten ausgelöst:
Die Clustercontroller von Google Distributed Cloud generieren das API-Serverzertifikat neu, um die geänderten zusätzlichen Domains aufzunehmen.
Die Clustercontroller starten den API-Server neu, um das neue Zertifikat neu zu laden.
Die neuen Werte von apiServerCertExtraSANs werden von einem Webhook überprüft, um sicherzustellen, dass sie den RFC 1035-Domainnamenkonventionen entsprechen.
Der Knotenpool der Steuerungsebene befindet sich im Abgleichstatus.
Control Plane Node Pool Status:Anthos Bare Metal Version:1.28.0-gke.435Anthos Bare Metal Versions:1.28.0-gke.435:3Conditions:...Last Transition Time:2023-11-15T18:23:49ZObserved Generation:1Reason:ReconcilingStatus:TrueType:Reconciling
Der Knotenpool ist bereit, nachdem die Änderung auf die Kubernetes API-Server auf jedem Knoten der Steuerungsebene übertragen wurde.
Control Plane Node Pool Status:Anthos Bare Metal Version:1.28.0-gke.435Anthos Bare Metal Versions:1.28.0-gke.435:3Conditions:. . .Last Transition Time:2023-11-15T18:32:25ZObserved Generation:1Reason:ReconciliationCompletedStatus:FalseType:Reconciling
Wenn Sie das Feld „Zusätzliche SANs“ des API-Serverzertifikats in einem laufenden Cluster aktualisieren, kann es zu Ausfallzeiten kommen:
In Hochverfügbarkeitsclustern (HA) werden API-Serverinstanzen nacheinander neu gestartet. Während des Zertifikatsupdates können Sie weiterhin mit dem Cluster interagieren, da der Load Balancer Anfragen an jeden API-Server verteilt.
Möglicherweise wird jedoch eine Antwort angezeigt, die darauf hinweist, dass der API-Server heruntergefahren wird. Wenn diese Antwort angezeigt wird, wiederholen Sie die Anfrage.
Bei Nicht-HA-Clustern kann es zu einer kurzen Unterbrechung von etwa einer Minute kommen, während ein API-Server neu gestartet wird, um das neue Zertifikat neu zu laden.
Die Änderung wird je nach Anzahl der Steuerungsebenenknoten im Cluster und der Auslastung des Clusters in 5 bis 20 Minuten auf alle API-Server übertragen.
[[["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-09-01 (UTC)."],[],[],null,["A subject alternative name (SAN) is a feature of SSL certificates that lets you\ndefine the domain names and subdomains that are secured by a certificate. On an\nGoogle Distributed Cloud cluster, the default SANs for the Kubernetes API server\ncertificate include the IP and VIP addresses of the control plane nodes and the\nKubernetes DNS names. With the custom API server certificate extra SANs feature,\nyou can add additional domains, subdomains, and IP addresses as SANs to the\nKubernetes API server certificate for the cluster.\n\nTo specify custom SANs for the API server certificate, you use the\n[`controlPlane.apiServerCertExtraSANs`](/kubernetes-engine/distributed-cloud/bare-metal/docs/reference/cluster-config-ref#controlplane-apiservercertextrasans)\nfield in the cluster configuration spec. This field takes a list of domain names\nand IP addresses. This field is optional and mutable. You can add this field and\nupdate it when you create a cluster or any time after. \n\n ...\n kind: Cluster\n metadata:\n name: sample001\n namespace: cluster-sample001\n spec:\n type: user\n ...\n controlPlane:apiServerCertExtraSANs:\n - \"demo-dns.example.com\"\n - \"sample-dns.com\"\n nodePoolSpec:\n nodes:\n - address: 10.200.0.20\n clusterNetwork:\n ...\n\nAdd domains during cluster creation\n\nWhen you add extra SANs when you create a cluster, the Kubernetes API server\ncertificate includes the additional specified domains and IP addresses when the\ncluster becomes available.\n\nAdd or update domains for an existing cluster\n\nBecause the `apiServerCertExtraSANs` field is mutable, you can add or update the\nfield at any time for existing clusters. When you modify the\n`apiServerCertExtraSANs` field in the cluster, it triggers the following\nactivities:\n\n- The Google Distributed Cloud cluster controllers regenerate the API server\n certificate to include the modified extra domains.\n\n- The cluster controllers restart the API server to reload the new\n certificate.\n\n- The new values of `apiServerCertExtraSANs` are verified by a webhook to\n ensure that they conform to the [RFC 1035 domain name\n conventions](https://datatracker.ietf.org/doc/html/rfc1035).\n\n- The control plane node pool enters a reconciling state.\n\n Control Plane Node Pool Status:\n Anthos Bare Metal Version: 1.28.0-gke.435\n Anthos Bare Metal Versions:\n 1.28.0-gke.435: 3\n Conditions:\n ...\n Last Transition Time: 2023-11-15T18:23:49Z\n Observed Generation: 1Reason: Reconciling\n Status: True\n Type: Reconciling\n\n- The node pool becomes ready after the change propagates to the Kubernetes\n API servers on each control plane node.\n\n Control Plane Node Pool Status:\n Anthos Bare Metal Version: 1.28.0-gke.435\n Anthos Bare Metal Versions:\n 1.28.0-gke.435: 3\n Conditions:\n . . .\n Last Transition Time: 2023-11-15T18:32:25Z\n Observed Generation: 1Reason: ReconciliationCompleted\n Status: False\n Type: Reconciling\n\nYou might experience downtime when updating the API server certificate extra\nSANs field on a running cluster:\n\n- On high availability (HA) clusters, API server instances restart\n sequentially. You can still interact with the cluster during the certificate\n update, because the load balancer distributes requests to each API server.\n However, you might see a response indicating that the API server is shutting\n down. If you see this response, retry the request.\n\n- On non-HA clusters, there might be a brief outage of about one minute while\n an API server restarts to reload the new certificate.\n\nThe change takes 5-20 minutes to propagate to all API servers, depending on the\nnumber of control plane nodes in the cluster and the load of the cluster."]]
