Diese Seite wurde von der Cloud Translation API übersetzt.

Nutzercluster zu Controlplane V2 migrieren

In diesem Dokument wird beschrieben, wie Sie einen Nutzercluster der Version 1.29 mit Kubeception zu Controlplane 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 Controlplane V2 für neue Nutzercluster eingeführt. Wenn Controlplane V2 aktiviert ist, wird die Steuerungsebene für den Nutzercluster im Nutzercluster selbst ausgeführt.

Vorteile von Controlplane V2:

Fehlerisolation. Ein Fehler im Administratorcluster hat keine Auswirkungen auf Nutzercluster.
Getrennte Ausführung. Das Upgrade eines Administratorclusters führt nicht zu Ausfallzeiten für Nutzercluster.
Deployment-Trennung. Sie können die Administrator- und Nutzercluster in verschiedenen Fehlerdomains oder an verschiedenen geografischen 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. Aktualisieren Sie den Cluster, falls erforderlich.
Im Nutzercluster muss Dataplane V2 aktiviert sein. Dieses Feld ist unveränderlich. Wenn Dataplane V2 im Cluster nicht aktiviert ist, können Sie den Cluster nicht zu Controlplane V2 migrieren.
Der Nutzercluster muss für die Verwendung von MetalLB oder eines manuellen Load-Balancers konfiguriert sein. 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 auf 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 Always-On-Secrets-Verschlüsselung jemals im Nutzercluster aktiviert wurde, 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 jemals 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 Always-On-Secrets-Verschlüsselung nie aktiviert. Sie können mit der Migration beginnen.

Wenn die Ausgabe des vorherigen Befehls nicht leer ist, wurde die Always-On-Secrets-Verschlüsselung zuvor 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

Führen Sie die folgenden Schritte aus, um die Always-On-Secret-Verschlüsselung zu deaktivieren und Secrets zu entschlüsseln:

Fügen Sie in der Konfigurationsdatei des Nutzerclusters dem Abschnitt secretsEncryption das Feld disabled: true hinzu, um die Always-On-Verschlüsselung von Secrets zu deaktivieren:
```
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

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

Manifeste aller Secrets im Nutzercluster im YAML-Format abrufen:

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

Damit alle Secrets in etcd als Nur-Text 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 im Cluster aktivieren.

Falsch konfigurierte Arbeitslast-Webhooks korrigieren

Wenn Sie Webhooks haben, die System-Pods im Namespace kube-system enthalten, fügen Sie namespaceSelector hinzu, um den Namespace kube-system herauszufiltern.

Beispiel:

  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - kube-system

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 Controlplane V2-Nutzercluster hochverfügbar machen. Wenn Sie von einem Nicht-HA- zu einem HA-Cluster wechseln möchten, ändern Sie masterNode.replicas von 1 in 3.
Fügen Sie die statische (n) IP-Adresse(n) für die Knoten der Steuerungsebene des Nutzerclusters dem Abschnitt network.controlPlaneIPBlock.ips hinzu. Die IP-Adresse (n) für die Knoten der Steuerungsebene müssen sich im selben VLAN wie die Worker-Knoten befinden. Die Hostnamen sind erforderlich.
Füllen Sie die Netzmaske und das Gateway im Abschnitt network.controlPlaneIPBlock aus.
Wenn der Abschnitt network.hostConfig leer ist, füllen Sie ihn aus.
Wenn der Nutzercluster manuelles Load-Balancing verwendet, konfigurieren Sie den Load-Balancer wie im nächsten Abschnitt beschrieben.
Wenn für den Nutzercluster manuelles Load-Balancing verwendet wird, legen Sie loadBalancer.manualLB.controlPlaneNodePort und loadBalancer.manualLB.konnectivityServerNodePort auf 0 fest, da sie nicht erforderlich sind, wenn Controlplane V2 aktiviert ist.
Aktualisieren Sie das Feld loadBalancer.vips.controlPlaneVIP mit der neuen IP-Adresse für die virtuelle IP der Steuerungsebene. Sie muss sich im selben VLAN wie die IP-Adressen der Knoten der Steuerungsebene befinden.
Alle vorherigen Felder sind unveränderlich, außer beim Aktualisieren des Clusters für die Migration. 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 Ihr Nutzercluster manuelles Load-Balancing verwendet, 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 ControlPlane 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. Aus Gründen der Fehlerbehebung, d. h. um auf den Kubeception-Cluster zurückgreifen zu können, werden die Knoten erst nach Abschluss der Migration gelöscht.
Stellen Sie die Clusterdaten in der neuen Steuerungsebene mit dem oben genannten etcd-Snapshot wieder her.
Verbinden Sie die Knoten des Knotenpools des Kubeception-Clusters mit der neuen Steuerungsebene, die über die neue controlPlaneVIP zugänglich ist.
Gleichen Sie den wiederhergestellten Nutzercluster ab, damit er dem Endstatus des Clusters mit aktivierter ControlPlane V2 entspricht.

Hinweise

Während der Migration kommt es zu keinen Ausfallzeiten für Nutzercluster-Arbeitslasten.
Während der Migration kommt es zu Ausfallzeiten 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 Steuerungsebene des Nutzerclusters 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 funktioniert die alte VIP-Adresse der Steuerungsebene weiterhin, ist aber instabil. Sie sind also nicht verlässlich. Aktualisieren Sie alle Abhängigkeiten von der alten VIP-Adresse so schnell wie möglich, damit die neue VIP-Adresse verwendet wird.

Nach der Migration

Wenn Sie die Always-On-Secrets-Verschlüsselung vor der Migration deaktiviert haben, führen Sie die folgenden Schritte aus, 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