Kity accueille aujourd’hui une douzaine de namespace, mais plus de 30 en cible
Les noms de namespace se chevauchent déjà entre plusieurs politiques
Il n’y a pas de consensus évident dans la communauté k8s sur une politique de nommage
Alternatives considérées
Utiliser des namespaces à plat, et mettre toutes les métadonnées en metadata
Structurer de gauche à droite : catégorie-usage, comme Kubernetes (kube- pour les usages internes k8s)
Structure de droite à gauche : usage-catégorie
Éléments moteurs de la décision
La logique a plat a rapidement plusieurs limites :
Elle est illisible en première intention sans descendre dans les objets, hors on navigue rarement les
objets namespace eux-mêmes
Elle incite à multiplier les usages dans un namespace, comme le périmètre n’est pas explicite
La logique de gauche à droite et droite à gauche sont équivalentes, sans argument franc dans un sens ou
l’autre (on est habitué autant à une arborescence de dossiers qu’à DNS), le choix est arbitraire et
suit l’existant interne Kubernetes
Cette logique de nommage s’applique immédiatement aux projets ArgoCD, où le wildcard est parfait pour
viser un lot de namespaces
Entre faire une catégorie par membre pour ses projets personnels, ou une catégorie membres avec un usage
par membre, la première proposition offre plus de possibilités sans empêcher d’être frugal
Conclusion
✅ Namespaces nommés catégorie-usage
✅ Catégorie infra- pour l’infrastructure
✅ Catégorie storage- pour le stockage mutualisé
✅ Catégorie tedomum- pour les applications TeDomum
✅ Chaque membre qui déploie dispose d’une catégorie dédiée
✅ Projets ArgoCD nommés d’après la catégorie pour déployer toute la catégorie
Conséquences
👍 Lisibilité des namespaces en balayant les listes de ressources
👍 Cohérence entre le gitops et la gestion des namespaces
👍 Espace de liberté pour les membres plus clairs
👎 Renommage partiel des ressources existantes, avec usage intempestif de kube-