Les namespaces constituent le principal mécanisme d'isolement logique dans Kubernetes. Sous Helm, ils déterminent où une release dépose ses ressources et comment celles-ci sont isolées des autres déploiements. Cet article présente leur rôle dans l'architecture de Helm, les différentes manières de les paramétrer et les pièges les plus fréquents.

1. Rôle des namespaces dans Helm

Helm interagit avec Kubernetes via un client qui applique des manifestes générés depuis des charts. Le namespace cible est transmis à l'API server lors de chaque opération (install, upgrade, uninstall, rollback). Si aucun namespace n'est précisé, Helm utilise le contexte courant de kubeconfig, souvent default.

À l'intérieur d'un chart, le namespace est accessible via l'objet .Release :

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}
  namespace: {{ .Release.Namespace }}
spec:
  replicas: 2
  selector:
    matchLabels:
      app: {{ .Release.Name }}

Ce modèle garantit que chaque ressource créée se situe dans le même namespace que la release, évitant ainsi les déploiements accidentels dans default.

2. Méthodes pour définir le namespace cible

2.1 Utilisation de l'option --namespace

La méthode la plus explicite consiste à passer l'option --namespace (ou -n) lors de l'installation ou de la mise à jour :

helm install frontend ./frontend-chart --namespace production --create-namespace

L'option --create-namespace est souvent associée pour initialier le namespace s'il n'existe pas encore. Cela évite une étape manuelle supplémentaire avec kubectl create namespace.

2.2 Variable d'environnement HELM_NAMESPACE

Pour éviter de répéter le namespace sur toutes les commandes, Helm consulte la variable d'environnement HELM_NAMESPACE :

export HELM_NAMESPACE=production
helm install frontend ./frontend-chart

Cette variable est particulièrement utile dans des pipelines CI/CD où toutes les releases d'un même job doivent être déployées dans le même namespace.

2.3 Paramétrage via le contexte Kubernetes

Helm hérite également du namespace défini dans le contexte actif de kubeconfig. Si current-context pointe vers un namespace spécifique, Helm l'utilisera par défaut :

kubectl config set-context --current --namespace=production
helm install frontend ./frontend-chart

Cette approche centralise la configuration au niveau du cluster et du poste de travail.

3. Problèmes courants et solutions

3.1 Namespace absent lors de l'installation

Par défaut, Helm ne crée pas le namespace. Deux approches permettent de résoudre ce problème :

Création manuelle :

kubectl create namespace production

Création automatique :

helm install frontend ./frontend-chart --namespace production --create-namespace

3.2 Ressources partagées entre namespaces

Certains objets Kubernetes, comme les ConfigMap ou les Secret partagés, doivent être référencés depuis un autre namespace. Il faut alors préciser explicitement le namespace de l'objet cible :

# templates/configmap-reference.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: shared-config
  namespace: production
data:
  database-url: "postgres://db.shared.svc.cluster.local"

Les références entre namespaces ne sont pas automatiques et doivent être déclarées dans les templates.

3.3 Nettoyage incomplet d'une release

Lors d'un helm uninstall, les ressources Kubernetes déployées par le chart sont supprimées, mais le namespace lui-même peut rester. Pour libérer complètement l'environnement :

helm uninstall frontend --namespace production
kubectl delete namespace production

4. Bonnes pratiques

4.1 Conventions de nommage

Adoptez une convention claire incluant le projet et l'environnement :

frontend-prod
frontend-staging
backend-prod

4.2 Quotas et limites

Associez chaque namespace à un ResourceQuota pour éviter qu'un seul déploiement ne monopolise les ressources du cluster :

apiVersion: v1
kind: ResourceQuota
metadata:
  name: production-quota
  namespace: production
spec:
  hard:
    pods: "20"
    requests.cpu: "8"
    requests.memory: 16Gi
    limits.cpu: "16"
    limits.memory: 32Gi

4.3 RBAC et isolement multi-équipes

Dans un cluster partagé, utilisez des rôles et des RoleBinding par namespace pour restreindre l'accès des équipes uniquement aux ressources dont elles ont la responsabilité. Cela renforce l'isolement et facilite l'audit.

4.4 Éviter le namespace default en production

Le namespace default ne doit pas héberger les applications de production. Il est préférable de créer des namespaces dédiés par application et par environnement, avec des quotas et des politiques de sécurité spécifiques.