Google Cloud a annoncé que son service GKE propose désormais des mises à niveau du plan de contrôle en deux étapes, désormais disponibles de manière générale, permettant aux clients de séparer la mise à niveau du binaire logiciel de la migration du format de données et de maintenir une fenêtre de retour en arrière ouverte lors des changements de version mineure.

Pourquoi GKE avait besoin d'une voie plus sûre

La mise à niveau d'un plan de contrôle Kubernetes d'une version mineure à la suivante a toujours comporté des risques. Passer de la version 1.33 à la 1.34 ne se limite pas au remplacement des binaires, mais réécrit également les structures de données sous-jacentes. Si la nouvelle version contient un bug, le cluster ne peut pas être simplement annulé ; les administrateurs doivent restaurer d'anciennes captures instantanées (snapshots) de la base de données ou reconstruire l'intégralité du cluster, un processus chronophage et sujet aux erreurs.

Comment fonctionne la mise à niveau en deux étapes

Le nouveau flux divise la mise à niveau en deux phases distinctes :

  • Étape 1 – Mise à niveau du binaire (mode émulé). GKE remplace les binaires du plan de contrôle par la version cible tout en préservant l'ancien format de données. Comme aucune nouvelle structure de données n'est écrite, le cluster reste protégé contre un retour en arrière (rollback-safe) tout au long de cette phase.
  • Étape 2 – Finalisation. Après une période d'attente configurable, GKE convertit les données stockées vers le nouveau format. Une fois cette conversion terminée, un retour en arrière nécessiterait le même effort de restauration de snapshot que le processus en deux étapes était censé éviter.

Cette séparation crée une « fenêtre de rodage » (soak window) au cours de laquelle les opérateurs peuvent observer les binaires mis à niveau en production sans s'engager dans la migration irréversible des données.

La fenêtre de rodage en pratique

GKE surveille automatiquement les indicateurs de santé clés pendant la période de rodage : latence de l'API, taux d'erreur et état de santé des pods. Si le service détecte des anomalies, il interrompt le déploiement, laissant le cluster dans l'état « binaire uniquement » où un retour en arrière est encore possible. Google cite un taux de réussite de 99,999 % pour les mises à niveau suivant ce modèle.

Pour les clusters utilisant la fonctionnalité d'auto-mise à niveau de GKE, la plateforme orchestre l'ensemble de la séquence en deux étapes sans intervention manuelle. Les utilisateurs qui préfèrent un contrôle total peuvent lancer le processus via la Cloud CLI ou Terraform.

Exécuter une mise à niveau manuelle en deux étapes

Une mise à niveau manuelle typique avec une fenêtre de sécurité de 48 heures ressemble à ceci :

gcloud beta container clusters upgrade my-cluster \
  --location=us-central1 \
  --cluster-version=1.34.1-gke.1829001 \
  --control-plane-soak-duration=48h \
  --master

Pour inspecter l'état actuel :

gcloud container clusters describe my-cluster \
  --location=us-central1 \
  --format="yaml(rollbackSafeUpgradeStatus)"

Si un défaut apparaît pendant la période de rodage, l'administrateur peut émettre une commande de rollback et revenir à la version précédente sans perte de données. Lorsque le cluster s'avère stable, la mise à niveau peut être achevée prématurément avec la commande complete-control-plane-upgrade.

Limites et exigences

  • La fonctionnalité s'applique aux clusters GKE exécutant la version 1.33 ou ultérieure.
  • Une seule version mineure peut être mise à niveau à la fois ; le saut de versions n'est pas pris en charge.
  • Les clusters Autopilot et régionaux restent tous deux disponibles tout au long du processus en deux étapes.

Inconvénients potentiels

La séparation des mises à niveau binaires et de données ajoute une étape supplémentaire au calendrier de mise à niveau, ce qui peut prolonger la fenêtre globale pour les organisations ayant besoin de changements de version rapides. La période de rodage repose également sur des contrôles de santé automatisés ; les équipes qui exécutent des charges de travail hautement personnalisées pourraient avoir besoin de compléter la surveillance de GKE avec leurs propres outils d'observabilité pour détecter les régressions dans des cas limites.

À surveiller ensuite

Google n'a pas divulgué de feuille de route pour étendre le modèle en deux étapes aux mises à niveau de versions majeures, qui nécessitent encore, dans de nombreux cas, une recréation complète du cluster. Les observateurs attendent des annonces concernant des filets de sécurité similaires pour les mises à niveau de pools de nœuds (node-pools) et toute intégration avec des pipelines CI/CD tiers qui pourrait automatiser les contrôles de la fenêtre de rodage.

À retenir : En découplant les mises à niveau binaires des migrations de données, GKE offre aux ingénieurs plateforme une fenêtre de rollback pratique pour les changements de version mineure, réduisant ainsi le coût opérationnel de la maintenance des clusters tout en minimisant les temps d'arrêt.