Kubernetes en production : retours d'expérience terrain

Kubernetes est devenu le standard de fait pour l'orchestration de conteneurs. Mais le faire tourner en production est très différent de suivre un tutoriel. Voici les pièges qui apparaissent dès qu'un cluster reçoit du trafic réel.

Les requests et limits de ressources ne sont pas optionnelles

Le problème le plus courant dans les nouveaux clusters : des pods sans resource requests. Sans elles, le scheduler ne peut pas prendre de décisions de placement éclairées. Les nœuds se retrouvent sur-engagés, et tout ralentit — ou plante — sous charge.

Définissez les requests en vous basant sur l'usage observé, pas sur des suppositions. Utilisez des outils comme le Vertical Pod Autoscaler en mode recommandation pour collecter des données avant de vous engager sur des valeurs.

L'observabilité avant le scaling

Les équipes se tournent souvent vers l'autoscaling horizontal avant de pouvoir répondre à des questions basiques : quelle est notre latence P99 ? Où sont les goulots d'étranglement ? Combien de mémoire ce service consomme-t-il réellement ?

Investissez d'abord dans l'observabilité. Prometheus et Grafana sont la stack standard, mais ce qui compte, c'est d'avoir des dashboards que votre équipe consulte effectivement. Les alertes doivent être actionnables, pas bruyantes.

Namespaces et RBAC dès le premier jour

Il est tentant de tout faire tourner dans le namespace default pendant le développement initial. Mais ajouter l'isolation par namespace et les politiques RBAC à un cluster en fonctionnement est pénible.

Commencez avec des namespaces séparés pour chaque environnement et périmètre de service. Définissez les rôles RBAC tôt, même s'ils semblent permissifs au début. Resserrer les permissions est plus facile que de les créer à partir de zéro.

Le GitOps rend tout reproductible

Les commandes kubectl apply manuelles ne passent pas à l'échelle. Nous utilisons ArgoCD ou Flux pour synchroniser l'état du cluster depuis des dépôts Git. Chaque changement est auditable, réversible et vérifiable via des pull requests.

Une mauvaise configuration se corrige alors comme n'importe quel autre changement : on annule le commit et le contrôleur ramène le cluster à cet état.

La vérité sans détour

Kubernetes est puissant, mais il n'est pas gratuit. Il exige une expertise opérationnelle, et la courbe d'apprentissage est réelle. Pour les petites équipes qui font tourner une poignée de services, des alternatives plus simples peuvent être un meilleur choix. Mais quand vous avez besoin d'orchestration multi-services, de déploiements progressifs et d'infrastructure-as-code — Kubernetes répond présent.