Dieses Dokument wurde mithilfe automatisierter maschineller Übersetzungstechnologie übersetzt. Wir bemühen uns um korrekte Übersetzungen, übernehmen jedoch keine Gewähr für die Vollständigkeit, Richtigkeit oder Zuverlässigkeit der übersetzten Inhalte. Im Falle von Abweichungen ist die englische Originalversion maßgebend und stellt den verbindlichen Text dar.

Migration von Azure In-tree zu Out-of-tree

Kubernetes entfernt sich von der Pflege von Cloud-Anbietern im Baum.

Beginnend mit Kubernetes 1.29 wurden interne Cloud Provider deaktiviert. Sie müssen DisableCloudProviders und DisableKubeletCloudCredentialProvider deaktivieren, um den in-tree Azure-Cloud-Provider zu verwenden oder vom in-tree Cloud-Provider zu einem out-of-tree Provider zu migrieren. Sie können die erforderlichen Feature-Gates deaktivieren, indem Sie feature-gates=DisableCloudProviders=false als zusätzliches Argument für den Kubelet, Controller-Manager und API-Server des Clusters in der erweiterten Clusterkonfiguration festlegen. Zusätzlich setzen Sie DisableKubeletCloudCredentialProvider=false in den Argumenten des Kubelet ein, um die in-tree Funktionalität zur Authentifizierung bei Azure-Container-Registries für Image-Pull-Anmeldeinformationen zu aktivieren. Siehe Upstream-Dokumentation für weitere Details.

In Kubernetes v1.30 und später wurden die in-tree Cloud-Anbieter entfernt. Rancher ermöglicht es Ihnen, auf Kubernetes v1.30 zu aktualisieren, wenn Sie von einem in-tree zu einem out-of-tree Anbieter migrieren.

Um vom in-tree Cloud-Provider zum out-of-tree Azure-Cloud-Provider zu migrieren, müssen Sie den Kube-Controller-Manager des bestehenden Clusters stoppen und den Azure-Cloud-Controller-Manager installieren.

Wenn es akzeptabel ist, während der Migration eine gewisse Ausfallzeit zu haben, folgen Sie den Anweisungen, um einen externen Cloud-Provider einzurichten. Diese Anweisungen beschreiben, wie der externe Cloud-Anbieter für einen neu bereitgestellten Cluster konfiguriert wird. Während der Einrichtung wird es eine gewisse Ausfallzeit geben, da es eine Zeitspanne gibt, in der der alte Cloud-Anbieter nicht mehr läuft und der neue Cloud-Anbieter zu laufen beginnt.

Wenn Ihr Setup keine Ausfallzeit der Control Plane tolerieren kann, müssen Sie die Führungsmigration aktivieren. Dies erleichtert einen reibungslosen Übergang von den Controllern im Kube-Controller-Manager zu ihren Gegenstücken im Cloud-Controller-Manager.

Wichtig:

Die Kubernetes Dokumentation zur Migration des Cloud-Controllers besagt, dass es möglich ist, mit derselben Kubernetes-Version zu migrieren, geht jedoch davon aus, dass die Migration Teil eines Kubernetes-Upgrades ist. Verweisen Sie auf die Kubernetes-Dokumentation zu Migration zur Verwendung des Cloud-Controller-Managers, um zu sehen, ob Sie Ihre Einrichtung vor der Migration anpassen müssen. Bestätigen Sie Ihre Werte der Migrationskonfiguration. Wenn Ihr Cloud-Anbieter eine Implementierung des Node IPAM-Controllers bereitstellt, müssen Sie auch den IPAM-Controller migrieren.

Beginnend mit Kubernetes v1.26 sind die in-tree Persistent Volume-Typen kubernetes.io/azure-disk und kubernetes.io/azure-file als veraltet markiert und werden nicht mehr unterstützt. Es gibt keine Pläne, diese Treiber nach ihrem Auslaufen zu entfernen, jedoch sollten Sie auf die entsprechenden CSI-Treiber disk.csi.azure.com und file.csi.azure.com migrieren. Um die Migrationsoptionen für Ihre Speicherklassen zu überprüfen und Ihr Cluster auf die Verwendung von Azure Disks und Azure Files CSI-Treibern zu upgraden, finden Sie weitere Informationen unter Migration von In-Tree- zu CSI-Treibern.

  • RKE2

  • RKE

  1. Aktualisieren Sie die Clusterkonfiguration, um die Führungsmigration zu aktivieren:

    spec:
  rkeConfig:
    machineSelectorConfig:
      - config:
          kube-controller-manager-arg:
            - enable-leader-migration
        machineLabelSelector:
          matchExpressions:
            - key: rke.cattle.io/control-plane-role
              operator: In
              values:
                - 'true'

    Beachten Sie, dass der Cloud-Anbieter in diesem Schritt weiterhin azure ist:

    spec:
  rkeConfig:
    machineGlobalConfig:
      cloud-provider-name: azure

  2. Sperren Sie die Steuerungsknoten, damit die Azure Cloud-Controller-Pods nur nach dem Upgrade auf den externen Cloud-Anbieter auf den Knoten ausgeführt werden.

    kubectl cordon -l "node-role.kubernetes.io/control-plane=true"

  3. Um den Azure Cloud-Controller-Manager bereitzustellen, verwenden Sie eine der verfügbaren Optionen:

    Bestätigen Sie, dass das Chart installiert ist, die neuen Pods jedoch aufgrund der gesperrten Steuerungsknoten noch nicht ausgeführt werden.

  4. Um die Führungsmigration zu aktivieren, fügen Sie --enable-leader-migration zu den Containerargumenten von cloud-controller-manager hinzu:

    kubectl -n kube-system patch deployment cloud-controller-manager \
--type=json \
-p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--enable-leader-migration"}]'

  5. Aktualisieren Sie das Provisionierungs-Cluster, um den Cloud-Anbieter zu ändern und die Argumente für die Führungsmigration aus dem Kube-Controller-Manager zu entfernen. Wenn Sie die Kubernetes-Version aktualisieren, setzen Sie auch die Kubernetes-Version im Abschnitt spec.kubernetesVersion der Cluster-YAML-Datei.

    spec:
  rkeConfig:
    machineGlobalConfig:
      cloud-provider-name: external

    Entfernen Sie enable-leader-migration aus dem Kube-Controller-Manager:

    spec:
  rkeConfig:
    machineSelectorConfig:
      - config:
          kube-controller-manager-arg:
            - enable-leader-migration
        machineLabelSelector:
          matchExpressions:
            - key: rke.cattle.io/control-plane-role
              operator: In
              values:
                - 'true'

  6. Entcordonieren Sie die Steuerungsknotenknoten, damit die Azure Cloud-Controller-Pods jetzt auf den Knoten ausgeführt werden:

    kubectl uncordon -l "node-role.kubernetes.io/control-plane=true"

  7. Aktualisieren Sie das Cluster. Die cloud-controller-manager Pods sollten jetzt ausgeführt werden.

    kubectl rollout status deployment -n kube-system cloud-controller-manager
kubectl rollout status daemonset -n kube-system cloud-node-manager

  8. Der Cloud-Anbieter ist verantwortlich für die Festlegung der ProviderID des Knotens. Überprüfen Sie, ob alle Knoten mit der ProviderID initialisiert sind:

    kubectl describe nodes | grep "ProviderID"

  9. (Optional) Sie können die Führungsmigration nach dem Upgrade auch deaktivieren, da die Führungsmigration mit nur einem Cloud-Controller-Manager nicht erforderlich ist. Aktualisieren Sie die cloud-controller-manager Implementierung, um die Führungsmigration aus den Containerargumenten zu entfernen:

    - --enable-leader-migration=true

  1. Aktualisieren Sie die Clusterkonfiguration, um die Führungsmigration in cluster.yml zu aktivieren:

    services:
  kube-controller:
    extra_args:
      enable-leader-migration: "true"

    Beachten Sie, dass der Cloud-Anbieter in diesem Schritt weiterhin azure ist:

    cloud_provider:
  name: azure

  2. Sperren Sie die Steuerungsknotenknoten, damit die Azure-Cloud-Controller-Pods nur nach dem Upgrade auf den externen Cloud-Anbieter auf den Knoten ausgeführt werden:

    kubectl cordon -l "node-role.kubernetes.io/controlplane=true"

  3. Um den Azure-Cloud-Controller-Manager zu installieren, befolgen Sie die gleichen Schritte wie bei der Installation des Azure-Cloud-Anbieters in einem neuen Cluster:

  4. Bestätigen Sie, dass das Chart installiert ist, die neuen Pods jedoch aufgrund der gesperrten Steuerungsknoten noch nicht ausgeführt werden. Nach der Aktualisierung des Clusters im nächsten Schritt wird RKE jeden Knoten upgraden, entcordonieren und cloud-controller-manager Pods planen.

  5. Um die Führungsmigration zu aktivieren, fügen Sie --enable-leader-migration zu den Containerargumenten von cloud-controller-manager hinzu:

    kubectl -n kube-system patch deployment cloud-controller-manager \
--type=json \
-p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--enable-leader-migration"}]'

  6. Aktualisieren Sie cluster.yml, um den Cloud-Anbieter auf external zu ändern und die Argumente zur Führungsmigration aus dem kube-controller zu entfernen.

    rancher_kubernetes_engine_config:
  cloud_provider:
    name: external

    Entfernen Sie enable-leader-migration, wenn Sie es in Ihrem Cluster nicht aktiviert haben wollen:

    services:
  kube-controller:
    extra_args:
      enable-leader-migration: "true"

  7. Wenn Sie die Kubernetes-Version des Clusters upgraden, setzen Sie auch die Kubernetes-Version.

  8. Aktualisieren Sie das Cluster. Die cloud-controller-manager Pods sollten jetzt ausgeführt werden.

    kubectl rollout status deployment -n kube-system cloud-controller-manager
kubectl rollout status daemonset -n kube-system cloud-node-manager

  9. Der Cloud-Anbieter ist verantwortlich für die Festlegung der ProviderID des Knotens. Überprüfen Sie, ob alle Knoten mit der ProviderID initialisiert sind:

    kubectl describe nodes | grep "ProviderID"

  10. (Optional) Sie können die Führungsmigration nach dem Upgrade auch deaktivieren, da die Führungsmigration mit nur einem Cloud-Controller-Manager nicht erforderlich ist. Aktualisieren Sie die cloud-controller-manager Implementierung, um die Führungsmigration aus den Containerargumenten zu entfernen:

    - --enable-leader-migration=true