Règles de mise à niveau de version

Comprendre l'impact de votre version actuelle et de votre version cible sur la mise à niveau de votre cluster vous aide à vérifier l'écart de version, l'ordre de mise à niveau et les exigences d'OS avant de commencer.

Informations de mise à niveau spécifiques à la version

Le tableau suivant décrit les informations de mise à niveau spécifiques à chaque version. Vous trouverez des informations sur des versions spécifiques après le tableau. Les versions sont classées de la plus récente à la plus ancienne. Recherchez la version vers laquelle vous effectuez la mise à niveau pour connaître les détails et les règles spécifiques qui s'appliquent à votre cluster.

Version Mettre à niveau d'abord Versions du plan de contrôle (PC) Versions de pool de nœuds de calcul État du cluster avancé Anciennes fonctionnalités compatibles ? Images de l'OS par défaut et requises Comportement de mise à niveau des nœuds Kubeception cert-manager groupé
1.36 Cluster d'administrateur 1.36, 1.35, 1.34 1.36, 1.35, 1.34 Obligatoire Aucun ubuntu_cgv2, cos_cgv2 Non compatible Groupé
1.35 Cluster d'administrateur 1.35, 1.34, 1.33 1.35, 1.34, 1.33 Obligatoire Aucun ubuntu_cgv2, cos_cgv2 obligatoire (cgroup v1 supprimé) Non compatible Groupé
1.34 Cluster d'administrateur 1.34, 1.33, 1.32 1.34, 1.33, 1.32 Obligatoire (pas de désactivation ; conversion automatique non avancée) Aucun ubuntu_cgv2 (par défaut), cos_cgv2, ubuntu_containerd, cos Non compatible Groupé
1.33 Cluster d'administrateur 1.33, 1.32, 1.31 1.33, 1.32, 1.31 Par défaut (conversion automatique) (désactivation uniquement pour la version 1.32 vers la version 1.33) Aucun ubuntu_cgv2 (par défaut), cos_cgv2, ubuntu_containerd, cos Non compatible Inclus pour les clusters avancés
1.32 Cluster d'administrateur 1.32, 1.31, 1.30 1.32, 1.31, 1.30 DG (mises à niveau compatibles ; mises à niveau de nœuds distinctes et ignorées compatibles) Aucun ubuntu_cgv2 (par défaut), cos_cgv2, ubuntu_containerd, cos Non compatible (vous devez migrer vers Controlplane V2) Inclus pour les clusters avancés
1.31 Cluster d'administrateur 1.31, 1.30, 1.29 1.31, 1.30, 1.29 Preview (pas de mise à niveau vers la version 1.32 ; pas de mise à niveau de nœud distincte ni d'omission de mise à niveau de nœud) Oui (Seesaw, F5, Kubeception, non-HA) ; migration vers les fonctionnalités recommandées fortement conseillée ; Dataplane V2 obligatoire ubuntu_cgv2 (par défaut), cos_cgv2, ubuntu_containerd, cos Nœuds d'administrateur mis à niveau avec l'administrateur ; nœuds du plan de contrôle utilisateur mis à niveau avec le cluster d'utilisateur Non groupé
1.30 Cluster d'utilisateur 1,30 1.30, 1.29, 1.28 Non disponible Oui (Seesaw, F5, Kubeception, non-HA) ; migration vers les fonctionnalités recommandées fortement conseillée ubuntu_cgv2 (par défaut), cos_cgv2, ubuntu_containerd, cos Nœuds du plan de contrôle et d'administrateur mis à niveau lors de la mise à niveau du cluster d'administrateur Non groupé
1.29 Cluster d'utilisateur 1.29, 1.30 1.29, 1.28, 1.16 Non disponible Oui (Seesaw, F5, Kubeception, sans haute disponibilité) ubuntu_cgv2 (par défaut), cos_cgv2, ubuntu_containerd, cos Nœuds du plan de contrôle et d'administrateur mis à niveau lors de la mise à niveau du cluster d'administrateur Non groupé
1.28 Cluster d'utilisateur 1.28, 1.29, 1.30 1.28, 1.16, 1.15 Non disponible Oui (Seesaw, F5, Kubeception, sans haute disponibilité) ubuntu_containerd (par défaut), cos, ubuntu_cgv2, cos_cgv2 Nœuds du plan de contrôle et d'administrateur mis à niveau lors de la mise à niveau du cluster d'administrateur Non groupé

Pour toutes les versions, vous devez mettre à niveau les versions des pools de nœuds d'équilibreur de charge (pools de nœuds avec enableLoadBalancer: true) en même temps et vers la même version que le plan de contrôle du cluster d'utilisateur.

Informations sur la mise à niveau par version

Recherchez la section correspondant à la version vers laquelle vous effectuez la mise à niveau pour obtenir les informations spécifiques dont vous avez besoin pour effectuer la mise à niveau vers cette version.

Version 1.36

Mettre à niveau en premier : cluster d'administrateur

Règles de décalage de version :

  • Un cluster d'administrateur en version 1.36 peut gérer des clusters d'utilisateur en versions 1.36, 1.35 et 1.34.
  • Versions du plan de contrôle du cluster d'utilisateur : 1.36, 1.35 ou 1.34.
  • Versions de pool de nœuds de calcul : 1.36, 1.35 ou 1.34.

État du cluster avancé : les clusters avancés sont obligatoires.

Ignorer les mises à niveau de nœuds : compatible.

Anciennes fonctionnalités compatibles : non. Bloque la mise à niveau.

Images de l'OS par défaut et requises : ubuntu_cgv2, cos_cgv2. La valeur par défaut de osImageType pour les nouvelles configurations est ubuntu_cgv2.

Comportement de mise à niveau des nœuds Kubeception : non compatible. Bloque la mise à niveau.

Outils de mise à niveau :

  • gkectl : obligatoire pour les clusters d'administrateur. Les versions compatibles sont 1.36, 1.37 et 1.38.
  • Terraform : compatible si vous avez créé le cluster d'utilisateur à l'aide de Terraform.
  • Google Cloud console : compatible avec les mises à niveau de clusters d'utilisateur.
  • Google Cloud CLI : compatible avec les mises à niveau des clusters d'utilisateur.

Exigences supplémentaires :

  • Vous pouvez exécuter les mises à niveau du cluster d'administrateur de manière asynchrone avec gkectl upgrade admin --async.

Version 1.35

Mettre à niveau en premier : cluster d'administrateur

Règles de décalage de version :

  • Un cluster d'administrateur en version 1.35 peut gérer des clusters d'utilisateur en versions 1.35, 1.34 et 1.33.
  • Versions du plan de contrôle du cluster d'utilisateur : 1.35, 1.34 ou 1.33.
  • Versions de pool de nœuds de calcul : 1.35, 1.34 ou 1.33.

État du cluster avancé : les clusters avancés sont obligatoires.

Ignorer les mises à niveau de nœuds : compatible.

Anciennes fonctionnalités compatibles : non. Bloque la mise à niveau.

Images de l'OS par défaut et requises : ubuntu_cgv2, cos_cgv2 obligatoires (cgroup v1 supprimé). La valeur par défaut de osImageType pour les nouvelles configurations est ubuntu_cgv2. Vous devez migrer les clusters vers cgroup v2 avant de procéder à la mise à niveau.

Comportement de mise à niveau des nœuds Kubeception : non compatible. Bloque la mise à niveau.

Outils de mise à niveau :

  • gkectl : obligatoire pour les clusters d'administrateur. Les versions compatibles sont 1.35, 1.36 et 1.37.
  • Terraform : compatible si vous avez créé le cluster d'utilisateur à l'aide de Terraform.
  • console : compatible avec les mises à niveau des clusters d'utilisateur.
  • gcloud CLI : compatible avec les mises à niveau des clusters d'utilisateur.

Exigences supplémentaires :

  • Vous pouvez exécuter les mises à niveau du cluster d'administrateur de manière asynchrone avec gkectl upgrade admin --async.

Version 1.34

Mettre à niveau en premier : cluster d'administrateur

Règles de décalage de version :

  • Un cluster d'administrateur en version 1.34 peut gérer des clusters d'utilisateur en versions 1.34, 1.33 et 1.32.
  • Versions du plan de contrôle du cluster d'utilisateur : 1.34, 1.33 ou 1.32.

  • Versions de pool de nœuds de calcul : 1.34, 1.33 ou 1.32.

État du cluster avancé : les clusters avancés sont obligatoires.

Ignorer les mises à niveau de nœuds : compatible.

Anciennes fonctionnalités compatibles : non. Bloque la mise à niveau.

Images de l'OS par défaut et requises : ubuntu_cgv2, cos_cgv2, ubuntu_containerd, cos. La valeur par défaut de osImageType est ubuntu_cgv2.

Comportement de mise à niveau des nœuds Kubeception : non compatible. Bloque la mise à niveau.

Outils de mise à niveau :

  • gkectl : obligatoire pour les clusters d'administrateur. Obligatoire pour convertir des clusters non avancés en clusters avancés (obligatoire dans la version 1.34 ; la version binaire gkectl doit correspondre exactement à la version cible). Les versions compatibles sont 1.34, 1.35 et 1.36.
  • Terraform : compatible si vous avez créé le cluster d'utilisateur à l'aide de Terraform.
  • console : compatible avec les mises à niveau avancées des clusters d'utilisateur.
  • gcloud CLI : compatible avec les mises à niveau avancées des clusters d'utilisateur.

Exigences supplémentaires :

Les exigences supplémentaires suivantes s'appliquent aux mises à niveau vers la version 1.34 :

  • Les clusters non avancés sont automatiquement convertis en clusters avancés lorsque vous passez à la version 1.34. Pour en savoir plus sur les règles spécifiques de mise à niveau de clusters non avancés vers des clusters avancés, consultez Mettre à jour ou mettre à niveau un cluster vers un cluster avancé.

  • cert-manager groupé est obligatoire et mis à jour vers la version 1.19, ce qui remplace les installations cert-manager personnalisées préexistantes. Pour en savoir plus sur les mises à niveau vers cert-manager groupé, consultez Utiliser cert-manager groupé.

  • L'environnement d'exécution du conteneur de nœud a été mis à niveau vers containerd 2.0. Cela peut avoir les conséquences suivantes :

    • containerd 2.0 n'est pas compatible avec les anciennes images Docker Image Manifest v2 ou de schéma 1. Assurez-vous que les charges de travail extraient les images de conteneurs à l'aide du schéma Docker 2 ou d'un format compatible OCI avant de passer à la version 1.34.
    • La configuration du miroir de registre est migrée au format hosts.toml dans containerd 2.0. Si vous gérez des configurations de miroir personnalisées ou des points de terminaison de registre sous air gap directement sur vos nœuds, vérifiez que votre configuration est conforme à hosts.toml.
    • Si vous utilisez des DaemonSets ou des scripts personnalisés qui corrigent /etc/containerd/config.toml, assurez-vous qu'ils n'utilisent pas d'options de configuration containerd v1 obsolètes, car cela peut entraîner des échecs de démarrage de containerd avec containerd 2.0.

  • La valeur par défaut du champ nodePoolUpdatePolicy.maximumConcurrentNodePoolUpdate a changé dans la version 1.34.300. Si vous souhaitez effectuer des mises à niveau séquentielles des pools de nœuds dans les versions 1.34.300 et ultérieures, définissez nodePoolUpdatePolicy.maximumConcurrentNodePoolUpdate: 1 dans le fichier de configuration de votre cluster d'utilisateur :

    • Pour les versions 1.34.0 à 1.34.200, nodePoolUpdatePolicy.maximumConcurrentNodePoolUpdate est défini par défaut sur 1, ce qui met à jour un pool de nœuds à la fois de manière séquentielle.
    • Pour les versions 1.34.300 et ultérieures, nodePoolUpdatePolicy.maximumConcurrentNodePoolUpdate est défini par défaut sur 0, ce qui met à jour tous les pools de nœuds simultanément.

    Pour en savoir plus, consultez Configurer la règle de mise à jour du pool de nœuds.

  • Les vérifications préliminaires de mise à niveau valident activement toutes les configurations PodDisruptionBudget (PDB) du cluster. Avant de procéder à la mise à niveau, vérifiez que vos charges de travail ne comportent pas de PDB trop restrictifs (par exemple, maxUnavailable: 0 ou minAvailable correspondant au nombre total d'instances répliquées) qui bloquent le drainage des nœuds ou qui peuvent entraîner l'échec des vérifications préliminaires.

  • Si une mise à niveau est interrompue, passez directement à la version 1.34.300-gke.59 ou ultérieure. Cette version empêche la suppression du cluster d'amorçage si vous devez réexécuter gkectl upgrade admin après un échec. Pour en savoir plus, consultez Réexécuter gkectl upgrade admin supprime le cluster d'amorçage.

  • Vous pouvez exécuter des mises à niveau de clusters d'administrateur de manière asynchrone avec gkectl upgrade admin --async pour les clusters avancés, sauf lorsque vous convertissez un cluster non avancé en cluster avancé.

Version 1.33

Mettre à niveau en premier : cluster d'administrateur

Règles de décalage de version :

  • Un cluster d'administrateur en version 1.33 peut gérer des clusters d'utilisateur en versions 1.33, 1.32 et 1.31.
  • Versions du plan de contrôle du cluster d'utilisateur : 1.33, 1.32 ou 1.31.

  • Versions de pool de nœuds de calcul : 1.33, 1.32 ou 1.31.

État des clusters avancés : les clusters avancés sont le type de cluster par défaut et sont convertis automatiquement. Désactivation autorisée. Pour en savoir plus, consultez Mettre à niveau et gérer des clusters non avancés. Si vous définissez enableAdvancedCluster sur false, la création du cluster échoue.

Ignorer les mises à niveau de nœuds : compatible.

Anciennes fonctionnalités compatibles : non. Bloque la mise à niveau.

Images de l'OS par défaut et requises : ubuntu_cgv2, cos_cgv2, ubuntu_containerd, cos. La valeur par défaut de osImageType est ubuntu_cgv2.

Comportement de mise à niveau des nœuds Kubeception : non compatible. Bloque la mise à niveau.

Outils de mise à niveau :

  • gkectl : requis pour convertir des clusters non avancés en clusters avancés (la version binaire gkectl doit correspondre exactement à la version cible). Obligatoire pour les clusters d'administrateur. Les versions compatibles sont 1.33, 1.34 et 1.35.
  • Terraform : compatible si vous avez créé le cluster d'utilisateur à l'aide de Terraform.
  • console : compatible avec les mises à niveau avancées des clusters d'utilisateur.
  • gcloud CLI : compatible avec les mises à niveau avancées des clusters d'utilisateur.

Exigences supplémentaires :

Les exigences supplémentaires suivantes s'appliquent aux mises à niveau vers la version 1.33 :

  • Les mises à niveau de la version 1.32 vers la version 1.33 convertissent automatiquement les clusters non avancés en clusters avancés par défaut. Vous pouvez conserver les clusters non avancés. Pour en savoir plus sur la façon de conserver des clusters non avancés, consultez Mettre à niveau et gérer des clusters non avancés.

  • Les clusters avancés installent et regroupent automatiquement cert-manager v1.18, en remplaçant les installations cert-manager personnalisées préexistantes. Pour en savoir plus sur les mises à niveau vers cert-manager groupé, consultez Utiliser cert-manager groupé.

  • Si vous passez à des clusters avancés dans cette version, la version binaire de gkectl doit correspondre exactement à la version cible lorsque vous passez de clusters non avancés à des clusters avancés. Cette exigence ne s'applique que lors de la mise à niveau vers un cluster avancé. Pour toutes les autres mises à niveau de votre cluster avancé, les règles d'écart de version standards s'appliquent.

  • Si une mise à niveau est interrompue, passez directement à la version 1.33.700-gke.71 ou ultérieure. Cette version empêche la suppression du cluster d'amorçage si vous devez réexécuter gkectl upgrade admin après un échec.

  • Vous pouvez exécuter les mises à niveau des clusters d'administrateur de manière asynchrone avec gkectl upgrade admin --async pour les clusters avancés et les clusters HA non avancés si tous les clusters d'utilisateur exécutent Controlplane V2. Vous ne pouvez pas utiliser l'option --async lorsque vous convertissez un cluster non avancé en cluster avancé.

Version 1.32

Mettre à niveau en premier : cluster d'administrateur

Règles de décalage de version :

  • Un cluster d'administrateur en version 1.32 peut gérer des clusters d'utilisateur en versions 1.32, 1.31 et 1.30.
  • Versions du plan de contrôle du cluster d'utilisateur : 1.32, 1.31 ou 1.30.

  • Versions de pool de nœuds de calcul : 1.32, 1.31 ou 1.30.

État du cluster avancé : compatible.

Ignorer les mises à niveau de nœuds : compatible.

Anciennes fonctionnalités compatibles : non. Bloque la mise à niveau.

Images de l'OS par défaut et requises : ubuntu_cgv2, cos_cgv2, ubuntu_containerd, cos. La valeur par défaut de osImageType est ubuntu_cgv2.

Comportement de mise à niveau des nœuds Kubeception : non compatible. Bloque la mise à niveau. Vous devez migrer vers Controlplane V2.

Outils de mise à niveau :

  • gkectl : requis pour convertir des clusters non avancés en clusters avancés (la version binaire gkectl doit correspondre exactement à la version cible). Obligatoire pour les clusters d'administrateur. Les versions compatibles sont 1.32, 1.33 et 1.34.
  • Terraform : compatible si vous avez créé le cluster d'utilisateur à l'aide de Terraform.
  • console : compatible avec les mises à niveau avancées des clusters d'utilisateur.
  • gcloud CLI : compatible avec les mises à niveau avancées des clusters d'utilisateur.

Exigences supplémentaires :

Les exigences supplémentaires suivantes s'appliquent aux mises à niveau vers la version 1.32 :

  • Il s'agit de la première version qui permet une mise à niveau facultative vers un cluster avancé GA entièrement compatible. Vous pouvez choisir les options suivantes :

    • Passer à un cluster non avancé et conserver le cluster non avancé. Si vous choisissez cette option, vous pouvez effectuer les opérations suivantes à partir de cette version :

      • Mettez à niveau le plan de contrôle du cluster d'utilisateur et les pools de nœuds de calcul séparément. Les pools de nœuds de calcul peuvent avoir jusqu'à deux versions mineures de retard par rapport au plan de contrôle.
      • Exécutez la mise à niveau de manière asynchrone pour les clusters d'administrateur et d'utilisateur.

    • Mettez à niveau vers un cluster non avancé, puis convertissez le cluster non avancé en cluster avancé. Si vous choisissez cette option, vous pouvez effectuer les opérations suivantes à partir de cette version :

      • Mettez à niveau le plan de contrôle du cluster d'utilisateur et les pools de nœuds de calcul séparément lorsque vous mettez à niveau le cluster non avancé, mais pas lorsque vous le convertissez en cluster avancé. Les pools de nœuds de calcul peuvent être jusqu'à deux versions mineures derrière le plan de contrôle.
      • Exécutez la mise à niveau de manière asynchrone pour les clusters d'administrateur et d'utilisateur lorsque vous mettez à niveau le cluster non avancé.
      • Lorsque vous passez au cluster avancé, effectuez une mise à niveau vers la version 1.32.1000-gke.57 ou une version ultérieure, car elle intègre un correctif pour un problème connu qui empêche la suppression du cluster d'amorçage.

    • Passez directement à un cluster Advanced. Si vous choisissez cette option, les règles suivantes s'appliquent à partir de cette version :

      • Vous devez mettre à niveau le plan de contrôle et tous les pools de nœuds en même temps.
      • Vous pouvez exécuter la mise à niveau de manière asynchrone pour les clusters d'utilisateur, mais pas pour les clusters d'administrateur.
      • Passez à la version 1.32.1000-gke.57 ou ultérieure, car elle intègre un correctif pour un problème connu qui empêche la suppression du cluster d'amorçage.

  • Les anciennes fonctionnalités suivantes ne sont plus prises en charge à partir de cette version. Pour en savoir plus, consultez Anciennes fonctionnalités :

    • Dataplane V1 (Calico). Passez à Dataplane V2 avant de passer à la version 1.32.
    • Seesaw. Passez à un autre équilibreur de charge avant de passer à la version 1.32.
    • F5 BIG-IP intégré. Passez à un autre équilibreur de charge avant de passer à la version 1.32.
    • Kubeception. Passez à un cluster non-Kubeception avant de passer à la version 1.32.
    • Clusters d'administrateurs non HD. Passez à un cluster d'administrateur haute disponibilité avant de passer à la version 1.32.

  • La version binaire de gkectl doit correspondre exactement à la version cible lorsque vous passez de clusters non avancés à des clusters avancés. Cette exigence ne s'applique que lors de la mise à niveau vers un cluster avancé. Pour toutes les autres mises à niveau de votre cluster avancé, les règles d'écart de version standards s'appliquent.

  • Si une mise à niveau est interrompue, passez directement à la version 1.32.1000-gke.57 ou ultérieure. Cette version empêche la suppression du cluster d'amorçage si vous devez réexécuter gkectl upgrade admin après un échec.

  • Dans la version 1.32 et les versions ultérieures, vous pouvez exécuter des mises à niveau de clusters d'administrateur de manière asynchrone avec gkectl upgrade admin --async pour les clusters avancés et les clusters à haute disponibilité non avancés si tous les clusters d'utilisateur exécutent Controlplane V2. Vous ne pouvez pas utiliser l'option --async lorsque vous convertissez un cluster non avancé en cluster avancé.

Version 1.31

Mettre à niveau en premier : cluster d'administrateur

Règles de décalage de version :

  • Un cluster d'administrateur en version 1.31 peut gérer des clusters d'utilisateur en versions 1.31, 1.30 et 1.29.
  • Versions du plan de contrôle du cluster d'utilisateur : 1.31, 1.30 ou 1.29.
  • Versions de pool de nœuds de calcul : 1.31, 1.30 ou 1.29. (Non compatible avec les clusters avancés 1.31).
  • Pour passer de la version 1.29/1.30 à la version 1.31, vous devez mettre à niveau tous les clusters vers la version 1.30 avant de mettre à niveau le cluster d'administrateur vers la version 1.31.

État du cluster avancé : version preview uniquement. Impossible de passer à des versions supérieures.

Ignorer les mises à niveau de nœuds : compatible.

Anciennes fonctionnalités compatibles : Dataplane V2 obligatoire ; Kubeception, Seesaw et F5 toujours compatibles.

Images de l'OS par défaut et requises : ubuntu_cgv2, cos_cgv2, ubuntu_containerd, cos. La valeur par défaut de osImageType est ubuntu_cgv2.

Comportement de mise à niveau des nœuds Kubeception : les nœuds d'administrateur sont mis à niveau avec le cluster d'administrateur, et les nœuds du plan de contrôle utilisateur sont mis à niveau avec le cluster d'utilisateur.

Outils de mise à niveau :

  • gkectl : obligatoire pour les clusters d'administrateur, les clusters non avancés et les clusters avancés (preview, pour cette version). Les versions compatibles sont 1.31, 1.32 et 1.33.
  • Terraform : compatible avec les clusters d'utilisateur enregistrés si vous avez créé le cluster d'utilisateur à l'aide de Terraform.
  • console : compatible avec les mises à niveau des clusters d'utilisateur enregistrés.
  • gcloud CLI : compatible avec les mises à niveau des clusters d'utilisateurs enregistrés.

Exigences supplémentaires :

Les exigences supplémentaires suivantes s'appliquent aux mises à niveau vers la version 1.31 :

  • Cette version a introduit les clusters avancés en mode Aperçu. Dans cette version, vous ne pouvez pas migrer des clusters non avancés vers des clusters avancés. Vous pouvez créer des clusters en tant que clusters avancés, mais vous ne pouvez pas mettre à niveau ces clusters avancés en version preview vers une version ultérieure. Nous vous déconseillons de créer des clusters avancés dans cette version. Pour en savoir plus sur les étapes de lancement des produits, comme la version preview, consultez Étapes de lancement des produits.

  • Dans la version 1.31 et les versions ultérieures, l'architecture des mises à niveau a été modifiée pour adopter un modèle dans lequel le cluster d'administrateur doit désormais être supérieur ou égal à ses clusters d'utilisateur. Auparavant, les clusters d'utilisateur pouvaient avoir jusqu'à deux versions mineures d'avance sur le cluster d'administrateur.

  • Vous devez mettre à niveau le cluster d'administrateur avant de mettre à niveau les clusters d'utilisateur qu'il gère. Les clusters d'administrateur peuvent gérer des clusters d'utilisateur avec la même version mineure ou jusqu'à deux versions mineures inférieures. Par exemple, un cluster d'administrateur en version 1.31 peut gérer des clusters d'utilisateur en versions 1.31, 1.30 et 1.29.

  • Pour passer de la version 1.29 à la version 1.31, vous devez d'abord déployer le bundle 1.30 en tant qu'étape intermédiaire. Vous devez télécharger les bundles 1.30 et 1.31 sur le poste de travail administrateur pour passer à la version 1.31. Pour effectuer une mise à niveau en sautant une version (de la version 1.29 à la version 1.31), procédez comme suit :

    1. Mettez à niveau uniquement le plan de contrôle du cluster d'utilisateur de la version 1.29 vers la version 1.30 (en laissant les pools de nœuds de calcul sur la version 1.29).
    2. Mettez à niveau le cluster d'administrateur de la version 1.29 vers la version 1.30.
    3. Mettez à niveau le cluster d'administrateur de la version 1.30 vers la version cible 1.31.
    4. Mettez à niveau le plan de contrôle du cluster d'utilisateur et les pools de nœuds de calcul vers la version 1.31.

  • Si vous utilisez Kubeception, les nœuds du cluster d'administrateur sont mis à niveau lors de la mise à niveau du cluster d'administrateur, et les nœuds du plan de contrôle du cluster d'utilisateur sont mis à niveau lors de la mise à niveau du cluster d'utilisateur.

  • Pour passer à la version 1.31, vous devez activer Dataplane V2. Pour éviter les conflits de règles de réseau et les pertes de trafic lors de la migration CNI, vous devez enregistrer manuellement, puis supprimer tous les objets NetworkPolicy et les restaurer après la mise à niveau. Pour passer à Dataplane V2, procédez comme suit :

    1. Exportez et enregistrez toutes vos règles de réseau personnalisées :

      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get networkpolicy -A -o wide \
    --field-selector metadata.namespace!=kube-system
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get networkpolicy POLICY_NAME \
    -n NAMESPACE -o yaml > policy.yaml

      Remplacez les éléments suivants :

      • USER_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'utilisateur.
      • POLICY_NAME : nom de l'objet NetworkPolicy
      • NAMESPACE : espace de noms de l'objet NetworkPolicy.

    2. Supprimez les règles de réseau du cluster :

      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    delete networkpolicy POLICY_NAME \
    -n NAMESPACE

    3. Définissez enableDataplaneV2: true dans le fichier de configuration du cluster d'utilisateur et effectuez la mise à niveau vers la version 1.31.

    4. Appliquez les règles enregistrées une fois la mise à niveau vers la version 1.31 terminée afin que Cilium les compile correctement dans un filtre de paquets Berkeley étendu (eBPF) :

      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    apply -f policy.yaml

  • Si vous disposez de clusters d'administrateur à haute disponibilité et que tous les clusters d'utilisateur exécutent Controlplane V2, vous pouvez exécuter la mise à niveau de manière asynchrone à l'aide de la commande gkectl upgrade admin --async.

  • Dataplane V2 est requis pour tous les clusters d'utilisateur. Avant de mettre à niveau un cluster d'utilisateur vers la version 1.31, suivez les étapes de la section Activer Dataplane V2.

  • Les anciennes fonctionnalités ne sont pas compatibles avec la version 1.32. Vous pouvez les remplacer dans les versions 1.30 et 1.31 pour éviter les problèmes lors de la mise à niveau vers la version 1.32.

Version 1.30

Mettre à niveau en premier : cluster d'utilisateur

Règles de décalage de version :

  • Un cluster d'utilisateur en version 1.30 peut être géré par un cluster d'administrateur en version 1.30, 1.29 ou 1.28.
  • Un cluster d'administrateur en version 1.30 ne peut gérer que des clusters d'utilisateur en version 1.30. Tous les clusters d'utilisateur et le cluster d'administrateur doivent atteindre la version 1.30 avant que vous ne puissiez mettre à niveau le cluster d'administrateur vers la version 1.31. Vous devez mettre à niveau le cluster d'administrateur vers la version 1.31 avant de pouvoir mettre à niveau un cluster d'utilisateur vers la version 1.31.
  • Versions du plan de contrôle du cluster d'utilisateur : 1.30.
  • Versions de pool de nœuds de calcul : 1.30, 1.29 ou 1.28.

État avancé du cluster : non disponible.

Ignorer les mises à niveau de nœuds : compatible.

Anciennes fonctionnalités compatibles : compatibles. La migration vers les fonctionnalités recommandées est vivement conseillée.

Images de l'OS par défaut et requises : ubuntu_cgv2, cos_cgv2, ubuntu_containerd, cos. La valeur par défaut de osImageType est ubuntu_cgv2.

Outils de mise à niveau :

  • gkectl : obligatoire pour les clusters d'administrateur. Les versions compatibles sont 1.30, 1.31 et 1.32.
  • Terraform : compatible avec les clusters d'utilisateur enregistrés si vous avez créé le cluster d'utilisateur à l'aide de Terraform.
  • console : compatible avec les mises à niveau des clusters d'utilisateur enregistrés.
  • gcloud CLI : compatible avec les mises à niveau des clusters d'utilisateurs enregistrés.

Exigences supplémentaires :

Les exigences supplémentaires suivantes s'appliquent aux mises à niveau vers la version 1.30 :

  • Pour cette version et toutes les versions précédentes, vous devez migrer tous les clusters d'utilisateur avant de mettre à niveau le cluster d'administrateur de gestion. Le cluster d'administrateur doit être à la même version mineure ou à une version mineure inférieure à celle de tout cluster d'utilisateur géré.

  • Si vous utilisez Kubeception, voici ce qui se passe lors d'une mise à niveau :

    1. Mettez à niveau le cluster d'utilisateur. Étant donné que le plan de contrôle utilisateur se trouve dans le cluster d'administrateur, l'exécution de gkectl upgrade cluster ne met à niveau que les pools de nœuds de calcul.
    2. Mettez à niveau le cluster d'administrateur. La mise à niveau du cluster d'administrateur met à niveau les nœuds d'administrateur et met automatiquement à niveau tous les plans de contrôle des clusters d'utilisateur en même temps.

  • Si vous utilisez Controlplane V2, voici ce qui se passe pendant la mise à niveau :

    1. Mettez à niveau le cluster d'utilisateur. Cette opération met à niveau le plan de contrôle et les pools de nœuds de calcul.
    2. Mettez à niveau le cluster d'administrateur. Cela met à niveau les nœuds d'administrateur.

  • Lorsque vous créez un cluster d'utilisateur, vous devez définir le champ enableControlplaneV2 sur true, qui est la valeur par défaut à partir de cette version. Si vous définissez le champ enableControlplaneV2 sur false, gkectl rejette le fichier et ne crée pas le cluster.

  • Si vous disposez de clusters d'administrateur à haute disponibilité et que tous les clusters d'utilisateur exécutent Controlplane V2, vous pouvez exécuter la mise à niveau de manière asynchrone à l'aide de la commande gkectl upgrade admin --async.

  • Les anciennes fonctionnalités ne sont pas compatibles avec la version 1.32. Vous pouvez les remplacer dans les versions 1.30 et 1.31 pour éviter les problèmes lors de la mise à niveau vers la version 1.32.

Version 1.29

Mettre à niveau en premier : cluster d'utilisateur

Règles de décalage de version :

  • Un cluster d'utilisateur en version 1.29 peut être géré par un cluster d'administrateur en version 1.29, 1.28 ou 1.16.
  • Un cluster d'administrateur en version 1.29 peut gérer des clusters d'utilisateur en versions 1.29 et 1.30. Un cluster d'administrateur en version 1.29 ne peut pas gérer des clusters d'utilisateur en version 1.31, car tous les clusters doivent d'abord atteindre la version 1.30 et le cluster d'administrateur doit être mis à niveau vers la version 1.31 avant qu'un cluster d'utilisateur puisse être mis à niveau vers la version 1.31.
  • Versions du plan de contrôle du cluster d'utilisateur : 1.29 ou 1.30, soit jusqu'à une version mineure supérieure.
  • Versions de pool de nœuds de calcul : 1.29, 1.28 ou 1.16.

État avancé du cluster : non disponible.

Ignorer les mises à niveau de nœuds : compatible.

Anciennes fonctionnalités compatibles : compatibles.

Images de l'OS par défaut et requises : ubuntu_cgv2, cos_cgv2, ubuntu_containerd, cos. La valeur par défaut de osImageType est ubuntu_cgv2.

Comportement de la mise à niveau des nœuds Kubeception : mise à niveau du plan de contrôle et des nœuds d'administrateur lors de la mise à niveau du cluster d'administrateur

Outils de mise à niveau :

  • gkectl : obligatoire pour les clusters d'administrateur. Les versions compatibles sont 1.29, 1.30 et 1.31.
  • Terraform : compatible avec les clusters d'utilisateur enregistrés si vous avez créé le cluster d'utilisateur à l'aide de Terraform.
  • console : compatible avec les mises à niveau des clusters d'utilisateur enregistrés.
  • gcloud CLI : compatible avec les mises à niveau des clusters d'utilisateurs enregistrés.

Exigences supplémentaires :

Les exigences supplémentaires suivantes s'appliquent aux mises à niveau vers la version 1.29 :

  • Les nœuds de calcul peuvent être jusqu'à deux versions mineures derrière le plan de contrôle (n+2).
  • Vous pouvez ignorer une version mineure lorsque vous mettez à niveau des pools de nœuds de calcul. Par exemple, vous pouvez mettre à niveau un pool de nœuds de calcul de la version 1.28 vers la version 1.30.
  • Les vérifications préliminaires s'exécutent en tant que pods dans le cluster d'administrateur ou dans un cluster kind d'amorçage temporaire, plutôt que sur le poste de travail administrateur.
  • À partir de cette version, vous pouvez exécuter une vérification préliminaire sans mettre à niveau le cluster à l'aide de gkectl upgrade cluster --dry-run.
  • Si vous disposez de clusters d'administrateur à haute disponibilité et que tous les clusters d'utilisateur exécutent Controlplane V2, vous pouvez exécuter la mise à niveau de manière asynchrone à l'aide de la commande gkectl upgrade admin --async.

Version 1.28

Mettre à niveau en premier : cluster d'utilisateur

Règles de décalage de version :

  • Un cluster d'utilisateur en version 1.28 peut être géré par un cluster d'administrateur en version 1.28, 1.16 ou 1.15.
  • Un cluster d'administrateur en version 1.28 peut gérer des clusters d'utilisateur en versions 1.28, 1.29 et 1.30.
  • Versions du plan de contrôle du cluster d'utilisateur : 1.28, 1.29 ou 1.30, soit jusqu'à deux versions mineures plus récentes.
  • Versions du pool de nœuds de calcul : 1.28, 1.16 ou 1.15, soit jusqu'à deux versions mineures inférieures.

État avancé du cluster : non disponible.

Ignorer les mises à niveau de nœuds : compatible.

Anciennes fonctionnalités compatibles : compatibles.

Images de l'OS par défaut et requises : ubuntu_containerd, cos, ubuntu_cgv2, cos_cgv2. La valeur par défaut de osImageType est ubuntu_containerd.

Comportement de la mise à niveau des nœuds Kubeception : mise à niveau du plan de contrôle et des nœuds d'administrateur lors de la mise à niveau du cluster d'administrateur

Outils de mise à niveau :

  • gkectl : obligatoire pour les clusters d'administrateur. Les versions compatibles sont les versions 1.28, 1.29 et 1.30.
  • Terraform : compatible avec les clusters d'utilisateur enregistrés si vous avez créé le cluster d'utilisateur à l'aide de Terraform.
  • console : compatible avec les mises à niveau des clusters d'utilisateur enregistrés.
  • gcloud CLI : compatible avec les mises à niveau des clusters d'utilisateurs enregistrés.

Exigences supplémentaires :

Les exigences supplémentaires suivantes s'appliquent aux mises à niveau vers la version 1.28 :

  • Vous devez activer kubernetesmetadata.googleapis.com et accorder roles/kubernetesmetadata.publisher au compte de service de surveillance de la journalisation. Sans cela, les vérifications préliminaires peuvent échouer ou des erreurs 403 PERMISSION_DENIED peuvent s'afficher. Activez l'API et attribuez le rôle au compte de service logging-monitoring existant :

    gcloud services enable kubernetesmetadata.googleapis.com
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:LOGGING_SA" \
    --role="roles/kubernetesmetadata.publisher"

    Remplacez les éléments suivants :

    • PROJECT_ID : ID du projet hôte de parc dans lequel ce cluster d'utilisateur est membre.
    • LOGGING_SA : adresse e-mail de votre compte de service de journalisation et de surveillance.

  • Même s'il est techniquement possible d'ignorer des versions lors d'une mise à niveau de pool de nœuds, cette fonctionnalité a été introduite en tant que fonctionnalité en preview et n'est pas recommandée pour cette version. Pour en savoir plus sur les étapes de lancement des produits, comme la version preview, consultez Étapes de lancement des produits.

  • Les pools de nœuds avec un équilibreur de charge groupé doivent correspondre exactement à la version du cluster.

  • Vous pouvez mettre à niveau plusieurs nœuds en même temps en définissant le champ nodePools[i].updateStrategy.rollingUpdate.maxSurge. Votre cluster vSphere doit disposer de suffisamment de processeurs, de RAM et d'adresses IP disponibles pour accueillir les VM de surutilisation supplémentaires pendant la mise à niveau :

    • Définissez maxSurge: 1 (par défaut) pour mettre à niveau un nœud à la fois (drainer, remplacer, vérifier, puis répéter).
    • Définissez maxSurge: N (où N > 1) pour provisionner et drainer jusqu'à N nœuds de calcul en même temps (par exemple, maxSurge: 3 met à niveau trois nœuds de calcul simultanément).

  • Vous devez disposer d'au moins 100 Go d'espace disque libre sur votre poste de travail administrateur pour le mettre à niveau.

  • La version de gkectl que vous utilisez pour la mise à niveau peut être jusqu'à deux versions mineures supérieure à celle du cluster actuel. Vous ne pouvez pas utiliser une version mineure antérieure.

Versions antérieures à la version 1.28

Les exigences supplémentaires suivantes s'appliquent aux mises à niveau vers des versions antérieures à la version 1.28. Il n'y a pas eu de versions entre la 1.16 et la 1.28 :

Version 1.16 :

  • Le décalage de version entre les clusters d'administrateur et d'utilisateur, et entre le plan de contrôle et les pools de nœuds, ne peut être que d'une version mineure. Par exemple, un cluster d'administrateur en version 1.15 ne peut gérer que des clusters d'utilisateur en version 1.15 ou 1.16. Un plan de contrôle de cluster d'utilisateur mis à niveau vers la version 1.16 peut gérer des pools de nœuds de calcul exécutant la version 1.15 ou 1.16. Un pool de la version 1.14 doit être mis à niveau vers la version 1.15 avant que le plan de contrôle puisse passer à la version 1.16. Pour en savoir plus sur les écarts de version, consultez Règles d'écart de version.
  • Les clusters sont automatiquement enregistrés dans l'API GKE On-Prem lors de leur création ou de leur mise à niveau vers la version 1.16. Grâce à ce changement, vous pouvez afficher, surveiller et mettre à niveau les clusters d'utilisateur à l'aide de la console, de gcloud CLI et de Terraform, au lieu d'utiliser uniquement l'interface système du poste de travail administrateur.

Version 1.14 :

  • Vous pouvez d'abord mettre à niveau uniquement le plan de contrôle du cluster d'utilisateur, afin de ne pas avoir à drainer et à mettre à niveau chaque pool de nœuds de calcul en même temps.
  • Lors de la mise à niveau, le système inspecte et met à jour automatiquement les fichiers kubeconfig existants des clusters d'administrateur et d'utilisateur sur le poste de travail, en renouvelant automatiquement les identifiants.

Version 1.13 :

  • Avant cette version, vous pouviez disposer d'un cluster d'administrateur hors connexion. Cette version nécessite que vous enregistriez votre cluster d'administrateur dans Google Cloud. Pour en savoir plus sur l'enregistrement d'un cluster, consultez Enregistrer un cluster existant.
  • Pour mettre à niveau un cluster vers Google Distributed Cloud (logiciel uniquement) pour VMware version 1.13 ou ultérieure, vous devez d'abord mettre à jour tous les pools de nœuds de cluster d'utilisateur qui utilisent encore Docker Engine vers containerd.

Utiliser le cert-manager groupé

Vous devez utiliser le cert-manager groupé, qui est automatiquement installé sur les clusters avancés. Lorsque vous migrez d'un cluster non avancé vers un cluster avancé, le cert-manager intégré remplace automatiquement toutes les versions de cert-manager installées par le client. Assurez-vous qu'aucune configuration ou fonctionnalité personnalisée critique n'est appliquée à votre cert-manager existant avant de passer à des clusters avancés.

Pour savoir si vous avez appliqué des configurations ou des fonctionnalités personnalisées critiques à votre cert-manager, procédez comme suit :

  • Suspendre les outils de déploiement continu. Si vous gérez cert-manager à l'aide d'outils GitOps (tels que Config Sync, ArgoCD ou Flux), suspendez la synchronisation ou supprimez les fichiers manifestes cert-manager de votre dépôt avant d'effectuer la mise à niveau. Si un contrôleur GitOps tente de rapprocher cert-manager vers une version antérieure ou un fichier manifeste personnalisé pendant la mise à niveau du cluster, il crée une boucle de rapprochement qui peut bloquer la mise à niveau du cluster.
  • Ne désinstallez pas et ne supprimez pas manuellement les pods, les espaces de noms ou les CRD cert-manager avant la mise à niveau. gkectl gère ces mises à niveau sur place.
  • Si vous avez modifié les options de déploiement cert-manager, les sélecteurs de nœuds ou les limites de ressources des pods, annulez ces modifications. Les clusters avancés ne sont pas compatibles avec les arguments binaires personnalisés ni les remplacements au niveau du déploiement sur cert-manager.
  • Si vous utilisez des émetteurs externes spécialisés, des plug-ins de webhook ACME DNS-01 privés ou des webhooks personnalisés, vérifiez que vos plug-ins tiers sont compatibles avec la version cert-manager groupée de la version vers laquelle vous effectuez la mise à niveau.

Pour en savoir plus, consultez Passer à cert-manager avec les clusters avancés.

Le tableau suivant indique les versions de release qui nécessitent l'intégration de cert-manager :

Version État des nouveaux clusters État des mises à niveau des clusters existants cert-manager groupé requis ?
1.34+ Obligatoire Conversion obligatoire (v1.19 groupée) Obligatoire pour tous les clients. Les clusters non avancés ne peuvent plus exister.
1.33 Standard/Par défaut pour tous les nouveaux clusters Conversion automatique en clusters avancés par défaut (v1.18 groupée) Obligatoire pour presque tous les clusters, sauf si vous désactivez explicitement l'option avec enableAdvancedCluster: false (1.32 → 1.33 uniquement).
1.32 (DG) Activée par défaut Conversion facultative en clusters avancés Obligatoire si les clusters avancés sont activés.
1.31 (Preview) Facultatif (enableAdvancedCluster: true) Non compatible Obligatoire si les clusters avancés sont activés.

Pour savoir quelle version de cert-manager est incluse dans chaque version compatible, consultez Versions de cert-manager incluses.

Plan de contrôle V2

Lorsque Controlplane V2 est activé, le plan de contrôle du cluster d'utilisateur s'exécute sur le cluster d'utilisateur lui-même. Pour Controlplane V2, les nœuds du plan de contrôle du cluster d'utilisateur sont mis à niveau lors de la mise à niveau du cluster d'utilisateur, et les nœuds du plan de contrôle du cluster d'administrateur sont mis à niveau lors de la mise à niveau du cluster d'administrateur.

Anciennes fonctionnalités

Le tableau suivant répertorie les anciennes fonctionnalités qui sont bloquées dans la version 1.32 et les versions ultérieures. Si vous utilisez ces fonctionnalités, vous devez migrer vers les alternatives recommandées avant de pouvoir passer à la version 1.32 ou ultérieure.

| Ancienne fonctionnalité (bloquée dans la version 1.32) | Remplacer par (recommandé) | Lien vers les instructions de migration | | --- | --- | --- | | Dataplane V1 (Calico) | Dataplane V2 (Cilium/eBPF) | Migrer vers Dataplane V2| | Kubeception | Controlplane V2 | Migrer vers Controlplane V2 | | Cluster d'administrateur sans haute disponibilité (1 instance répliquée) | Cluster d'administrateur haute disponibilité (3 instances répliquées) | Migrer vers un cluster d'administrateur haute disponibilité | | Équilibreur de charge Seesaw | MetalLB ou ManualLB | Migrer vers MetalLB ou Migrer le type d'équilibreur de charge| | F5 BIG-IP intégré (loadBalancer.kind: "F5BigIP") | ManualLB (associé au contrôleur F5 Big-IP ou à CCGI) | Migrer vers ManualLB |

Pour savoir comment migrer d'anciennes fonctionnalités vers les fonctionnalités recommandées, consultez Planifier la migration du cluster vers les fonctionnalités recommandées.

Migration et comportement des versions de Kubeception

Kubeception est une ancienne fonctionnalité qui doit être migrée vers Controlplane V2 avant de pouvoir passer à la version 1.32 ou ultérieure.

Les mises à niveau se comportent différemment pour les clusters avec Kubeception en fonction de votre version :

  • Pour la version 1.28 : mise à niveau du plan de contrôle et des nœuds d'administrateur lors de la mise à niveau du cluster d'administrateur
  • Pour la version 1.29 : mise à niveau du plan de contrôle et des nœuds d'administrateur lors de la mise à niveau du cluster d'administrateur

  • Pour la version 1.30 : mise à niveau du plan de contrôle et des nœuds d'administrateur lors de la mise à niveau du cluster d'administrateur. Si vous utilisez Kubeception, voici ce qui se passe lors d'une mise à niveau :

    1. Mettez à niveau le cluster d'utilisateur. Étant donné que le plan de contrôle utilisateur se trouve dans le cluster d'administrateur, l'exécution de gkectl upgrade cluster ne met à niveau que les pools de nœuds de calcul.
    2. Mettez à niveau le cluster d'administrateur. La mise à niveau du cluster d'administrateur met à niveau les nœuds d'administrateur et met automatiquement à niveau tous les plans de contrôle des clusters d'utilisateur en même temps.

  • Pour la version 1.31 : les nœuds d'administrateur sont mis à niveau avec le cluster d'administrateur, et les nœuds du plan de contrôle utilisateur sont mis à niveau avec le cluster d'utilisateur.

  • Pour la version 1.32 et les versions ultérieures : Kubeception n'est pas compatible. Vous devez migrer vers Controlplane V2 avant de pouvoir passer à la version 1.32 ou ultérieure.

    Pour en savoir plus sur la migration de Kubeception vers Controlplane V2, consultez Planifier la migration du cluster vers les fonctionnalités recommandées.

Décalage entre les versions et saut d'une version lors de la mise à niveau

Le décalage de version est la différence autorisée entre les versions mineures d'un cluster d'administrateur et de ses clusters d'utilisateur gérés, ou la différence entre les versions mineures du plan de contrôle d'un cluster d'utilisateur et des pools de nœuds sur le cluster d'utilisateur.

L'asymétrie de version est différente de l'omission d'une version mineure lors de la mise à niveau.

Vous ne pouvez ignorer une version mineure que lorsque vous mettez à niveau des pools de nœuds de calcul, après avoir mis à niveau le plan de contrôle. Cela s'applique aux clusters avancés et non avancés, à l'exception des clusters avancés exécutant la version 1.31 et les versions antérieures à la version 1.28. Par exemple, si un pool de nœuds de calcul est en version 1.29, mettez à jour le plan de contrôle du cluster d'utilisateur vers la version 1.30, puis vers la version 1.31. Une fois que le plan de contrôle est en version 1.31, mettez à niveau le pool de nœuds de calcul de la version 1.29 vers la version 1.31 directement, sans passer par la version 1.30. Pour en savoir plus, consultez Ignorer une version lors de la mise à niveau des pools de nœuds.

Pour passer à une version mineure supérieure à la version mineure séquentielle suivante, passez d'abord à la version mineure suivante, puis à la version mineure supérieure. Vous ne pouvez pas ignorer une version mineure lorsque vous mettez à niveau les plans de contrôle des clusters d'administrateur et d'utilisateur. Par exemple, si vous souhaitez passer de la version 1.34.x à la version 1.36.x, vous ne pouvez pas effectuer la mise à niveau directement. Vous devez d'abord passer de la version 1.34.x à la version 1.35.x, puis à la version 1.36.x.

Le plan de contrôle d'un cluster d'utilisateur peut être jusqu'à deux versions mineures plus récentes que les pools de nœuds de calcul du cluster. Par exemple, si le plan de contrôle d'un cluster d'utilisateur est à la version 1.36, les pools de nœuds de calcul du cluster peuvent être à la version 1.34, 1.35 ou 1.36.

Quels écarts de version sont autorisés ?

Un cluster d'administrateur peut gérer des clusters d'utilisateur jusqu'à deux versions mineures inférieures. Par exemple, si un cluster d'administrateur est en version 1.31, les clusters d'utilisateur gérés par ce cluster d'administrateur peuvent être en version 1.29, 1.30 ou 1.31.

Avant la version 1.31, les règles d'asymétrie de version suivantes s'appliquent :

  • Pour les versions 1.28 à 1.30, les clusters d'utilisateur peuvent être jusqu'à deux versions mineures plus récentes que leur cluster d'administrateur. Par exemple, si un cluster d'administrateur est à la version 1.15, les clusters d'utilisateur gérés par ce cluster d'administrateur peuvent être à la version 1.15, 1.16 ou 1.28. Vous ne pouvez pas mettre à niveau un cluster d'utilisateur 1.28 vers la version 1.29 tant que le cluster d'administrateur n'a pas été mis à niveau vers la version 1.16 au moins. Étant donné que la version 1.31 modifie l'ordre de mise à niveau pour exiger la mise à niveau du cluster d'administrateur en premier, un cluster d'administrateur en version 1.29 ou 1.30 ne peut pas gérer les clusters d'utilisateur en version 1.31 ou 1.32. Tous les clusters d'utilisateur et le cluster d'administrateur doivent atteindre la version 1.30 avant que vous ne puissiez mettre à niveau le cluster d'administrateur vers la version 1.31.
  • Pour les versions 1.16 et antérieures, les clusters d'utilisateur ne peuvent être que d'une version mineure supérieure à celle de leur cluster d'administrateur. Par exemple, si un cluster d'administrateur est à la version 1.15, les clusters d'utilisateur gérés par ce cluster d'administrateur peuvent être à la version 1.15 ou 1.16.

Dois-je mettre à niveau tous les clusters d'utilisateur en même temps ?

Lorsque vous mettez à niveau des clusters d'utilisateur, vous pouvez choisir l'une des options suivantes :

  • Mettez à niveau l'ensemble du cluster d'utilisateur avec le plan de contrôle et tous les pools de nœuds du cluster en même temps.
  • Mettez à niveau le plan de contrôle du cluster d'utilisateur et laissez les pools de nœuds à la version actuelle.
  • Mettez à niveau le plan de contrôle du cluster d'utilisateur et mettez à niveau de manière sélective les pools de nœuds.

L'approche que vous adoptez dépend de plusieurs facteurs, tels que :

  • Environnement (production ou hors production) dans lequel se trouve le cluster.
  • La durée de votre intervalle de maintenance.
  • Version du cluster d'utilisateur.

Par exemple, vous pouvez mettre à niveau le plan de contrôle du cluster d'utilisateur et tous les pools de nœuds dans un environnement de développement. Toutefois, dans un environnement de production avec un court intervalle de maintenance, vous pouvez choisir de ne mettre à niveau que le plan de contrôle, car cela prend moins de temps. La mise à niveau du plan de contrôle ne devrait pas perturber les charges de travail des utilisateurs.

Les pools de nœuds d'équilibreur de charge (pools de nœuds avec enableLoadBalancer: true) doivent être de la même version que le cluster pour chaque version.

Règles de version pour gkectl

La version de gkectl que vous pouvez utiliser pour la mise à niveau dépend de la version du cluster cible (c'est-à-dire la version du cluster vers laquelle vous effectuez la mise à niveau). En règle générale, vous utilisez la même version de gkectl que la version cible du cluster. Les règles suivantes sont appliquées lors de la mise à niveau :

  • La version de gkectl doit être identique ou supérieure à la version mineure du cluster cible. Par exemple, si vous mettez à niveau un cluster 1.29 vers la version 1.30, vous devez utiliser gkectl 1.30 ou une version ultérieure. Les versions de correctif n'ont pas d'importance.

  • La version gkectl peut être jusqu'à deux versions mineures supérieure à la version actuelle du cluster. Par exemple, pour mettre à niveau un cluster 1.28 vers la version 1.29, utilisez la version 1.29 ou 1.30 de gkectl, mais pas la version 1.31, car elle est supérieure de trois versions mineures à la version du cluster.

La version binaire de gkectl doit correspondre exactement à la version cible lorsque vous convertissez des clusters non avancés en clusters avancés. Cette exigence de version stricte ne s'applique que lors de la mise à niveau vers un cluster avancé. Pour toutes les autres mises à niveau de cluster avancées, les règles d'écart de version standards s'appliquent.

Règles de mise à niveau des versions de correctif

Passez à la dernière version du correctif dès que possible pour vous assurer que vos clusters disposent des derniers correctifs de sécurité. Les versions de correctif n'affectent pas les règles d'asymétrie de version et de mise à niveau. Pour une version mineure donnée, vous pouvez passer à n'importe quelle version de correctif supérieure. Par exemple, vous pouvez passer de la version 1.35.0 à la version 1.35.1 et de la version 1.35.1 à la version 1.35.3.

Étapes suivantes