Comment déployer une app sur GKE en 2026 (Tutoriel)

Introduction

Google Kubernetes Engine (GKE) est le service managé de Google Cloud pour orchestrer des conteneurs avec Kubernetes. Il simplifie la gestion des clusters en gérant la mise à jour, la scalabilité et la sécurité, vous permettant de vous concentrer sur votre code. Pourquoi GKE en 2026 ? Avec l'essor des microservices et de l'IA, les apps cloud-native exigent une orchestration robuste. Ce tutoriel beginner vous guide pour créer un cluster, déployer une app Nginx simple, l'exposer via un service et la scaler. À la fin, vous maîtriserez les bases pour des déploiements production-ready. Imaginez Kubernetes comme un chef d'orchestre : GKE est le théâtre qui s'occupe des lumières et du son. (128 mots)

Prérequis

Un compte Google Cloud Platform (GCP) gratuit avec facturation activée.
Terminal avec gcloud CLI et kubectl installés (instructions ci-dessous).
Connaissances basiques de Docker et YAML.
Région GCP activée (ex: us-central1).

Installer gcloud et kubectl

install-tools.sh

#!/bin/bash

# Télécharger et installer gcloud CLI (édition 2026)
curl https://sdk.cloud.google.com | bash
exec -l $SHELL

gcloud init

gcloud components install kubectl

gcloud components update

Ce script installe la CLI gcloud et kubectl, essentiels pour interagir avec GKE. Exécutez-le une seule fois. Piège : Vérifiez votre PATH après installation avec gcloud version pour éviter les erreurs 'command not found'.

Authentification GCP

Avant de créer un cluster, authentifiez-vous et configurez votre projet. Cela génère un token OAuth pour les API GCP.

S'authentifier et configurer le projet

auth-gcp.sh

#!/bin/bash

# Authentification interactive
gcloud auth login

# Lister les projets disponibles
gcloud projects list

# Définir le projet (remplacez PROJECT_ID par le vôtre)
gcloud config set project mon-projet-gke-2026

gcloud config list

Ces commandes vous connectent à GCP et sélectionnent votre projet. Copiez l'ID de projet depuis la console GCP. Attention : Sans facturation activée, les clusters GKE échouent silencieusement.

Créer le cluster GKE

create-cluster.sh

#!/bin/bash

# Créer un cluster standard (3 nœuds, machine e2-medium)
gcloud container clusters create mon-cluster-gke \
    --zone=us-central1-a \
    --num-nodes=3 \
    --machine-type=e2-medium \
    --enable-ip-alias

# Obtenir les credentials kubectl pour ce cluster
gcloud container clusters get-credentials mon-cluster-gke --zone=us-central1-a

# Vérifier la connexion
kubectl get nodes

Ce script provisionne un cluster managé prêt en 5-10 minutes. --enable-ip-alias active le networking VPC-native pour la scalabilité. Piège : Changez la zone si indisponible ; vérifiez avec kubectl get nodes que les 3 nœuds sont 'Ready'.

Déployer l'application

Maintenant, déployons un pod Nginx via un Deployment Kubernetes. C'est le cœur de l'orchestration : réplication, rolling updates et self-healing.

Créer le Deployment Nginx

nginx-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.27-alpine
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"

Ce manifeste YAML crée 2 replicas de Nginx avec limites de ressources pour éviter les OOMKills. Copiez-le dans un fichier et appliquez-le. Analogie : Comme un blueprint pour des clones identiques de votre conteneur.

Appliquer le Deployment

apply-deployment.sh

#!/bin/bash

# Créer le fichier YAML (ou copiez manuellement)
cat > nginx-deployment.yaml << EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.27-alpine
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"
EOF

# Appliquer le Deployment
kubectl apply -f nginx-deployment.yaml

# Vérifier le statut
kubectl get deployments
kubectl get pods

Applique le YAML et vérifie les pods en 'Running'. Piège : Si image pull échoue, vérifiez le registry public ; utilisez kubectl describe pod pour debug.

Exposer l'application

Pour accéder à Nginx depuis l'extérieur, créez un Service LoadBalancer. GKE provisionne automatiquement une IP externe.

Créer le Service LoadBalancer

nginx-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
  selector:
    app: nginx

Ce Service route le trafic externe vers les pods Nginx. Type LoadBalancer est idéal pour GKE (gratuit pour ingress basique). Astuce : L'IP apparaît après kubectl get svc.

Appliquer le Service et tester

apply-service.sh

#!/bin/bash

# Appliquer le Service
kubectl apply -f nginx-service.yaml

# Attendre l'IP externe (1-2 min)
kubectl get services nginx-service

# Récupérer l'IP
EXTERNAL_IP=$(kubectl get service nginx-service -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
echo "IP externe: $EXTERNAL_IP"

# Tester avec curl (ou navigateur)
curl http://$EXTERNAL_IP

# Port-forward alternatif pour test local
kubectl port-forward service/nginx-service 8080:80

Expose l'app publiquement et teste la connectivité. Port-forward est parfait pour dev sans IP publique. Piège : Firewall GCP bloque par défaut ; autorisez le port 80 via console.

Scaler l'application

scale-app.sh

#!/bin/bash

# Scaler à 5 replicas
kubectl scale deployment nginx-deployment --replicas=5

# Vérifier les nouveaux pods
kubectl get pods -w

# Autoscaling HPA (optionnel, pour prod)
cat > hpa.yaml << EOF
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
EOF
kubectl apply -f hpa.yaml
kubectl get hpa

Scale manuellement ou auto avec HPA sur CPU. -w watch en temps réel. Avantage GKE : Cluster autosize gère les nœuds automatiquement.

Bonnes pratiques

Utilisez des namespaces : kubectl create namespace prod pour isoler les environnements.
Limitez les ressources : Toujours définir requests/limits pour éviter les noisy neighbors.
Activez Workload Identity : Pour la sécurité des pods sans clés Service Account.
Surveillez avec Cloud Monitoring : Intégré à GKE, activez-le via console.
Utilisez des Images vulnérabilité-scannées : Avec Artifact Registry.

Erreurs courantes à éviter

Oublier get-credentials : kubectl ne voit pas le cluster.
Quota GCP épuisé : Vérifiez limits dans console avant create.
Pods Pending : Image non-public ou nœuds insuffisants (scale cluster).
IP LoadBalancer non-assignée : Attendez 2-5 min ou utilisez Ingress.

Pour aller plus loin

Maîtrisez Helm pour les charts complexes, Istio pour le service mesh, ou Anthos pour multi-cloud. Découvrez nos formations Learni sur Kubernetes et GKE pour un parcours certifiant CKA/CKAD.

Comment déployer une app sur Google Kubernetes Engine (GKE) en 2026