Déployer un cluster Google Kubernetes Engine (GKE) — Standard ou Autopilot, zonal ou régional — exposer une application via un Service LoadBalancer et un Ingress, comprendre Workload Identity et le coût du management fee. Tutoriel pas-à-pas du cluster Associate Cloud Engineer.

📍 Article principal du cluster : Devenir Google Cloud Associate Cloud Engineer (ACE) — Guide complet 2026
Cet article fait partie du cluster « GCP ACE ». Pour la vue d’ensemble, lire d’abord le pilier.

Introduction

Google Kubernetes Engine est la plateforme Kubernetes managée de Google Cloud — l’origine de Kubernetes a d’ailleurs été codée par les ingénieurs Google avant d’être donnée à la CNCF. À l’examen ACE, GKE pèse lourd dans le domaine 2 (Plan and implement). On attend que vous sachiez choisir entre Standard et Autopilot, entre cluster zonal et régional, déployer une première application, l’exposer via un Service ou un Ingress, et configurer Workload Identity pour que les pods accèdent aux APIs GCP sans clés JSON. Ce tutoriel couvre tout cela avec des commandes gcloud et kubectl validées sur la doc officielle d’avril 2026.

Prérequis

Compte GCP Free Trial actif et projet lab-ace-2026.
VPC vpc-lab avec le subnet subnet-app-eu9 en europe-west9.
gcloud CLI configuré + kubectl installé (livré avec gcloud, ou via gcloud components install kubectl).
Notions de base Kubernetes (Pod, Deployment, Service). Si vous démarrez de zéro, prévoyez 1h supplémentaire.
Niveau attendu : intermédiaire en cloud, débutant en GKE.
Temps estimé : 120 minutes pour suivre toutes les étapes.

Étape 1 — Standard vs Autopilot

GKE propose deux modes d’opération qui changent radicalement votre rapport au cluster. La doc officielle est explicite : Autopilot manages the entire underlying infrastructure of clusters, including the control plane, nodes, and all system components. En Standard, Google gère uniquement le plan de contrôle ; vous administrez vous-même les nœuds (taille, nombre, mises à jour, scaling).

Autopilot. Vous payez par pod (CPU + mémoire + ressources éphémères) sans vous soucier des nœuds. Idéal pour les charges petites à moyennes, les équipes qui veulent éviter l’ops d’infrastructure, et la plupart des applications stateless. Inconvénient : moins de flexibilité sur les types de machines, certaines features Kubernetes restreintes (privileged containers, hostNetwork, etc.).

Standard. Vous payez les nœuds (VMs Compute Engine sous-jacentes) plus le management fee du plan de contrôle. Vous avez le contrôle total : choix de la machine, autoscaler, Daemonsets privilégiés, GPU sur des node pools dédiés. Plus économique à grande échelle, plus exigeant en ops.

À l’examen, retenez : Autopilot pour la simplicité opérationnelle, Standard pour le contrôle et les charges spécialisées. Une question piège : « la startup veut le minimum d’ops sur leur cluster » → Autopilot. « L’équipe DevOps veut tunnnel les types de machines pour optimiser » → Standard.

Étape 2 — Zonal vs régional

Un cluster zonal a son plan de contrôle dans une seule zone. Si la zone tombe, le plan de contrôle devient inaccessible (les nœuds peuvent continuer à servir le trafic existant un certain temps, mais aucune nouvelle action de management n’est possible). Coût d’un cluster zonal : un seul plan de contrôle facturé. Pour le free tier GKE, le management fee de votre premier cluster zonal Standard est généralement compensé par le crédit mensuel inclus dans le compte de facturation — vérifiez les conditions exactes sur la page tarification.

Un cluster régional réplique le plan de contrôle sur trois zones de la région et peut placer ses nœuds sur trois zones également. Résilient à la perte d’une zone entière. Coût : trois fois le management fee. Pour la production, c’est presque toujours le bon choix. Pour un lab d’apprentissage ACE, un zonal suffit largement et économise des dollars.

Étape 3 — Créer un cluster Autopilot

Autopilot est plus simple à démarrer : une seule commande, pas de node pool à dimensionner. Démarrons par lui pour minimiser la complexité.

gcloud container clusters create-auto cluster-ace \
  --region=europe-west9 \
  --network=vpc-lab \
  --subnetwork=subnet-app-eu9 \
  --release-channel=stable \
  --project=lab-ace-2026

# Recuperer les credentials kubectl
gcloud container clusters get-credentials cluster-ace \
  --region=europe-west9 \
  --project=lab-ace-2026

# Verifier la connexion
kubectl get nodes
kubectl cluster-info

La création prend 5 à 10 minutes. Le cluster Autopilot est régional par défaut — vous ne pouvez pas créer un Autopilot zonal. Le release channel stable reçoit les nouvelles versions Kubernetes plus tard que regular ou rapid mais avec moins de risque de régression. Pour la production, stable est le bon choix ; pour de l’expérimentation, rapid.

Étape 4 — Déployer une première application

Application web de test : un Deployment Nginx avec 3 réplicas, exposé via un Service LoadBalancer.

cat <<'EOF' | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-nginx
spec:
  replicas: 3
  selector:
    matchLabels: {app: web-nginx}
  template:
    metadata:
      labels: {app: web-nginx}
    spec:
      containers:
      - name: nginx
        image: nginx:1.27-alpine
        ports:
        - containerPort: 80
        resources:
          requests: {cpu: "100m", memory: "128Mi"}
          limits: {cpu: "500m", memory: "256Mi"}
---
apiVersion: v1
kind: Service
metadata:
  name: web-nginx-svc
spec:
  type: LoadBalancer
  selector: {app: web-nginx}
  ports:
  - port: 80
    targetPort: 80
EOF

# Suivre le deploiement
kubectl get pods -w
kubectl get svc web-nginx-svc

# Recuperer l'IP publique du LoadBalancer (delai ~2 min)
EXTERNAL_IP=$(kubectl get svc web-nginx-svc -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
curl -I http://$EXTERNAL_IP

Sur Autopilot, les requests sont importantes : c’est sur cette base que Google facture les pods. Si vous omettez les requests, Google les inférera, mais autant rester explicite. Le Service LoadBalancer demande à GCP de provisionner un Network Load Balancer régional avec une IP publique, ce qui prend une à deux minutes. Pour exposer plusieurs services HTTP/HTTPS sur la même IP publique avec routage par chemin/domaine, utilisez plutôt un Ingress.

Étape 5 — Exposer via Ingress et HTTPS

Un Ingress GKE crée un Application Load Balancer global avec terminaison TLS gérée par Google. Pratique pour exposer plusieurs services sur un même hostname.

cat <<'EOF' | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
  annotations:
    kubernetes.io/ingress.class: "gce"
    networking.gke.io/managed-certificates: cert-web
spec:
  rules:
  - host: app.exemple.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service: {name: web-nginx-svc, port: {number: 80}}
---
apiVersion: networking.gke.io/v1
kind: ManagedCertificate
metadata:
  name: cert-web
spec:
  domains:
  - app.exemple.com
EOF

L’Ingress GCE provisionne un Application Load Balancer global et un certificat managé Google Cloud après vérification du domaine. La validation du certificat managé peut prendre 15 à 60 minutes — c’est normal et c’est le délai officiel. En attendant, le LB sert le trafic HTTP. Pointez le DNS de votre domaine vers l’IP du LB avant de lancer la création du certificat sinon la validation échoue.

Étape 6 — Workload Identity pour accéder aux APIs GCP

Pour qu’un pod accède à Cloud Storage, BigQuery ou Pub/Sub, n’embarquez jamais une clé JSON de service account dans une image Docker. La méthode propre est Workload Identity, qui mappe un Kubernetes Service Account (KSA) à un Google Service Account (GSA). Les pods obtiennent les credentials de courte durée automatiquement.

# Creer le GSA et lui donner roles/storage.objectViewer
gcloud iam service-accounts create gsa-app
GSA="gsa-app@lab-ace-2026.iam.gserviceaccount.com"
gcloud projects add-iam-policy-binding lab-ace-2026 \
  --member="serviceAccount:$GSA" \
  --role="roles/storage.objectViewer"

# Creer le KSA et le binder au GSA
kubectl create serviceaccount ksa-app
gcloud iam service-accounts add-iam-policy-binding $GSA \
  --role=roles/iam.workloadIdentityUser \
  --member="serviceAccount:lab-ace-2026.svc.id.goog[default/ksa-app]"

# Annoter le KSA pour activer Workload Identity
kubectl annotate serviceaccount ksa-app \
  iam.gke.io/gcp-service-account=$GSA

Les pods qui spécifient serviceAccountName: ksa-app hériteront automatiquement de l’identité GSA et pourront appeler les APIs GCP avec ses permissions, sans clé JSON. C’est le pattern recommandé en 2026 ; toutes les nouvelles applications GKE doivent partir de là.

Étape 7 — Cluster Standard avec node pool dédié

Pour comprendre l’autre mode, créons un cluster Standard avec un node pool e2-medium. Cela vous permet de comparer les deux expériences.

gcloud container clusters create cluster-ace-std \
  --zone=europe-west9-b \
  --num-nodes=2 \
  --machine-type=e2-medium \
  --release-channel=stable \
  --enable-ip-alias \
  --network=vpc-lab \
  --subnetwork=subnet-app-eu9

# Ajouter un node pool dedie a des charges memoire
gcloud container node-pools create np-mem \
  --cluster=cluster-ace-std \
  --zone=europe-west9-b \
  --machine-type=n2-highmem-2 \
  --num-nodes=1 \
  --node-taints=workload=memory:NoSchedule

Le taint workload=memory:NoSchedule empêche les pods génériques de se déployer sur le node pool memory. Seuls les pods avec une toleration correspondante y seront placés. C’est le pattern standard pour isoler des charges sensibles à la mémoire.

Étape 8 — Cleanup obligatoire

# Detruire les ressources Kubernetes
kubectl delete ingress web-ingress
kubectl delete managedcertificate cert-web
kubectl delete svc web-nginx-svc
kubectl delete deployment web-nginx
kubectl delete serviceaccount ksa-app

# Detruire les clusters (le plus couteux)
gcloud container clusters delete cluster-ace --region=europe-west9 --quiet
gcloud container clusters delete cluster-ace-std --zone=europe-west9-b --quiet

# Supprimer le GSA
gcloud iam service-accounts delete $GSA --quiet

Le plus important du tutoriel : ne laissez JAMAIS un cluster GKE tourner inutilement. Le management fee est de 0,10 USD/heure (soit environ 73 USD par mois) pour un cluster Standard hors free tier, et le coût Autopilot des pods s’accumule en continu. Un cluster oublié 7 jours coûte facilement 25-30 USD.

Erreurs fréquentes

Erreur	Cause	Solution
Cluster oublié, facture 50 USD	Pas de cleanup	Toujours `gcloud container clusters delete` en fin de session.
kubectl ne trouve pas le cluster	Credentials kubectl non récupérées	`gcloud container clusters get-credentials` obligatoire après création.
Service LoadBalancer pending IP	Région n’a pas de quota LB ou pas d’IP libre	Vérifier les quotas. Patienter 2-3 min.
Ingress certificat ne devient pas Active	DNS pas pointé vers l’IP du LB	Configurer le DNS d’abord, le certificat managé valide ensuite (15-60 min).
Workload Identity ne marche pas	Annotation KSA manquante ou binding GSA mal configuré	Vérifier l’annotation ET le membership `serviceAccount:PROJECT.svc.id.goog[NS/KSA]`.
Pod en CrashLoopBackOff Autopilot	Resources requests trop petites ou trop grandes	Ajuster requests selon vraie charge ; consulter les logs `kubectl logs`.
Cluster zonal soudain inaccessible	Panne de zone (rare mais possible)	Pour la production, toujours régional.

Adaptation au contexte ouest-africain

Coût et lab. Pour 90 jours de prépa ACE, créez et détruisez le cluster à chaque session de lab. Un cluster Autopilot avec 1 ou 2 pods de test pendant 2 heures coûte moins de 1 USD ; le laisser tourner toute une nuit en oubliant pèse plus lourd. Le crédit Free Trial supporte plusieurs dizaines d’heures de cluster cumulées sans problème.

Hébergement d’apps PME. Pour une app SaaS sénégalaise avec ~5000 utilisateurs actifs/jour, un cluster Autopilot régional en europe-west9 est suffisant et tient en 50-100 USD/mois côté pods. Plus de zones de disponibilité que ce qu’un VPS Hetzner ou OVH unique peut offrir, mais à un prix légèrement supérieur — arbitrage à faire selon les exigences SLA.

CI/CD depuis GitHub Actions. Pour des équipes africaines distribuées qui poussent du code depuis Dakar, Abidjan, Ouagadougou, Workload Identity Federation pour GitHub Actions est indispensable : pas de clé JSON à stocker, audit clean, rotation automatique. Voir le tutoriel IAM pour la mise en place côté GCP.

Tutoriels frères

Compute Engine : déployer une VM Linux et Windows — l’alternative aux conteneurs pour les charges qui ne sont pas prêtes pour Kubernetes.
IAM GCP : utilisateurs, rôles, service accounts, MFA — la base de Workload Identity.

Pour aller plus loin

🔝 Retour au pilier : Devenir Google Cloud Associate Cloud Engineer (ACE) — Guide complet 2026
Doc GKE architecture : cloud.google.com/kubernetes-engine/docs/concepts/cluster-architecture
GKE pricing officielle : cloud.google.com/kubernetes-engine/pricing
Workload Identity : cloud.google.com/kubernetes-engine/docs/how-to/workload-identity
Suggestion suivante : Cloud SQL Postgres + monitoring et alertes facturation

FAQ

Autopilot ou Standard pour mon premier cluster ?
Autopilot. Il enlève la quasi-totalité du travail d’ops : pas de gestion de nœuds, pas de tuning de l’autoscaler, pas de mises à jour à orchestrer. Vous économisez du temps de cerveau pour vous concentrer sur l’application. Migrez vers Standard plus tard si vous avez besoin de contrôle fin.

Le management fee est-il vraiment compensé par le free tier ?
Pour le premier cluster zonal Standard, généralement oui — le crédit mensuel inclus dans tout compte de facturation couvre approximativement le management fee d’un cluster zonal. Pour un cluster régional ou un deuxième cluster, vous payez la totalité. Vérifiez sur la page de tarification GKE pour les conditions exactes.

Régional ou zonal pour la production ?
Régional sans hésiter. Coût trois fois supérieur sur le management fee, mais résilience à la panne d’une zone. Sur une charge sérieuse avec un SLA contractuel, le delta de coût est négligeable.

Workload Identity ou clé JSON pour mes pods ?
Workload Identity. C’est la méthode officielle recommandée et c’est aussi la bonne réponse à l’examen. Les clés JSON dans les pods sont un anti-pattern qui pénalise au quiz et en production.

Combien de pods peut accueillir un cluster Autopilot ?
Plusieurs milliers, mais en pratique vous serez limité par le quota de votre projet GCP. Pour un lab ACE, deux ou trois Deployments avec quelques réplicas chacun sont largement suffisants pour explorer toutes les notions.

Mots-clés : GKE, Google Kubernetes Engine, Autopilot, cluster zonal régional, Workload Identity, kubectl, Service LoadBalancer, Ingress GCE, ACE certification Kubernetes

GKE : cluster Kubernetes managé pas-à-pas — tutoriel ACE 2026