Maîtriser les Namespaces Kubernetes pour une Gestion Efficace des Clusters

Les Namespaces : La Base de l'Organisation Kubernetes

Les namespaces Kubernetes sont un concept simple mais mal utilisé sur la majorité des clusters que j'audite. Soit tout est déployé dans le namespace default (le chaos), soit il y a trop de namespaces avec une logique incohérente. Voici comment je les utilise en production, tiré de mes expériences sur des dizaines de clusters.

Ma Convention de Nommage

Sur chaque cluster que je configure, je mets en place une structure de namespaces standardisée :

• system : les composants d'infrastructure (ingress controller, cert-manager, external-secrets, monitoring)
• app-{nom} ou {nom}-prod / {nom}-staging : les applications métier, séparées par service ou par environnement
• monitoring : la stack d'observabilité (Grafana, Loki, Prometheus/Mimir, Tempo)
• argocd : le contrôleur GitOps

Chez un client dans la Défense, chaque équipe avait son propre namespace avec des quotas de ressources et des RBAC spécifiques. L'équipe backend ne pouvait pas voir les pods de l'équipe data, et vice versa.

Sécurité : RBAC par Namespace

Le RBAC Kubernetes fonctionne naturellement avec les namespaces. Un RoleBinding dans un namespace donne des permissions uniquement dans ce namespace. C'est la base de l'isolation multi-tenant dans un cluster partagé.

En pratique, je crée systématiquement :

• Un Role viewer qui permet de lister et consulter les ressources (pour les développeurs en production)
• Un Role editor qui permet de modifier les ressources (pour les développeurs en staging/dev)
• Un Role admin limité aux opérations sensibles (pour les leads techniques)

Le ClusterRole cluster-admin est réservé à un nombre restreint de personnes, et chaque utilisation est loggée.

Quotas de Ressources

Les ResourceQuotas par namespace sont indispensables en environnement partagé. Sans quotas, un service qui fuit en mémoire peut consommer toutes les ressources du cluster et impacter tous les autres services.

Sur un cluster OVH partagé entre 3 équipes, j'ai mis en place des quotas CPU et mémoire par namespace. Quand l'équipe data a lancé un job qui consommait 10x les ressources prévues, le quota l'a bloqué sans impacter les services des autres équipes. Sans cette protection, le cluster entier aurait été dégradé.

LimitRanges : Les Garde-fous

En complément des ResourceQuotas, les LimitRanges définissent des valeurs par défaut et des limites pour chaque pod dans un namespace. Si un développeur oublie de spécifier des resource requests/limits (ce qui arrive constamment), le LimitRange applique des valeurs par défaut raisonnables.

L'Erreur du Namespace default

Mon conseil : n'utilisez jamais le namespace default pour quoi que ce soit en production. Sur certains clusters que j'ai audités, le default contenait un mélange de tests, de services oubliés, et parfois même des applications de production. C'est ingérable et dangereux.

Je configure même parfois une NetworkPolicy deny-all sur le namespace default pour s'assurer que rien n'y tourne accidentellement.

Les Namespaces dans le GitOps

Avec ArgoCD, chaque Application pointe vers un namespace cible. La convention est claire : un dépôt Git, un chart Helm, un namespace. Cette approche permet de déployer et de rollback de façon isolée, sans risquer d'impacter d'autres services.

Les namespaces sont un outil simple mais puissant. Bien utilisés, ils transforment un cluster Kubernetes en une plateforme multi-tenant sécurisée et organisée.