Google Kubernetes Engine (GKE) vient de souffler ses dix bougies et Google en a profité pour repenser en profondeur son offre : Autopilot est désormais activable à la demande sur n’importe quel cluster Standard, la version 1.36 pousse la limite à 15 000 nœuds par cluster, et l’infrastructure pour agents IA (Agent Sandbox) est passée en disponibilité générale. Pour une équipe qui déploie ses premières charges sur Google Cloud, ou qui migre depuis un cluster auto-géré, ce tutoriel couvre la création, la sécurisation et l’exploitation d’un cluster GKE de bout en bout, avec des commandes testables et des pièges à éviter.

Nous partons d’un projet Google Cloud vide et allons jusqu’au déploiement d’une API conteneurisée en production, avec autoscaling, politiques réseau, gestion des secrets, supervision, pipeline CI/CD et plan de sauvegarde. Chaque commande a été vérifiée sur les versions de gcloud et kubectl indiquées dans les prérequis, valides début septembre 2026.

Pourquoi GKE plutôt qu’un Kubernetes auto-géré

GKE reste le service Kubernetes managé le plus mature du marché : Google a créé Kubernetes en interne avant de l’ouvrir à la CNCF en 2014, et le service commercial fête ses dix ans en 2026. Cette antériorité se traduit par un control plane entièrement géré (mises à jour, certificats, etcd), un autoscaling natif au niveau des nœuds et des pods, et deux modes d’exploitation distincts : Standard, où vous gardez la main sur la configuration des nœuds, et Autopilot, où Google gère l’intégralité de l’infrastructure sous-jacente.

La bascule récente change la donne pour les équipes déjà en place. Depuis la KubeCon EU 2026, les compute classes Autopilot sont disponibles sur les clusters Standard existants, ce qui permet d’activer la gestion automatisée workload par workload sans migrer tout le cluster. Google a aussi annoncé l’ouverture du GKE Cluster Autoscaler en open source, une pièce centrale du provisioning automatique de nœuds. Pour une PME européenne qui veut réduire sa charge opérationnelle sans sacrifier le contrôle, GKE Autopilot devient une option crédible là où il fallait auparavant choisir entre gestion complète et confort managé.

Sur le plan réseau, GKE Dataplane V2, basé sur eBPF, gère désormais jusqu’à 15 000 nœuds par cluster avec NetworkPolicies actives, contre 7 500 auparavant en version 1.36. Pour les charges d’inférence IA et de calcul distribué, Google a aussi introduit GKE Hypercluster (disponibilité générale restreinte), un control plane unique capable de piloter des accélérateurs GPU et TPU sur plusieurs régions Google Cloud. Pour la majorité des équipes qui déploient des applications web ou des API classiques, ces limites extrêmes ne seront jamais atteintes, mais elles montrent que l’infrastructure sous-jacente a été repensée pour absorber des charges bien plus lourdes qu’il y a encore deux ans.

Prérequis avant de commencer

Avant de lancer le premier cluster, réunissez les éléments suivants. Le tutoriel a été vérifié avec les versions ci-dessous, valides début septembre 2026.

ComposantVersion minimaleRemarque
Compte Google CloudFacturation activéeLe niveau gratuit couvre les tests légers, GKE facture 0,10 $/heure par cluster hors niveau Autopilot gratuit
Google Cloud CLI (gcloud)509.0.0 ou supérieurInstaller via le script officiel Google Cloud SDK
kubectl1.33 ou supérieurInstallable via gcloud components install kubectl
Kubernetes (côté cluster)1.36Version courante du canal Regular en septembre 2026
Helm (optionnel)3.15 ou supérieurUtile pour déployer des applications packagées
Docker ou Cloud BuildDocker 26.xPour construire vos images de conteneurs
Système d’exploitation localLinux, macOS ou WSL2Le SDK gcloud fonctionne nativement sur les trois

Vous aurez aussi besoin des droits IAM roles/container.admin sur le projet Google Cloud cible, et d’un projet avec l’API Kubernetes Engine activée. Comptez environ 90 minutes pour dérouler l’ensemble du tutoriel, y compris le déploiement d’une application de test et la mise en place du monitoring. Si vous testez pour la première fois, activez la facturation avec une limite de dépense basse : la section consacrée aux alertes de budget plus loin dans ce tutoriel explique comment procéder en quelques minutes.

Étape 1 : créer et configurer le projet Google Cloud

Commencez par créer un projet dédié plutôt que de réutiliser un projet existant : cela isole la facturation et les rôles IAM, ce qui facilite grandement le nettoyage en fin de test. Authentifiez-vous ensuite avec le SDK.

# Authentification
gcloud auth login

# Création d'un projet dédié
gcloud projects create shattered-gke-demo --name="Shattered GKE Demo"

# Sélection du projet actif
gcloud config set project shattered-gke-demo

# Activation des APIs nécessaires
gcloud services enable container.googleapis.com \
  compute.googleapis.com \
  artifactregistry.googleapis.com \
  monitoring.googleapis.com \
  logging.googleapis.com

Liez ensuite un compte de facturation au projet, sans quoi la création du cluster échouera avec une erreur explicite. Si vous gérez plusieurs environnements, adoptez dès maintenant une convention de nommage par projet (dev, staging, prod) : GKE facture au cluster, donc mutualiser un cluster par environnement limite les coûts fixes.

Étape 2 : choisir entre Autopilot et Standard

C’est la décision structurante du tutoriel. Autopilot facture au pod (vCPU et mémoire réellement consommés), gère le provisioning, le patching des nœuds et la sécurité de base automatiquement. Standard facture à la VM sous-jacente et vous laisse configurer les pools de nœuds, les types de machines et les politiques de scaling.

CritèreGKE AutopilotGKE Standard
Gestion des nœudsEntièrement gérée par GoogleÀ la charge de l’équipe
FacturationPar pod (vCPU + mémoire demandés)Par VM provisionnée
Prix vCPU (tarif standard)0,0445 $/vCPU/heureTarif Compute Engine classique
Prix mémoire (tarif standard)0,0049225 $/GiB/heureTarif Compute Engine classique
Contrôle du nombre de nœudsAutomatiqueManuel ou via autoscaler
Compute classes par workloadActivable sur cluster Standard existantNon applicable (déjà natif)
Cas d’usage recommandéÉquipes sans SRE dédié, charges variablesWorkloads spécialisés (GPU custom, kernel tuning)

Pour ce tutoriel, nous partons sur Autopilot : c’est le chemin le plus rapide pour obtenir un cluster sécurisé par défaut, et c’est aussi devenu la recommandation par défaut de Google depuis l’annonce du dixième anniversaire de GKE, où les compute classes Autopilot ont été rendues disponibles sur les clusters Standard existants pour un déploiement à la carte, workload par workload.

Étape 3 : créer le cluster GKE Autopilot

La commande suivante crée un cluster Autopilot régional, recommandé en production pour sa haute disponibilité (le control plane est répliqué sur trois zones). Choisissez une région européenne pour rester conforme aux exigences de localisation des données si votre activité est concernée par le RGPD ou NIS2.

# Création d'un cluster Autopilot en Europe (Belgique)
gcloud container clusters create-auto shattered-demo-cluster \
  --region=europe-west1 \
  --release-channel=regular

# Récupération des identifiants kubectl
gcloud container clusters get-credentials shattered-demo-cluster \
  --region=europe-west1

# Vérification de la connexion
kubectl get nodes
kubectl cluster-info

La création prend généralement entre 6 et 10 minutes. Une fois terminée, kubectl get nodes doit lister au moins un nœud avec le statut Ready. Notez que sur Autopilot, les nœuds sont provisionnés dynamiquement dès qu’un pod est planifié : il est normal de ne voir aucun nœud tant qu’aucune charge n’a été déployée.

Étape 4 : préparer et pousser une image de conteneur

Créez un dépôt Artifact Registry (le registre historique Container Registry est en fin de vie) et poussez une image d’exemple. Voici un Dockerfile minimal pour une API Node.js.

# Dockerfile
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 8080
USER node
CMD ["node", "server.js"]
# Création du dépôt Artifact Registry
gcloud artifacts repositories create shattered-repo \
  --repository-format=docker \
  --location=europe-west1

# Authentification Docker vers Artifact Registry
gcloud auth configure-docker europe-west1-docker.pkg.dev

# Build et push de l'image
docker build -t europe-west1-docker.pkg.dev/shattered-gke-demo/shattered-repo/api:v1 .
docker push europe-west1-docker.pkg.dev/shattered-gke-demo/shattered-repo/api:v1

Le fait d’exécuter le conteneur avec un utilisateur non-root (USER node) n’est pas cosmétique : Autopilot applique par défaut des politiques de sécurité qui bloquent les conteneurs tentant de tourner en root sans configuration explicite.

Étape 5 : déployer l’application sur le cluster

Créez un manifeste de déploiement et un service pour exposer l’application. Sur Autopilot, définissez systématiquement des requêtes de ressources précises : c’est ce qui détermine directement votre facture, puisque la facturation se fait au pod.

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: shattered-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: shattered-api
  template:
    metadata:
      labels:
        app: shattered-api
    spec:
      containers:
      - name: api
        image: europe-west1-docker.pkg.dev/shattered-gke-demo/shattered-repo/api:v1
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: "250m"
            memory: "256Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"
---
apiVersion: v1
kind: Service
metadata:
  name: shattered-api-svc
spec:
  type: LoadBalancer
  selector:
    app: shattered-api
  ports:
  - port: 80
    targetPort: 8080
kubectl apply -f deployment.yaml
kubectl get pods -w
kubectl get service shattered-api-svc

Patientez quelques minutes le temps que Google provisionne un Network Load Balancer et lui attribue une IP externe. La colonne EXTERNAL-IP passe de <pending> à une adresse IP publique une fois l’opération terminée.

Étape 6 : configurer l’autoscaling horizontal et vertical

Sur Autopilot, le scaling des nœuds est automatique, mais le scaling des pods (nombre de réplicas) reste à votre charge via un Horizontal Pod Autoscaler (HPA). GKE a introduit lors de Cloud Next ’26 une forme d’autoscaling basé sur l’intent et des métriques custom, mais le HPA standard reste la brique de base à maîtriser.

kubectl autoscale deployment shattered-api \
  --cpu-percent=70 \
  --min=3 \
  --max=10

kubectl get hpa shattered-api

Testez la montée en charge avec un outil comme hey ou k6 pour vérifier que de nouveaux pods apparaissent bien quand le CPU dépasse 70 %. Sur Autopilot, cela déclenche en cascade un provisioning de capacité supplémentaire côté infrastructure, sans intervention manuelle sur les pools de nœuds.

Étape 7 : sécuriser le cluster avec les politiques réseau

Depuis la version 1.36, GKE Dataplane V2 (basé sur eBPF via Cilium) gère nativement les NetworkPolicies jusqu’à 15 000 nœuds par cluster. Sur Autopilot, Dataplane V2 est activé par défaut. Définissez une politique qui restreint le trafic entrant vers votre API aux seuls pods du même namespace.

# network-policy.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-api-ingress
spec:
  podSelector:
    matchLabels:
      app: shattered-api
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: default
    ports:
    - protocol: TCP
      port: 8080
kubectl apply -f network-policy.yaml
kubectl describe networkpolicy restrict-api-ingress

Pour renforcer le trafic externe, GKE Gateway prend désormais en charge le mTLS frontal (validation de certificat client) sur les classes gke-l7-global-external-managed, gke-l7-regional-external-managed et gke-l7-rilb. C’est pertinent si vous exposez des API à des partenaires B2B qui doivent s’authentifier par certificat plutôt que par simple jeton.

Étape 8 : gérer les secrets et les identités de service

Évitez de stocker des identifiants en clair dans vos manifestes. GKE s’intègre nativement avec Google Secret Manager via Workload Identity, ce qui évite de gérer des clés de service statiques dans le cluster.

# Création d'un compte de service Google Cloud
gcloud iam service-accounts create shattered-api-sa \
  --display-name="Shattered API Service Account"

# Liaison à un compte de service Kubernetes via Workload Identity
gcloud iam service-accounts add-iam-policy-binding \
  [email protected] \
  --role="roles/iam.workloadIdentityUser" \
  --member="serviceAccount:shattered-gke-demo.svc.id.goog[default/shattered-ksa]"

kubectl annotate serviceaccount shattered-ksa \
  iam.gke.io/gcp-service-account=shattered-api-sa@shattered-gke-demo.iam.gserviceaccount.com

Avec cette configuration, votre application peut appeler Secret Manager, Cloud SQL ou Cloud Storage sans exposer de clé JSON dans le cluster. C’est la méthode recommandée par Google depuis plusieurs années, et elle est désormais quasi obligatoire sur Autopilot, qui restreint fortement l’usage des ServiceAccounts avec des permissions larges par défaut.

Étape 9 : mettre en place la supervision et les journaux

Cloud Monitoring et Cloud Logging sont activés automatiquement sur les clusters Autopilot. Vérifiez que les métriques remontent correctement et créez une alerte simple sur le taux d’erreur HTTP.

# Vérifier que les logs du pod remontent
kubectl logs -l app=shattered-api --tail=50

# Lister les métriques exposées par le cluster
gcloud monitoring dashboards list --project=shattered-gke-demo

Pour des besoins avancés de traçabilité applicative (traces distribuées, profiling), Google recommande Cloud Trace et Cloud Profiler, tous deux compatibles OpenTelemetry. Si votre stack utilise déjà Prometheus, GKE expose une compatibilité native via Google Cloud Managed Service for Prometheus, ce qui évite d’auto-héberger un serveur Prometheus supplémentaire dans le cluster.

Étape 10 : maîtriser les coûts avec les remises d’engagement

Un changement de tarification est passé relativement inaperçu en 2026 : les remises d’engagement (committed use discounts) spécifiques à Autopilot ont été retirées. Les équipes doivent désormais utiliser les Compute Flexible CUD ou les Kubernetes Engine CUD génériques pour obtenir une réduction sur 1 ou 3 ans.

Type de tarifPrix vCPU (par heure)Prix mémoire GiB (par heure)
Tarif standard (à la demande)0,0445 $0,0049225 $
Compute Flexible CUD – 1 an0,03204 $Réduction équivalente
Compute Flexible CUD – 3 ans0,02403 $Réduction équivalente
Kubernetes Engine CUD – 1 an0,0356 $Réduction équivalente
Kubernetes Engine CUD – 3 ans0,02447 $Réduction équivalente

En plus de la compute, chaque cluster GKE (Standard ou Autopilot) facture un forfait de gestion de 0,10 $ par heure et par cluster, indépendamment de la taille. Pour une petite équipe qui multiplie les clusters de test, ce forfait fixe peut vite dépasser le coût de la compute elle-même : préférez des namespaces séparés dans un cluster partagé pour les environnements non critiques.

Étape 11 : exploiter les nouveautés IA de GKE (Agent Sandbox)

Si votre feuille de route inclut des agents IA ou des workloads d’inférence LLM, GKE Agent Sandbox est passé en disponibilité générale en 2026. Il fournit une infrastructure isolée, à faible latence, pensée pour exécuter du code généré dynamiquement par des agents sans compromettre la sécurité du cluster hôte. Cette brique s’accompagne du projet open source Agent Substrate, destiné à densifier l’infrastructure agentique.

Pour les charges d’entraînement ou d’inférence à très grande échelle, GKE Hypercluster (disponibilité générale restreinte) propose un control plane unique capable de piloter des accélérateurs GPU et TPU répartis sur plusieurs régions Google Cloud. Ce n’est pas un besoin courant pour une PME, mais c’est un signal clair de la direction que prend GKE : devenir la plateforme de référence pour les charges IA, pas seulement pour les microservices classiques.

Étape 12 : mettre à jour et faire évoluer le cluster en production

Sur Autopilot, les mises à jour de version Kubernetes sont automatiques selon le canal choisi (Rapid, Regular ou Stable). Le canal Regular, utilisé dans ce tutoriel, propage la version 1.36 avec un délai de stabilisation raisonnable par rapport au canal Rapid. Vérifiez régulièrement votre version courante et anticipez les échéances de fin de support.

# Vérifier la version actuelle du cluster
gcloud container clusters describe shattered-demo-cluster \
  --region=europe-west1 \
  --format="value(currentMasterVersion)"

# Lister les versions disponibles sur le canal Regular
gcloud container get-server-config \
  --region=europe-west1 \
  --format="yaml(channels)"

D’après le calendrier de publication officiel, la version 1.36 est sortie fin avril 2026 sur le canal Rapid et mi-juin 2026 sur le canal Regular, avec un support prolongé jusqu’en 2028 pour les canaux étendus. Documentez cette échéance dans votre registre de gestion des risques techniques si votre cluster héberge des charges critiques. Pour les environnements réglementés (banque, santé, secteur public), privilégiez le canal Stable plutôt que Regular : la propagation des nouvelles versions y est plus lente, ce qui laisse davantage de temps pour valider la compatibilité de vos workloads avant chaque montée de version majeure.

Étape 13 : ajouter des sondes de santé pour un déploiement fiable

Un déploiement qui répond au trafic ne veut pas dire qu’il est prêt à le recevoir. Les sondes de disponibilité (readinessProbe) et de vivacité (livenessProbe) permettent à Kubernetes de retirer temporairement un pod du service tant qu’il n’a pas fini de démarrer, et de redémarrer un pod bloqué sans intervention manuelle. Sur Autopilot, ces sondes sont d’autant plus importantes que le scheduler s’appuie dessus pour décider quand un pod peut recevoir du trafic après un scaling.

        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 20
          failureThreshold: 3

Ajoutez cet extrait dans la section containers du manifeste de déploiement créé à l’étape 5, puis réappliquez avec kubectl apply -f deployment.yaml. Vérifiez ensuite le comportement avec kubectl describe pod : la ligne Readiness doit passer à true une fois le point de terminaison /healthz accessible. Sans route dédiée au sondage de santé, exposez au minimum une route racine qui répond en 200, faute de quoi Kubernetes considérera systématiquement le pod comme non prêt.

Étape 14 : automatiser le déploiement avec Cloud Build

Construire et pousser une image manuellement fonctionne pour un tutoriel, mais devient vite ingérable en équipe. Cloud Build, le service CI/CD natif de Google Cloud, se déclenche automatiquement à chaque push sur votre dépôt Git et peut construire l’image, la pousser vers Artifact Registry, puis déployer sur GKE en une seule pipeline déclarative.

# cloudbuild.yaml
steps:
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', 'europe-west1-docker.pkg.dev/$PROJECT_ID/shattered-repo/api:$SHORT_SHA', '.']
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'europe-west1-docker.pkg.dev/$PROJECT_ID/shattered-repo/api:$SHORT_SHA']
  - name: 'gcr.io/cloud-builders/gke-deploy'
    args:
      - 'run'
      - '--filename=deployment.yaml'
      - '--image=europe-west1-docker.pkg.dev/$PROJECT_ID/shattered-repo/api:$SHORT_SHA'
      - '--location=europe-west1'
      - '--cluster=shattered-demo-cluster'
images:
  - 'europe-west1-docker.pkg.dev/$PROJECT_ID/shattered-repo/api:$SHORT_SHA'

Créez ensuite un déclencheur lié à votre dépôt (GitHub, GitLab ou Cloud Source Repositories) pour lancer cette pipeline à chaque merge sur la branche principale.

# Création du déclencheur Cloud Build lié à un dépôt GitHub
gcloud builds triggers create github \
  --repo-name=shattered-api \
  --repo-owner=votre-organisation \
  --branch-pattern="^main$" \
  --build-config=cloudbuild.yaml

Le compte de service Cloud Build a besoin du rôle roles/container.developer sur le projet pour pouvoir déployer sur GKE. Sans cette permission, la pipeline échouera à l’étape de déploiement avec une erreur d’autorisation explicite dans les journaux de build.

Étape 15 : sauvegarder le cluster avec Backup for GKE

Un cluster Kubernetes n’est pas seulement composé de conteneurs éphémères : il porte aussi des volumes persistants, des ConfigMaps et des Secrets qu’il faut pouvoir restaurer après un incident. Backup for GKE, le service de sauvegarde natif de Google, capture l’état complet d’un espace de noms ou du cluster entier, y compris les volumes Persistent Disk associés.

# Activation de l'add-on Backup for GKE
gcloud container clusters update shattered-demo-cluster \
  --region=europe-west1 \
  --update-addons=BackupRestore=ENABLED

# Création d'un plan de sauvegarde quotidien
gcloud beta container backup-restore backup-plans create shattered-daily-backup \
  --project=shattered-gke-demo \
  --location=europe-west1 \
  --cluster=projects/shattered-gke-demo/locations/europe-west1/clusters/shattered-demo-cluster \
  --all-namespaces \
  --cron-schedule="0 3 * * *" \
  --backup-retain-days=14

Testez systématiquement une restauration dans un cluster séparé avant d’en avoir réellement besoin en production. Une sauvegarde qui n’a jamais été restaurée avec succès n’est, dans les faits, pas une sauvegarde fiable. Documentez le temps de restauration observé : c’est cette donnée, plus que la fréquence de sauvegarde elle-même, qui déterminera votre capacité réelle à respecter un objectif de temps de reprise (RTO) en cas d’incident. Conservez également une copie de vos manifestes Kubernetes dans un dépôt Git versionné, séparément des sauvegardes Backup for GKE : en cas de corruption du dépôt de configuration lui-même, c’est ce second filet qui vous permettra de reconstruire un cluster propre depuis zéro.

Les 5 erreurs les plus fréquentes avec GKE

1. Oublier de définir des requêtes de ressources précises sur Autopilot. Sans requests explicites, Autopilot applique des valeurs par défaut qui peuvent gonfler la facture de façon inattendue, puisque la facturation suit strictement les ressources demandées, pas celles réellement consommées.

2. Choisir un cluster zonal en production. Un cluster zonal n’a qu’un seul control plane sur une seule zone : en cas d’incident zonal, le cluster entier devient inaccessible. Privilégiez systématiquement un cluster régional pour toute charge critique.

3. Laisser le compte de service par défaut avec des permissions larges. Le compte de service Compute Engine par défaut dispose historiquement d’un rôle Editor sur le projet. Créez toujours un compte de service dédié à portée réduite pour chaque cluster.

4. Ignorer les NetworkPolicies en pensant que le VPC suffit. Le VPC protège le périmètre externe, pas la communication entre pods au sein du cluster. Sans NetworkPolicy, un pod compromis peut dialoguer librement avec tous les autres pods du cluster.

5. Multiplier les clusters de test sans les supprimer. Chaque cluster facture un forfait fixe de 0,10 $/heure, soit environ 72 $ par mois, même s’il ne contient aucune charge active. Automatisez la suppression des clusters de démonstration après usage.

Exemple de sortie attendue

Voici à quoi doit ressembler la sortie de kubectl get pods une fois le déploiement stabilisé :

NAME                             READY   STATUS    RESTARTS   AGE
shattered-api-7d8f9c6b45-2xk9p   1/1     Running   0          3m12s
shattered-api-7d8f9c6b45-9mzq4   1/1     Running   0          3m12s
shattered-api-7d8f9c6b45-jv7wd   1/1     Running   0          3m12s

NAME                 TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)        AGE
shattered-api-svc    LoadBalancer   10.44.3.201    34.140.22.118   80:31842/TCP   4m01s

Si l’EXTERNAL-IP reste bloquée sur <pending> plus de 5 minutes, passez directement à la section dépannage ci-dessous, à l’entrée consacrée au Load Balancer.

Dépannage : les 8 problèmes les plus courants

1. Erreur “quota exceeded” à la création du cluster. Les nouveaux projets Google Cloud ont des quotas d’adresses IP et de CPU limités par région. Demandez une augmentation de quota depuis la console IAM ou changez de région.

2. Pods bloqués en statut “Pending” indéfiniment. Sur Autopilot, cela signifie généralement que les requests demandées dépassent la taille de machine maximale disponible dans la région, ou qu’une politique de sécurité (comme l’interdiction de tourner en root) bloque le scheduling. Inspectez avec kubectl describe pod.

3. EXTERNAL-IP reste à <pending>. Vérifiez que l’API Compute Engine est bien activée et que le projet dispose d’un quota d’adresses IP externes suffisant. Un délai de 2 à 5 minutes est normal, au-delà il s’agit généralement d’un souci de quota.

4. Erreur “Insufficient permissions” lors de gcloud container clusters get-credentials. Le rôle roles/container.developer minimum est requis. Vérifiez vos rôles IAM avec gcloud projects get-iam-policy.

5. ImagePullBackOff au démarrage du pod. Le compte de service du nœud n’a probablement pas les droits de lecture sur Artifact Registry. Vérifiez le rôle roles/artifactregistry.reader sur le compte de service du cluster.

6. HPA affiche “unknown” pour les métriques CPU. Le metrics-server met parfois jusqu’à 2 minutes à collecter les premières données après le déploiement. Si le problème persiste, vérifiez que les requests CPU sont bien définies : sans elles, le pourcentage d’utilisation ne peut pas être calculé.

7. NetworkPolicy appliquée mais trafic toujours bloqué. Vérifiez que le namespace cible porte bien le label kubernetes.io/metadata.name utilisé dans le sélecteur : ce label est automatique depuis Kubernetes 1.21+, mais certains clusters migrés depuis d’anciennes versions peuvent en manquer.

8. Facture Autopilot plus élevée que prévu en fin de mois. Comparez les requests déclarées dans vos manifestes avec la consommation réelle observée dans Cloud Monitoring. Un surdimensionnement systématique des requêtes est la cause numéro un des dérapages de coût sur Autopilot.

Astuces avancées pour aller plus loin

Une fois le cluster de base stabilisé, plusieurs pistes permettent d’aller plus loin. D’abord, activez les Mutating Admission Policies, passées en disponibilité générale en 2026 : elles remplacent une partie des webhooks de mutation par des règles déclaratives écrites en Common Expression Language (CEL), ce qui simplifie l’ajout automatique de labels ou d’annotations sans maintenir un service webhook séparé.

Ensuite, si votre trafic est sensible à la latence ou nécessite qu’un client reste attaché au même backend, la session affinity via GCPTrafficDistributionPolicy pour GKE Gateway est désormais en disponibilité générale. Elle évite de recourir à des solutions de contournement basées sur des cookies applicatifs.

Côté matériel, GKE propose désormais des familles de VM basées sur les processeurs Google Axion (N4A, en preview) et sur les processeurs AMD EPYC de 5ᵉ génération (N4D, en disponibilité générale). Ces familles apportent un meilleur rapport coût/performance pour les charges Kubernetes intensives, notamment en traitement de données et en IA. Sur Autopilot, vous ne choisissez pas directement le type de machine, mais Google sélectionne automatiquement la génération la plus adaptée à votre profil de charge.

Enfin, pour les organisations gérant plusieurs clusters, les fonctionnalités multi-cluster (Fleets, Teams, Config Management, Policy Controller) sont désormais incluses gratuitement avec GKE Standard, alors qu’elles nécessitaient auparavant une licence Anthos séparée. Cela simplifie la gouvernance centralisée pour les équipes qui opèrent sur plusieurs régions ou plusieurs environnements, en particulier pour appliquer une politique de sécurité unique à l’ensemble d’une flotte de clusters plutôt que de la dupliquer manuellement cluster par cluster.

GKE face à EKS et AKS : ce qui change concrètement

Les trois grands fournisseurs cloud proposent désormais un mode “sans gestion de nœuds” : GKE Autopilot, Amazon EKS avec Fargate ou Auto Mode, et Azure AKS avec ses node pools automatiques. La différence la plus nette reste l’ancienneté et la profondeur d’intégration : Google a inventé Kubernetes et conserve une longueur d’avance sur les fonctionnalités réseau avancées (Dataplane V2 basé sur eBPF) et sur l’intégration IA native (Agent Sandbox, Hypercluster). Cette avance se ressent surtout sur les projets qui démarrent aujourd’hui avec des besoins d’inférence IA ou de trafic à très forte volumétrie, moins sur une migration classique de microservices où les trois offres se valent globalement.

Pour une équipe déjà investie dans l’écosystème AWS ou Azure, changer de fournisseur uniquement pour ces fonctionnalités n’est pas toujours justifié. En revanche, pour un nouveau projet sans contrainte d’ancrage cloud, l’ouverture récente du GKE Cluster Autoscaler en open source et la gratuité des fonctionnalités multi-cluster (Fleets, Config Management) sur Standard rendent GKE particulièrement compétitif sur le rapport fonctionnalités/prix en 2026.

CritèreGKE AutopilotAmazon EKS (Fargate/Auto Mode)Azure AKS (node pools automatiques)
Origine du projet KubernetesCréé en interne chez GoogleAdopté, non créé par AWSAdopté, non créé par Microsoft
Facturation du control plane0,10 $/heure/cluster0,10 $/heure/clusterGratuit (support standard)
Limite de nœuds documentée15 000 (Dataplane V2, v1.36)Variable selon la configVariable selon la config
Fonctionnalités multi-cluster gratuitesOui (Fleets, Config Management)Payant via add-ons tiersPayant via Azure Arc
Infrastructure dédiée agents IAAgent Sandbox (GA), HyperclusterPas d’équivalent direct annoncéPas d’équivalent direct annoncé

Ce tableau reste indicatif : les trois fournisseurs font évoluer leurs tarifs et fonctionnalités plusieurs fois par an. Vérifiez toujours la documentation officielle avant de prendre une décision d’architecture engageante sur plusieurs années.

Configurer une alerte de budget pour éviter les mauvaises surprises

La facturation à la ressource réellement consommée sur Autopilot est un avantage, mais elle peut aussi surprendre une équipe qui n’a pas l’habitude de suivre sa consommation cloud au jour le jour. Google Cloud Billing permet de créer une alerte de budget qui envoie un courriel, ou déclenche une fonction Cloud Functions, dès qu’un seuil de dépense est franchi.

# Création d'un budget mensuel avec alerte à 50 %, 90 % et 100 %
gcloud billing budgets create \
  --billing-account=XXXXXX-XXXXXX-XXXXXX \
  --display-name="Budget GKE Demo" \
  --budget-amount=100EUR \
  --threshold-rule=percent=0.5 \
  --threshold-rule=percent=0.9 \
  --threshold-rule=percent=1.0

Pour un cluster de production, fixez un budget réaliste basé sur au moins un mois d’historique de consommation observé, plutôt que sur une estimation théorique établie avant le déploiement. Les workloads Kubernetes ont tendance à sous-estimer la consommation réelle lors du premier mois, le temps que l’équipe calibre correctement les requests et les seuils d’autoscaling.

Nettoyage : supprimer les ressources en fin de test

Pour éviter toute facturation résiduelle après ce tutoriel, supprimez systématiquement le cluster et les ressources associées.

# Suppression du cluster
gcloud container clusters delete shattered-demo-cluster \
  --region=europe-west1 --quiet

# Suppression du dépôt Artifact Registry
gcloud artifacts repositories delete shattered-repo \
  --location=europe-west1 --quiet

# Suppression du projet si créé uniquement pour ce test
gcloud projects delete shattered-gke-demo --quiet

La suppression du cluster libère automatiquement le Load Balancer et les adresses IP externes associées. Vérifiez dans la console Google Cloud, section “Adresses IP externes”, qu’aucune ressource orpheline ne subsiste, car une IP statique réservée mais non utilisée continue d’être facturée séparément.

Questions fréquentes

GKE Autopilot est-il adapté à un petit projet personnel ?
Oui, à condition de surveiller les requêtes de ressources définies dans vos manifestes. Le forfait fixe de 0,10 $/heure par cluster (environ 72 $/mois) reste le principal poste de coût pour un projet à faible trafic, indépendamment du mode choisi.

Quelle est la différence entre un cluster zonal et régional sur GKE ?
Un cluster zonal n’a qu’un seul control plane hébergé dans une seule zone, alors qu’un cluster régional réplique le control plane sur trois zones d’une même région, ce qui garantit la continuité de service en cas d’incident zonal.

Peut-on migrer un cluster Standard existant vers Autopilot sans le recréer ?
Il n’existe pas de bascule directe et automatique d’un cluster Standard complet vers Autopilot. En revanche, les compute classes Autopilot peuvent désormais être activées workload par workload sur un cluster Standard existant, ce qui permet une transition progressive.

GKE est-il conforme au RGPD si l’on choisit une région européenne ?
Choisir une région comme europe-west1 (Belgique) ou europe-west9 (Paris) garantit que les données au repos restent dans l’UE, mais la conformité RGPD dépend aussi des traitements applicatifs, des sous-traitants et des transferts de données annexes, pas uniquement de la localisation du cluster.

Faut-il activer Workload Identity dès le premier déploiement ?
Oui, c’est une bonne pratique dès le départ. Ajouter Workload Identity après coup sur une application déjà en production nécessite de réécrire la logique d’authentification aux services Google Cloud, ce qui est plus coûteux que de l’intégrer dès la conception.

Quelle est la limite de nœuds par cluster GKE en 2026 ?
Depuis la version 1.36, GKE Dataplane V2 avec NetworkPolicies actives supporte jusqu’à 15 000 nœuds par cluster, contre 7 500 dans les versions précédentes.

GKE Agent Sandbox remplace-t-il les fonctions serverless classiques pour l’IA ?
Non, il s’agit d’un environnement d’exécution isolé pensé spécifiquement pour du code généré dynamiquement par des agents IA, avec des garanties de sécurité et de faible latence différentes de celles d’une fonction serverless classique comme Cloud Run.

Comment réduire la facture GKE Autopilot sans dégrader les performances ?
Ajustez les requêtes de ressources au plus près de la consommation réelle observée dans Cloud Monitoring, utilisez le Vertical Pod Autoscaler en mode recommandation pour identifier le bon dimensionnement, et envisagez un engagement Compute Flexible CUD si votre charge est stable dans le temps.

Peut-on utiliser Helm avec GKE Autopilot ?
Oui, Helm fonctionne normalement sur Autopilot, à condition que les charts déployés définissent des requests et des limits explicites dans leurs valeurs. De nombreux charts publics par défaut n’en définissent pas, ce qui provoque un échec de scheduling sur Autopilot : vérifiez systématiquement le fichier values.yaml avant d’installer un chart tiers.

GKE Hypercluster est-il accessible aux petites organisations ?
Non, à ce stade GKE Hypercluster est en disponibilité générale restreinte et cible des charges d’entraînement ou d’inférence IA à très grande échelle, réparties sur plusieurs régions avec des milliers d’accélérateurs GPU ou TPU. Pour un usage courant, un cluster Autopilot régional classique couvre largement les besoins.