Architecture Kubernetes : control-plane, pods et namespaces

L'architecture Kubernetes repose sur une séparation claire entre le plan de contrôle (control plane) et les nœuds d'exécution (worker nodes). Comprendre cette architecture est le premier pas vers la compréhension de l'orchestration de conteneurs. Selon le CNCF Annual Survey 2025, 82% des utilisateurs de conteneurs exécutent Kubernetes en production. Cette adoption massive exige une compréhension solide des composants fondamentaux.

TL;DR : L'architecture Kubernetes s'articule autour du control plane (cerveau du cluster) qui orchestre les pods (unités d'exécution) organisés dans des namespaces (espaces logiques isolés). Maîtriser ces trois concepts permet de concevoir, déployer et maintenir des applications cloud-native efficacement.

Pour découvrir ces concepts avec des exercices pratiques, explorez la formation Kubernetes, les fondamentaux.

Qu'est-ce que l'architecture Kubernetes ?

L'architecture Kubernetes est un système distribué conçu pour orchestrer des applications conteneurisées à grande échelle. Elle suit un modèle déclaratif : vous définissez l'état souhaité, Kubernetes le maintient.

À retenir : Kubernetes compare en permanence l'état actuel du cluster à l'état désiré et effectue les ajustements nécessaires automatiquement.

Cette architecture se divise en deux couches distinctes :

Couche	Rôle	Composants principaux
Control Plane	Décisions et orchestration	kube-apiserver, etcd, scheduler, controller-manager
Data Plane	Exécution des workloads	kubelet, kube-proxy, container runtime

Le premier commit Kubernetes date du 6 juin 2014, avec 250 fichiers et 47 501 lignes de code. La version 1.0 a été publiée le 21 juillet 2015.

Comment fonctionne le control plane Kubernetes ?

Le control plane Kubernetes constitue le cerveau du cluster. Il prend toutes les décisions globales : scheduling des pods, détection des pannes, réponse aux événements.

kube-apiserver : le point d'entrée unique

Le kube-apiserver est le composant frontal du control plane. Toute communication passe par lui :

# Vérifier l'état du cluster via l'API
kubectl cluster-info

# Interroger directement l'API server
kubectl get --raw /api/v1/namespaces

L'API server valide chaque requête, applique les politiques d'admission et persiste l'état dans etcd.

etcd : la mémoire du cluster

etcd est une base de données clé-valeur distribuée qui stocke l'intégralité de l'état du cluster. Sans etcd, Kubernetes ne peut pas fonctionner.

# Configuration etcd typique
apiVersion: v1
kind: Pod
metadata:
  name: etcd
spec:
  containers:
  - name: etcd
    image: registry.k8s.io/etcd:3.5.10-0
    command:
    - etcd
    - --data-dir=/var/lib/etcd

À retenir : Sauvegardez etcd régulièrement. La perte d'etcd signifie la perte complète de la configuration du cluster.

kube-scheduler : l'affectation intelligente

Le kube-scheduler détermine sur quel nœud exécuter chaque pod. Il évalue les ressources disponibles, les contraintes d'affinité et les politiques de priorité.

kube-controller-manager : la boucle de réconciliation

Ce composant exécute les contrôleurs qui maintiennent l'état désiré :

ReplicaSet controller : maintient le nombre de réplicas demandé
Node controller : surveille la santé des nœuds
Endpoint controller : peuple les objets Endpoints
Service Account controller : crée les comptes par défaut

Pour approfondir l'administration du control plane, consultez notre guide complet Formation Kubernetes.

Qu'est-ce qu'un pod dans l'architecture Kubernetes ?

Un pod est la plus petite unité déployable dans Kubernetes. Il encapsule un ou plusieurs conteneurs qui partagent réseau et stockage.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  namespace: production
spec:
  containers:
  - name: nginx
    image: nginx:1.27
    ports:
    - containerPort: 80
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

Caractéristiques essentielles des pods

Propriété	Description
Éphémère	Les pods peuvent être supprimés et recréés à tout moment
Adresse IP unique	Chaque pod reçoit une IP dans le réseau du cluster
Volumes partagés	Les conteneurs d'un pod accèdent aux mêmes volumes
Namespace	Un pod appartient à un seul namespace

À retenir : Ne déployez jamais des pods directement en production. Utilisez des Deployments ou StatefulSets qui gèrent leur cycle de vie.

Les équipes IT consacrent en moyenne 34 jours de travail par an à résoudre des problèmes Kubernetes selon Cloud Native Now. La compréhension des pods réduit significativement ce temps.

Pour découvrir la gestion des pods, consultez les fondamentaux Kubernetes pour débutants.

Comment les namespaces organisent l'architecture Kubernetes ?

Un namespace est un espace de noms logique qui segmente les ressources d'un cluster. Il permet l'isolation, le contrôle d'accès et la gestion des quotas.

# Lister les namespaces existants
kubectl get namespaces

# Créer un namespace
kubectl create namespace staging

# Déployer dans un namespace spécifique
kubectl apply -f deployment.yaml -n staging

Namespaces par défaut

Kubernetes crée quatre namespaces initiaux :

Namespace	Usage
default	Ressources sans namespace explicite
kube-system	Composants système Kubernetes
kube-public	Ressources accessibles publiquement
kube-node-lease	Objets Lease pour la détection de santé des nœuds

Bonnes pratiques de namespacing

Isolez les environnements : créez des namespaces distincts pour dev, staging et production.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: production-quota
  namespace: production
spec:
  hard:
    requests.cpu: "10"
    requests.memory: 20Gi
    limits.cpu: "20"
    limits.memory: 40Gi
    pods: "50"

Appliquez des Network Policies pour contrôler le trafic inter-namespaces :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          environment: production

Quelle est la relation entre control plane et worker nodes ?

Les worker nodes exécutent les workloads orchestrés par le control plane. Chaque nœud contient trois composants essentiels.

kubelet : l'agent du nœud

Le kubelet s'exécute sur chaque nœud worker. Il reçoit les spécifications de pods du control plane et garantit leur exécution.

# Vérifier l'état du kubelet
systemctl status kubelet

# Logs du kubelet
journalctl -u kubelet -f

kube-proxy : le réseau de services

kube-proxy maintient les règles réseau sur chaque nœud. Il permet la communication entre services via iptables ou IPVS.

Container runtime : l'exécution des conteneurs

Le runtime (containerd, CRI-O) exécute effectivement les conteneurs. Kubernetes communique avec lui via l'interface CRI (Container Runtime Interface).

Selon le rapport Spectro Cloud 2025, 80% des organisations exécutent Kubernetes en production avec une moyenne de 20+ clusters par entreprise.

Comment visualiser l'architecture Kubernetes en pratique ?

┌─────────────────────────────────────────────────────────────┐
│                      CONTROL PLANE                          │
│  ┌─────────────┐  ┌──────────┐  ┌──────────────────────┐   │
│  │ kube-apiserver │  │  etcd    │  │ controller-manager │   │
│  └─────────────┘  └──────────┘  └──────────────────────┘   │
│  ┌────────────────┐  ┌─────────────────────────────────┐   │
│  │ kube-scheduler │  │ cloud-controller-manager        │   │
│  └────────────────┘  └─────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                      WORKER NODES                           │
│  ┌─────────────────────────────────────────────────────┐   │
│  │ Node 1                                               │   │
│  │  ┌─────────┐  ┌───────────┐  ┌─────────────────┐   │   │
│  │  │ kubelet │  │ kube-proxy│  │ container runtime│   │   │
│  │  └─────────┘  └───────────┘  └─────────────────┘   │   │
│  │  ┌─────────────────────────────────────────────┐   │   │
│  │  │ Pods (namespace: default, production, ...)  │   │   │
│  │  └─────────────────────────────────────────────┘   │   │
│  └─────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘

Cette architecture explique pourquoi 71 % des entreprises Fortune 100 exécutent Kubernetes en production.

Quelles commandes pour explorer l'architecture Kubernetes ?

# Composants du control plane
kubectl get --raw='/healthz?verbose'

# Détails des nœuds
kubectl describe nodes

# Tous les pods système
kubectl get pods -n kube-system

# Événements récents du cluster
kubectl get events --sort-by='.lastTimestamp' -A

# Ressources par namespace
kubectl api-resources --namespaced=true

Le marché Kubernetes atteindra 8,41 milliards USD d'ici 2031 avec un CAGR de 21,85% selon Mordor Intelligence. Maîtriser cette architecture est un investissement de carrière.

Passez à la pratique avec SFEIR Institute

Comprendre l'architecture Kubernetes théoriquement ne suffit pas. Chris Aniszczyk, CTO de la CNCF, affirme :

« Kubernetes is no longer experimental but foundational. Soon, it will be essential to AI as well. » — CNCF State of Cloud Native 2026

Formez-vous avec des experts praticiens :

Kubernetes, les fondamentaux : découvrez l'architecture et les concepts clés en une journée intensive
LFS458 Administration Kubernetes : maîtrisez le control plane et préparez la certification CKA
LFD459 Kubernetes pour les développeurs : déployez vos applications et préparez le CKAD

Contactez nos conseillers pour définir votre parcours de formation Kubernetes.

Points clés