Administratorcluster zu empfohlenen Funktionen migrieren

Übersicht

Auf dieser Seite erfahren Sie, wie Sie einen Administratorcluster der Version 1.30 oder höher zu diesen empfohlenen Funktionen migrieren:

• Die Load Balancer-Konfiguration:

  • Die Konfiguration des integrierten F5 BIG-IP-Load Balancers zu ManualLB.

    oder

  • Der gebündelte Seesaw-Load Balancer zu MetalLB.

• Von einem Administratorcluster ohne Hochverfügbarkeit (HA) zu einem Administratorcluster mit Hochverfügbarkeit migrieren. Mit einem HA-Administratorcluster wird die Verfügbarkeit deutlich verbessert, während dieselbe Anzahl von VMs verwendet wird. Ein Administratorcluster ohne Hochverfügbarkeit hat einen Steuerungsebenenknoten und zwei Add-on-Knoten. Die drei Knoten eines HA-Administratorclusters sind alle Steuerungsebenenknoten ohne Add-on-Knoten.

Diese Seite richtet sich an IT-Administratoren und Betreiber, die den Lebenszyklus der zugrunde liegenden Technologieinfrastruktur verwalten. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud-Inhalten verweisen, finden Sie unter Häufig verwendete GKE Enterprise-Nutzerrollen und -Aufgaben.

Weitere Informationen zur Migrationsplanung finden Sie unter Clustermigration zu empfohlenen Funktionen planen.

Best Practices

Wenn Sie mehrere Umgebungen wie Test-, Entwicklungs- und Produktionsumgebungen haben, empfehlen wir, zuerst die am wenigsten kritische Umgebung zu migrieren, z. B. die Testumgebung. Nachdem Sie bestätigt haben, dass die Migration erfolgreich war, wiederholen Sie diesen Vorgang für jede Umgebung. Migrieren Sie zuletzt Ihre Produktionsumgebung. So können Sie den Erfolg jeder Migration prüfen und dafür sorgen, dass Ihre Arbeitslasten ordnungsgemäß ausgeführt werden, bevor Sie zur nächsten kritischeren Umgebung übergehen.

Voraussetzungen

• Der Administratorcluster muss mindestens Version 1.30 haben.
• Alle vom Administratorcluster verwalteten Nutzercluster müssen bereits zu den empfohlenen Funktionen migriert worden sein, wie unter Nutzercluster zu empfohlenen Funktionen migrieren beschrieben.

Ausfallzeiten während der Migration planen

Planen Sie für die Migration eine begrenzte Ausfallzeit der Steuerungsebene ein. Der Zugriff auf die Kubernetes API ist für Administratorcluster ohne HA etwa 20 Minuten lang nicht verfügbar. Die Kubernetes-Steuerungsebene bleibt jedoch für HA-Administratorcluster mit F5 verfügbar. Während der Migrationen arbeitet die Kubernetes-Datenebene weiterhin in einem stabilen Zustand.

Hinweis: Nutzerarbeitslasten sollten nur in Nutzerclustern ausgeführt werden, die von der Migration der Administratorcluster nicht betroffen sind.

Von	Zu	Kubernetes API-Zugriff	Nutzerarbeitslasten
HA-Administratorcluster mit F5 BIG-IP	HA-Administratorcluster mit ManualLB	Nicht betroffen	Nicht betroffen
Nicht-HA-Administratorcluster mit MetalLB oder ManualLB	HA-Administratorcluster mit derselben Art von Load Balancer	Betroffen	Nicht betroffen
Nicht-HA-Administratorcluster mit F5 BIG-IP	HA-Administratorcluster mit ManualLB	Betroffen	Nicht betroffen
Nicht-HA-Administratorcluster mit Seesaw	HA-Administratorcluster mit MetalLB	Betroffen	Nicht betroffen

• Betroffen: Während der Migration kommt es zu einer wahrnehmbaren Dienstunterbrechung.
• Nicht betroffen: Es kommt entweder zu keiner Dienstunterbrechung oder sie ist fast nicht wahrnehmbar.

Migration vorbereiten

Wenn Ihr Administratorcluster nicht hochverfügbar ist, bereiten Sie die Migration zu einem HA-Administratorcluster vor. Folgen Sie dazu der Anleitung in diesem Abschnitt. Wenn Ihr Administratorcluster bereits hochverfügbar ist, fahren Sie mit dem nächsten Abschnitt Vorbereitung auf die Load Balancer-Migration fort.

Zusätzliche IP-Adressen zuweisen

Wenn Sie den Administratorcluster von Nicht-HA zu HA migrieren, weisen Sie vier zusätzliche IP-Adressen zu. Achten Sie darauf, dass sich diese IP-Adressen im selben VLAN wie die vorhandenen Administratorclusterknoten befinden und nicht bereits von vorhandenen Knoten verwendet werden:

• Weisen Sie der neuen VIP-Adresse der Steuerungsebene eine IP-Adresse für das Feld loadBalancer.vips.controlPlaneVIP in der Konfigurationsdatei des Administratorclusters zu.
• Weisen Sie jedem der drei Knoten der Steuerungsebene neue IP-Adressen für den Abschnitt network.controlPlaneIPBlock in der Konfigurationsdatei des Administratorclusters zu.

Firewallregeln aktualisieren

Wenn Sie den Administratorcluster von Nicht-HA- zu HA migrieren, aktualisieren Sie die Firewallregeln in Ihrem Administratorcluster. So können die neu zugewiesenen IP-Adressen für die Knoten der Steuerungsebene alle erforderlichen APIs und anderen Ziele erreichen, wie unter Firewallregeln für Administratorcluster beschrieben.

Load Balancer-Migration vorbereiten

Wenn in Ihrem Administratorcluster die integrierte F5 BIG-IP-Konfiguration oder der gebündelte Seesaw-Load Balancer verwendet wird, folgen Sie der Anleitung in diesem Abschnitt, um die erforderlichen Änderungen an der Konfigurationsdatei des Administratorclusters vorzunehmen. Andernfalls fahren Sie mit dem nächsten Abschnitt Migration von einem Nicht-HA zu einem HA-Cluster vorbereiten fort.

F5 BIG-IP

Wenn in Ihrem Administratorcluster die integrierte F5 BIG-IP-Konfiguration verwendet wird, nehmen Sie die folgenden Änderungen an der Konfigurationsdatei des Administratorclusters vor:

1. Setzen Sie das Feld loadBalancer.kind auf "ManualLB".
2. Legen Sie den Wert des Felds loadBalancer.vips.controlPlaneVIP fest oder belassen Sie ihn. Wenn Ihr Administratorcluster bereits hochverfügbar ist, belassen Sie den Wert unverändert. Wenn Sie von einem Nicht-HA-Administratorcluster zu einem HA-Administratorcluster migrieren, ändern Sie den Wert des Felds loadBalancer.vips.controlPlaneVIP in die von Ihnen zugewiesene IP-Adresse.
3. Löschen Sie den gesamten Abschnitt loadBalancer.f5BigIP.

Die folgende Beispielkonfigurationsdatei für den Administratorcluster zeigt diese Änderungen:

loadBalancer:
vips:
  controlPlaneVIP: 192.0.2.6 192.0.2.50
kind: "F5BigIP" "ManualLB"
f5BigIP:
    address: "203.0.113.20"
  credentials:
    fileRef:
      path: ""my-config-folder/user-creds.yaml"
      entry: "f5-creds"
  partition: "my-f5-user-partition"
  

Seesaw

Wenn in Ihrem Administratorcluster der Seesaw-Load Balancer verwendet wird, nehmen Sie die folgenden Änderungen an der Konfigurationsdatei des Administratorclusters vor:

1. Legen Sie für das Feld loadBalancer.kind den Wert „MetalLB“ fest.
2. Behalten Sie den network.hostConfig-Abschnitt bei.
3. Legen Sie den Wert des Felds loadBalancer.vips.controlPlaneVIP]5 fest oder belassen Sie ihn unverändert. Wenn Ihr Administratorcluster bereits hochverfügbar ist, können Sie denselben Wert beibehalten. Wenn Sie von einem Nicht-HA-Administratorcluster zu einem HA-Administratorcluster migrieren, ändern Sie den Wert des Felds loadBalancer.vips.controlPlaneVIP in die von Ihnen zugewiesene IP-Adresse.
4. Entfernen Sie den Abschnitt loadBalancer.seesaw.

Die folgende Beispielkonfigurationsdatei für den Administratorcluster zeigt diese Änderungen:

network:
hostConfig:
  dnsServers:
  - "203.0.113.1"
  - "203.0.113.2"
  ntpServers:
  - "203.0.113.3"
loadBalancer:
vips:
  controlPlaneVIP: 192.0.2.6 192.0.2.50
kind: "MetalLB" "Seesaw"
seesaw:
  ipBlockFilePath: "user-cluster-1-ipblock.yaml"
  vrid: 1
  masterIP: ""
  cpus: 4
  memoryMB: 3072

Migration von Nicht-HA zu HA vorbereiten

Wenn Ihr Administratorcluster nicht-HA ist, führen Sie die Schritte in diesem Abschnitt aus, um die Migration zu HA vorzubereiten.

Wenn Ihr Administratorcluster bereits hochverfügbar ist, fahren Sie mit dem nächsten Abschnitt Administratorcluster migrieren fort.

Wenn die Version Ihres Administratorclusters 1.29.0-1.29.600 oder 1.30.0-1.30.100 ist und die Verschlüsselung für Always-On-Secrets in der Version 1.14 oder niedriger aktiviert wurde, müssen Sie den Verschlüsselungsschlüssel rotieren, bevor Sie mit der Migration beginnen. Andernfalls kann der neue HA-Administratorcluster keine Secrets entschlüsseln.

So prüfen Sie, ob der Cluster möglicherweise einen alten Verschlüsselungsschlüssel verwendet:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret -n kube-system admin-master-component-options -o jsonpath='{.data.data}' | base64 -d | grep -oP '"GeneratedKeys":\[.*?\]'

Wenn in der Ausgabe ein leerer Schlüssel angezeigt wird, wie im folgenden Beispiel, müssen Sie den Verschlüsselungsschlüssel rotieren.

"GeneratedKeys":[{"KeyVersion":"1","Key":""}]

Verschlüsselungsschlüssel bei Bedarf rotieren

Wenn Sie in den Schritten im vorherigen Abschnitt festgestellt haben, dass Sie den Verschlüsselungsschlüssel rotieren müssen, führen Sie die folgenden Schritte aus:

1. Erhöhen Sie die keyVersion in der Konfigurationsdatei für den Administratorcluster.

2. Aktualisieren Sie den Administratorcluster:

   gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     --config ADMIN_CLUSTER_CONFIG
   

   Dadurch wird ein neuer Schlüssel erstellt, der mit der neuen Versionsnummer übereinstimmt, jedes Secret wird neu verschlüsselt und alte Schlüssel werden sicher gelöscht. Alle nachfolgenden neuen Secrets werden mit dem neuen Verschlüsselungsschlüssel verschlüsselt.

Warnung: Wenn Sie die Migration gestartet haben, ohne den Verschlüsselungsschlüssel zu rotieren, wenden Sie sich an den Google-Support.

Konfigurationsdatei für den Administratorcluster aktualisieren

Nehmen Sie die folgenden Änderungen an der Konfigurationsdatei des Administratorclusters vor:

1. Geben Sie im network.controlPlaneIPBlock die drei IP-Adressen ein, die Sie für den Knoten der Steuerungsebene zugewiesen haben.
2. Der Abschnitt network.hostConfig muss ausgefüllt sein. Dieser Abschnitt enthält Informationen zu NTP-Servern, DNS-Servern und DNS-Suchdomains, die von den VMs verwendet werden, die Ihre Clusterknoten sind.
3. Achten Sie darauf, den Wert von loadBalancer.vips.controlPlaneVIP durch die von Ihnen zugewiesene IP-Adresse zu ersetzen.
4. Setzen Sie adminMaster.replicas auf 3.
5. Entfernen Sie das Feld vCenter.dataDisk. Bei einem hochverfügbaren Administratorcluster werden die Pfade für die drei Datenlaufwerke, die von Knoten der Steuerungsebene verwendet werden, automatisch im Stammverzeichnis anthos im Datenspeicher generiert.
6. Wenn loadBalancer.kind auf "ManualLB" gesetzt ist, setzen Sie loadBalancer.manualLB.controlPlaneNodePort auf 0.

Die folgende Beispielkonfigurationsdatei für den Administratorcluster zeigt diese Änderungen:

vCenter:
  address: "my-vcenter-server.my-domain.example"
  datacenter: "my-data-center"
  dataDisk: "xxxx.vmdk"
...
network:
  hostConfig:
    dnsServers:
    – 203.0.113.1
    – 203.0.113.2
    ntpServers:
    – 203.0.113.3
  ...
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "198.51.100.1"
    ips:
    – ip: "192.0.2.1"
      hostname: "admin-cp-hostname-1"
    – ip: "192.0.2.2"
      hostname: "admin-cp-hostname-2"
    – ip: "192.0.2.3"
      hostname: "admin-cp-hostname-3"
...

...
loadBalancer:
  vips:
    controlPlaneVIP: 192.0.2.6 192.0.2.50
  kind: ManualLB
  manualLB:
    controlPlaneNodePort: 30003 0

...
adminMaster:
  replicas: 3
  cpus: 4
  memoryMB: 8192
...

Zuordnungen im Load Balancer bei Bedarf anpassen

Wenn in Ihrem Administratorcluster manuelles Load Balancing verwendet wurde, führen Sie den Schritt in diesem Abschnitt aus.

Wenn Sie von einem integrierten F5 BIG-IP-Load Balancer zu einem manuellen Load Balancer oder zu MetalLB migrieren, fahren Sie mit dem nächsten Abschnitt Administratorcluster migrieren fort.

Konfigurieren Sie diese Zuordnung für jede der drei neuen IP-Adressen der Steuerungsebene, die Sie im Abschnitt network.controlPlaneIPBlock angegeben haben, in Ihrem externen Load Balancer (z. B. F5 BIG-IP oder Citrix):

(old controlPlaneVIP:443) -> (NEW_NODE_IP_ADDRESS:old controlPlaneNodePort)

So wird sichergestellt, dass die alte VIP der Steuerungsebene während der Migration weiterhin funktioniert.

Administratorcluster migrieren

Prüfen Sie alle Änderungen, die Sie an der Konfigurationsdatei des Administratorclusters vorgenommen haben. Alle Einstellungen sind unveränderlich, es sei denn, der Cluster wird für die Migration aktualisiert.

Aktualisieren Sie den Cluster:

gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG

Replace the following:

• ADMIN_CLUSTER_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters
• ADMIN_CLUSTER_CONFIG: der Pfad Ihrer Administratorcluster-Konfigurationsdatei.

Der Befehl zeigt den Fortschritt der Migration an.

Geben Sie bei Aufforderung Y ein, um fortzufahren.

Während der Migration von Nicht-HA zu HA funktioniert die ältere VIP der Steuerungsebene weiter und kann zum Zugriff auf den neuen HA-Administratorcluster verwendet werden. Nach Abschluss der Migration wird die kubeconfig-Datei des Administratorclusters automatisch so aktualisiert, dass die neue VIP-Adresse der Steuerungsebene verwendet wird.

Nach der Migration

Prüfen Sie nach Abschluss des Updates, ob der Administratorcluster ausgeführt wird:

kubectl get nodes --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Die erwartete Ausgabe sieht in etwa so aus:

Load Balancer-Migration

Wenn Sie den Load Balancer migriert haben, prüfen Sie, ob die Load Balancer-Komponenten erfolgreich ausgeführt werden.

MetalLB

Wenn Sie zu MetalLB migriert sind, prüfen Sie mit dem folgenden Befehl, ob die MetalLB-Komponenten erfolgreich ausgeführt werden:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods \
    --namespace kube-system --selector app=metallb

Die Ausgabe zeigt Pods für den MetalLB-Controller und -Lautsprecher. Beispiel:

metallb-controller-744884bf7b-rznr9 1/1 Running
metallb-speaker-6n8ws 1/1 Running
metallb-speaker-nb52z 1/1 Running
metallb-speaker-rq4pp 1/1 Running

Löschen Sie nach einer erfolgreichen Migration die ausgeschalteten Seesaw-VMs für den Administratorcluster. Sie finden die Seesaw-VM-Namen im vmnames-Abschnitt der Datei seesaw-for-gke-admin.yaml in Ihrem Konfigurationsverzeichnis.

ManualLB

Nachdem Sie Ihre Cluster für die Verwendung des manuellen Load Balancing aktualisiert haben, wird der Traffic zu Ihren Clustern nicht unterbrochen. Das liegt daran, dass die vorhandenen F5-Ressourcen noch vorhanden sind. Dies können Sie mit dem folgenden Befehl sehen:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \

Die erwartete Ausgabe sieht in etwa so aus:

Warning: v1 ComponentStatus is deprecated in v1.19+
NAMESPACE     NAME                        TYPE     DATA   AGE
kube-system   secret/bigip-login-xt697x   Opaque   4      13h
NAMESPACE     NAME                              SECRETS   AGE
kube-system   serviceaccount/bigip-ctlr         0         13h
kube-system   serviceaccount/load-balancer-f5   0         13h
NAMESPACE     NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/k8s-bigip-ctlr-deployment   1/1     1            1           13h
kube-system   deployment.apps/load-balancer-f5            1/1     1            1           13h
NAME                                                                                ROLE                                       AGE
clusterrolebinding.rbac.authorization.k8s.io/bigip-ctlr-clusterrole-binding         ClusterRole/bigip-ctlr-clusterrole         13h
clusterrolebinding.rbac.authorization.k8s.io/load-balancer-f5-clusterrole-binding   ClusterRole/load-balancer-f5-clusterrole   13h
NAME                                                                 CREATED AT
clusterrole.rbac.authorization.k8s.io/bigip-ctlr-clusterrole         2024-03-25T04:37:34Z
clusterrole.rbac.authorization.k8s.io/load-balancer-f5-clusterrole   2024-03-25T04:37:34Z