Selon l'édition 2026 de l'enquête annuelle CNCF, 82 % des utilisateurs de conteneurs font désormais tourner Kubernetes en production, contre 66 % en 2023. Mais « ça tourne » et « c'est prêt pour la production » restent deux choses différentes.
25 % des incidents de sécurité cloud impliquent un service mal configuré, selon l'IBM X-Force Threat Intelligence Index — et non l'exploitation d'une vulnérabilité inédite.
Disponibilité : le piège du réplica unique
Un service déployé avec un seul réplica n'a, par définition, aucune tolérance aux pannes.
La bonne pratique : au moins 3 réplicas par service critique, répartis sur plusieurs zones, avec un PodDisruptionBudget pour empêcher qu'une mise à jour de nœud ne fasse tomber trop de réplicas simultanément.
Sécurité : RBAC, réseau, conteneurs
La sécurité Kubernetes se joue à trois niveaux : qui peut agir sur le cluster (RBAC scopé par espace de noms), qui peut communiquer avec qui (NetworkPolicy explicites) et ce qu'un conteneur compromis peut atteindre (utilisateur non-root, capacités réduites).
Un tableau de bord ou une API server exposé sans authentification reste l'une des erreurs les plus documentées.
Ce qu'il faut retenir
- Chaque service critique tourne avec au moins 3 réplicas répartis sur plusieurs zones
- Un PodDisruptionBudget protège chaque charge critique lors des mises à jour de nœud
- Le RBAC applique le moindre privilège, sans ClusterRoleBinding large
- Des NetworkPolicy limitent le trafic est-ouest entre espaces de noms
- Métriques, logs et traces sont centralisés et alertants
- Le plan de sauvegarde des volumes persistants a été restauré en test
