Quand j’ai découvert Kubernetes pour la première fois en formation, j’ai eu l’impression de regarder un schéma d’architecture avec cinquante boîtes reliées par des flèches dans tous les sens. Aujourd’hui, après plusieurs années à déployer des clusters en production et à enseigner cette technologie à mes étudiants BTS SIO, je peux vous assurer que la kubernetes architecture devient limpide une fois qu’on comprend le rôle de chaque composant. Dans ce guide, je vous emmène pas à pas dans les entrailles d’un cluster Kubernetes pour que vous puissiez non seulement comprendre son fonctionnement, mais aussi prendre des décisions éclairées pour vos projets.

Comprendre l’architecture of Kubernetes en profondeur

L’architecture kubernetes suit un modèle maître-esclave distribué. À son niveau le plus fondamental, un cluster se compose de deux types de machines : les nœuds du control plane (anciennement appelés masters) et les worker nodes. Cette séparation n’est pas arbitraire ; elle reflète une philosophie de conception où la prise de décision est centralisée tandis que l’exécution est distribuée.

Kubernetes a été conçu par Google, qui s’est inspiré de son système interne Borg pour créer un orchestrateur open source capable de gérer des milliers de conteneurs. Le projet, hébergé par la Cloud Native Computing Foundation (CNCF), est aujourd’hui le standard de facto pour l’orchestration de conteneurs.

Voici les principes fondamentaux qui régissent cette architecture :

• Déclaratif plutôt qu’impératif : vous décrivez l’état souhaité, Kubernetes se charge de l’atteindre
• Réconciliation continue : des boucles de contrôle comparent en permanence l’état actuel à l’état désiré
• Immutabilité : les conteneurs ne sont jamais modifiés en place, ils sont remplacés
• Auto-réparation : si un pod tombe, le système le redémarre automatiquement

Pour bien saisir cette architecture, pensez à une entreprise : le control plane est la direction qui prend les décisions stratégiques, et les worker nodes sont les équipes opérationnelles qui exécutent le travail. Si vous travaillez déjà avec des solutions cloud, je vous recommande de consulter mon article sur l’infrastructure cloud computing pour comprendre comment Kubernetes s’intègre dans un écosystème plus large.

Le control plane : cerveau du cluster Kubernetes

Le control plane héberge les composants qui prennent les décisions globales concernant le cluster. En production, ces composants sont répliqués sur 3 à 5 nœuds pour assurer la haute disponibilité. Détaillons chaque élément.

kube-apiserver : la porte d’entrée unique

L’API Server est le seul composant avec lequel vous interagissez directement via kubectl. Il expose une API REST qui valide et configure les objets Kubernetes (pods, services, deployments). Chaque requête passe par trois étapes : authentification, autorisation (RBAC) et admission control.

# Vérifier que l'API Server répond
kubectl cluster-info

# Lister les ressources disponibles via l'API
kubectl api-resources

etcd : la mémoire persistante

etcd est une base de données clé-valeur distribuée qui stocke l’intégralité de l’état du cluster. C’est le composant le plus critique : si etcd est corrompu, le cluster entier est perdu. En production, je recommande toujours un cluster etcd dédié avec des disques SSD et une latence réseau inférieure à 10 ms entre les nœuds.

kube-scheduler : le planificateur intelligent

Quand vous créez un pod, le scheduler détermine sur quel nœud il doit tourner. Il évalue chaque nœud selon des critères comme les ressources disponibles (CPU, RAM), les affinités, les taints et tolerations, puis attribue un score. Le nœud avec le meilleur score remporte le pod.

kube-controller-manager : les boucles de contrôle

Ce composant exécute les contrôleurs qui surveillent l’état du cluster. Parmi les plus importants :

• ReplicaSet controller : maintient le nombre de réplicas souhaité
• Node controller : surveille la santé des nœuds (timeout de 40 secondes par défaut)
• Endpoint controller : met à jour les endpoints des services
• ServiceAccount controller : crée les comptes de service par défaut

Les worker nodes : là où vos applications tournent

Les worker nodes sont les machines qui exécutent réellement vos conteneurs. Chaque nœud embarque trois composants essentiels qui collaborent pour maintenir les pods en vie.

kubelet : l’agent local

Le kubelet est un agent qui tourne sur chaque nœud du cluster. Il reçoit les spécifications de pods (PodSpecs) depuis l’API Server et s’assure que les conteneurs décrits sont en fonctionnement. Il effectue des health checks réguliers (liveness, readiness et startup probes) et rapporte l’état du nœud au control plane toutes les 10 secondes.

kube-proxy : le routage réseau

kube-proxy maintient les règles réseau sur chaque nœud. Il permet la communication entre les services et les pods en utilisant soit iptables, soit IPVS (plus performant au-delà de 1 000 services). C’est grâce à lui que le Kubernetes NodePort fonctionne, exposant vos services sur un port fixe de chaque nœud.

Container runtime : le moteur d’exécution

Depuis la version 1.24, Kubernetes ne supporte plus Docker directement comme runtime. Les options actuelles sont :

• containerd : le choix par défaut, léger et performant
• CRI-O : développé par Red Hat, optimisé pour Kubernetes
• gVisor / Kata Containers : pour l’isolation renforcée

# Vérifier le runtime utilisé sur un nœud
kubectl get nodes -o wide

# Inspecter la capacité d'un nœud
kubectl describe node mon-noeud | grep -A 5 "Capacity"

En termes de dimensionnement, un worker node typique en production dispose de 4 à 16 vCPU et 8 à 64 Go de RAM. Le choix dépend de la nature de vos workloads. Pour comprendre les enjeux de dimensionnement dans le cloud, consultez mon comparatif on-premise vs cloud computing.

Communication et réseau dans le cluster

Le réseau est sans doute l’aspect le plus complexe de l’architecture Kubernetes. Trois types de communication coexistent dans un cluster, et chacun obéit à des règles précises.

Communication pod-à-pod

Kubernetes impose une règle fondamentale : chaque pod reçoit sa propre adresse IP et peut communiquer avec n’importe quel autre pod sans NAT. Cette contrainte est implémentée par un plugin CNI (Container Network Interface) comme Calico, Cilium ou Flannel.

Communication service-à-pod

Les Services Kubernetes fournissent une IP virtuelle stable (ClusterIP) qui répartit le trafic vers les pods sous-jacents. Même si les pods meurent et renaissent avec des IP différentes, le service reste accessible à la même adresse.

Communication externe vers le cluster

Pour exposer vos applications au monde extérieur, plusieurs mécanismes existent :

• NodePort : expose le service sur un port (30000-32767) de chaque nœud
• LoadBalancer : provisionne un load balancer cloud
• Ingress : routage HTTP/HTTPS avec règles de path et de host

La documentation officielle Kubernetes sur le réseau détaille chaque mode d’exposition avec des exemples concrets.

DNS interne

CoreDNS fournit la résolution de noms à l’intérieur du cluster. Chaque service est accessible via nom-service.namespace.svc.cluster.local. C’est ce qui permet aux microservices de se découvrir sans coder en dur des adresses IP.

Services, volumes et exposition des applications

Au-delà de l’orchestration pure, Kubernetes gère le stockage persistant et l’exposition réseau de vos applications. Ces deux aspects sont essentiels pour toute application stateful en production.

Les Kubernetes volumes en détail

Par défaut, le stockage d’un conteneur est éphémère : il disparaît à la mort du pod. Les Kubernetes volumes résolvent ce problème en attachant du stockage persistant. L’architecture utilise trois abstractions :

• PersistentVolume (PV) : une ressource de stockage provisionnée par l’administrateur
• PersistentVolumeClaim (PVC) : une demande de stockage par un pod
• StorageClass : un profil de provisionnement dynamique

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-data
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: fast-ssd
  resources:
    requests:
      storage: 50Gi

Les 4 types de Service Kubernetes

Chaque type de service répond à un besoin spécifique d’exposition :

Pour approfondir la configuration des services, je vous invite à lire mon guide dédié aux Kubernetes Services qui couvre chaque type avec des exemples déployables.

Déployer une architecture Kubernetes en production

Passer d’un cluster de développement à une architecture de production demande de la rigueur. Voici les points que je vérifie systématiquement avec mes étudiants lors de leurs projets de fin d’année.

Haute disponibilité du control plane

Un control plane hautement disponible nécessite :

• 3 nœuds master minimum (nombre impair pour le quorum etcd)
• Un load balancer devant les API Servers
• Des snapshots etcd automatisés toutes les 30 minutes
• Des nœuds master répartis sur des zones de disponibilité distinctes

Dimensionnement des worker nodes

Je recommande de prévoir 20 à 30 % de capacité supplémentaire par rapport à la charge nominale. Cela permet d’absorber les pics de trafic et de tolérer la perte d’un nœud sans impact sur les performances. Les solutions GPU cloud computing sont particulièrement pertinentes si vos workloads incluent du machine learning.

Sécurité du cluster

Les bonnes pratiques de sécurité incluent :

• Activer le RBAC et appliquer le principe du moindre privilège
• Utiliser des Network Policies pour segmenter le trafic
• Scanner les images conteneur avec Trivy ou Snyk
• Chiffrer les secrets avec un KMS externe
• Activer l’audit logging sur l’API Server

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress

Kubernetes vs Terraform, CI/CD et autres outils

Je constate souvent une confusion entre Kubernetes et d’autres outils DevOps. Clarifions les choses une bonne fois pour toutes.

Kubernetes vs Terraform : quelle différence ?

Terraform provisionne l’infrastructure (serveurs, réseaux, bases de données managées) tandis que Kubernetes orchestre les applications conteneurisées sur cette infrastructure. Ils ne sont pas concurrents mais complémentaires. En pratique, vous utilisez Terraform pour créer votre cluster Kubernetes (EKS, GKE, AKS), puis Kubernetes pour déployer vos applications dessus.

Kubernetes est-il un outil CI ou CD ?

Kubernetes n’est ni CI ni CD à proprement parler. C’est une plateforme d’exécution. Cependant, il s’intègre parfaitement dans une chaîne CI/CD :

• CI (Continuous Integration) : GitLab CI, GitHub Actions ou Jenkins construisent et testent vos images
• CD (Continuous Delivery) : ArgoCD ou Flux déploient ces images sur Kubernetes via GitOps

Kubernetes fournit les primitives (rolling updates, canary deployments) qui rendent le déploiement continu possible, mais il a besoin d’un outil dédié pour piloter le processus.

Peut-on apprendre Kubernetes en 2 jours ?

Soyons honnêtes : en 2 jours, vous pouvez comprendre les concepts fondamentaux et déployer une application simple sur Minikube. Mais maîtriser la production (réseau, sécurité, observabilité, scaling) demande plusieurs mois de pratique. Mon conseil : commencez par un cluster local avec kind ou minikube, déployez une application stateless, puis ajoutez progressivement de la complexité.

Pour automatiser vos tâches d’administration, le scripting Bash reste un allié précieux au quotidien avec Kubernetes.

Bonnes pratiques pour une architecture résiliente

Après avoir déployé et maintenu des clusters pour différents projets, voici les pratiques que j’enseigne systématiquement à mes étudiants et que j’applique moi-même.

Resource requests et limits

Toujours définir des requests (garantie de ressources) et des limits (plafond) pour chaque conteneur. Sans cela, un pod gourmand peut asphyxier tout un nœud.

resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
  limits:
    cpu: "1000m"
    memory: "512Mi"

Observabilité

Un cluster sans observabilité est un cluster en sursis. La stack standard comprend :

• Prometheus + Grafana pour les métriques
• Loki ou Elasticsearch pour les logs centralisés
• Jaeger ou Tempo pour le tracing distribué

Stratégies de mise à jour

Kubernetes propose plusieurs stratégies de déploiement. Le rolling update est le défaut : il remplace les pods un par un, garantissant zéro downtime. Pour des déploiements plus sophistiqués, le canary deployment envoie un faible pourcentage du trafic vers la nouvelle version avant de basculer complètement.

Namespace et isolation

Structurez votre cluster avec des namespaces logiques : production, staging, monitoring. Appliquez des ResourceQuotas par namespace pour éviter qu’une équipe ne consomme toutes les ressources. Cette isolation logique, combinée à des Network Policies, offre un bon niveau de sécurité multi-tenant.

Si vous hésitez entre héberger votre cluster en interne ou dans le cloud, mon comparatif on-premises vs cloud computing vous aidera à trancher selon vos contraintes budgétaires et réglementaires.

Lucie Moreau

Formatrice IT indépendante depuis 2016, ancienne étudiante BTS SIO SLAM. 6 ans d'expérience en entreprise.