Migrer des clusters de VPC natif vers GKE Dataplane V2

Ce document explique comment migrer vos clusters Google Kubernetes Engine (GKE) VPC natifs existants de Dataplane V1 vers GKE Dataplane V2, surveiller la migration et l'annuler si nécessaire.

Ce document est destiné aux administrateurs et opérateurs de plate-forme, ainsi qu'aux spécialistes de la mise en réseau qui gèrent les configurations réseau de leurs clusters GKE.

Avant de commencer, découvrez ce qui se passe pendant chaque phase de migration et comment planifier les interruptions de charge de travail dans À propos de la migration vers GKE Dataplane V2.

Avant de commencer

Avant de lancer la migration, vérifiez que votre cluster répond aux exigences d'éligibilité et tenez compte de l'impact sur vos charges de travail.

Vérifiez que votre cluster répond aux exigences suivantes :

  • Le cluster est un cluster de VPC natif.
  • Le cluster exécute la version 1.35.3-gke.1155000 ou une version ultérieure.
  • Les pools de nœuds exécutent la version 1.35.1-gke.1516000 ou une version ultérieure.
  • Si vous utilisez Cloud Service Mesh ou Istio Open Source, votre version d'Istio est la version 1.23 ou une version ultérieure.

Préparer votre cluster

Effectuez les tâches suivantes avant de commencer la migration :

  • Suppression de NetworkPolicy : supprimez vos règles de réseau existantes. Si GKE applique soudainement des règles de réseau lorsqu'il recrée vos nœuds, vous risquez de subir des interruptions réseau involontaires.
  • Règles de réseau Calico : si vous utilisez un cluster GKE Standard avec la règle de réseau (Calico) activée, désactivez l'application de la règle de réseau. Vous ne pouvez pas migrer ces clusters directement.
  • Recommandations Active Assist : consultez Active Assist ou la page d'informations du cluster pour obtenir des recommandations susceptibles d'entrer en conflit avec la migration.
  • Capacité d'adresse IP : vérifiez que la plage d'adresses IP des pods de votre cluster dispose d' une capacité suffisante pour vos stratégies de mise à niveau du pool de nœuds. Pour en savoir plus, consultez la section Insights sur l'utilisation des adresses IP GKE.
    • Fonctionnalités de mise en réseau : activez les fonctionnalités de mise en réseau telles que NodeLocal DNSCache ou la visibilité intranœud avant de commencer la migration ou une fois la migration terminée. Vous ne pouvez pas les activer pendant la migration.

Comprendre les limites

  • Configurations réseau verrouillées : une fois la migration lancée, vous ne pouvez plus modifier les configurations réseau à l'échelle du cluster tant qu'elle n'est pas terminée.
  • Intervalles de maintenance : la migration suit vos intervalles et exclusions de maintenance. Il peut donc sembler qu'elle soit bloquée. Pour l'accélérer, vous pouvez appliquer des correctifs manuellement aux pools de nœuds. Pour savoir comment procéder, consultez Accélérer la migration.
  • Fonctionnalités facultatives de GKE Dataplane V2 : configurez les fonctionnalités facultatives de GKE Dataplane V2, telles que l'observabilité de GKE Dataplane V2 ou la prise en charge de plusieurs réseaux pour les pods, une fois la migration terminée.
  • Terraform : vous ne pouvez pas utiliser Terraform pour migrer vers GKE Dataplane V2.

Lancer la migration

Pour démarrer manuellement la migration et contourner les vérifications de diagnostic automatisées, vous pouvez appliquer un correctif au cluster à l'aide de la Google Cloud CLI.

Exécutez la commande suivante :

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --enable-dataplane-v2

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du cluster.
  • LOCATION : emplacement de calcul du cluster.

Observer la progression de la migration

Vous pouvez surveiller l'état de la migration en vérifiant le champ datapathProvider. Pendant la transition, ce champ affiche MIGRATE_TO_ADVANCED_DATAPATH.

  1. Vérifiez l'état du cluster :

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format='value(networkConfig.datapathProvider)'

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster.
    • LOCATION : emplacement de calcul du cluster.

  2. Vérifiez l'état du pool de nœuds :

    gcloud container node-pools list \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --format='value(name, networkConfig.datapathProvider)'

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster.
    • LOCATION : emplacement de calcul du cluster.

  3. Vérifiez le DaemonSet anetd pour vous assurer que les agents sont en cours d'exécution :

    kubectl get ds -n kube-system anetd

Accélérer la migration

Pour contourner le calendrier de déploiement automatisé, vous pouvez appliquer des correctifs manuellement aux pools de nœuds.

Pour appliquer manuellement un correctif à un pool de nœuds, exécutez la commande suivante :

gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --datapath-provider=advanced-datapath

Remplacez les éléments suivants :

  • NODE_POOL_NAME : nom du pool de nœuds.
  • CLUSTER_NAME : nom du cluster.
  • LOCATION : emplacement de calcul du cluster.

Finaliser la migration

Une fois que tous les pools de nœuds ont été migrés vers GKE Dataplane V2, GKE finalise automatiquement la migration. Une fois la migration terminée, le résultat de la commande affiche l'état ADVANCED_DATAPATH et le cluster exécute GKE Dataplane V2.

Observez la finalisation en vérifiant l'état du cluster :

gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format='value(networkConfig.datapathProvider)'

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du cluster.
  • LOCATION : emplacement de calcul du cluster.

Une fois la migration terminée, le résultat affiche ADVANCED_DATAPATH.

Effectuer un rollback d'une migration

Vous pouvez revenir à Dataplane V1 à tout moment avant la fin de la phase de finalisation. L'annulation de la migration est un processus symétrique à la migration directe : une fois que vous avez lancé le rollback, GKE applique automatiquement un correctif aux pools de nœuds pour revenir à l'ancien chemin de données, puis finalise le cluster.

  1. Observer l'état de anetd santé : avant d'annuler la migration, vérifiez si les agents sont en cours d'exécution pour déterminer si l'échec peut être atténué.

    kubectl get ds -n kube-system anetd

  2. Annuler les opérations de pool de nœuds en cours :

    1. Identifiez et annulez toutes les opérations de pool de nœuds en cours qui bloqueraient la requête de correctif de cluster.

      gcloud container operations list \
    --location=LOCATION \
    --filter="operationType=UPGRADE_NODES AND status=RUNNING AND targetLink:*/clusters/CLUSTER_NAME"

      Remplacez les éléments suivants :

      • LOCATION : emplacement de calcul du cluster.
      • CLUSTER_NAME : nom du cluster.

    2. Annulez l'opération à l'aide de l'ID d'opération :

      gcloud container operations cancel OPERATION_ID \
    --location=LOCATION

      Remplacez les éléments suivants :

      • OPERATION_ID : ID de l'opération en cours d'exécution.
      • LOCATION : emplacement de calcul du cluster.

  3. Lancer le rollback : émettez une requête de correctif de cluster pour revenir à la migration vers Dataplane V1.

    gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --no-enable-dataplane-v2

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster.
    • LOCATION : emplacement de calcul du cluster.

  4. Observer le déploiement du pool de nœuds : vérifiez l'état du pool de nœuds pour vérifier la migration vers l'ancien chemin de données.

    gcloud container node-pools list \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --format='value(name, networkConfig.datapathProvider)'

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster.
    • LOCATION : emplacement de calcul du cluster.

    Pendant le rollback, le résultat de la commande affiche l'état LEGACY_DATAPATH pour les pools de nœuds corrigés.

  5. Observer la finalisation : une fois que tous les pools de nœuds ont été migrés vers Dataplane V1, GKE finalise automatiquement la migration. Observez la finalisation en vérifiant l'état du cluster :

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format='value(networkConfig.datapathProvider)'

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster.
    • LOCATION : emplacement de calcul du cluster.

    Une fois le rollback terminé, le résultat de la commande affiche l'état LEGACY_DATAPATH.

Résoudre les problèmes de migration

Cette section fournit des informations pour vous aider à résoudre les problèmes courants que vous pouvez rencontrer lors de la migration vers GKE Dataplane V2.

Échec de la migration du pool de nœuds

Lors de la migration des pools de nœuds, GKE utilise la stratégie de mise à niveau de surutilisation ou de mise à niveau bleu-vert configurée pour créer des nœuds avant de supprimer les anciens. Si votre Google Cloud zone ne dispose pas de suffisamment de ressources pour provisionner les nouveaux nœuds, la migration échoue et une erreur GCE_STOCKOUT ou ZONE_RESOURCE_POOL_EXHAUSTED_WITH_DETAILS s'affiche. GKE tente automatiquement de migrer à nouveau ces pools de nœuds. Si vous appliquez manuellement un correctif aux pools de nœuds, attendez et réessayez la migration ultérieurement lorsque des ressources seront disponibles.

Étape suivante