Bonnes pratiques Kubernetes en production : la checklist complète

Vous déployez Kubernetes en production ? Avec 82% des utilisateurs de conteneurs qui exécutent Kubernetes en production en 2025, les bonnes pratiques kubernetes en production ne sont plus optionnelles.

Elles déterminent la différence entre un cluster stable et des incidents à 3h du matin.

Kubernetes est le système d'orchestration de conteneurs qui automatise le déploiement, la mise à l'échelle et la gestion des applications conteneurisées. Ce guide vous présente les recommandations essentielles pour optimiser vos clusters, validées par les organisations qui gèrent en moyenne 20+ clusters en production.

TL;DR : Cette checklist couvre 10 bonnes pratiques indispensables : images optimisées, ressources limitées, probes configurées, namespaces isolés, RBAC strict, network policies, monitoring centralisé, GitOps, secrets chiffrés, et stratégies de déploiement maîtrisées. Appliquez-les systématiquement pour éviter 80% des incidents courants.

Ces compétences sont au cœur de la formation LFS458 Administration Kubernetes.

---

Pourquoi ces bonnes pratiques sont-elles critiques pour votre production ?

Quelles sont les bonnes pratiques kubernetes en production ? Cette question guide chaque équipe DevOps qui migre vers le cloud-native. Selon Spectro Cloud, 80% des organisations exécutent désormais Kubernetes en production. Pourtant, la complexité opérationnelle reste le défi majeur.

À retenir : 71 % des entreprises Fortune 100 utilisent Kubernetes en production. Ces organisations appliquent des pratiques rigoureuses que vous devez adopter pour atteindre leur niveau de fiabilité.

Explorons maintenant chaque pratique en détail. Pour une vue d'ensemble des concepts fondamentaux, consultez notre Formation Kubernetes : Guide Complet.

---

1. Optimisez vos images conteneur pour réduire la surface d'attaque

Pourquoi c'est essentiel : Les images volumineuses augmentent les temps de déploiement, consomment plus de stockage, et élargissent votre surface d'attaque. Chaque binaire inutile représente une vulnérabilité potentielle que vous devez éliminer.

Comment procéder :

1. Utilisez des images de base minimales. Une image Alpine pèse ~3MB contre ~70MB pour Ubuntu.
2. Appliquez les builds multi-stage. Vous pouvez réduire vos images de 800MB à 15-30MB.
3. Visez des images inférieures à 200MB pour vos microservices.

# Build stage
FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o myapp

# Production stage
FROM alpine:3.19
RUN adduser -D -u 1000 appuser
USER appuser
COPY --from=builder /app/myapp /myapp
ENTRYPOINT ["/myapp"]

Pour approfondir cette pratique, consultez notre guide Optimiser un Dockerfile pour Kubernetes.

À retenir : Scannez systématiquement vos images avec Trivy ou Grype avant chaque déploiement. Intégrez ce scan dans votre pipeline CI/CD.

---

2. Définissez des limites et requests de ressources strictes

Pourquoi c'est essentiel : Sans limites de ressources, un pod défaillant peut consommer toutes les ressources du node et impacter vos autres workloads. Vous risquez des effets de cascade sur l'ensemble de votre cluster.

Comment procéder :

apiVersion: v1
kind: Pod
metadata:
  name: application-prod
spec:
  containers:
  - name: app
    image: myapp:1.2.3
    resources:
      requests:
        memory: "256Mi"
        cpu: "250m"
      limits:
        memory: "512Mi"
        cpu: "500m"

Appliquez ces règles :

• Requests = consommation moyenne observée de votre application
• Limits = 1.5x à 2x les requests pour absorber les pics
• Configurez des LimitRanges par namespace pour imposer des valeurs par défaut

Consultez notre Aide-mémoire Docker et Kubernetes pour les commandes de diagnostic rapide.

---

3. Configurez des probes de santé adaptées à votre application

Pourquoi c'est essentiel : Kubernetes ne peut pas deviner si votre application fonctionne correctement. Les probes permettent de détecter les défaillances et de rediriger le trafic automatiquement.

Comment configurer vos trois types de probes :

apiVersion: v1
kind: Pod
metadata:
  name: app-with-probes
spec:
  containers:
  - name: app
    image: myapp:1.2.3
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 10
      failureThreshold: 3
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5
    startupProbe:
      httpGet:
        path: /healthz
        port: 8080
      failureThreshold: 30
      periodSeconds: 10

LivenessProbe détecte si votre conteneur est bloqué. ReadinessProbe indique si vous êtes prêt à recevoir du trafic. StartupProbe gère les applications à démarrage lent.

À retenir : Ne pointez jamais votre livenessProbe vers une dépendance externe (base de données, API tierce). Un timeout de dépendance ne doit pas déclencher un redémarrage en cascade de vos pods.

---

4. Isolez vos workloads avec des namespaces dédiés

Pourquoi c'est essentiel : Les namespaces créent des frontières logiques entre vos équipes, environnements et applications. Vous pouvez ainsi appliquer des politiques spécifiques à chaque périmètre.

Comment structurer vos namespaces :

# Créez des namespaces par environnement et équipe
kubectl create namespace prod-team-payment
kubectl create namespace prod-team-catalog
kubectl create namespace staging-team-payment

# Appliquez des ResourceQuotas par namespace
kubectl apply -f - <<EOF
apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: prod-team-payment
spec:
  hard:
    requests.cpu: "10"
    requests.memory: 20Gi
    limits.cpu: "20"
    limits.memory: 40Gi
    pods: "50"
EOF

Cette isolation est fondamentale pour comprendre les différences entre Kubernetes et Docker dans la gestion des workloads.

---

5. Implémentez RBAC avec le principe du moindre privilège

Pourquoi c'est essentiel : Un accès trop permissif expose votre cluster à des erreurs humaines et des compromissions. 70% des organisations utilisent Helm, souvent avec des permissions excessives.

Comment appliquer RBAC correctement :

# Role limité à la lecture des pods dans un namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: prod-team-payment
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]
---
# Binding vers un ServiceAccount spécifique
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: prod-team-payment
subjects:
- kind: ServiceAccount
  name: monitoring-sa
  namespace: prod-team-payment
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Règles à suivre :

• Utilisez des Roles (namespaced) plutôt que des ClusterRoles
• Créez un ServiceAccount dédié par application
• Auditez régulièrement les permissions avec kubectl auth can-i --list

Pour approfondir la sécurité Kubernetes, la formation LFS460 Principes Fondamentaux de la Sécurité Kubernetes couvre ces aspects en profondeur.

---

6. Sécurisez le réseau avec des Network Policies

Pourquoi c'est essentiel : Par défaut, tous les pods peuvent communiquer entre eux. Vous devez explicitement restreindre ces flux pour limiter la propagation d'une compromission.

Comment implémenter le zero-trust networking :

# Politique par défaut : deny all ingress
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: prod-team-payment
spec:
  podSelector: {}
  policyTypes:
  - Ingress
---
# Autoriser uniquement le trafic depuis le frontend
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-api
  namespace: prod-team-payment
spec:
  podSelector:
    matchLabels:
      app: payment-api
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

Consultez notre guide Monitoring et dépannage Kubernetes pour diagnostiquer les problèmes de connectivité réseau.

À retenir : Testez vos Network Policies avant de les déployer en production. Utilisez kubectl exec pour valider que le trafic autorisé passe et que le trafic non autorisé est bloqué.

---

7. Centralisez votre monitoring et vos logs

Pourquoi c'est essentiel : Sans observabilité centralisée, vous ne pouvez pas diagnostiquer efficacement les incidents dans un environnement distribué. Chaque minute de MTTR (Mean Time To Resolution) compte.

Stack recommandée :

• Prometheus + Grafana pour les métriques
• Loki ou Elasticsearch pour les logs
• Jaeger ou Tempo pour le tracing distribué

# ServiceMonitor pour Prometheus Operator
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: payment-api-monitor
  labels:
    team: payment
spec:
  selector:
    matchLabels:
      app: payment-api
  endpoints:
  - port: metrics
    interval: 30s
    path: /metrics

Métriques essentielles à surveiller :

• Taux d'erreurs (HTTP 5xx)
• Latence P95 et P99
• Utilisation CPU/mémoire vs limits
• Nombre de restarts de pods

Pour résoudre les problèmes courants, référez-vous à Dépannage Docker et Kubernetes : résoudre les erreurs fréquentes.

---

8. Adoptez GitOps pour des déploiements reproductibles

Pourquoi c'est essentiel : Les modifications manuelles via kubectl apply créent de la dette technique et des écarts entre environnements. GitOps garantit que votre cluster reflète toujours l'état déclaré dans Git.

Comment implémenter GitOps :

# ArgoCD Application
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: payment-service
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/k8s-manifests.git
    targetRevision: main
    path: apps/payment-service/overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: prod-team-payment
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

À retenir : Activez la réconciliation automatique mais gardez prune: false initialement. Passez à prune: true uniquement quand vous maîtrisez votre workflow.

Si vous migrez depuis Docker Compose, notre guide Migrer vers Kubernetes depuis Docker Compose, VMs ou monolithes vous accompagne étape par étape.

---

9. Chiffrez et gérez vos secrets correctement

Pourquoi c'est essentiel : Les Secrets Kubernetes sont encodés en base64, pas chiffrés. Sans protection supplémentaire, ils sont lisibles par quiconque a accès à l'API server ou etcd.

Comment sécuriser vos secrets :

# Activez le chiffrement at-rest dans l'API server
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-encoded-secret>
      - identity: {}

Alternatives recommandées :

• External Secrets Operator avec AWS Secrets Manager ou HashiCorp Vault
• Sealed Secrets pour stocker des secrets chiffrés dans Git
• SOPS pour le chiffrement de fichiers YAML

# Créez un SealedSecret
kubeseal --format=yaml < secret.yaml > sealed-secret.yaml
kubectl apply -f sealed-secret.yaml

---

10. Maîtrisez vos stratégies de déploiement

Pourquoi c'est essentiel : Un déploiement mal configuré peut causer une indisponibilité totale de votre service. Vous devez choisir la stratégie adaptée à votre tolérance aux risques.

Configuration rolling update optimisée :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-api
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    spec:
      terminationGracePeriodSeconds: 60
      containers:
      - name: api
        lifecycle:
          preStop:
            exec:
              command: ["/bin/sh", "-c", "sleep 15"]

Pour optimiser vos déploiements, commencez par rolling update puis évoluez vers canary quand votre observabilité le permet.

Notre hub Bonnes pratiques conteneurisation et Docker approfondit chacune de ces stratégies.

---

Anti-patterns à éviter absolument

Avant de conclure, voici les erreurs que vous devez impérativement éviter dans vos clusters de production :

---

Passez à l'action : validez vos compétences

Vous maîtrisez maintenant les recommandations essentielles pour optimiser vos clusters Kubernetes en production. Chaque pratique que vous appliquez réduit votre risque d'incident et améliore la fiabilité de vos services.

Pour maîtriser ces bonnes pratiques, SFEIR Institute propose des parcours certifiants encadrés par des praticiens qui gèrent ces clusters quotidiennement :

• LFS458 Administration Kubernetes : 4 jours pour préparer la certification CKA et maîtriser l'administration de clusters
• LFD459 Kubernetes pour les développeurs d'applications : 3 jours pour la certification CKAD et le développement cloud-native
• Kubernetes, les fondamentaux : 1 jour pour découvrir les concepts essentiels

Comme le souligne un CTO interviewé par Spectro Cloud : « Just given the capabilities that exist with Kubernetes, and the company's desire to consume more AI tools, we will use Kubernetes more in future. » — State of Kubernetes 2025

Appliquez cette checklist dès maintenant et transformez vos déploiements Kubernetes en infrastructures de production fiables et sécurisées.