DEV Community

Cover image for Mettre à jour GKE sans sueurs froides : La stratégie Terraform Zero-Downtime
La Formule Nuagique profile image Benoît Garçon
Benoît Garçon for La Formule Nuagique

Posted on • Originally published at formulenuagique.com

Mettre à jour GKE sans sueurs froides : La stratégie Terraform Zero-Downtime

#googlecloud #devops #kubernetes #terraform

Dans la vie d'un ingénieur Cloud, peu de notifications génèrent autant d'anxiété que : "GKE version 1.27 will reach end of life soon". La mise à jour de Kubernetes est souvent perçue comme une opération à cœur ouvert. Pourtant, avec une stratégie Terraform rigoureuse, c'est un non-événement.

Chez La Formule Nuagique, nous voyons trop souvent des clusters "Snowflake" mis à jour manuellement via la console Google Cloud. C'est une erreur critique en production. Une mise à jour GKE doit être déclarative, prévisible et codifiée.

Voici comment on architecture les montées de version GKE pour garantir la continuité de service, code Terraform à l'appui.

1. La règle d'or : Dissocier control plane et node pools

Sur GKE, la mise à jour se fait en deux temps : le Master (Control Plane) puis les Nodes (Workers). Terraform doit refléter cette réalité.

Une erreur classique est de tout vouloir mettre à jour en même temps. La bonne pratique consiste à piloter la version via des variables distinctes.

Le control plane

La mise à jour du master est gérée par Google. Elle ne cause pas de downtime applicatif, mais l'API server peut être indisponible quelques minutes (attention à vos pipelines CI/CD).

resource "google_container_cluster" "primary" {
  name     = "prod-cluster-01"
  location = "europe-west1"

  # On fixe la version mineure, mais on laisse Google gérer les patchs de sécu
  min_master_version = "1.29" 

  # ... configuration réseau ...
}
Enter fullscreen mode Exit fullscreen mode

Le conseil de l'expert : Ne spécifiez pas la version complète (ex: 1.29.1-gke.1589000) dans min_master_version sauf nécessité absolue. Ciblez la mineure (1.29) pour bénéficier des auto-upgrades de sécurité critiques sans changer votre code tous les jours.

2. Les node pools : Là où le danger réside

C'est ici que votre trafic de production est traité. Si vous mettez à jour brutalement, les pods sont tués. Si vos nœuds redémarrent tous en même temps, c'est l'incident majeur.

Pour éviter cela, nous utilisons une stratégie de surge configurée directement dans Terraform.

L'approche max_surge et max_unavailable

L'objectif est de créer de nouveaux nœuds (en version N+1) avant de détruire les anciens (version N).

resource "google_container_node_pool" "primary_nodes" {
  name       = "pool-standard-v1"
  location   = "europe-west1"
  cluster    = google_container_cluster.primary.name

  # La version des noeuds suit celle du master, ou peut être gérée manuellement
  version = "1.29"

  upgrade_settings {
    # Combien de nœuds supplémentaires peut-on créer temporairement ?
    # Ici, on ajoute 1 nœud en plus pour absorber la charge pendant la migration.
    max_surge = 1

    # Combien de nœuds peuvent être indisponibles en même temps ?
    # 0 = On veut ABSOLUMENT maintenir la capacité actuelle.
    max_unavailable = 0
  }

  node_config {
    machine_type = "e2-standard-4"
    # ...
  }
}
Enter fullscreen mode Exit fullscreen mode

L'analyse de Benoît Garçon : Avec max_unavailable = 0 et max_surge = 1, GKE va créer un nouveau nœud, attendre qu'il soit "Ready", déplacer les pods dessus (Drain), et seulement ensuite détruire l'ancien nœud. C'est plus lent, mais c'est l'assurance-vie de votre production.

3. Les fenêtres de maintenance

Ne laissez jamais Google décider quand la mise à jour s'applique. Vous ne voulez pas d'un upgrade le lundi matin à 9h00 lors du pic de charge.

Utilisez le bloc maintenance_policy dans votre ressource google_container_cluster :

resource "google_container_cluster" "primary" {
  # ...

  maintenance_policy {
    recurring_window {
      start_time = "2024-01-01T02:00:00Z" # 2h du matin UTC
      end_time   = "2024-01-01T06:00:00Z" # Jusqu'à 6h du matin
      recurrence = "FREQ=WEEKLY;BYDAY=SA,SU" # Uniquement le week-end
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

4. Le piège invisible : Les Pod Disruption Budgets

Même avec le meilleur code Terraform, votre montée de version peut rester bloquée indéfiniment. Pourquoi ? À cause des Pod Disruption Budgets.

Si vous avez une application avec 3 réplicas et un PDB qui exige minAvailable: 3, GKE ne pourra jamais drainer le nœud pour le mettre à jour.

La checklist de pré-upgrade de La Formule Nuagique :

  • Vérifier les APIs dépréciées : Utilisez l'outil kubent ou les "Deprecation Insights" dans la console GCP.

  • Audit des PDB : Assurez-vous qu'ils autorisent au moins 1 pod indisponible.

  • StatefulSets : Soyez extrêmement vigilant avec les bases de données hébergées dans Kubernetes, les volumes (PVC) peuvent être lents à se détacher/rattacher.

Conclusion : L'automatisation comme standard

La montée de version GKE ne doit pas être un projet héroïque, mais un processus standardisé. En codant ces stratégies dans Terraform, vous transformez un risque opérationnel en une simple Pull Request.

Besoin d'auditer la résilience de vos clusters Kubernetes ?

Benoît Garçon, via La Formule Nuagique, accompagne les équipes Tech dans la sécurisation de leurs infrastructures GCP et l'automatisation de leurs opérations Day-2.

Top comments (0)