Maîtriser Kubernetes : Déploiement et Gestion de Containers
Introduction
Maîtriser Kubernetes, ce n'est pas juste savoir écrire un Deployment YAML. C'est comprendre les pods, les probes, les resource requests, les NetworkPolicies, le RBAC, et surtout savoir diagnostiquer quand ça ne marche pas. Après avoir formé des équipes chez SFR Business Team, Coopengo et Bloomflow, voici les concepts essentiels et les pièges à éviter.
Les pods : bien au-delà du conteneur unique
Un pod peut contenir plusieurs conteneurs, et c'est un pattern puissant quand il est bien utilisé. Chez TEKYN, j'ai implémenté un sidecar Nginx devant les conteneurs applicatifs ECS Fargate pour gérer le TLS termination et le rate limiting. Chez KNDS, les pods applicatifs ont un sidecar Vault Agent pour l'injection de secrets. Chez Bloomflow, un sidecar Fluent Bit collecte les logs structurés et les envoie vers Loki. Le pattern init container est tout aussi utile : chez Okeiro (e-Santé HDS), un init container attend que la base FHIR soit ready avant de démarrer l'application, évitant les crashloops au démarrage.
Resource requests et limits : le calibrage qui fait la différence
La cause n°1 des problèmes Kubernetes que je rencontre en audit : des requests et limits mal calibrés. Un pod qui déclare 100m CPU en request mais qui en consomme 500m en pic va être throttlé. Un pod sans memory limit peut OOM-kill ses voisins. Chez F2R2, l'audit AWS a révélé des pods avec 1 vCPU en request pour une consommation réelle de 200m. Après calibrage avec les recommandations du Vertical Pod Autoscaler, les node groups ont été réduits de 30%. Ma règle : commencer avec des requests conservateurs, déployer le VPA en mode recommandation pendant une semaine, puis ajuster.
Probes : liveness, readiness et startup
Les probes sont le mécanisme de self-healing de Kubernetes, et leur mauvaise configuration est une source infinie de problèmes. Chez Coopengo, un liveness probe trop agressif (timeout 1s, seuil d'échec à 1) redémarrait les pods dès qu'un garbage collection Java causait une pause. La solution : un startup probe avec un timeout généreux pour les applications lentes au démarrage, un readiness probe pour contrôler quand le pod reçoit du trafic, et un liveness probe avec des seuils réalistes. Chez Cardiologs, les probes HTTP vérifient non seulement que l'application répond, mais aussi qu'elle est connectée à PostgreSQL et aux services de dépendance.
Observabilité : voir ce qui se passe dans le cluster
Sans observabilité, Kubernetes est une boîte noire. Ma stack standard, déployée chez Metronome, Bloomflow et KNDS : Prometheus pour les métriques (kube-state-metrics, node-exporter, métriques applicatives custom), Grafana pour la visualisation (dashboards par namespace, par application, par node), Loki pour les logs centralisés, et Alertmanager pour les notifications. Chez Bloomflow, on a ajouté Tempo pour le tracing distribué avec OpenTelemetry. Le résultat : le temps moyen de diagnostic d'un incident est passé de 2 heures à 15 minutes.
Sécurité : les fondamentaux non négociables
Chez KNDS (Défense), la sécurité Kubernetes est poussée au maximum : RBAC granulaire par namespace et par équipe, NetworkPolicies en deny-all par défaut avec des règles whitelist, profils seccomp custom pour restreindre les appels système, et PodSecurity Standards en mode "restricted". Les secrets passent par OKMS (OVH Key Management Service) avec rotation automatique. Chez Bloomflow (ISO 27001), Gatekeeper/OPA impose des policies : pas de conteneur en root, pas d'image sans tag précis, pas de hostPath mount. Ces contrôles automatisés sont plus fiables que n'importe quelle checklist manuelle.
Scalabilité : de 3 pods à 300 pods
Chez Coopengo, la plateforme HDS devait absorber des pics de charge 4x supérieurs à la baseline. L'Horizontal Pod Autoscaler, configuré sur des métriques custom (requêtes/seconde via Prometheus Adapter), ajuste le nombre de replicas en temps réel. Le Cluster Autoscaler ajoute des nodes quand les pods ne trouvent plus de place. Chez Bloomflow, Karpenter remplace le Cluster Autoscaler avec une réactivité supérieure : les nodes sont provisionnés en moins de 60 secondes. Le résultat : un scaling transparent pour les utilisateurs, et une facture cloud qui suit la charge réelle.
Conclusion
Maîtriser Kubernetes demande de la pratique et de la rigueur. Les fondamentaux (pods, probes, resource management) sont la base ; l'observabilité et la sécurité sont les différenciateurs. Après avoir formé et accompagné des équipes sur ces sujets pendant des années, je constate que les deux erreurs les plus courantes sont : des probes mal configurées et des requests/limits non calibrées. Corrigez ces deux points, et vos clusters seront immédiatement plus stables.