Par défaut, les mises à niveau automatiques sont activées pour les clusters Google Kubernetes Engine (GKE) et pour les pools de nœuds GKE Standard.
Cette page explique comment demander manuellement une mise à niveau ou un retour à une version antérieure pour le plan de contrôle ou les nœuds d'un cluster GKE. Vous pouvez mettre à jour la version manuellement comme suit :
- Autopilot : mettez à niveau la version du plan de contrôle.
- Standard : mettez à niveau la version du plan de contrôle et la version du pool de nœuds.
Pour mettre à niveau un cluster, GKE met à jour la version du plan de contrôle et des nœuds. Les clusters sont mis à niveau vers une version mineure plus récente (par exemple, 1.24 à 1.25) ou une version du correctif plus récente (par exemple, 1.24.2-gke.100 vers 1.24.5-gke.200). Pour en savoir plus, consultez la page Gestion des versions et compatibilité GKE.
Pour en savoir plus, consultez la section Fonctionnement des mises à niveau automatiques et manuelles des clusters. Vous pouvez également contrôler le moment où les mises à niveau peuvent avoir lieu ou non en configurant des intervalles de maintenance et des exclusions.
De nouvelles versions de GKE sont régulièrement publiées et vous pouvez recevoir des notifications sur les nouvelles versions disponibles pour chaque cluster spécifique grâce aux notifications de cluster. Pour trouver des cibles de mise à niveau automatique spécifiques pour les clusters, obtenez des informations sur les mises à niveau d'un cluster.
Pour en savoir plus sur les versions disponibles, consultez la page Gestion des versions. Pour en savoir plus sur les clusters, consultez la page Architecture d'un cluster. Pour obtenir des conseils sur la mise à niveau des clusters, consultez Bonnes pratiques de mise à niveau des clusters.
Avant de commencer
Avant de commencer, effectuez les tâches suivantes :
- Activez l'API Google Kubernetes Engine. Activer l'API Google Kubernetes Engine
- Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la commande
gcloud components update. Il est possible que les versions antérieures de gcloud CLI ne permettent pas d'exécuter les commandes de ce document.
- Assurez-vous de disposer d'un cluster Autopilot ou Standard existant. Pour créer un cluster, consultez la page Créer un cluster Autopilot.
Sauvegarder vos données sur des disques persistants
Avant de mettre à jour un pool de nœuds, vous devez vous assurer que toutes les données que vous souhaitez conserver sont stockées dans un pod utilisant des volumes persistants, qui eux-mêmes utilisent des disques persistants. Les disques persistants sont désinstallés au lieu d'être effacés lors des mises à jour, ce qui permet leur transmission d'un pod à un autre.
Les disques persistants sont soumis aux restrictions suivantes :
- Les nœuds sur lesquels les pods sont exécutés doivent être des machines virtuelles Compute Engine.
- Ces machines virtuelles doivent appartenir au même projet et à la même zone Compute Engine que le disque persistant.
Pour savoir comment ajouter un disque persistant à une instance de nœud existante, consultez la page Ajouter ou redimensionner des disques persistants zonaux dans la documentation Compute Engine.
À propos des mises à niveau
Le plan de contrôle et les nœuds d'un cluster sont mis à jour séparément.
Les plans de contrôle du cluster sont toujours mis à niveau régulièrement, que votre cluster soit enregistré dans une version disponible ou non.
Limites
Les clusters alpha ne peuvent pas être mis à jour.
Versions compatibles
Les notes de version vous informent lorsque de nouvelles versions sont disponibles et lorsque d'anciennes versions ne le sont plus. Vous pouvez à tout moment répertorier l'ensemble des versions des clusters et des nœuds compatibles à l'aide de la commande suivante :
gcloud container get-server-config \
--location=CONTROL_PLANE_LOCATION
Remplacez CONTROL_PLANE_LOCATION par l'emplacement (région ou zone) du plan de contrôle, par exemple us-central1 ou us-central1-a.
Si votre cluster est enregistré dans une version disponible, vous pouvez passer à une version de correctif dans une version disponible différente avec la même version mineure que votre plan de contrôle. Par exemple, vous pouvez passer de la version 1.21.12-gke.1700 du canal standard à la version 1.21.13-gke.900 du canal rapide dans votre cluster. Pour plus d'informations, consultez la section Exécuter des versions de correctif à partir d'un canal plus récent. Tous les clusters Autopilot sont enregistrés dans une version disponible.
Limites applicables au retour à une version antérieure
Dans certains cas, vous pouvez rétrograder la version de votre cluster.
Pour limiter l'échec de la mise à niveau d'un plan de contrôle de cluster, vous pouvez revenir à une version de correctif antérieure de votre plan de contrôle si la version est une version de correctif antérieure dans la même version mineure. Par exemple, si le plan de contrôle de votre cluster exécute GKE 1.25.3-gke.400, vous pouvez revenir au plan de contrôle 1.25.2-gke.100 si cette version est toujours disponible.
Vous ne pouvez pas revenir à une version mineure antérieure du plan de contrôle d'un cluster Kubernetes. Par exemple, si votre plan de contrôle exécute la version 1.25 de GKE, vous ne pouvez pas revenir à la version 1.24. Si vous tentez de le faire, le message d'erreur suivant s'affiche :
ERROR: (gcloud.container.clusters.upgrade) ResponseError: code=400,
message=Master cannot be upgraded to "1.24.3-gke.100": specified version is not
newer than the current version.
Vous ne pouvez pas revenir à une version antérieure du plan de contrôle d'un cluster. Nous vous recommandons donc de tester et qualifier les mises à niveau de versions mineures avec des clusters dans un environnement de test lorsqu'une nouvelle version mineure devient disponible, mais avant que la version ne devienne la version par défaut. Cela est particulièrement recommandé si votre cluster est susceptible d'être affecté par des modifications importantes dans la prochaine version mineure, comme la suppression d'API ou de fonctionnalités obsolètes.
Pour remédier à une mise à niveau du pool de nœuds qui a échoué, vous pouvez revenir à une version antérieure du pool de nœuds (version de correctif ou version mineure). Assurez-vous de ne pas revenir à une version antérieure des nœuds de plus de deux versions mineures par rapport à la version du plan de contrôle du cluster.
Mise à niveau du cluster
Google met automatiquement à jour les clusters et les nœuds. Si vous souhaitez avoir davantage de contrôle sur les mises à niveau automatiques que votre cluster et ses nœuds reçoivent, vous pouvez enregistrer ce cluster dans une version disponible. Tous les clusters Autopilot sont enregistrés automatiquement dans une version disponible.
Pour en savoir plus sur la gestion de la version GKE de votre cluster, consultez la page Mises à niveau.
Vous pouvez lancer une mise à jour manuelle à tout moment lorsqu'une nouvelle version est disponible.
Mettre à jour manuellement le plan de contrôle
Lors du lancement de la mise à jour d'un cluster, vous ne pouvez pas modifier la configuration du cluster pendant plusieurs minutes, jusqu'à ce que le plan de contrôle soit à nouveau accessible. Si vous devez éviter les temps d'arrêt pendant les mises à niveau du plan de contrôle, envisagez d'utiliser un cluster Autopilot ou un cluster Standard régional. Cette opération n'affecte pas la disponibilité des nœuds de calcul sur lesquels vos charges de travail s'exécutent, car ils restent disponibles pendant les mises à niveau du plan de contrôle.
Vous pouvez mettre à niveau manuellement votre plan de contrôle Autopilot ou Standard à l'aide de la console Google Cloud ou de Google Cloud CLI.
gcloud
Pour afficher les versions disponibles du plan de contrôle de votre cluster, exécutez la commande suivante :
gcloud container get-server-config \
--location=CONTROL_PLANE_LOCATION
Pour passer à la version de cluster par défaut, exécutez la commande suivante :
gcloud container clusters upgrade CLUSTER_NAME \
--master \
--location=CONTROL_PLANE_LOCATION
Pour effectuer une mise à niveau vers une version spécifique autre que celle par défaut, spécifiez l'option --cluster-version comme dans la commande suivante :
gcloud container clusters upgrade CLUSTER_NAME \
--master \
--location=CONTROL_PLANE_LOCATION \
--cluster-version=VERSION
Remplacez VERSION par la version vers laquelle vous souhaitez mettre à niveau votre cluster. Vous pouvez utiliser une version spécifique, telle que 1.18.17-gke.100, ou un alias de version, tel que latest. Pour en savoir plus, consultez la section Spécifier la version du cluster.
Console
Pour mettre à niveau manuellement le plan de contrôle du cluster, procédez comme suit :
Accédez à la page Google Kubernetes Engine dans la console Google Cloud .
Cliquez sur le nom du cluster.
Sous Paramètres de base du cluster, cliquez sur editMise à niveau disponible à côté de Version.
Sélectionnez la version souhaitée, puis cliquez sur Enregistrer les modifications.
Après la mise à niveau d'un plan de contrôle standard, vous pouvez mettre à jour ses nœuds. Par défaut, la mise à niveau automatique est activée sur les nœuds standards créés à l'aide de la console Google Cloud . Vous n'avez donc pas besoin de le faire manuellement. Autopilot met toujours à niveau les nœuds automatiquement.
Revenir à une version antérieure des clusters
- Définissez une exclusion de maintenance avant de revenir à une version antérieure pour empêcher GKE de mettre à niveau automatiquement le plan de contrôle après la rétrogradation.
Revenez à une version de correctif antérieure du plan de contrôle du cluster :
gcloud container clusters upgrade CLUSTER_NAME \ --master \ --location=CONTROL_PLANE_LOCATION \ --cluster-version=VERSION
Désactiver les mises à niveau automatiques du cluster
La sécurité de l'infrastructure est une priorité élevée pour GKE. Ces plans de contrôle sont mis à niveau régulièrement et ne peuvent pas être désactivés. Toutefois, vous pouvez appliquer des intervalles et des exclusions de maintenance afin de suspendre temporairement les mises à niveau pour les plans de contrôle et les nœuds.
Bien que cette pratique ne soit pas recommandée, vous pouvez désactiver la mise à niveau automatique des nœuds.
Consulter l'historique récent des mises à niveau du plan de contrôle
Pour obtenir un aperçu de l'historique récent des mises à niveau automatiques d'un cluster, consultez les informations sur les mises à niveau d'un cluster.
Vous pouvez également lister les opérations récentes pour voir quand le plan de contrôle a été mis à niveau :
gcloud container operations list --filter="TYPE:UPGRADE_MASTER AND TARGET:CLUSTER_NAME" \
--location=CONTROL_PLANE_LOCATION
Mettre à niveau les pools de nœuds
Par défaut, la mise à niveau automatique est activée sur les nœuds d'un cluster. Les mises à niveau automatiques des nœuds garantissent que le plan de contrôle et la version des nœuds de votre cluster restent synchronisés et conformes aux règles d'asymétrie de version Kubernetes, ce qui garantit que les plans de contrôle sont compatibles avec les nœuds jusqu'à deux versions mineures antérieures au plan de contrôle. Par exemple, les plans de contrôle Kubernetes 1.29 sont compatibles avec les nœuds Kubernetes 1.27.
Évitez de désactiver les mises à niveau automatiques des nœuds afin que votre cluster bénéficie des mises à niveau listées dans le paragraphe précédent.
Avec les mises à niveau du pool de nœuds GKE, vous pouvez choisir entre deux stratégies de mise à niveau configurables, à savoir les mises à niveau de la surutilisation et les mises à niveau bleu-vert.
Choisissez une stratégie et utilisez les paramètres pour ajuster la stratégie afin de répondre au mieux aux besoins de votre environnement de cluster.
Fonctionnement des mises à niveau de nœuds
Lorsqu'un nœud est mis à jour, GKE interrompt la programmation de nouveaux pods et tente de programmer les pods en cours d'exécution sur d'autres nœuds. Cette opération est semblable à d'autres événements permettant de recréer le nœud, tels que l'activation ou la désactivation d'une fonctionnalité dans le pool de nœuds.
Pendant les mises à jour automatiques ou manuelles des nœuds, les PodDisruptionBudgets (PDB) et le délai de grâce pour l'arrêt des pods sont respectés pendant une heure au maximum. Si les pods exécutés sur le nœud ne peuvent pas être programmés sur de nouveaux nœuds au bout d'une heure, GKE lance quand même la mise à niveau. Ce comportement s'applique même si vous configurez vos PDB pour que toutes vos instances répliquées soient toujours disponibles en définissant le champ maxUnavailable sur 0 ou 0%, ou en définissant le champ minAvailable sur 100% ou sur le nombre d'instances répliquées. Dans tous ces scénarios, GKE supprime les pods au bout d'une heure afin que le nœud puisse être supprimé.
Si une charge de travail nécessite plus de flexibilité avec une résiliation concertée, utilisez les mises à niveau bleu-vert, qui fournissent des paramètres de temps de stabilisation supplémentaire pour étendre les vérifications PDB au-delà de la valeur par défaut de 1 heure.
Pour savoir à quoi vous attendre lors de l'arrêt de nœuds en général, consultez la page sur les pods.
La mise à jour n'est terminée que lorsque tous les nœuds ont été recréés et que le cluster est dans l'état souhaité. Lorsqu'un nœud qui vient d'être mis à niveau s'enregistre auprès du plan de contrôle, GKE le marque comme programmable.
Les nouvelles instances de nœud exécutent la version souhaitée de Kubernetes, ainsi que les composants suivants :
Pour qu'une mise à niveau d'un pool de nœuds soit considérée comme terminée, tous les nœuds du pool doivent être recréés. Si une mise à niveau a commencé, mais ne s'est pas terminée et est dans un état partiellement mis à niveau, la version du pool de nœuds peut ne pas refléter la version de tous les nœuds. Pour en savoir plus, consultez Certaines versions de nœuds ne correspondent pas à la version du pool de nœuds après une mise à niveau incomplète du pool de nœuds. Pour déterminer si la mise à niveau du pool de nœuds est terminée, vérifiez l'état de la mise à niveau du pool de nœuds. Si l'opération de mise à niveau dépasse la période de conservation, vérifiez que la version de chaque nœud correspond à la version du pool de nœuds.
Mettre à niveau manuellement un pool de nœuds
Vous pouvez mettre à niveau manuellement une version du pool de nœuds vers celle du plan de contrôle ou vers une version antérieure qui est toujours disponible et compatible avec le plan de contrôle. Vous pouvez mettre à niveau manuellement plusieurs pools de nœuds en parallèle, tandis que GKE ne met à niveau automatiquement qu'un seul pool de nœuds à la fois.
Lorsque vous mettez à niveau manuellement un pool de nœuds, GKE supprime les libellés que vous avez ajoutés à des nœuds individuels à l'aide de kubectl.
Pour éviter cela, essayez plutôt d'appliquer des libellés aux pools de nœuds.
Avant de mettre à niveau manuellement votre pool de nœuds, tenez compte des conditions suivantes :
- La mise à niveau d'un pool de nœuds peut perturber les charges de travail s'exécutant dans celui-ci. Pour éviter cela, vous pouvez créer un pool de nœuds de la version souhaitée, puis migrer la charge de travail vers celui-ci. Une fois la migration terminée, vous pouvez supprimer l'ancien pool de nœuds.
- Si vous mettez à niveau un pool de nœuds avec un Ingress dans un état erroné, le groupe d'instances ne se synchronise pas. Afin d'éviter ce problème, commencez par vérifier l'état à l'aide de la commande
kubectl get ing. Si le groupe d'instances n'est pas synchronisé, vous pouvez réappliquer le fichier manifeste utilisé pour créer l'entrée.
Vous pouvez mettre à niveau manuellement vos pools de nœuds vers une version compatible avec le plan de contrôle à l'aide de la console Google Cloud ou de la Google Cloud CLI.
gcloud
Les variables suivantes sont utilisées dans les commandes de cette section :
CLUSTER_NAME: nom du cluster du pool de nœuds à mettre à jour.NODE_POOL_NAME: nom du pool de nœuds à mettre à jour.CONTROL_PLANE_LOCATION: emplacement (région ou zone) du plan de contrôle, tel queus-central1ouus-central1-a.VERSION: version de Kubernetes vers laquelle les nœuds sont mis à niveau. Par exemple,--cluster-version=1.7.2oucluster-version=latest.
Mettre à niveau un pool de nœuds :
gcloud container clusters upgrade CLUSTER_NAME \
--node-pool=NODE_POOL_NAME \
--location=CONTROL_PLANE_LOCATION
Pour spécifier une autre version de GKE sur les nœuds, utilisez l'indicateur --cluster-version facultatif :
gcloud container clusters upgrade CLUSTER_NAME \
--node-pool=NODE_POOL_NAME \
--location=CONTROL_PLANE_LOCATION \
--cluster-version VERSION
Pour en savoir plus sur la spécification des versions, consultez la page Gestion des versions.
Pour en savoir plus, consultez la documentation sur gcloud container clusters upgrade.
Console
Pour mettre à niveau un pool de nœuds à l'aide de la console Google Cloud , procédez comme suit :
Accédez à la page Google Kubernetes Engine dans la console Google Cloud .
Cliquez sur le nom du cluster.
Sur la page Détails du cluster, cliquez sur l'onglet Nœuds.
Dans la section Pools de nœuds, cliquez sur le nom du pool de nœuds que vous souhaitez mettre à niveau.
Cliquez sur edit Modifier.
Cliquez sur Modifier sous Version du nœud.
Sélectionnez la version souhaitée dans la liste déroulante Version du nœud, puis cliquez sur Modifier.
Le changement de version du nœud peut prendre plusieurs minutes.
Rétablir une version antérieure d'un pool de nœuds
Vous pouvez revenir à une version antérieure d'un pool de nœuds, par exemple pour récupérer de l'échec d'une mise à niveau du pool de nœuds. Consultez les limites avant de revenir à une version antérieure d'un pool de nœuds.
Utilisez la stratégie de mise à niveau des nœuds bleu-vert si vous devez optimiser les mesures de réduction des risques pour les mises à niveau du pool de nœuds affectant vos charges de travail. Avec cette stratégie, vous pouvez effectuer un rollback d'une mise à niveau en cours vers les nœuds d'origine si la mise à niveau échoue.
- Définissez une exclusion de maintenance pour le cluster afin d'empêcher la mise à niveau automatique du pool de nœuds par GKE après son retour à une version antérieure.
- Pour revenir à une version antérieure d'un pool de nœuds, spécifiez une version antérieure en suivant les instructions de la section Mettre à jour manuellement un pool de nœuds.
Modifier les paramètres de mise à niveau de la surutilisation
Pour en savoir plus sur la modification des paramètres de mise à niveau de la surutilisation, consultez la page Configurer les mises à niveau de la surutilisation.
Vérifier l'état de la mise à niveau du pool de nœuds
Vous pouvez vérifier l'état d'une mise à niveau à l'aide de gcloud container operations.
Affichez la liste de toutes les opérations en cours ou terminées dans le cluster au cours des 12 derniers jours (si le nombre d'opérations est inférieur à 5 000) ou des 5 000 dernières opérations :
gcloud container operations list \
--location=CONTROL_PLANE_LOCATION
Chaque opération se voit attribuer un ID d'opération et un type d'opération, ainsi que des heures de début et de fin, un cluster cible et un état. Cette liste se présente comme dans l'exemple suivant :
NAME TYPE ZONE TARGET STATUS_MESSAGE STATUS START_TIME END_TIME
operation-1505407677851-8039e369 CREATE_CLUSTER us-west1-a my-cluster DONE 20xx-xx-xxT16:47:57.851933021Z 20xx-xx-xxT16:50:52.898305883Z
operation-1505500805136-e7c64af4 UPGRADE_CLUSTER us-west1-a my-cluster DONE 20xx-xx-xxT18:40:05.136739989Z 20xx-xx-xxT18:41:09.321483832Z
operation-1505500913918-5802c989 DELETE_CLUSTER us-west1-a my-cluster DONE 20xx-xx-xxT18:41:53.918825764Z 20xx-xx-xxT18:43:48.639506814Z
Pour obtenir plus d'informations sur une opération déterminée, spécifiez l'ID de cette opération, comme indiqué dans la commande suivante :
gcloud container operations describe OPERATION_ID \
--location=CONTROL_PLANE_LOCATION
Exemple :
gcloud container operations describe operation-1507325726639-981f0ed6
endTime: '20xx-xx-xxT21:40:05.324124385Z'
name: operation-1507325726639-981f0ed6
operationType: UPGRADE_CLUSTER
selfLink: https://container.googleapis.com/v1/projects/.../kubernetes-engine/docs/zones/us-central1-a/operations/operation-1507325726639-981f0ed6
startTime: '20xx-xx-xxT21:35:26.639453776Z'
status: DONE
targetLink: https://container.googleapis.com/v1/projects/.../kubernetes-engine/docs/zones/us-central1-a/clusters/...
zone: us-central1-a
Si la mise à niveau a été annulée ou a échoué et qu'elle est partiellement terminée, vous pouvez la reprendre ou effectuer un rollback.
Vérifier les paramètres de mise à niveau du pool de nœuds
Vous pouvez afficher les détails de la stratégie de mise à niveau de nœuds utilisée pour vos pools de nœuds à l'aide de la commande gcloud container node-pools
describe. Pour les mises à niveau bleu-vert, la commande renvoie également la phase actuelle de la mise à niveau.
Exécutez la commande ci-dessous.
gcloud container node-pools describe NODE_POOL_NAME \
--cluster=CLUSTER_NAME \
--location=CONTROL_PLANE_LOCATION
Remplacez les éléments suivants :
NODE_POOL_NAME: nom du pool de nœuds à décrire.CLUSTER_NAME: nom du cluster du pool de nœuds à décrire.CONTROL_PLANE_LOCATION: emplacement (région ou zone) du plan de contrôle, tel queus-central1ouus-central1-a.
Cette commande génère les paramètres de mise à niveau actuels. L'exemple suivant montre le résultat si vous utilisez la stratégie de mise à niveau bleu-vert.
upgradeSettings:
blueGreenSettings:
nodePoolSoakDuration: 1800s
standardRolloutPolicy:
batchNodeCount: 1
batchSoakDuration: 10s
strategy: BLUE_GREEN
Si vous utilisez la stratégie de mise à niveau bleu-vert, le résultat inclut également des détails sur les paramètres de mise à niveau bleu-vert et sa phase intermédiaire actuelle. L'exemple suivant montre comment cela se présente :
updateInfo:
blueGreenInfo:
blueInstanceGroupUrls:
- https://www.googleapis.com/compute/v1/projects/{PROJECT_ID}/zones/{LOCATION}/instanceGroupManagers/{BLUE_INSTANCE_GROUP_NAME}
bluePoolDeletionStartTime: {BLUE_POOL_DELETION_TIME}
greenInstanceGroupUrls:
- https://www.googleapis.com/compute/v1/projects/{PROJECT_ID}/zones/{LOCATION}/instanceGroupManagers/{GREEN_INSTANCE_GROUP_NAME}
greenPoolVersion: {GREEN_POOL_VERSION}
phase: DRAINING_BLUE_POOL
Annuler une mise à niveau du pool de nœuds
Vous pouvez annuler une mise à jour à tout moment. Pour en savoir plus sur ce qui se passe lorsque vous annulez une mise à niveau de la surutilisation, consultez la page Annuler une mise à niveau de la surutilisation. Pour en savoir plus sur ce qui se passe lorsque vous annulez une mise à niveau bleu-vert, consultez la page Annuler une mise à niveau bleu-vert.
Obtenez l'ID d'opération de la mise à niveau :
gcloud container operations list \ --location=CONTROL_PLANE_LOCATIONAnnulez la mise à niveau :
gcloud container operations cancel OPERATION_ID \ --location=CONTROL_PLANE_LOCATION
Consultez la documentation sur gcloud container operations cancel.
Reprendre une mise à niveau d'un pool de nœuds
Vous pouvez reprendre une mise à niveau en lançant manuellement la mise à niveau, en spécifiant la version cible de la mise à niveau d'origine.
Par exemple, si une mise à niveau a échoué ou si vous avez suspendu une mise à niveau en cours, vous pouvez la reprendre en relançant la même mise à niveau sur le pool de nœuds, en spécifiant la version cible de l'opération de mise à niveau initiale.
Pour en savoir plus sur ce qui se passe lorsque vous réactivez une mise à niveau, consultez les pages Reprendre une mise à niveau de la surutilisation et Mise à niveau bleu-vert.
Pour reprendre une mise à niveau, utilisez la commande suivante :
gcloud container clusters upgrade CLUSTER_NAME \
--node-pool=NODE_POOL_NAME \
--location=CONTROL_PLANE_LOCATION \
--cluster-version VERSION
Remplacez les éléments suivants :
NODE_POOL_NAME: nom du pool de nœuds pour lequel vous souhaitez reprendre la mise à niveau du pool de nœuds.CLUSTER_NAME: nom du cluster du pool de nœuds pour lequel vous souhaitez reprendre la mise à niveau.CONTROL_PLANE_LOCATION: emplacement (région ou zone) du plan de contrôle, tel queus-central1ouus-central1-a.VERSION: version cible de la mise à niveau du pool de nœuds annulé.
Pour en savoir plus, consultez la documentation sur gcloud container clusters upgrade.
Effectuer un rollback pour rétablir la version du pool de nœuds
Vous pouvez effectuer un rollback d'un pool de nœuds pour revenir à l'état d'origine des nœuds mis à niveau avant le début de la mise à niveau du pool de nœuds.
Utilisez la commande rollback si une mise à niveau en cours a été annulée, si la mise à niveau a échoué ou si la mise à niveau est incomplète en raison d'un intervalle de maintenance dont le délai a expiré. Si vous souhaitez spécifier la version, suivez les instructions pour revenir à une version antérieure du pool de nœuds.
Pour en savoir plus sur ce qui se passe lorsque vous effectuez un rollback de la mise à niveau d'un pool de nœuds, consultez la page Restaurer une mise à niveau de la surutilisation ou Effectuer un rollback vers une mise à niveau bleu-vert.
Pour effectuer le rollback d'une mise à jour, exécutez la commande suivante :
gcloud container node-pools rollback NODE_POOL_NAME \
--cluster CLUSTER_NAME \
--location=CONTROL_PLANE_LOCATION
Remplacez les éléments suivants :
NODE_POOL_NAME: nom du pool de nœuds pour lequel vous souhaitez effectuer un rollback de la mise à niveau du pool de nœuds.CLUSTER_NAME: nom du cluster du pool de nœuds pour lequel vous souhaitez effectuer un rollback de la mise à niveau.CONTROL_PLANE_LOCATION: emplacement (région ou zone) du plan de contrôle, tel queus-central1ouus-central1-a.
Consultez la documentation sur gcloud container node-pools rollback.
Terminer une mise à niveau du pool de nœuds
Si vous utilisez la stratégie de mise à niveau bleu-vert, vous pouvez effectuer une mise à niveau du pool de nœuds pendant la phase de stabilisation, en ignorant le reste du temps de stabilisation.
Pour savoir comment effectuer une mise à niveau du pool de nœuds, consultez la page Effectuer une mise à niveau du pool de nœuds.
Pour effectuer une mise à niveau lors de l'utilisation de la stratégie de mise à niveau bleu-vert, exécutez la commande suivante :
gcloud container node-pools complete-upgrade NODE_POOL_NAME \
--cluster CLUSTER_NAME \
--location=CONTROL_PLANE_LOCATION
Remplacez les éléments suivants :
NODE_POOL_NAME: nom du pool de nœuds pour lequel vous souhaitez effectuer la mise à niveau.CLUSTER_NAME: nom du cluster du pool de nœuds pour lequel vous souhaitez effectuer la mise à niveau.CONTROL_PLANE_LOCATION: emplacement (région ou zone) du plan de contrôle, tel queus-central1ouus-central1-a.
Consultez la documentation sur gcloud container node-pools complete-upgrade.
Problèmes connus
Si des objets PodDisruptionBudget sont configurés pour ne pas autoriser d'autres interruptions, les mises à niveau de nœuds peuvent échouer à passer à la version du plan de contrôle après plusieurs tentatives. Pour éviter cet échec, nous vous recommandons d'effectuer un scaling à la hausse de Deployment ou HorizontalPodAutoscaler afin de permettre au nœud de se drainer tout en respectant la configuration PodDisruptionBudget.
Pour afficher tous les objets PodDisruptionBudget qui n'autorisent aucune interruption, procédez comme suit :
kubectl get poddisruptionbudget --all-namespaces -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'
Bien que les mises à niveau automatiques puissent rencontrer ce problème, le processus de mise à niveau automatique oblige les nœuds à se mettre à niveau. Cependant, la mise à niveau prend une heure supplémentaire pour chaque nœud de l'espace de noms istio-system qui ne respecte pas le PodDisruptionBudget.
Dépannage
Pour en savoir plus sur le dépannage, consultez Résoudre les problèmes de mise à niveau de cluster.
Étapes suivantes
- Apprenez-en plus sur l'architecture d'un cluster.
- Apprenez-en plus sur les versions disponibles.