Module7 min de lecture

Déploiement et mise en production Kubernetes

SFEIR Institute
Formation Kubernetes : Guide Complet

Points clés

  • Rolling Update permet des mises à jour sans interruption avec rollback automatique
  • Blue-Green et Canary minimisent les risques pour les déploiements critiques
  • Helm et Kustomize standardisent la gestion des manifestes Kubernetes

Le déploiement et mise en production Kubernetes désigne l'ensemble des processus permettant de livrer, configurer et maintenir des applications conteneurisées sur un cluster Kubernetes en environnement de production.

Si vous gérez des applications cloud-native en 2026, cette expertise représente le socle indispensable pour garantir disponibilité, scalabilité et fiabilité de vos workloads.

Selon le CNCF Annual Survey 2025, 82% des organisations utilisent Kubernetes en production. Maîtriser les stratégies de déploiement vous permet de réduire drastiquement les incidents liés aux mises en production.

TL;DR : Déployer sur Kubernetes en production exige de maîtriser les stratégies de rollout (Rolling Update, Blue-Green, Canary), le GitOps (ArgoCD, FluxCD), l'autoscaling (HPA, VPA) et les pipelines CI/CD. La formation LFS458 Administration Kubernetes (4 jours, 28h) couvre ces compétences pour le CKA.

Qu'est-ce qu'un déploiement Kubernetes et pourquoi est-il critique ?

Un Deployment est un objet Kubernetes qui gère le cycle de vie des Pods applicatifs. Il définit l'état souhaité de votre application : nombre de réplicas, image conteneur, ressources allouées et stratégie de mise à jour. Kubernetes compare en permanence l'état actuel à l'état souhaité et effectue les corrections nécessaires.

Le ReplicaSet est le mécanisme sous-jacent qui maintient le nombre de Pods en fonctionnement. Vous ne manipulez généralement pas les ReplicaSets directement : le Deployment s'en charge pour vous.

Kelsey Hightower, créateur de "Kubernetes The Hard Way", compare Kubernetes à une plateforme de base sur laquelle vous construisez votre propre système de déploiement (CNCF Blog).

Voici un Deployment minimal que vous pouvez appliquer immédiatement :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-backend
  labels:
    app: api-backend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-backend
  template:
    metadata:
      labels:
        app: api-backend
    spec:
      containers:
      - name: api
        image: registry.example.com/api:v2.4.1
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"
À retenir : Définissez toujours les requests et limits de ressources. Sans eux, vos Pods peuvent être évincés sous pression mémoire ou monopoliser les ressources du nœud.

Comment choisir votre stratégie de déploiement ?

Kubernetes propose plusieurs stratégies de mise à jour. Votre choix dépend de vos contraintes métier : tolérance à l'indisponibilité, criticité des tests en production et capacité d'infrastructure.

StratégieDescriptionInterruptionRollbackCas d'usage
Rolling UpdateRemplacement progressif des PodsAucuneAutomatiqueApplications stateless standard
Blue-GreenDeux environnements parallèlesAucuneInstantanéApplications critiques, validation manuelle
CanaryDéploiement graduel par pourcentageAucuneGraduelTest A/B, validation progressive
RecreateSuppression puis recréationOuiManuelApplications stateful avec contraintes

Le Rolling Update est la stratégie par défaut. Vous configurez le comportement via maxSurge et maxUnavailable :

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 0

Consultez notre guide détaillé sur le Rolling Update Kubernetes pour approfondir cette stratégie.

Pour les applications critiques nécessitant une validation avant bascule, le Blue-Green Deployment offre une approche plus sécurisée. Vous maintenez deux environnements identiques et basculez le trafic instantanément.

Le Canary Deployment vous permet de tester une nouvelle version sur un pourcentage limité d'utilisateurs avant généralisation.

À retenir : En 2026, privilégiez le Canary pour les applications à fort trafic. Les équipes utilisant des déploiements progressifs réduisent significativement les incidents liés aux mises en production.

Comment implémenter GitOps pour vos déploiements ?

GitOps est une méthodologie où Git devient la source de vérité unique pour l'infrastructure et les applications. Vous déclarez l'état souhaité dans un repository Git, et un opérateur synchronise automatiquement le cluster.

Les deux outils dominants en 2026 sont ArgoCD et FluxCD. Notre comparatif ArgoCD vs FluxCD vous aide à choisir.

Brendan Burns, co-créateur de Kubernetes, décrit Kubernetes comme "the assembly language for Cloud Native applications" (The New Stack). GitOps transforme le déploiement en processus auditable et reproductible.

Voici comment vous configurez une Application ArgoCD :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: api-backend
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/votre-org/k8s-manifests
    targetRevision: main
    path: apps/api-backend/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true

Pour approfondir les principes et la mise en œuvre, consultez notre guide GitOps et Kubernetes.

Quelles sont les bonnes pratiques pour un pipeline CI/CD Kubernetes ?

Un pipeline CI/CD (Continuous Integration / Continuous Deployment) automatise les étapes entre le commit du code et le déploiement en production. Pour Kubernetes, vous devez intégrer la construction d'images, les tests, la mise à jour des manifests et la synchronisation du cluster.

Notre guide complet Pipeline CI/CD Kubernetes détaille chaque étape.

Selon le rapport DORA 2024, les équipes "elite performers" déploient plusieurs fois par jour tandis que les équipes à faible performance déploient moins d'une fois par mois. Ils récupèrent également plus rapidement après incident.

Structurez votre pipeline en étapes distinctes :

  1. Build : Construisez votre image avec un tag immutable (commit SHA)
  2. Test : Exécutez tests unitaires, intégration et sécurité
  3. Scan : Analysez l'image pour les vulnérabilités (Trivy, Snyk)
  4. Push : Poussez vers votre registry privé
  5. Update : Mettez à jour le manifest Kubernetes avec le nouveau tag
  6. Sync : Déclenchez la synchronisation GitOps ou appliquez directement
# Exemple de commandes CLI dans votre pipeline
# Build avec tag immutable
docker build -t registry.example.com/api:${COMMIT_SHA} .

# Scan de vulnérabilités
trivy image --severity HIGH,CRITICAL registry.example.com/api:${COMMIT_SHA}

# Push vers registry
docker push registry.example.com/api:${COMMIT_SHA}

# Mise à jour du manifest via Kustomize
cd k8s-manifests/apps/api-backend/production
kustomize edit set image api=registry.example.com/api:${COMMIT_SHA}
git commit -am "Deploy api:${COMMIT_SHA}"
git push
À retenir : N'utilisez jamais le tag latest en production. Vous perdez la traçabilité et le rollback devient impossible. Utilisez le SHA du commit ou un tag sémantique versionné.

Comment configurer l'autoscaling pour absorber la charge ?

L'autoscaling ajuste automatiquement le nombre de Pods en fonction de la charge. Kubernetes propose trois mécanismes complémentaires que vous devez comprendre.

Le HPA (Horizontal Pod Autoscaler) ajuste le nombre de réplicas. Le VPA (Vertical Pod Autoscaler) ajuste les ressources CPU/mémoire des Pods existants. Le Cluster Autoscaler ajoute ou supprime des nœuds selon les besoins.

Notre guide Autoscaling Kubernetes : HPA, VPA et scaling automatique couvre ces trois mécanismes en détail.

Configurez un HPA basé sur la CPU :

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-backend-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-backend
  minReplicas: 3
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 10
        periodSeconds: 60

Selon Google Kubernetes Engine Best Practices 2026, vous devez toujours définir un stabilizationWindowSeconds pour le scale-down afin d'éviter les oscillations.

Quels outils pour gérer vos manifests Kubernetes ?

Vous avez deux approches principales pour gérer la complexité des manifests : Helm et Kustomize. Chacune répond à des besoins différents.

Helm est un gestionnaire de packages. Vous utilisez des templates paramétrables et des valeurs par environnement. Il excelle pour les applications tierces et les déploiements standardisés.

Kustomize est un outil de personnalisation sans template. Vous superposez des patches sur des manifests de base. Il est natif à kubectl depuis la version 1.14.

Notre comparatif Helm vs Kustomize vous guide dans votre choix.

CritèreHelmKustomize
ComplexitéModérée (Go templates)Faible (YAML natif)
RéutilisationCharts partagésBases + overlays
ÉcosystèmeArtifact Hub (15 000+ charts)Composants natifs
GitOpsVia ArgoCD/FluxNatif kubectl
Cas d'usageApps tierces, standardsApps internes, customisation

Pour une vue exhaustive des stratégies, consultez notre tableau comparatif des stratégies de déploiement.

Quelles vérifications avant la mise en production ?

Avant de déployer en production, vous devez valider systématiquement plusieurs points critiques. Notre Checklist de mise en production détaille 15 bonnes pratiques essentielles.

Validez vos ressources : Chaque conteneur doit définir requests et limits. Utilisez kubectl describe node pour vérifier la pression sur vos nœuds.

Configurez les probes : Les liveness et readiness probes permettent à Kubernetes de gérer correctement le cycle de vie de vos Pods.

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 15
  periodSeconds: 10
readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5

Préparez le rollback : Vérifiez que vous pouvez revenir à la version précédente avec kubectl rollout undo deployment/api-backend.

Testez le monitoring : Assurez-vous que vos métriques et alertes sont configurées avant le déploiement. Consultez notre hub Monitoring et dépannage Kubernetes pour les bonnes pratiques.

À retenir : Un rollback rapide est critique pour limiter l'impact des incidents. Préparez vos runbooks et testez la procédure de rollback avant la mise en production.

Comment diagnostiquer et résoudre les problèmes de déploiement ?

Les erreurs de déploiement sont inévitables. Vous devez savoir les diagnostiquer rapidement.

Les causes les plus fréquentes selon notre guide de résolution des erreurs de déploiement :

  1. ImagePullBackOff : L'image n'existe pas ou les credentials sont incorrects
  2. CrashLoopBackOff : L'application crash au démarrage
  3. Pending : Ressources insuffisantes sur le cluster
  4. OOMKilled : Limite mémoire dépassée

Commandes de diagnostic essentielles :

# État du déploiement
kubectl rollout status deployment/api-backend

# Événements du Pod
kubectl describe pod api-backend-xyz

# Logs du conteneur
kubectl logs -f deployment/api-backend --all-containers

# Historique des révisions
kubectl rollout history deployment/api-backend

Pour des retours d'expérience concrets, consultez notre article Retour d'expérience : migration vers Kubernetes en production.

Notre hub Tutoriels et guides pratiques Kubernetes propose également des exercices hands-on.

Passez à l'action : formez-vous au déploiement Kubernetes

Vous maîtrisez maintenant les concepts fondamentaux du déploiement Kubernetes en production. Pour aller plus loin et obtenir une certification reconnue, SFEIR Institute propose des formations officielles Linux Foundation.

La formation LFS458 Administration Kubernetes vous prépare à la certification CKA. Vous apprendrez à configurer, gérer et dépanner des clusters en conditions réelles sur 4 jours intensifs.

Pour les développeurs, la formation LFD459 Kubernetes pour les développeurs couvre en 3 jours les compétences de déploiement applicatif nécessaires au CKAD.

Si vous débutez, la formation Kubernetes les fondamentaux vous donne les bases en une journée.

Rapprochez-vous de votre OPCO pour explorer les possibilités de financement. Contactez nos conseillers pour construire votre parcours de certification.

Consultez notre Formation Kubernetes : Guide Complet pour découvrir l'ensemble des parcours disponibles.

Guides et tutoriels de cette section

Pour approfondir le déploiement et la mise en production Kubernetes, explorez ces ressources :