Aller au contenu principal

Pod, Deployment, Service, Namespace : la trinité +1

Résumé : ces quatre mots reviennent en boucle dans toute discussion Kubernetes. Il faut les distinguer clairement. Un Pod est la plus petite unité déployable (un ou plusieurs conteneurs). Un Deployment gère plusieurs Pods identiques avec mises à jour progressives. Un Service donne à ces Pods une adresse stable dans le cluster. Un Namespace isole logiquement plusieurs équipes ou environnements dans le même cluster.

1. La pyramide des objets Kubernetes​

Kubernetes possède plus de 50 types d'objets natifs. Mais 95 % de ce que vous rencontrerez au début tient dans cette pyramide.

Lisez la pyramide de haut en bas : un Namespace contient des Deployments qui gèrent des ReplicaSets qui contiennent des Pods qui contiennent des Conteneurs. Un Service est transverse — il route le trafic vers les Pods.

2. Le Pod — la plus petite unité déployable​

Un Pod est l'unité atomique de Kubernetes. C'est ce que le cluster déploie, redémarre, migre.

2.1 · Anatomie d'un Pod​

2.2 · À quoi ressemble un Pod en YAML​

Voici le manifest le plus simple possible pour un Pod.

apiVersion: v1
kind: Pod
metadata:
  name: mon-serveur-web
  labels:
    app: web
spec:
  containers:
    - name: nginx
      image: nginx:1.27
      ports:
        - containerPort: 80

Décodage rapide :

ChampCe qu'il dit à Kubernetes
kind: PodOn déclare un Pod
metadata.nameNom unique dans le Namespace
metadata.labelsÉtiquettes utilisées pour le routage
spec.containersListe des conteneurs du Pod
image: nginx:1.27L'image Docker à lancer
containerPort: 80Le port exposé par le conteneur

MAIS ATTENTION : dans la vraie vie, vous ne créez jamais un Pod directement. Vous créez toujours un Deployment qui gère les Pods pour vous. Pourquoi ? Parce qu'un Pod n'est pas résilient — s'il meurt, personne ne le remplace.

2.3 · Pourquoi le concept de Pod (et pas juste conteneur) ?​

Question fréquente : pourquoi Kubernetes ajoute-t-il une couche « Pod » au-dessus du conteneur ?

Réponse : parce que dans certains cas, on veut plusieurs conteneurs qui travaillent ensemble comme une seule unité — patterns sidecar, ambassador, adapter.

En pratique, 80 % des Pods en production contiennent un seul conteneur. Les patterns multi-conteneurs sont utilisés dans des cas avancés (mesh, observabilité).

3. Le Deployment — la vraie unité qu'on manipule​

Un Deployment est l'objet que vous créez au quotidien pour déployer votre application. Il gère les Pods pour vous avec deux super-pouvoirs : mise à l'échelle et mises à jour progressives.

3.1 · Ce que fait un Deployment​

3.2 · Un Deployment en YAML​

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mon-app
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: mon-app
  template:
    metadata:
      labels:
        app: mon-app
    spec:
      containers:
        - name: mon-app
          image: mon-app:v2.5
          ports:
            - containerPort: 8080
          resources:
            requests:
              memory: "128Mi"
              cpu: "100m"
            limits:
              memory: "512Mi"
              cpu: "500m"

Décodage rapide :

  • replicas: 3 — Kubernetes maintient 3 Pods en permanence.
  • selector.matchLabels — comment le Deployment identifie ses Pods.
  • template — le gabarit utilisé pour créer chaque Pod.
  • resources — les demandes et limites CPU/RAM (essentiel en prod).

Un kubectl apply -f deployment.yaml lance immédiatement les 3 Pods. Si un meurt, Kubernetes en recrée un dans les 5 secondes.

3.3 · Le workflow rolling update​

Quand vous changez l'image de v2.5 à v2.6, voici ce qui se passe.

Zéro downtime, rollback en une commande. C'est la magie d'un Deployment.

Note : ce rolling update est le plus courant. Kubernetes supporte aussi blue-green, canary, et d'autres stratégies plus avancées.

4. Le Service — l'adresse stable dans un monde éphémère​

Problème : les Pods sont jetables et immutables. Ils changent d'IP à chaque redémarrage. Comment un client trouve-t-il l'application de manière fiable ?

Solution : le Service.

Un Service offre :

  • Une adresse IP stable dans le cluster.
  • Un nom DNS (mon-app.production.svc.cluster.local).
  • Un équilibrage de charge natif entre les Pods.
  • Une résilience — si un Pod meurt, le trafic est redirigé automatiquement vers les vivants.

4.1 · Les 4 types de Services​

4.2 · L'Ingress — le patron des Services HTTP​

Pour une application web publique, on n'utilise généralement pas un LoadBalancer direct — on utilise un Ingress.

Un seul Ingress gère tous les Services HTTP du cluster, avec routage par nom de domaine et par chemin d'URL. C'est le reverse-proxy natif de Kubernetes.

5. Le Namespace — cloisonner un cluster​

Un Namespace est un dossier virtuel dans un cluster Kubernetes. Il permet de cloisonner plusieurs équipes, environnements, ou applications dans le même cluster.

Ce que permet un Namespace :

  • Isolation logique — mêmes noms de ressources possibles dans deux Namespaces différents.
  • Quotas de ressources — limiter chaque équipe à 10 CPU et 50 Go RAM par exemple.
  • RBAC ciblé — équipe A a des droits sur namespace-A uniquement.
  • Network policies — filtrer qui peut parler à qui entre Namespaces.

Bonne pratique 2026 : jamais déployer dans default. Toujours créer un Namespace explicite par équipe, environnement ou domaine fonctionnel.

6. Autres objets à connaître (aperçu rapide)​

Ces objets complètent la palette essentielle Kubernetes — approfondis dans le Cours Premium Kubernetes.

Ces objets représentent 95 % de ce que vous rencontrerez en production. Kubernetes en propose plus de 50 au total, mais les autres sont soit des détails techniques, soit des extensions spécialisées.

7. Comment tout ça s'articule — une application web complète​

Voici comment ces objets s'articulent dans une application web complète.

Un vrai stack de production en Kubernetes ressemble à ça : un Namespace qui contient les Deployments, StatefulSets, Services, ConfigMaps et Secrets d'une application. Le tout décrit en YAML et versionné dans Git.

Retenir en 30 secondes​

  • Pod = la plus petite unité déployable — un ou plusieurs conteneurs partageant IP et cycle de vie.
  • Deployment = la vraie unité de travail — gère N Pods identiques + rolling updates + rollback.
  • Service = adresse réseau stable pointant vers les Pods (4 types : ClusterIP, NodePort, LoadBalancer, ExternalName).
  • Ingress = reverse-proxy HTTP natif pour exposer plusieurs services sur Internet.
  • Namespace = cloisonnement logique d'un cluster entre équipes ou environnements.
  • ConfigMap / Secret = configuration non sensible / sensible injectée dans les Pods.
  • 95 % des cas d'usage tiennent dans ces 6 objets.

Suivant : Architecture d'un cluster : control plane et nodes →