HPA sur métriques custom : quand le CPU ne dit rien d'utile
Un worker qui consomme une file d'attente peut tourner à 5% de CPU tout en étant complètement submergé. Le HPA sur métrique custom résout ce que CPU/mémoire ne peuvent pas voir.
parcours
Kubernetes en production
Ce que Kubernetes fait vraiment quand la charge monte, quand un nœud tombe, quand un pod refuse de mourir. Les sections suivent l'ordre dans lequel les problèmes arrivent en exploitation.
42 articles · 5 sections
01
Ressources et ordonnancement
Pourquoi un pod est tué, throttlé, ou refuse d’être planifié.
Quand le HPA épuise les connexions Postgres
Le HPA scale les pods, chaque pod ouvre son propre pool de connexions. Sous charge, la base atteint max_connections avant même que le HPA n'ait fini de scaler.
Classes QoS : l'ordre d'éviction que personne n'a choisi
La classe QoS d'un pod fixe son ordre d'éviction, déduite des requests/limits, jamais choisie explicitement. Un service critique sans limits part en premier.
PriorityClass : garantir qu'un pod critique se place toujours
Sans priorité définie, tous les pods sont égaux devant un nœud saturé. PriorityClass et la préemption décident qui reste et qui se fait évincer quand la capacité manque.
metrics-server : le prérequis silencieux derrière HPA et kubectl top
kubectl top pod et le HPA n'ont aucune donnée à lire sans metrics-server installé. Comment il fonctionne, et l'erreur de certificat la plus fréquente à l'installation.
Taints et tolerations : empêcher un pod de se poser
Les taints repoussent tous les pods d'un nœud sauf ceux qui les tolèrent explicitement. Les trois effets, et pourquoi ce n'est pas une affinité positive.
Karpenter ou Cluster Autoscaler : au-delà des groupes de nœuds
Le Cluster Autoscaler reste prisonnier des groupes de nœuds préconfigurés. Karpenter provisionne l'instance exacte dont le pod a besoin, sans ce détour.
VPA : dimensionner les pods sans deviner à la main
Le VPA sert à dimensionner les requests CPU/mémoire à partir de la consommation réelle. Son mode Auto redémarre les pods à chaque ajustement.
CrashLoopBackOff : la méthode pour trouver la vraie cause
CrashLoopBackOff est un symptôme, jamais une cause. Trois familles d'origine différentes, une méthode pour les distinguer en quelques commandes.
Cluster Autoscaler : pourquoi le scale down traîne
Le Cluster Autoscaler ajoute des nœuds facilement. Le scale down casse en silence : PDB trop stricts, pods sans contrôleur, annotation oubliée.
HPA : ce que l'autoscaling horizontal suppose déjà en place
Pourquoi le Horizontal Pod Autoscaler ne fonctionne pas sans requests correctement posées, comment il décide de scaler, et le piège de l'oscillation.
Requests et limits Kubernetes : throttling, OOMKill et QoS
Ce qui se passe vraiment quand un pod Kubernetes dépasse sa limite CPU ou mémoire, les classes QoS, le débat des limites, et une méthode de réglage.
02
Réseau
Résolution, routage et politiques — la couche qui échoue en silence.
nsswitch.conf : pourquoi /etc/hosts passe avant le DNS
Une résolution de nom incohérente entre deux machines pointe souvent vers nsswitch.conf, pas vers le DNS : il définit l'ordre des sources pour hosts, passwd et group.
ClusterIP, NodePort, LoadBalancer : trois types, une seule base
LoadBalancer et NodePort ne remplacent jamais ClusterIP : ils l'ajoutent en couche. Comprendre cet empilement évite de choisir le mauvais type de Service.
Gateway API : ce qui remplace vraiment l'Ingress
L'Ingress encode toute logique avancée dans des annotations propres à chaque contrôleur. La Gateway API sépare les rôles en ressources typées, portables entre contrôleurs.
kubectl port-forward : le tunnel qui contourne NetworkPolicy
port-forward passe par le serveur API, pas par le réseau du pod. NetworkPolicy ne le voit jamais, un angle mort qui a son propre verbe RBAC à restreindre spécifiquement.
ndots:5 : pourquoi une résolution DNS externe coûte 5 requêtes
Le ndots:5 par défaut de Kubernetes essaie 5 domaines de recherche internes avant chaque nom externe. Une latence DNS invisible jusqu'à ce qu'elle s'accumule.
nf_conntrack_max : la table qui perd des connexions en silence
Une table conntrack pleine ne ralentit rien : elle rejette silencieusement les nouvelles connexions, un symptôme qui ressemble à un problème applicatif ailleurs.
nginx-ingress ou Traefik : comment choisir son Ingress Controller
Un Ingress ne fait rien sans contrôleur pour l'exécuter. nginx-ingress et Traefik répondent au même besoin par deux modèles de configuration opposés.
MetalLB : un vrai LoadBalancer sur un cluster on-premise
Un Service de type LoadBalancer reste en Pending indéfiniment sur un cluster on-premise, faute de cloud provider pour le satisfaire. Ce que MetalLB fait à la place.
DaemonSet : exactement un pod par nœud
Un Deployment ne garantit aucune répartition par nœud. DaemonSet en garantit une exacte, le mécanisme derrière la plupart des agents d'infrastructure.
Ingress et cert-manager : le TLS qui se renouvelle sans vous
Comment un Ingress route le trafic HTTP, ce que cert-manager automatise pour les certificats Let's Encrypt, et le piège du challenge HTTP-01.
03
Stockage et état
Volumes, sauvegardes et migrations sans perdre de données.
lvextend agrandit le volume logique, pas le système de fichiers
df continue d'afficher l'ancienne taille après un lvextend réussi : agrandir un volume logique LVM ne redimensionne jamais automatiquement le système de fichiers qu'il contient.
VolumeSnapshot : cloner un volume persistant sans Velero
VolumeSnapshot capture l'état d'un PVC à un instant donné, sans jamais toucher aux ressources Kubernetes autour. Un besoin différent de la sauvegarde cluster complète.
Longhorn : du stockage persistant sur un cluster on-premise
Sans cloud provider, aucun StorageClass ne provisionne de volume automatiquement. Ce que Longhorn fait à la place, et ce que la réplication ne remplace pas.
StatefulSet : quand un Deployment ne suffit pas
Un Deployment traite ses pods comme interchangeables. Une base de données ne l'est pas : elle a besoin d'une identité stable et de son propre volume. C'est le rôle du StatefulSet.
04
Déploiement et retour arrière
Mettre en ligne sans coupure, et revenir en arrière quand il le faut.
Deployment et ReplicaSet : pourquoi les anciens restent en vie
Un Deployment ne modifie jamais un ReplicaSet existant : il en crée un nouveau et réduit l'ancien à zéro replica. C'est ce mécanisme précis qui rend le rollback possible.
kubectl rollout restart : un nouveau rollout sans changer la spec
rollout restart force un rolling update propre sans modifier une seule ligne du Deployment. La bonne commande pour un refresh de ConfigMap ponctuel, pas kubectl delete pod.
ConfigMap modifié : pourquoi les pods ne redémarrent jamais
Modifier un ConfigMap ne redémarre aucun pod automatiquement. Les variables d'environnement ne se mettent même jamais à jour sans un redémarrage manuel.
Helm hooks : hors du cycle de vie normal de la release
Un hook Helm s'exécute en dehors de la release qu'il accompagne. helm rollback ne le rejoue jamais, ce qui casse le principe même du rollback si on ne le sait pas.
SIGTERM vs retrait des endpoints : la course jamais synchronisée
Kubernetes envoie SIGTERM et retire un pod des endpoints du Service en parallèle, jamais dans un ordre garanti. Sans preStop, des requêtes arrivent dans le vide.
Blue-green : quand doubler l'infra vaut vraiment le coût
Le blue-green bascule tout le trafic d'un coup, pas progressivement. Rollback instantané, prix réel : deux environnements complets à faire tourner en double.
GitOps avec ArgoCD : le déploiement déclaratif expliqué
Comment ArgoCD réconcilie en continu l'état du cluster avec Git, la différence entre push et pull deployment, et ce que la dérive (drift) révèle vraiment.
kubectl rollout undo : comment fonctionnent les rollbacks
Comment les révisions d'un Deployment correspondent aux ReplicaSets, ce que kubectl rollout undo restaure vraiment, et pourquoi GitOps préfère un revert Git.
05
Accès et admission
Qui peut faire quoi dans le cluster, et ce qui est refusé à l’entrée.
Audit logging Kubernetes : qui a fait quoi, après coup
RBAC empêche, Falco détecte en direct, l'audit logging répond après l'incident. Sans Audit Policy activée, cette question n'a tout simplement pas de réponse.
Finalizers : pourquoi un namespace refuse de mourir
Un finalizer bloqué, pas Kubernetes, empêche un objet en Terminating de mourir : il attend un nettoyage qu'un contrôleur disparu ne fera jamais.
Environnements de preview éphémères par pull request
Des environnements éphémères par pull request, créés et détruits automatiquement, résolvent un vrai problème de revue. Ce que ça coûte en isolation, et le piège du nettoyage qui ne se fait jamais.
Multi-tenancy Kubernetes : trois niveaux d'isolation, un seul coût
Namespaces, vcluster ou clusters séparés : trois façons d'isoler des équipes sur Kubernetes, avec un compromis identique entre force d'isolation et coût opérationnel.
GitOps à l'échelle : ApplicationSets, le piège du tenant
Gérer un Application ArgoCD par service tient à dix équipes. À cent, ApplicationSets automatise la génération, mais déplace le vrai problème d'isolation.
Pod Security Standards : la sécurité par label de namespace
PodSecurityPolicy est mort depuis Kubernetes 1.25. Pod Security Admission le remplace par trois profils appliqués via un simple label de namespace.
ResourceQuota et LimitRange : gouverner un namespace, pas un pod
Des requests bien posées protègent un pod. Rien n'empêche une équipe d'en créer mille sans limite globale. ResourceQuota et LimitRange gouvernent au niveau du namespace.
RBAC Kubernetes : le moindre privilège, en pratique
RBAC Kubernetes refuse tout par défaut, mais un rôle trop large ne casse jamais rien : il existe, silencieux, jusqu'à l'incident qui l'expose.