Anthos Clusters on VMware heißt jetzt Google Distributed Cloud (nur Software) für VMware. Weitere Informationen finden Sie in der Produktübersicht.

Nutzercluster zu Controlplane V2 migrieren

In diesem Dokument wird gezeigt, wie Sie einen Nutzercluster der Version 1.29 mit kubeception auf die Steuerungsebene V2 migrieren. Wenn Ihre Cluster die Version 1.30 oder höher haben, empfehlen wir Ihnen, der Anleitung unter Clustermigration zu empfohlenen Funktionen planen zu folgen.

1.29: Vorabversion
1.28: Nicht verfügbar

Nutzercluster-Steuerungsebenen

Vor Google Distributed Cloud-Version 1.13 wurde die Steuerungsebene für einen Nutzercluster auf einem oder mehreren Knoten in einem Administratorcluster ausgeführt. Diese Art von Steuerungsebene wird als „Kubeception“ bezeichnet. In Version 1.13 wurde die Steuerungsebene V2 für neue Nutzercluster eingeführt. Wenn die Steuerungsebene V2 aktiviert ist, wird die Steuerungsebene für den Nutzercluster im Nutzercluster selbst ausgeführt.

Die Vorteile von Controlplane V2:

Fehlerisolation. Ein Fehler im Administratorcluster wirkt sich nicht auf Nutzercluster aus.
Betriebliche Trennung. Ein Administratorcluster-Upgrade führt nicht zu einer Ausfallzeit für Nutzercluster.
Bereitstellungstrennung Sie können die Administrator- und Nutzercluster in verschiedenen Fehlerdomains oder an verschiedenen Standorten platzieren. Ein Nutzercluster an einem Edge-Standort kann sich beispielsweise an einem anderen geografischen Standort als der Administratorcluster befinden.

Voraussetzungen

Damit ein Nutzercluster zu Controlplane V2 migriert werden kann, muss er die folgenden Anforderungen erfüllen:

Der Nutzercluster muss mindestens Version 1.29 haben. Der Administratorcluster und die Knotenpools können eine oder zwei Nebenversionen niedriger als der Nutzercluster sein. Führen Sie bei Bedarf ein Clusterupgrade durch.
Für den Nutzercluster muss Dataplane V2 aktiviert sein. Dieses Feld ist unveränderlich. Wenn Dataplane V2 also nicht für den Cluster aktiviert ist, können Sie ihn nicht zur Steuerungsebene V2 migrieren.
Der Nutzercluster muss so konfiguriert sein, dass er entweder MetalLB oder einen manuellen Load Balancer verwendet. Wenn der Nutzercluster den SeeSaw Load Balancer verwendet, können Sie ihn zu MetalLB migrieren.
Lesen Sie das Dokument zur Planung von IP-Adressen und achten Sie darauf, dass genügend IP-Adressen für die Knoten der Steuerungsebene des Nutzerclusters verfügbar sind. Die Knoten der Steuerungsebene benötigen statische IP-Adressen und Sie benötigen eine zusätzliche IP-Adresse für eine neue virtuelle IP-Adresse (VIP) der Steuerungsebene.

Migration vorbereiten

Wenn die Verschlüsselung von immer aktiven Secrets im Nutzercluster aktiviert war, müssen Sie die Schritte unter Always-On-Secrets-Verschlüsselung deaktivieren und Secrets entschlüsseln ausführen, bevor Sie mit der Migration beginnen. Andernfalls kann der neue Controlplane V2-Cluster keine Secrets entschlüsseln.

Führen Sie vor Beginn der Migration den folgenden Befehl aus, um zu prüfen, ob die Always-On-Secrets-Verschlüsselung bereits aktiviert wurde:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  get onpremusercluster USER_CLUSTER_NAME \
  -n USER_CLUSTER_NAME-gke-onprem-mgmt \
  -o jsonpath={.spec.secretsEncryption}

Wenn die Ausgabe des vorherigen Befehls leer ist, wurde die Verschlüsselung für immer aktive Secrets noch nie aktiviert. Sie können mit der Migration beginnen.

Wenn die Ausgabe des vorherigen Befehls nicht leer ist, wurde die Verschlüsselung für immer aktive Secrets bereits aktiviert. Bevor Sie mit der Migration beginnen, müssen Sie die Schritte im nächsten Abschnitt ausführen, damit der neue Controlplane V2-Cluster Secrets entschlüsseln kann.

Das folgende Beispiel zeigt eine nicht leere Ausgabe:

{"generatedKeyVersions":{"keyVersions":[1]}}

Always-On-Secret-Verschlüsselung deaktivieren und Secrets bei Bedarf entschlüsseln

So deaktivieren Sie die Verschlüsselung mit immer aktiven Secrets und entschlüsseln Secrets:

Wenn Sie die Verschlüsselung von Always-On-Secrets in der Konfigurationsdatei des Nutzerclusters deaktivieren möchten, fügen Sie dem Abschnitt secretsEncryption das Feld disabled: true hinzu:
```
secretsEncryption:
    mode: GeneratedKey
    generatedKey:
        keyVersion: KEY_VERSION
        disabled: true
```
Aktualisieren Sie den Cluster:
```
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG
```
Ersetzen Sie Folgendes:
- ADMIN_CLUSTER_KUBECONFIG: Der Pfad der kubeconfig-Datei des Administratorclusters.
- USER_CLUSTER_CONFIG: der Pfad Ihrer Nutzerclusterkonfigurationsdatei

So führen Sie ein Rolling Update für ein bestimmtes DaemonSet aus:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  rollout restart statefulsets kube-apiserver \
  -n USER_CLUSTER_NAME

Rufen Sie die Manifeste aller Secrets im Nutzercluster im YAML-Format ab:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  get secrets -A -o yaml > SECRETS_MANIFEST.yaml

Damit alle Secrets in etcd im Klartext gespeichert werden, wenden Sie alle Secrets im Nutzercluster noch einmal an:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  apply -f SECRETS_MANIFEST.yaml
```
Sie können jetzt mit der Migration zu Controlplane V2 beginnen. Nach Abschluss der Migration können Sie die Always-On-Secrets-Verschlüsselung wieder aktivieren.

Konfigurationsdatei des Nutzerclusters aktualisieren

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

enableControlplaneV2 auf „true“ festlegen.
Optional können Sie die Steuerungsebene für den Nutzercluster mit Controlplane V2 hochverfügbar (HA) machen. Wenn Sie von einem Nicht-HA-Cluster zu einem HA-Cluster wechseln möchten, ändern Sie masterNode.replicas von 1 zu 3.
Fügen Sie die statische (n) IP-Adresse(n) für die Knoten der Steuerungsebene des Nutzerclusters dem Abschnitt network.controlPlaneIPBlock.ips hinzu.
Geben Sie die Netzmaske und das Gateway im Abschnitt network.controlPlaneIPBlock ein.
Wenn der Abschnitt network.hostConfig leer ist, füllen Sie ihn aus.
Wenn im Nutzercluster manuelles Load Balancing verwendet wird, konfigurieren Sie den Load Balancer wie im nächsten Abschnitt beschrieben.
Wenn im Nutzercluster manuelles Load Balancing verwendet wird, legen Sie für loadBalancer.manualLB.controlPlaneNodePort und loadBalancer.manualLB.konnectivityServerNodePort den Wert 0 fest, da sie bei aktivierter Steuerungsebene V2 nicht erforderlich sind.
Aktualisieren Sie das Feld loadBalancer.vips.controlPlaneVIP mit der neuen IP-Adresse für die VIP der Steuerungsebene. Sie muss sich im selben VLAN wie die IP-Adressen der Knoten der Steuerungsebene befinden.
Alle vorherigen Felder sind unveränderlich, es sei denn, der Cluster wird für die Migration aktualisiert. Prüfen Sie alle Einstellungen noch einmal.
Führen Sie gkectl diagnose cluster aus und beheben Sie alle Probleme, die vom Befehl gefunden werden.
```
gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
      --cluster-name=USER_CLUSTER_NAME
```
Ersetzen Sie Folgendes:
- ADMIN_CLUSTER_KUBECONFIG: Pfad der kubeconfig-Datei des Administratorclusters.
- USER_CLUSTER_NAME: Der Name des Nutzerclusters.

Manuelle Load Balancer-Konfiguration anpassen

Wenn in Ihrem Nutzercluster manuelles Load Balancing verwendet wird, führen Sie den Schritt in diesem Abschnitt aus. Überspringen Sie andernfalls diesen Abschnitt.

Ähnlich wie beim Konfigurieren des Load Balancers für einen CPv2-Nutzercluster müssen Sie für jede der drei neuen IP-Adressen der Knoten der Steuerungsebene, die Sie im Abschnitt network.controlPlaneIPBlock angegeben haben, die Zuordnungen in Ihrem Load Balancer konfigurieren:

(ingressVIP:80) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)
(ingressVIP:443) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)

Aktualisieren Sie den Cluster

Führen Sie den folgenden Befehl aus, um den Cluster zu Controlplane V2 zu migrieren:

gkectl update cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG

Ersetzen Sie Folgendes:

ADMIN_CLUSTER_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters
USER_CLUSTER_CONFIG: der Pfad Ihrer Nutzerclusterkonfigurationsdatei.

Der Befehl führt folgende Schritte durch:

Erstellen Sie die Steuerungsebene eines neuen Clusters mit aktivierter Steuerungsebene V2.
Beenden Sie die Kubernetes-Steuerungsebene des kubeception-Clusters.
Erstellen Sie einen etcd-Snapshot des kubeception-Clusters.
Schalten Sie die Knoten der Steuerungsebene des Nutzerclusters des kubeception-Clusters aus. Hinweis: Aus Gründen der Fehlerwiederherstellung, also des Rückfalls auf den kubeception-Cluster, werden die Knoten erst nach Abschluss der Migration gelöscht.
Stellen Sie die Clusterdaten in der neuen Kontrollebene mit dem oben genannten etcd-Snapshot wieder her.
Verbinden Sie die Knotenpoolknoten des kubeception-Clusters mit der neuen Steuerungsebene, auf die über die neue controlPlaneVIP zugegriffen werden kann.
Stellen Sie den wiederhergestellten Nutzercluster so ein, dass er dem Endstatus des Clusters mit aktivierter Steuerungsebene V2 entspricht.

Hinweise

Während der Migration kommt es zu keinen Ausfallzeiten für Nutzercluster-Arbeitslasten.
Während der Migration kommt es zu einer kurzen Ausfallzeit für die Steuerungsebene des Nutzerclusters. Genauer gesagt ist die Steuerungsebene zwischen Schritt 2 und dem Abschluss von Schritt 6 nicht verfügbar. Laut unseren Tests beträgt die Ausfallzeit weniger als 7 Minuten. Die tatsächliche Dauer hängt jedoch von Ihrer Infrastruktur ab.
Am Ende der Migration werden die Knoten der Nutzercluster-Steuerungsebene der kubeception-Cluster gelöscht. Wenn für den Administratorcluster network.ipMode.type auf „static“ festgelegt ist, können Sie einige der nicht verwendeten statischen IP-Adressen wiederverwenden. Entfernen Sie sie dazu aus der Konfigurationsdatei des Administratorclusters und führen Sie gkectl update admin aus. Sie können die Knotenobjekte des Administratorclusters mit kubectl get nodes -o wide auflisten, um zu sehen, welche IP-Adressen verwendet werden.

Nach der Migration

Wenn Sie die Always-On-Secret-Verschlüsselung vor der Migration deaktiviert haben, gehen Sie so vor, um die Funktion wieder zu aktivieren:

Legen Sie in der Konfigurationsdatei des Nutzerclusters secretsEncryption.generatedKey.disabled auf „false“ fest. Beispiele:
```
secretsEncryption:
    mode: GeneratedKey
    generatedKey:
        keyVersion: KEY_VERSION
        disabled: false
```

Aktualisieren Sie den Nutzercluster:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG