Organiser vos environnements

Un même namespace peut héberger plusieurs applications sans le moindre problème ; toutefois, créer un namespace dédié reste utile pour :

• Séparer les environnements (développement, staging, production) ;
• Réutiliser les mêmes noms de ressources — par exemple un Service nommé api ou une ConfigMap settings — sans collisions ;
• Cloisonner les budgets : chaque namespace a ses propres quotas, donc son propre plafond de dépense.

Un namespace suffit souvent

Si vos services partagent le même cycle de vie et la même équipe, il est souvent plus simple de les garder dans un seul namespace. Nous conseillons néanmoins de différencier au minimum développement et production.

Demander un namespace supplémentaire

La création est gratuite et passe par le support (validation manuelle). Indiquez :

1. Identifiant d’organisation complet (ex. acme-rtximz) ;
2. Nom souhaité (ex. staging) — format a-z, 0-9, -, commence par une lettre ;
3. Usage (dev, test, prod…).

Le namespace créé suivra le modèle :

c-<identifiant-organisation>-<nom>
# Exemple : c-acme-rtximz-staging

Le pattern dev / prod / tooling

Une organisation typique :

Namespace	Rôle
c-acme-rtximz-dev	Développement — requests réduites, scale à zéro la nuit
c-acme-rtximz-prod	Production — replicas ≥ 2, HPA et PDB
c-acme-rtximz-tooling	Outillage transverse — CI, jobs d’administration, supervision maison

Le réseau intra-organisation étant ouvert, le namespace tooling peut joindre dev et prod sans configuration : pratique pour un runner CI qui déploie partout, ou un outil de supervision maison.

Pour promouvoir une version entre environnements, utilisez la même image, taguée immuablement (v1.4.2, un digest ou un SHA de commit — pas latest) et ne changez entre namespaces que la configuration (ConfigMaps/Secrets).

dev peut joindre prod

L’ouverture intra-organisation joue dans les deux sens : un pod de dev peut joindre la base de prod, et aucune NetworkPolicy client ne peut l’empêcher. Protégez-vous par la configuration : des secrets distincts par environnement (mots de passe de base différents en dev et en prod), et jamais d’URL de prod dans une config de dev.

Bien démarrer un nouveau namespace

• Votre kubeconfig existant y donne accès immédiatement — mais son namespace par défaut ne change pas : pensez au -n ou changez de contexte (rappel) ;
• Chaque namespace reçoit ses propres quotas, son Issuer TLS, son ServiceAccount CI et sa sauvegarde quotidienne — rien à configurer ;
• Multiplier les environnements multiplie les plafonds : deux namespaces = 2 × 20 pods, 2 × 10 vCPU…