Domains zum API-Serverzertifikat hinzufügen

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 enthalten die standardmäßigen 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 benutzerdefiniertes API-Serverzertifikat“ 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 Clusterspezifikation. Dieses Feld akzeptiert eine Liste von Domainnamen und IP-Adressen. 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.

...
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 beim Erstellen eines Clusters 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änderbar 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 einzuschließen.

  • Die Cluster-Controller starten den API-Server neu, um das neue Zertifikat neu zu laden.

  • Die neuen Werte von apiServerCertExtraSANs werden von einem Webhook geprüft, um sicherzustellen, dass sie den RFC 1035-Konventionen für Domainnamen 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:                  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.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 „extra SANs“ des API-Serverzertifikats in einem laufenden 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 verteilt. Möglicherweise erhalten Sie jedoch eine Antwort, die darauf hinweist, dass der API-Server heruntergefahren wird. Wenn Sie diese Antwort sehen, versuchen Sie es noch einmal.

  • Bei Nicht-HA-Clustern 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 auf alle API-Server übertragen wird. Das hängt von der Anzahl der Steuerungsebenenknoten im Cluster und der Clusterlast ab.