Kubernetes (souvent abrégé en K8s) est un orchestrateur de conteneurs open source devenu le standard de facto pour déployer, exécuter et opérer des applications conteneurisées à grande échelle. Issu du projet interne Borg de Google, le code source a été ouvert en juin 2014, puis donné à la Cloud Native Computing Foundation (CNCF) en juillet 2015 où il est devenu le tout premier projet "graduated" en mars 2018. Kubernetes automatise la planification des conteneurs sur un parc de machines, gère la résilience (auto-restart, auto-scaling, rolling updates), expose les services au réseau, distribue la configuration et les secrets, et orchestre le stockage persistant via des interfaces standardisées (CRI, CNI, CSI). En 2026, Kubernetes équipe la quasi-totalité des plateformes cloud-native modernes : EKS (AWS), AKS (Azure), GKE (Google Cloud), OpenShift (Red Hat), Rancher (SUSE), Tanzu (VMware) ainsi que d'innombrables clusters on-premises basés sur Kubeadm, Talos Linux ou K3s. Sa puissance s'accompagne cependant d'une complexité opérationnelle réelle qui exige une stratégie de sécurité robuste, un durcissement RBAC rigoureux et une chaîne d'observabilité mature pour éviter les pièges classiques (RBAC trop permissif, secrets en clair, container escape, supply chain compromise).

L'essentiel en 30 secondes

  • Quoi : orchestrateur de conteneurs open source, projet CNCF graduated
  • Origine : Borg (Google) → open source 2014 → CNCF 2015 → graduated 2018
  • Architecture : Control Plane (API server, etcd, scheduler, controller-manager) + Worker nodes (kubelet, kube-proxy, container runtime)
  • Version actuelle : v1.35 (2026), cycle de release ~3 mois
  • Standards : CRI (runtime), CNI (réseau), CSI (stockage)
  • Sécurité critique : RBAC, NetworkPolicies, Pod Security Standards, secrets management
  • Limites : steep learning curve, surcoût opérationnel pour workloads simples

Définition : qu'est-ce que Kubernetes ?

Kubernetes est une plateforme open source d'orchestration de conteneurs qui automatise le déploiement, la mise à l'échelle et l'administration d'applications conteneurisées sur un cluster de machines. Le mot Kubernetes vient du grec ancien κυβερνήτης (kubernētēs) signifiant "pilote" ou "timonier" — d'où l'icône emblématique du logo en forme de barre à roue à sept rayons (clin d'œil à Star Trek : "Project Seven of Nine").

Plus concrètement, Kubernetes fournit :

  • Une API déclarative : on décrit l'état désiré d'un système (3 réplicas de cette image, exposée sur le port 80) et Kubernetes converge vers cet état en boucle de réconciliation
  • Un planificateur (scheduler) qui place les conteneurs sur les nœuds disponibles selon les ressources, contraintes et affinités
  • Une auto-cicatrisation : redémarrage des conteneurs morts, remplacement des pods sur les nœuds défaillants, vérifications de santé (liveness, readiness, startup probes)
  • Un service discovery et load balancing intégrés via les objets Service et Ingress
  • Un système d'extensibilité via les Custom Resource Definitions (CRD) et le pattern Operator

Kubernetes est sous licence Apache 2.0, écrit en Go, et son développement est piloté par la Cloud Native Computing Foundation, qui héberge également Prometheus, Envoy, etcd, Helm, ArgoCD et plus de 150 projets cloud-native.

Histoire : de Borg à Kubernetes v1.35

L'histoire de Kubernetes commence à l'intérieur de Google avec Borg, un système d'orchestration interne développé dès 2003 pour gérer les flottes massives de conteneurs (Linux cgroups était lui-même issu de Google). Borg avait un successeur expérimental nommé Omega. Trois ingénieurs Google — Joe Beda, Brendan Burns et Craig McLuckie — ont initié en 2013 un projet baptisé "Project Seven" visant à porter les principes de Borg dans un produit open source.

Chronologie clé :

  • Juin 2014 : annonce publique du projet Kubernetes par Google
  • Juillet 2015 : sortie de Kubernetes v1.0 et donation à la nouvelle Cloud Native Computing Foundation (CNCF), créée conjointement par Google et la Linux Foundation
  • 2016 : v1.5 introduit StatefulSet, première gestion native des charges stateful
  • Mars 2018 : Kubernetes devient le tout premier projet "graduated" de la CNCF
  • 2019-2020 : adoption massive en entreprise, généralisation des distributions managées (EKS, AKS, GKE)
  • 2022 : v1.24 supprime définitivement Dockershim, marquant la fin de Docker comme runtime direct
  • 2024 : v1.31 stabilise Pod Security Standards et l'API CSI Snapshot
  • 2026 : v1.35 consolide les User Namespaces, le sidecar pattern stable et les avancées de KEP-4639 sur la résilience cluster

Pour approfondir les nouveautés récentes, voir notre analyse de Kubernetes 1.35 et les User Namespaces.

Architecture : Control Plane et Worker Nodes

Un cluster Kubernetes se compose de deux types de nœuds : les nœuds du Control Plane (cerveau du cluster) et les Worker nodes (où s'exécutent les charges de travail).

Control Plane

  • kube-apiserver : front-end REST/gRPC du cluster, point d'entrée unique de toute l'API Kubernetes. Toutes les actions (kubectl, contrôleurs internes, dashboards) passent par là
  • etcd : base de données clé-valeur distribuée (consensus Raft) qui stocke l'intégralité de l'état du cluster. Composant critique : sa perte = perte du cluster
  • kube-scheduler : décide sur quel nœud chaque pod nouveau sera placé selon les ressources, les contraintes (nodeSelector, affinity, taints/tolerations) et les politiques de placement
  • kube-controller-manager : exécute les boucles de contrôle (Deployment controller, ReplicaSet controller, Node controller, ServiceAccount controller, etc.) qui réconcilient l'état réel vers l'état désiré
  • cloud-controller-manager : isole la logique spécifique au cloud provider (création de load balancers, attachement de volumes, gestion des routes réseau)

Worker Nodes

  • kubelet : agent installé sur chaque nœud, il reçoit les manifests de pods de l'API server et instruit le container runtime de les exécuter. Il rapporte aussi l'état du nœud et des pods
  • kube-proxy : maintient les règles réseau (iptables, IPVS ou eBPF) qui implémentent les Services et le load-balancing intra-cluster
  • Container runtime : containerd, CRI-O ou autres runtimes implémentant l'interface CRI

L'ensemble communique via l'API server, qui authentifie chaque appel (mTLS, ServiceAccount tokens, OIDC) et applique les règles RBAC avant toute opération.

Objets fondamentaux Kubernetes

Kubernetes manipule des "objets" via son API déclarative. Voici les abstractions essentielles :

  • Pod : unité atomique de déploiement, regroupe un ou plusieurs conteneurs partageant le même namespace réseau et stockage. Un pod a une IP unique dans le cluster
  • ReplicaSet : garantit qu'un nombre N de pods identiques tournent en permanence (rarement utilisé directement, géré par Deployment)
  • Deployment : abstraction de plus haut niveau qui gère les ReplicaSets et orchestre les rolling updates et rollbacks
  • StatefulSet : équivalent de Deployment pour les charges stateful (bases de données), avec identité stable, ordre de démarrage et stockage persistant attaché
  • DaemonSet : exécute exactement un pod sur chaque nœud (typique pour les agents log/monitoring/réseau)
  • Job / CronJob : exécution batch ponctuelle ou planifiée
  • Service : abstraction réseau stable (IP virtuelle ClusterIP, NodePort, LoadBalancer, ExternalName) qui expose un ensemble de pods sélectionnés par labels
  • Ingress : règles de routage HTTP/HTTPS (host, path) vers les services internes, avec terminaison TLS et load balancing L7
  • Gateway API : successeur d'Ingress, plus expressif et standardisé (GA depuis v1.30)
  • ConfigMap : configuration non-sensible injectable dans les pods (variables d'env, fichiers montés)
  • Secret : variante de ConfigMap pour données sensibles (encodées base64, chiffrées at-rest si etcd encryption configurée)
  • Namespace : cloisonnement logique d'objets dans un même cluster (multi-tenant léger)
  • PersistentVolume / PersistentVolumeClaim : abstraction du stockage persistant via CSI

Container Runtimes : containerd, CRI-O

Kubernetes ne lance pas lui-même les conteneurs : il délègue cette tâche à un container runtime via la Container Runtime Interface (CRI), une API gRPC standardisée depuis 2016.

  • containerd : runtime extrait du daemon Docker, devenu projet CNCF graduated. Standard de facto en 2026 sur EKS, GKE, AKS, K3s
  • CRI-O : runtime minimaliste développé par Red Hat, standard sur OpenShift
  • Docker (deprecated) : avant Kubernetes v1.24, Docker était utilisé via un shim (dockershim). Depuis v1.24, le shim a été supprimé : Docker n'est plus runtime direct, mais containerd (qui est sous le capot de Docker) reste utilisé
  • gVisor / Kata Containers : runtimes "sandboxés" qui ajoutent une couche d'isolation supplémentaire (microVM Kata, user-space kernel gVisor) pour les workloads multi-tenant ou hostiles

CNI : Container Network Interface

Le réseau Kubernetes repose sur un modèle plat : chaque pod a une IP unique, accessible directement depuis tout autre pod du cluster. Cette implémentation est déléguée à un plugin CNI.

  • Calico : CNI mature basé sur BGP, supporte les NetworkPolicies riches et eBPF dataplane optionnel
  • Cilium : CNI eBPF-native, leader 2026 pour l'observabilité (Hubble), la sécurité L7 et le service mesh sans sidecar
  • Flannel : CNI simple, overlay VXLAN, utilisé par défaut dans K3s
  • Weave Net : CNI mesh, mais le projet est en mode maintenance depuis 2024
  • AWS VPC CNI : alloue directement des IPs ENI VPC aux pods sur EKS
  • Azure CNI : équivalent pour AKS, intégration native avec les vNets Azure
  • Multus : meta-CNI permettant à un pod d'avoir plusieurs interfaces réseau

Le choix du CNI conditionne les capacités de NetworkPolicy, l'observabilité et les performances. Cilium est devenu en 2026 le choix par défaut pour les nouveaux clusters exigeants.

CSI : Container Storage Interface

Le stockage persistant est abstrait via la Container Storage Interface (CSI), qui permet à n'importe quel fournisseur de stockage d'écrire un driver utilisable par Kubernetes.

  • Rook-Ceph : opérateur Kubernetes pour Ceph (block, file, object), stockage distribué cloud-native
  • Longhorn : stockage block distribué léger, développé par Rancher/SUSE, projet CNCF
  • OpenEBS : container-attached storage (CAS), plusieurs moteurs (Mayastor, cStor, Jiva, LocalPV)
  • AWS EBS CSI : volumes EBS dynamiques sur EKS
  • Azure Disk / Azure File CSI : équivalent sur AKS
  • GCE Persistent Disk CSI : équivalent sur GKE
  • Portworx : solution commerciale stockage cloud-native, populaire en multi-cluster

Les fonctionnalités CSI avancées (snapshots, clonage, expansion en ligne, raw block) sont GA depuis v1.24.

Distributions managées : EKS, AKS, GKE

En 2026, la majorité des clusters Kubernetes en production sont managés par un fournisseur cloud, qui prend en charge le Control Plane, les mises à jour et la haute disponibilité.

  • Amazon EKS (AWS) : Control Plane managé, intégration IAM, AWS VPC CNI, EBS CSI, EKS Anywhere pour on-prem
  • Azure AKS (Microsoft) : intégration Azure AD, Azure Policy, GitOps Flux managé, Workload Identity
  • Google GKE (Google Cloud) : pionnier des distributions managées, Autopilot mode (sans gestion de nœuds), Anthos pour le multi-cluster hybride
  • Red Hat OpenShift : distribution Kubernetes enrichie (Routes, BuildConfig, ImageStream, OAuth intégré, Operator Hub), disponible en self-managed (OCP) et managé (ROSA, ARO, OpenShift Dedicated)
  • SUSE Rancher : suite multi-cluster (Rancher, RKE2, K3s, Longhorn, NeuVector), forte présence Edge
  • VMware Tanzu : distribution multi-cluster avec Tanzu Mission Control, intégrée à vSphere
  • DigitalOcean DOKS, Linode LKE, Scaleway Kapsule, OVHcloud Managed Kubernetes : alternatives cloud souverain

Distributions on-premises : Kubeadm, Talos, K3s

Pour les déploiements on-premises, edge ou self-hosted, plusieurs distributions répondent à des besoins distincts.

  • Kubeadm : outil officiel d'amorçage de cluster, génère la PKI, déploie le Control Plane, joint les workers. Base de la plupart des distributions on-prem
  • Talos Linux : OS minimaliste immuable, sans SSH, configuré uniquement par API gRPC, dédié à Kubernetes. Réduit drastiquement la surface d'attaque
  • K3s : distribution ultra-légère (binaire unique < 60 MB), idéale pour Edge, IoT, ARM, dev local. Maintenue par CNCF (graduated en 2024)
  • K0s : alternative à K3s, single binary, sans dépendance OS
  • MicroK8s : distribution Canonical, snap-based, avec add-ons one-click
  • Kind (Kubernetes-in-Docker) : clusters locaux via conteneurs Docker, idéal pour CI/CD et dev
  • Minikube : cluster mono-nœud local, plusieurs drivers (Docker, KVM, VirtualBox, Hyper-V)
  • RKE2 / Rancher Kubernetes Engine 2 : distribution durcie CIS-compliant, certifiée FIPS, populaire dans les environnements gouvernementaux

Sécurité Kubernetes : RBAC, NetworkPolicy, Pod Security

La sécurité d'un cluster Kubernetes repose sur plusieurs couches complémentaires. Notre guide de durcissement cluster Kubernetes détaille la mise en œuvre complète.

RBAC (Role-Based Access Control)

Activé par défaut depuis v1.6, le RBAC contrôle qui peut faire quoi sur quelle ressource. Quatre objets clés :

  • Role : permissions au sein d'un namespace
  • ClusterRole : permissions cluster-wide
  • RoleBinding : associe un Role à un sujet (User, Group, ServiceAccount) dans un namespace
  • ClusterRoleBinding : association cluster-wide

Les erreurs RBAC sont la première source de compromission : voir les 10 erreurs RBAC critiques et notre guide complet de sécurisation RBAC. Côté offensif, l'analyse des techniques RBAC offensives couvre l'escalade de privilèges.

NetworkPolicies

Par défaut, tous les pods d'un cluster peuvent communiquer entre eux. Les NetworkPolicies (implémentées par le CNI) permettent de définir des règles ingress/egress par labels, namespaces, IP blocks. Cilium étend ce modèle aux couches L7 (HTTP, gRPC, Kafka).

Pod Security Standards (PSS)

Depuis v1.25, les Pod Security Standards remplacent les PodSecurityPolicies. Trois niveaux prédéfinis (Privileged, Baseline, Restricted) appliqués par namespace via le Pod Security Admission controller. Restricted bloque par défaut hostPath, hostNetwork, runAsRoot, capabilities dangereuses.

Admission policies : OPA Gatekeeper et Kyverno

  • OPA Gatekeeper : moteur de policies basé sur Rego, validation et mutation des objets à la création
  • Kyverno : alternative cloud-native, policies en YAML, plus accessible que Rego
  • ValidatingAdmissionPolicy : mécanisme natif Kubernetes (CEL) GA depuis v1.30, alternative légère sans webhook

Outils de sécurité Kubernetes

  • Falco : détection runtime CNCF graduated, surveille syscalls via eBPF et alerte sur comportements anormaux. Voir notre analyse de Falco
  • Trivy : scanner de vulnérabilités tout-terrain (images, IaC, K8s manifests, SBOM). Détails dans notre guide Trivy
  • Kubescape : scanner de posture cluster, mapping NSA-CISA hardening, MITRE ATT&CK Containers
  • Kube-bench : audit CIS Kubernetes Benchmark automatisé
  • Polaris : audit best practices configurations
  • Kubeaudit : audit ciblé sécurité workloads
  • NeuVector : firewall L7 cloud-native, packet inspection, image scanning, runtime enforcement
  • Tetragon : observabilité runtime eBPF (Cilium), enforcement noyau temps réel

Attaques typiques sur Kubernetes

Les clusters Kubernetes mal configurés constituent des cibles privilégiées. Pour un audit complet, voir notre offre audit Kubernetes et pentest Kubernetes.

  • Container escape : exploitation d'une CVE runtime (runc CVE-2019-5736, leaky vessels CVE-2024-21626), d'un montage hostPath dangereux ou d'une capability excessive (CAP_SYS_ADMIN) pour s'évader vers le nœud hôte
  • RBAC privilege escalation : abus de permissions trop larges (verbs * sur secrets, escalation via impersonate, bind, escalate). Un ServiceAccount avec accès à create pods + un compte privilégié = pwned
  • Secrets exposure : Secrets Kubernetes en clair dans etcd (sans EncryptionConfiguration), exposition via logs, montage dans des conteneurs compromis
  • Supply chain : injection dans une image Docker base, compromission d'une chart Helm, registries non signées (mitigé par Sigstore Cosign et admission policies signature)
  • API server exposé : ports 6443 / 8001 (kubectl proxy) exposés à Internet, dashboards sans authentification
  • Kubelet compromis : port 10250 exposé sans authentification permet exec arbitraire sur les pods du nœud
  • etcd non chiffré : accès direct à etcd = lecture/modification de tout l'état du cluster
  • Crypto-mining : exploitation classique sur clusters mal sécurisés exposés (Tesla, Capital One)

Compliance : CIS Benchmark, PCI-DSS, NIS2, GDPR

  • CIS Kubernetes Benchmark : référentiel ~120 contrôles (master, etcd, control plane, worker, policies). Audit automatisable avec Kube-bench. Versions par distribution (Vanilla, EKS, GKE, AKS, OpenShift)
  • NSA-CISA Kubernetes Hardening Guidance : guide officiel américain, mapping MITRE ATT&CK
  • PCI-DSS v4.0 : applicable aux clusters traitant des données cartes (segmentation réseau, chiffrement at-rest et in-transit, journalisation)
  • NIS2 (UE) : impose la gestion des risques sur les infrastructures critiques, dont les clusters K8s en production
  • GDPR / RGPD : Secrets / ConfigMaps avec PII, logs, exigent classification, chiffrement et droit à l'oubli
  • SOC 2, ISO 27001 : exigences sur le contrôle d'accès, la traçabilité, la gestion des changements

Helm : le package manager Kubernetes

Helm (CNCF graduated 2020) est le standard pour packager, distribuer et déployer des applications Kubernetes. Une "chart" Helm est un ensemble de templates YAML paramétrables (values.yaml). Helm v3 (sans Tiller) est la version actuelle.

  • Repos publics : Bitnami, Artifact Hub (~13 000 charts)
  • Commandes : helm install, helm upgrade, helm rollback, helm template
  • Helmfile / Helmwave : surcouche déclarative pour gérer plusieurs releases
  • Alternatives : Kustomize (overlays YAML natifs), Carvel ytt, Cue

Operator pattern : étendre Kubernetes

Le pattern Operator, introduit par CoreOS en 2016, encode la connaissance opérationnelle d'une application dans un contrôleur Kubernetes. Il combine :

  • Custom Resource Definitions (CRD) : nouvelles ressources métier (ex: PostgreSQLCluster, KafkaTopic, CertificateRequest)
  • Controllers personnalisés : boucle de réconciliation qui crée/supprime/maintient les sous-ressources

Operators populaires en 2026 : Prometheus Operator, cert-manager, External Secrets Operator, ArgoCD, Strimzi (Kafka), CloudNativePG (PostgreSQL), Crossplane (cloud resources as CRDs). Frameworks : Operator SDK, Kubebuilder, Metacontroller, KUDO.

GitOps : ArgoCD et Flux

Le GitOps (terme introduit par Weaveworks en 2017) consiste à utiliser Git comme source de vérité unique pour l'état désiré du cluster. Un agent dans le cluster réconcilie en continu vers cet état.

  • ArgoCD : projet CNCF graduated, UI riche, multi-cluster, ApplicationSets, RBAC fin, sync waves, Helm/Kustomize/Jsonnet supportés
  • Flux v2 : projet CNCF graduated, modèle plus modulaire (Source, Kustomize, Helm, Notification, Image controllers), GitOps Toolkit
  • Avantages : auditabilité (chaque changement = commit), rollback trivial, environnement reproductible, séparation CI/CD propre
  • Outils complémentaires : Argo Rollouts (canary, blue-green), Argo Workflows (CI cloud-native), Argo Events

Limites et complexité de Kubernetes

Kubernetes est puissant mais loin d'être universel. Connaître ses limites évite des choix d'architecture désastreux.

  • Steep learning curve : maîtriser networking pod-to-pod, RBAC, CSI, ingress, observabilité demande des mois. Une équipe DevOps Kubernetes coûte cher
  • Surcoût opérationnel : un cluster minimal (3 nœuds Control Plane HA + workers) consomme déjà 6-10 vCPU et plusieurs GB de RAM rien que pour le système. Disproportionné pour un site vitrine ou une API simple
  • Charges stateful complexes : bases de données distribuées sur K8s exigent operators matures + stockage performant + savoir-faire backup/restore
  • Surface d'attaque : nombreuses CVEs runtime, RBAC, supply chain. Sans hardening, c'est une cible facile
  • Débogage parfois difficile : comprendre pourquoi un pod ne démarre pas peut nécessiter de creuser scheduler events, kubelet logs, CNI logs, CSI events
  • Alternatives plus simples : pour des charges légères, considérer Nomad, Docker Swarm, AWS ECS Fargate, Cloud Run, Fly.io, Render

FAQ Kubernetes

Quelle différence entre K3s et Kubernetes standard ?

K3s est une distribution conforme Kubernetes (certifiée CNCF) mais ultra-légère (~60 MB binaire unique) qui remplace etcd par SQLite par défaut, supprime certains plugins cloud non utilisés, et bundle Traefik / Flannel / Local-path-provisioner. Idéal pour Edge, IoT, ARM (Raspberry Pi), dev local. Pour les clusters production multi-cloud avec haute charge, le Kubernetes standard reste préféré.

Le RBAC est-il obligatoire en production ?

Oui, sans discussion. Activé par défaut depuis v1.6, désactiver le RBAC revient à offrir un accès cluster-admin à toute compromission. La vraie question n'est pas "RBAC oui ou non" mais "RBAC fin et auditable" — principe du moindre privilège, ServiceAccounts dédiés par application, pas de cluster-admin partagé. Voir notre guide RBAC.

EKS, AKS ou GKE : lequel choisir ?

Trois leaders comparables sur les fondamentaux. GKE reste le plus mature (Google a inventé Kubernetes), avec Autopilot mode unique et un Control Plane robuste. EKS domine par la part de marché AWS et l'écosystème (Fargate, Karpenter, EKS Anywhere). AKS excelle dans l'intégration Azure AD / Microsoft 365 et coûte souvent moins cher en Europe. Le choix se fait surtout sur l'écosystème cloud existant de l'entreprise, pas sur Kubernetes en lui-même.

Kubernetes vs Docker Swarm : Swarm a-t-il encore un sens ?

Docker Swarm reste fonctionnel et plus simple à appréhender, mais son écosystème s'est largement éteint depuis 2020. Mirantis (qui détient Docker Swarm Enterprise) maintient le produit mais ne l'évolue plus activement. En 2026, Kubernetes a 95%+ du marché de l'orchestration de conteneurs. Swarm peut convenir pour 2-5 nœuds en interne, mais tout projet à pérenniser doit choisir Kubernetes ou Nomad.

Comment sécuriser efficacement un cluster Kubernetes ?

Six axes incontournables : (1) RBAC strict, ServiceAccounts dédiés, pas de cluster-admin partagé ; (2) NetworkPolicies par défaut deny-all + règles explicites ; (3) Pod Security Standards niveau Restricted en namespaces non-système ; (4) Secrets chiffrés at-rest (EncryptionConfiguration) + External Secrets Operator avec Vault/AWS SM/Azure KV ; (5) Image scanning Trivy + signing Cosign + admission policy ; (6) Runtime detection Falco + audit logs centralisés. Voir notre guide complet de durcissement.

Kubernetes consomme-t-il toujours plus de ressources avec le temps ?

Le Control Plane a un coût fixe (1-2 vCPU + 2-4 GB RAM par nœud master HA), indépendant de la charge. Côté workers, l'overhead par nœud est ~5% (kubelet, kube-proxy, CNI agent, monitoring). Le vrai surcoût vient des add-ons (logging, monitoring, service mesh, ingress controllers) qui peuvent consommer 20-30% des ressources d'un petit cluster. Sur les gros clusters (50+ nœuds), l'overhead relatif devient négligeable.

Liens approfondis et ressources

Nos ressources Kubernetes

Nos services

Ressources officielles