Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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 Version 1.30 oder höher haben, empfehlen wir Ihnen, der Anleitung unter Cluster zu empfohlenen Funktionen migrieren zu folgen.

1.29: Vorabversion
1.28: Nicht verfügbar

Steuerungsebenen von Nutzerclustern

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 zieht keine Ausfallzeit für Nutzercluster nach sich.
Bereitstellungstrennung. Sie können die Administrator- und Nutzercluster in verschiedenen fehlerhaften Domains 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 Sie einen Nutzercluster zu Controlplane V2 migrieren können, muss der Nutzercluster die folgenden Anforderungen erfüllen:

Der Nutzercluster muss Version 1.29 oder höher haben. Der Administratorcluster und die Knotenpools können eine oder zwei Nebenversionen niedriger als der Nutzercluster sein. Aktualisieren Sie den Cluster bei Bedarfbei Bedarf.
Für den Nutzercluster muss Dataplane V2 aktiviert sein. Dieses Feld ist unveränderlich. Wenn Dataplane V2 nicht im Cluster aktiviert ist, können Sie ihn nicht zu Controlplane 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 Nutzer clusters verfügbar sind. Die Knoten der Steuerungsebene erfordern 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 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 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 die Migration starten.

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-Secrets-Verschlüsselung deaktivieren und Secrets bei Bedarf entschlüsseln

So deaktivieren Sie die Always-On-Secrets-Verschlüsselung und entschlüsseln Secrets:

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

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 als Nur-Text in etcd 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 Webhooks für Arbeitslasten korrigieren

Wenn Sie Webhooks haben, die System-Pods im kube-system Namespace enthalten, fügen Sie namespaceSelector hinzu, um den kube-system Namespace 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 hochverfügbaren zu einem hochverfügbaren Cluster wechseln möchten, ändern Sie masterNode.replicas von 1 zu 3.
Fügen Sie die statische IP-Adresse (oder die Adressen) für die Knoten der Steuerungsebene des Nutzerclusters im 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.
Geben Sie die Netzmaske und das Gateway im network.controlPlaneIPBlock Abschnitt an.
Wenn der network.hostConfig Abschnitt leer ist, füllen Sie ihn aus.
Wenn der Nutzercluster manuelles Load-Balancing verwendet, konfigurieren Sie Ihren Load Balancer wie im nächsten Abschnitt beschrieben.
Wenn der Nutzercluster manuelles Load-Balancing verwendet, 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 loadBalancer.vips.controlPlaneVIP Feld mit der neuen IP-Adresse für die virtuelle IP-Adresse 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 wenn Sie den Cluster für die Migration aktualisieren. 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.

Konfiguration des manuellen Load Balancers anpassen

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

network.controlPlaneIPBlock

(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 kubeception-Clusters aus. Beachten Sie, dass die Knoten zur Fehlerbehebung, d. h. zur Rückkehr zum kubeception-Cluster, erst nach Abschluss der Migration gelöscht werden.
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 mit der neuen controlPlaneVIP zugänglich ist.
Gleichen Sie den wiederhergestellten Nutzercluster ab, damit er dem Endzustand des Clusters mit aktivierter Controlplane V2 entspricht.

Hinweise

Während der Migration gibt es keine Ausfallzeiten für Nutzercluster-Arbeitslasten.
Während der Migration gibt es einige Ausfallzeiten für die Steuerungsebene des Nutzerclusters. Genauer gesagt ist die Steuerungsebene zwischen Schritt 2 und dem Abschluss von Schritt 6 nicht verfügbar. Die Ausfallzeit beträgt laut unseren Tests 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 kubeception-Clusters 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, indem Sie sie aus der Konfigurationsdatei des Administratorclusters entfernen und gkectl update admin ausführen. 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 virtuelle IP-Adresse der Steuerungsebene weiterhin, ist aber instabil. Sie sind also nicht verlässlich. Aktualisieren Sie alle Abhängigkeiten von der alten virtuellen IP-Adresse so schnell wie möglich, um die neue virtuelle IP-Adresse zu verwenden.

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