Mettre à jour manuellement un cluster ou un pool de nœuds

Par défaut, les clusters et les pools de nœuds Google Kubernetes Engine sont mis à jour automatiquement par Google. Cette page explique comment demander manuellement une mise à niveau ou un retour à une version antérieure pour un cluster GKE ou ses nœuds. 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.

Remarque terminologique : Le plan de contrôle (maître) et les nœuds d'un cluster n'exécutent pas nécessairement la même version à tout moment. Dans cet article, les termes mise à niveau du cluster et mise à niveau du plan de contrôle sont interchangeables et se distinguent des mises à niveau de nœuds.

De nouvelles versions de GKE sont régulièrement publiées. Pour plus d'informations sur les versions disponibles, consultez la section Gestion des versions et mises à jour. 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 la page Bonnes pratiques de mise à niveau des clusters.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

• Assurez-vous d'avoir activé l'API Google Kubernetes Engine.
Activer l'API Google Kubernetes Engine
• Assurez-vous d'avoir installé le SDK Cloud.

Configurez les paramètres gcloud par défaut à l'aide de l'une des méthodes suivantes :

• Utilisez gcloud init pour suivre les instructions permettant de définir les paramètres par défaut.
• Utilisez gcloud config pour définir individuellement l'ID, la zone et la région de votre projet.

Utiliser gcloud init

Si le message d'erreur One of [--zone, --region] must be supplied: Please specify location s'affiche, effectuez les tâches ci-dessous.

1. Exécutez gcloud init et suivez les instructions :

   gcloud init

   Si vous utilisez SSH sur un serveur distant, utilisez l'option --console-only pour empêcher la commande d'ouvrir un navigateur :

   gcloud init --console-only

2. Suivez les instructions pour autoriser gcloud à utiliser votre compte Google Cloud.
3. Créez ou sélectionnez une configuration.
4. Choisissez un projet Google Cloud.
5. Choisissez une zone Compute Engine par défaut.

Remarque : Vous pouvez remplacer ces paramètres par défaut dans les commandes gcloud à l'aide des options --project, --zone et --region.

Utiliser gcloud config

• Définissez votre ID de projet par défaut :

  gcloud config set project project-id

• Si vous utilisez des clusters zonaux, définissez votre zone de calcul par défaut :

  gcloud config set compute/zone compute-zone

• Si vous utilisez des clusters régionaux, définissez votre région de calcul par défaut :

  gcloud config set compute/region compute-region

• Mettez à jour gcloud vers la dernière version :

  gcloud components update

Remarque : Vous pouvez remplacer ces paramètres par défaut dans les commandes gcloud à l'aide des options --project, --zone et --region.

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 de la mise à jour des clusters

Le plan de contrôle et les nœuds d'un cluster sont mis à jour séparément.

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

Problèmes connus

Si vous avez installé Anthos Service Mesh ou OSS Istio sur votre cluster, en fonction de vos paramètres PodDisruptionBudget pour les composants Istio, les nœuds utilisateur risquent de ne pas passer à la version du plan de contrôle après plusieurs tentatives. Pour éviter cet échec, nous vous recommandons d'augmenter le paramètre d'autoscaling des pods horizontal minReplicas de 1 à 2 pour les composants de l'espace de noms istio-system avant la mise à niveau. Cela garantit que vous disposez toujours d'une instance de plan de contrôle ASM en cours d'exécution.

Si vous disposez d'Anthos Service Mesh 1.5 ou d'OSS Istio 1.5 et versions ultérieures :

kubectl patch hpa -n istio-system istio-ingressgateway -p '{"spec":{"minReplicas": 2}}' --type=merge

kubectl patch hpa -n istio-system istiod -p '{"spec":{"minReplicas": 2}}' --type=merge

Si vous disposez d'Anthos Service Mesh 1.4.x ou d'OSS Istio 1.4.x :

kubectl patch hpa -n istio-system istio-galley -p '{"spec":{"minReplicas": 2}}' --type=merge

kubectl patch hpa -n istio-system istio-ingressgateway -p '{"spec":{"minReplicas": 2}}' --type=merge

kubectl patch hpa -n istio-system istio-nodeagent -p '{"spec":{"minReplicas": 2}}' --type=merge

kubectl patch hpa -n istio-system istio-pilot -p '{"spec":{"minReplicas": 2}}' --type=merge

kubectl patch hpa -n istio-system istio-sidecar-injector -p '{"spec":{"minReplicas": 2}}' --type=merge

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.

Limites applicables au retour à une version antérieure

Il n'est pas recommandé de revenir à une version antérieure d'un cluster. Les nœuds peuvent être ramenés à une version de correctif antérieure à celle du cluster. Vous ne pouvez pas rétrograder un cluster d'une version mineure à une autre. Par exemple, si un cluster exécute la version 1.11.5 de GKE, vous pouvez passer à la version 1.11.4 si elle toujours disponible, mais vous ne pouvez pas revenir à la version 1.10.9. À la place, une erreur est renvoyée sous la forme suivante :

ERROR: (gcloud.container.clusters.upgrade) ResponseError: code=400,
message=Master cannot be upgraded to "1.10.9-gke.9": specified version is not
newer than the current version.

Mettre à jour le 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.

Pour en savoir plus sur la gestion de la version GKE de votre cluster, consultez la page Gestion des versions et mises à jour.

Vous pouvez lancer une mise à jour manuelle à tout moment lorsqu'une nouvelle version est disponible.

Mettre à jour manuellement le plan de contrôle

Remarque : Vous ne pouvez mettre à jour votre cluster que d'une version mineure à la fois. Par exemple, vous pouvez passer d'une version 1.12.x à une version 1.13.x, mais pas directement d'une version 1.11.x à une version 1.13.x. Pour plus d'informations, consultez la page Gestion des versions et mises à jour.

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 régional.

Vous pouvez mettre à jour manuellement votre cluster à l'aide de la Cloud Console ou de l'outil de ligne de commande gcloud. Après la mise à niveau de votre cluster, vous pouvez mettre à jour ses nœuds. Par défaut, la mise à niveau automatique est activée sur les nœuds créés à l'aide de Google Cloud Console. Vous n'avez donc pas besoin de le faire manuellement.

gcloud

Pour mettre à jour la version du plan de contrôle du cluster, exécutez d'abord la commande suivante pour afficher les versions disponibles :

gcloud container get-server-config

Pour passer à la version de cluster par défaut, exécutez la commande suivante :

gcloud container clusters upgrade cluster-name --master

Pour effectuer une mise à jour vers une version spécifique autre que celle par défaut, exécutez la commande suivante :

gcloud container clusters upgrade cluster-name \
  --master --cluster-version cluster-version

Consultez la documentation sur gcloud container clusters upgrade.

Console

Pour mettre à niveau manuellement le plan de contrôle du cluster, procédez comme suit :

1. Accédez au menu Google Kubernetes Engine de Google Cloud Console.

   Accéder au menu Google Kubernetes Engine

2. Sélectionnez le cluster souhaité.

3. Cliquez sur le lien Mise à jour disponible à côté de Version maître.

4. Sélectionnez la version souhaitée, puis cliquez sur Modifier.

5. Cliquez sur la flèche en haut de l'écran pour revenir à la page de présentation du cluster.

Revenir à une version antérieure des clusters

Remarque : Avant d'essayer de revenir à une version antérieure du cluster, assurez-vous que vous comprenez bien les limites applicables.

Pour revenir à une version de correctif antérieure d'un cluster, modifiez la version du plan de contrôle du cluster à l'aide de la commande suivante :

gcloud container clusters upgrade cluster-name \
  --master --cluster-version downgrade-version

Désactiver les mises à niveau automatiques du cluster

Vous ne pouvez pas désactiver les mises à niveau automatiques d'un cluster. Bien que cette pratique ne soit pas recommandée, vous pouvez désactiver la mise à niveau automatique des nœuds.

Mettre à jour les nœuds

Par défaut, la mise à niveau automatique est activée sur les nœuds d'un cluster. Nous vous recommandons de ne pas la désactiver.

GKE met à jour un nœud à la fois lors de la mise à niveau d'un pool 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. Le nœud est ensuite recréé avec la nouvelle version, tout en conservant le même nom qu'avant. 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.

Remarque : Pendant les mises à jour automatiques ou manuelles des nœuds, les PodDisruptionBudgets (PDB) sont respectés pendant une heure au maximum. Si les pods exécutés sur un nœud ne peuvent pas être programmés sur de nouveaux nœuds dans un délai d'une heure, la mise à niveau est lancée, quoi qu'il en soit.
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 :

• L'Image du nœud
• Le démon Docker (le cas échéant)
• kubelet
• kube-proxy

Mettre à niveau un nœud manuellement

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. Les règles de compatibilité de la version de Kubernetes et du décalage de version garantissent que les plans de contrôle sont compatibles avec les nœuds jusqu'à deux versions mineures antérieures à celle du plan de contrôle. Par exemple, les plans de contrôle Kubernetes 1.13 sont compatibles avec les nœuds Kubernetes 1.11.

Remarque : La mise à jour 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.

Vous pouvez mettre à niveau manuellement vos nœuds vers une version compatible avec le plan de contrôle à l'aide de Google Cloud Console ou de l'outil de ligne de commande gcloud.

gcloud

La commande suivante met à niveau les nœuds d'un cluster vers la version qu'exécute votre plan de contrôle :

gcloud container clusters upgrade cluster-name \
  --node-pool=node-pool-name

où cluster-name est le nom du cluster à mettre à jour.

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 \
  --cluster-version cluster-version

où cluster-version est la version de Kubernetes vers laquelle les nœuds sont mis à jour Par exemple, --cluster-version=1.7.2 ou cluster-version=latest.

Pour plus d'informations sur la spécification des versions, consultez la page Versions et mises à jour.

Pour en savoir plus, consultez la documentation sur gcloud container clusters upgrade.

Console

Pour mettre à niveau un pool de nœuds à l'aide de Cloud Console, procédez comme suit :

1. Accédez au menu Google Kubernetes Engine de Cloud Console.

   Accéder au menu Google Kubernetes Engine

2. Cliquez sur le bouton Modifier du cluster (icône en forme de crayon).

3. Dans la section Pools de nœuds, cliquez sur le nom du pool de nœuds que vous souhaitez mettre à niveau.

4. Cliquez sur le bouton Modifier.

5. Cliquez sur le lien Modifier situé à côté de Version du nœud.

6. Sélectionnez la version souhaitée, puis cliquez sur Modifier.

7. Cliquez sur Enregistrer.

Remarque : Le changement de version du nœud peut prendre plusieurs minutes.

Revenir à une version antérieure des nœuds

Il est impossible de revenir à une version antérieure d'un pool de nœuds. À la place, créez un pool de nœuds de la version souhaitée et migrez vos charges de travail vers celle-ci. Les nœuds pour lesquels la mise à niveau automatique est activée sont mis à jour pour correspondre à la version du plan de contrôle.

Vérifier l'état de la mise à jour du nœud

Bêta

Ce produit ou cette fonctionnalité est couvert par les Conditions des offres avant disponibilité générale des conditions d'utilisation de Google Cloud Platform. Les fonctionnalités et produits avant disponibilité générale sont susceptibles de présenter une compatibilité limitée, et les modifications apportées à ces fonctionnalités ou produits peuvent ne pas être compatibles avec d'autres versions avant disponibilité générale. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Vous pouvez vérifier l'état d'une mise à jour à l'aide de gcloud beta container operations.

Remarque : Pour utiliser les commandes gcloud beta, vous devez configurer gcloud pour l'utilisation de l'API v1beta1.

Pour afficher la liste de toutes les opérations en cours ou terminées dans le cluster, exécutez la commande suivante :

gcloud beta container operations list

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 dans la commande suivante :

gcloud beta container operations describe operation-id

Exemple :

gcloud beta 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

Annuler une mise à jour de nœuds

Bêta — gcloud container operations

Cette fonctionnalité est couverte par les Conditions des offres avant disponibilité générale des conditions d'utilisation de Google Cloud Platform. Les fonctionnalités avant disponibilité générale sont susceptibles de présenter une compatibilité limitée, et les modifications apportées à ces fonctionnalités peuvent ne pas être compatibles avec d'autres versions avant disponibilité générale. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Vous pouvez annuler une mise à jour à tout moment. Lorsque vous annulez une mise à jour :

• Les nœuds dont la mise à jour a commencé poursuivent celle-ci jusqu'à son terme.
• Les nœuds dont la mise à jour n'a pas commencé ne sont pas mis à jour.
• Les nœuds dont la mise à jour a été menée à bien ne sont pas affectés par cette commande et ne subiront pas de rollback.

1. Obtenez l'ID d'opération de la mise à niveau à l'aide de la commande suivante :

   gcloud container operations list
   

2. Exécutez la commande suivante pour annuler la mise à niveau :

   gcloud beta container operations cancel operation-id
   

Consultez la documentation sur gcloud container operations cancel.

Effectuer un rollback pour rétablir la version précédant la mise à jour des nœuds

Vous pouvez effectuer un rollback pour les pools de nœuds dont la mise à jour a échoué ou a été annulée de façon à rétablir leur version précédente de Kubernetes. En revanche, le rollback n'est plus possible pour les pools de nœuds dont la mise à jour a abouti. Les nœuds dont la mise à jour n'a pas commencé ne sont pas affectés.

Pour effectuer le rollback d'une mise à jour, exécutez la commande suivante :

gcloud container node-pools rollback node-pool-name \
  --cluster cluster-name

où :

• node-pool-name est le nom du pool de nœuds sur lequel effectuer le rollback.
• cluster-name est le nom du cluster dans lequel se trouve le pool de nœuds sur lequel effectuer le rollback.

Consultez la documentation sur gcloud container node-pools rollback.

Modifier les paramètres de mise à niveau de la surutilisation

Les mises à niveau de surutilisation vous permettent de modifier le nombre de mises à niveau automatiques des nœuds GKE simultanées, ainsi que le nombre d'interruptions qu'une mise à niveau peut entraîner sur vos charges de travail.

Les options max-surge-upgrade et max-unavailable-upgrade sont définies pour chaque pool de nœuds. Pour plus d'informations sur la sélection des paramètres appropriés, consultez la section Déterminer la configuration optimale de surutilisation.

Remarque : Tous les nouveaux pools de nœuds sont automatiquement configurés pour utiliser les mises à niveau de la surutilisation maxSurge=1 maxUnavailable=0. Pour ajuster votre configuration, consultez la section Déterminer la configuration optimale de surutilisation.

Vous pouvez modifier ces paramètres lors de la création ou de la mise à jour d'un cluster ou d'un pool de nœuds.

Les variables suivantes sont utilisées dans les commandes mentionnées ci-dessous :

• cluster-name est le nom du cluster du pool de nœuds.
• compute-zone est la zone du cluster.
• node-pool-name est le nom du pool de nœuds.
• number-nodes est le nombre de nœuds du pool de nœuds dans chacune des zones du cluster.
• surge-nodes est le nombre de nœuds supplémentaires (surutilisation) à créer à chaque mise à niveau du pool de nœuds.
• unavailable-nodes est le nombre de nœuds qui peuvent être indisponibles simultanément à chaque mise à niveau du pool de nœuds.

Créer un cluster avec des paramètres de surutilisation spécifiques

Pour créer un cluster avec des paramètres spécifiques pour les mises à niveau de la surutilisation, utilisez les options max-surge-upgrade et max-unavailable-upgrade.

gcloud container clusters create cluster-name \
  --max-surge-upgrade=surge-nodes --max-unavailable-upgrade=unavailable-nodes

Créer un cluster sans mise à niveau de surutilisation

Pour créer un cluster sans mises à niveau de la surutilisation, définissez la valeur de l'option max-surge-upgrade sur 0.

gcloud container clusters create cluster-name \
  --max-surge-upgrade=0 --max-unavailable-upgrade=1

Créer un pool de nœuds avec des paramètres de surutilisation spécifiques

Pour créer un pool de nœuds dans un cluster existant avec des paramètres spécifiques pour les mises à niveau de la surutilisation, utilisez les options max-surge-upgrade et max-unavailable-upgrade.

gcloud container node-pools create node-pool-name \
  --num-nodes=number-nodes --cluster=cluster-name \
  --max-surge-upgrade=surge-nodes --max-unavailable-upgrade=unavailable-nodes

Activer ou désactiver les mises à niveau de surutilisation pour un pool de nœuds existant

Pour mettre à jour les paramètres de mise à niveau d'un pool de nœuds existant, utilisez les options max-surge-upgrade et max-unavailable-upgrade. Si vous définissez max-surge-upgrade sur une valeur supérieure à 0, GKE crée des nœuds de surutilisation. Si vous définissez max-surge-upgrade sur 0, GKE ne crée pas de nœuds de surutilisation.

gcloud beta container node-pools update node-pool-name \
  --cluster=cluster-name \
  --max-surge-upgrade=surge-nodes --max-unavailable-upgrade=unavailable-nodes

Vérifier si les mises à niveau de surutilisation sont activées dans un pool de nœuds

Pour savoir si les mises à niveau de la surutilisation sont activées sur un pool de nœuds, vous pouvez décrire les paramètres du cluster à l'aide de gcloud :

gcloud container node-pools describe node-pool-name \
--cluster=cluster-name

Remarque : Si la recréation de nœuds ne nécessite pas de ressources Compute Engine supplémentaires, il n'en va pas de même pour les mises à niveau de surutilisation. L'allocation des ressources est soumise à un quota Compute Engine. En fonction de votre configuration, ce quota peut limiter le nombre de mises à niveau effectuées en parallèle ou même entraîner leur échec.

Pour plus d'informations sur les quotas, consultez la page Mises à niveau et quotas de nœuds.

Étape suivante

• Apprenez-en plus sur l'architecture d'un cluster.
• Apprenez-en plus sur les versions disponibles.