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.
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.
-
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
- Suivez les instructions pour autoriser
gcloud
à utiliser votre compte Google Cloud. - Créez ou sélectionnez une configuration.
- Choisissez un projet Google Cloud.
- Choisissez une zone Compute Engine par défaut.
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
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
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 :
Accédez au menu Google Kubernetes Engine de Google Cloud Console.
Sélectionnez le cluster souhaité.
Cliquez sur le lien Mise à jour disponible à côté de Version maître.
Sélectionnez la version souhaitée, puis cliquez sur Modifier.
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
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.
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.
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 :
Accédez au menu Google Kubernetes Engine de Cloud Console.
Cliquez sur le bouton Modifier du cluster (icône en forme de crayon).
Dans la section Pools de nœuds, cliquez sur le nom du pool de nœuds que vous souhaitez mettre à niveau.
Cliquez sur le bouton Modifier.
Cliquez sur le lien Modifier situé à côté de Version du nœud.
Sélectionnez la version souhaitée, puis cliquez sur Modifier.
Cliquez sur Enregistrer.
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
Vous pouvez vérifier l'état d'une mise à jour à l'aide de gcloud beta container operations
.
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
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.
Obtenez l'ID d'opération de la mise à niveau à l'aide de la commande suivante :
gcloud container operations list
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.
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
Étape suivante
- Apprenez-en plus sur l'architecture d'un cluster.
- Apprenez-en plus sur les versions disponibles.