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 sind. 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 für 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
controlPlane.apiServerCertExtraSANs
Feld in der Clusterspezifikation. Dieses Feld akzeptiert eine Liste von Domainnamen
und IP-Adressen. Dieses Feld ist optional und veränderlich. Sie können dieses Feld hinzufügen und aktualisieren, wenn Sie einen Cluster erstellen oder jederzeit danach.
...
kind: Cluster
metadata:
name: sample001
namespace: cluster-sample001
spec:
type: user
...
controlPlane:
apiServerCertExtraSANs:
- "demo-dns.example.com"
- "sample-dns.com"
nodePoolSpec:
nodes:
- address: 10.200.0.20
clusterNetwork:
...
Domains während der Clustererstellung hinzufügen
Wenn Sie beim Erstellen eines Clusters zusätzliche SANs hinzufügen, enthält das Kubernetes API-Serverzertifikat 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änderlich ist, können Sie es jederzeit für vorhandene Cluster hinzufügen oder aktualisieren. Wenn Sie das Feld apiServerCertExtraSANs im Cluster ändern, werden die folgenden Aktivitäten ausgelöst:
Die Google Distributed Cloud-Clustercontroller generieren das API-Serverzertifikat neu, um die geänderten zusätzlichen Domains einzubeziehen.
Die Clustercontroller starten den API-Server neu, um das neue Zertifikat neu zu laden.
Die neuen Werte von
apiServerCertExtraSANswerden von einem Webhook überprüft, um sicherzustellen, dass sie den Domainnamen konventionen von RFC 1035 entsprechen.Der Knotenpool der Steuerungsebene wechselt in den Abgleichsstatus.
Control Plane Node Pool Status: Anthos Bare Metal Version: 1.28.0-gke.435 Anthos Bare Metal Versions: 1.28.0-gke.435: 3 Conditions: ... Last Transition Time: 2023-11-15T18:23:49Z Observed Generation: 1 Reason: Reconciling Status: True Type: ReconcilingDer Knotenpool ist bereit, nachdem die Änderung an die Kubernetes API-Server auf jedem Steuerungsebenenknoten weitergegeben wurde.
Control Plane Node Pool Status: Anthos Bare Metal Version: 1.28.0-gke.435 Anthos Bare Metal Versions: 1.28.0-gke.435: 3 Conditions: . . . Last Transition Time: 2023-11-15T18:32:25Z Observed Generation: 1 Reason: ReconciliationCompleted Status: False Type: Reconciling
Beim Aktualisieren des Felds für zusätzliche SANs für das API-Serverzertifikat in einem aktiven Cluster kann es zu Ausfallzeiten kommen:
In Clustern mit Hochverfügbarkeit (HA) werden API-Serverinstanzen sequenziell neu gestartet. Sie können während der Zertifikatsaktualisierung weiterhin mit dem Cluster interagieren, da der Load Balancer Anfragen an jeden API-Server weiterleitet. Möglicherweise wird jedoch eine Antwort angezeigt, die darauf hinweist, dass der API-Server heruntergefahren wird. Wenn Sie diese Antwort sehen, wiederholen Sie die Anfrage.
In Clustern ohne Hochverfügbarkeit kann es zu einem kurzen Ausfall von etwa einer Minute kommen, während ein API-Server neu gestartet wird, um das neue Zertifikat neu zu laden.
Es dauert 5 bis 20 Minuten, bis die Änderung an alle API-Server weitergegeben wird. Die genaue Zeit hängt von der Anzahl der Steuerungsebenenknoten im Cluster und der Last des Clusters ab.