Nommage des namespaces et projets

Infrastructure

Contexte et description de la problématique

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

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

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

✅ 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

👍 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-