FAQ déploiement Kubernetes : réponses aux questions les plus fréquentes

Cette FAQ déploiement Kubernetes rassemble les questions fréquentes déploiement Kubernetes posées par les équipes en production. De la stratégie de rolling update aux outils GitOps, trouvez des réponses déploiement Kubernetes entreprise validées par des praticiens.

TL;DR

Les questions les plus courantes concernent le choix des stratégies de déploiement, la gestion des rollbacks, la configuration CI/CD, et la sécurisation des secrets. Chaque réponse inclut des exemples de configuration et des références aux bonnes pratiques.

Ce sujet est couvert dans la formation LFS458 Administration Kubernetes.

Selon le rapport CNCF Annual Survey 2025, 82% des utilisateurs de conteneurs exécutent Kubernetes en production. Cette adoption massive génère de nombreuses questions pratiques.

Quelle stratégie de déploiement choisir selon la FAQ déploiement Kubernetes ?

La stratégie dépend de votre tolérance aux risques et de vos contraintes techniques. Kubernetes supporte nativement deux stratégies :

Configuration RollingUpdate :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

À retenir : maxUnavailable: 0 garantit qu'aucun Pod n'est indisponible pendant la mise à jour. Le coût est un Pod supplémentaire temporaire (maxSurge: 1).

Le guide stratégies de déploiement Kubernetes détaille chaque approche avec des tableaux comparatifs.

Pour le Rolling Update Kubernetes, consultez notre guide dédié.

Comment effectuer un rollback après un déploiement raté ?

Kubernetes conserve l'historique des révisions de chaque Deployment. Le rollback est une opération native.

Vérifiez l'historique :

kubectl rollout history deployment/my-app

Sortie :

REVISION  CHANGE-CAUSE
1         Initial deployment
2         Update image to v2.0.0
3         Update image to v2.1.0 (current)

Rollback vers la révision précédente :

kubectl rollout undo deployment/my-app

Rollback vers une révision spécifique :

kubectl rollout undo deployment/my-app --to-revision=1

Vérifiez le statut :

kubectl rollout status deployment/my-app

À retenir : Par défaut, Kubernetes conserve 10 révisions (revisionHistoryLimit). Augmentez cette valeur pour les applications critiques.

spec:
  revisionHistoryLimit: 20

La FAQ Formation Kubernetes répond à d'autres questions sur les fonctionnalités de base.

Quel outil CI/CD utiliser pour déployer sur Kubernetes ?

Cette question revient fréquemment dans la FAQ Kubernetes production. Le choix dépend de votre infrastructure existante.

Selon CNCF End User Survey 2025, ArgoCD détient 60% du marché GitOps. L'intégration CI/CD vers GitOps est une tendance forte.

Exemple pipeline GitHub Actions :

name: Deploy to Kubernetes
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build and push image
        run: |
          docker build -t my-registry/app:${{ github.sha }} .
          docker push my-registry/app:${{ github.sha }}
      - name: Update GitOps repo
        run: |
          cd k8s-config
          kustomize edit set image my-registry/app:${{ github.sha }}
          git commit -am "Deploy ${{ github.sha }}"
          git push

Le guide pipeline CI/CD pour Kubernetes propose une implémentation complète.

Comment gérer plusieurs environnements (dev, staging, prod) ?

Utilisez Kustomize ou Helm avec des overlays par environnement. Cette approche garantit la cohérence tout en permettant les variations.

Structure Kustomize recommandée :

├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
├── overlays/
│   ├── dev/
│   │   ├── kustomization.yaml
│   │   └── replicas-patch.yaml
│   ├── staging/
│   │   └── kustomization.yaml
│   └── prod/
│       ├── kustomization.yaml
│       └── resources-patch.yaml

Overlay de production :

# overlays/prod/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../base
replicas:
  - name: my-app
    count: 5
patches:
  - path: resources-patch.yaml
images:
  - name: my-app
    newTag: v2.1.0-stable

À retenir : Les overlays permettent de modifier replicas, resources, et images sans dupliquer les manifestes de base.

Consultez gestion multi-environnements Kubernetes pour les patterns avancés.

Comment sécuriser les secrets dans les déploiements Kubernetes ?

Ne stockez jamais de secrets en clair dans Git. Plusieurs solutions existent pour la FAQ déploiement Kubernetes sécurisé :

Configuration External Secrets Operator :

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: my-secret
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: ClusterSecretStore
  target:
    name: my-secret
  data:
    - secretKey: password
      remoteRef:
        key: prod/my-app/credentials
        property: password

L'opérateur synchronise automatiquement les secrets depuis le provider externe.

À retenir : External Secrets Operator est la solution recommandée pour les environnements multi-cloud et les intégrations Vault existantes.

La page Qualiopi Kubernetes explique le cadre de formation certifiée.

Comment surveiller l'état des déploiements en production ?

Combinez les métriques Kubernetes natives avec un stack d'observabilité. Les éléments essentiels :

# État des Deployments
kubectl get deployments -A
kubectl rollout status deployment/my-app

# Événements récents
kubectl get events --sort-by='.lastTimestamp' -n production

# Métriques des Pods
kubectl top pods -n production

Métriques Prometheus recommandées :

# Taux de Pods non-ready
sum(kube_deployment_status_replicas_unavailable) by (deployment)

# Temps depuis le dernier déploiement
time() - max(kube_deployment_created) by (deployment)

# Redémarrages de conteneurs
sum(increase(kube_pod_container_status_restarts_total[1h])) by (pod)

Comme le conseille TealHQ : « Don't let your knowledge remain theoretical - set up a real Kubernetes environment to solidify your skills. »

Le hub déploiement et mise en production Kubernetes centralise les ressources sur ce sujet.

Quelle est la différence entre Deployment, StatefulSet et DaemonSet ?

Chaque ressource répond à un besoin spécifique :

Exemple StatefulSet pour une base de données :

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: postgres
  replicas: 3
  selector:
    matchLabels:
      app: postgres
  template:
    spec:
      containers:
        - name: postgres
          image: postgres:16
          volumeMounts:
            - name: data
              mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 10Gi

À retenir : StatefulSet garantit que postgres-0 redémarre toujours avec le même PVC, préservant les données.

Comment configurer les health checks pour des déploiements fiables ?

Les probes Kubernetes détectent les problèmes et automatisent les actions correctives.

Configuration recommandée :

spec:
  containers:
    - name: app
      image: my-app:v1
      ports:
        - containerPort: 8080
      startupProbe:
        httpGet:
          path: /healthz
          port: 8080
        failureThreshold: 30
        periodSeconds: 10
      livenessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 0
        periodSeconds: 10
        failureThreshold: 3
      readinessProbe:
        httpGet:
          path: /ready
          port: 8080
        initialDelaySeconds: 0
        periodSeconds: 5
        failureThreshold: 3

À retenir : startupProbe est essentiel pour les applications lentes à démarrer. Sans lui, livenessProbe peut tuer le Pod avant qu'il ne soit prêt.

Le guide GitOps et Kubernetes explique comment intégrer ces configurations dans un workflow déclaratif.

Comment limiter l'impact d'un déploiement avec PodDisruptionBudget ?

PodDisruptionBudget (PDB) garantit une disponibilité minimale pendant les opérations de maintenance.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: my-app

Cette configuration garantit qu'au maximum 1 Pod peut être indisponible simultanément lors des évictions (scale-down, node drain, upgrades).

Pour les applications critiques avec 3 réplicas minimum :

spec:
  minAvailable: 2

À retenir : PDB protège contre les évictions volontaires. Il ne protège pas contre les crashs applicatifs.

Le comparatif des outils CI/CD pour Kubernetes intègre ces bonnes pratiques.

Passez à l'action : formez-vous aux déploiements Kubernetes

Comme l'indique Hired CTO via Splunk : « Demand and salaries for highly-skilled and qualified tech talent are fiercer than ever, and certifications present a clear pathway for IT professionals to further their careers. »

Pour maîtriser les déploiements Kubernetes :

• La formation LFS458 Administration Kubernetes couvre toutes ces thématiques sur 4 jours et prépare à la certification CKA
• La formation LFD459 pour développeurs se concentre sur les patterns applicatifs
• Pour débuter, découvrez Kubernetes, les fondamentaux

Contactez nos conseillers pour définir votre parcours de formation.