Pods, Deployments, Helm, autoscaling, AKS, EKS, GKE : maîtrisez les concepts fondamentaux de Kubernetes et déployez en production. Guide complet par Smile.
Selon l'enquête annuelle 2025 de la CNCF, 82 % des organisations utilisant des conteneurs font tourner Kubernetes en production, contre 66 % en 2023 — et 98 % des répondants déclarent avoir adopté des pratiques cloud native. En quelques années, Kubernetes est passé du statut de projet Google à celui de standard mondial de l'infrastructure cloud native.
Ce guide Kubernetes vous explique les concepts fondamentaux, les mécanismes de déploiement en production et les choix d'architecture qui font la différence entre un cluster stable et un cluster ingérable.
Qu'est-ce que Kubernetes ?
Kubernetes (ou K8s en abrégé) est la plateforme de conteneurisation et d'orchestration open source de référence, créée par Google et donnée à la Cloud Native Computing Foundation (CNCF) en 2014. Elle automatise le déploiement, la mise à l'échelle, la haute disponibilité et la gestion des applications conteneurisées en production.
Son rôle est de répondre à une question simple : comment faire fonctionner des dizaines, des centaines ou des milliers de conteneurs en production, de manière fiable et automatisée ?
Kubernetes vs Docker : la distinction essentielle
Docker et Kubernetes sont complémentaires, pas concurrents.
Docker package une application et ses dépendances dans une image portable et reproductible, indépendante des systèmes d'exploitation sous-jacents.
Kubernetes orchestre des conteneurs à grande échelle. Il décide où et comment les déployer, les redémarre en cas de panne, les scale selon la charge et gère leur réseau et leur stockage.
Docker Swarm est la solution native d'orchestration de Docker, mais Kubernetes s'est imposé comme le standard de l'industrie pour les déploiements en production à grande échelle. En résumé : Docker construit et exécute un conteneur. Kubernetes gère des flottes de conteneurs en production.
Kubernetes et le DevOps
Kubernetes est l'infrastructure native du DevOps moderne. Il rend possible le déploiement continu à grande échelle en s'intégrant dans les pipelines CI/CD, en automatisant les rolling updates, les rollbacks et la gestion des ressources. Sans orchestration, le déploiement de microservices à grande échelle reste un processus manuel et risqué.
Les concepts fondamentaux de Kubernetes
Comprendre Kubernetes commence par maîtriser ses briques de base.
Pod Kubernetes : l'unité atomique
Le Pod Kubernetes est la plus petite unité déployable dans la plateforme. Il contient un ou plusieurs conteneurs qui partagent le même réseau et le même stockage local. En pratique, un Pod contient généralement un seul conteneur applicatif.
Les Pods sont éphémères par nature. Kubernetes les crée, les détruit et les recrée automatiquement selon les besoins. On ne gère jamais un Pod directement en production.
Node et Cluster : l'infrastructure
Un Node est une machine physique ou une machine virtuelle qui exécute des Pods. Un Cluster est l'ensemble des Nodes géré par Kubernetes. Chaque cluster comprend un Control Plane (qui prend les décisions d'orchestration) et des Worker Nodes (qui exécutent les charges de travail).
Deployment : gestion du cycle de vie
Un Deployment est la ressource Kubernetes qui décrit l'état désiré d'une application : quelle image Docker utiliser, combien de réplicas maintenir, quelle stratégie de mise à jour appliquer. Kubernetes se charge en permanence de faire correspondre l'état réel au déploiement décrit.
Si un Pod tombe en panne, le Deployment le recrée automatiquement. Si on modifie le Deployment, Kubernetes applique la mise à jour selon la stratégie définie.
Service : exposition et découverte
Un Service expose un ensemble de Pods sous une adresse IP stable et un nom DNS. Les Pods sont éphémères et changent d'adresse IP à chaque recréation. Le Service abstrait cette instabilité et fournit un point d'accès stable aux applications.
Il existe plusieurs types de Services selon le besoin : ClusterIP (interne au cluster), NodePort (exposition sur chaque Node) et LoadBalancer (exposition via des load balancers cloud).
Namespace : isolation et organisation
Un Namespace est un espace de noms virtuel qui isole les ressources Kubernetes au sein d'un même cluster. Il permet de séparer les environnements (développement, staging, production), les équipes ou les applications dans un cluster partagé, avec des politiques de sécurité et des quotas de ressources distincts.
ConfigMap et Secret : gestion de la configuration
Les ConfigMaps stockent les configurations non sensibles (URLs, paramètres applicatifs) découplées du code. Les Secrets stockent les données sensibles (mots de passe, tokens, certificats) avec un chiffrement au repos. Ces deux ressources permettent d'externaliser la configuration et de la modifier sans reconstruire l'image Docker.
Déployer en production avec Kubernetes
Autoscaling : adapter les ressources à la charge
Kubernetes propose deux mécanismes d'autoscaling.
Le HPA (Horizontal Pod Autoscaler) augmente ou diminue automatiquement le nombre de réplicas d'un Deployment en fonction des métriques de charge (CPU, mémoire, métriques custom). C'est le mécanisme le plus courant pour absorber les pics de trafic.
Le VPA (Vertical Pod Autoscaler) optimise l'allocation des ressources (CPU et mémoire) de chaque Pod en fonction de sa consommation réelle. Il est utile pour optimiser les coûts sans avoir à dimensionner manuellement chaque déploiement.
Rolling updates et rollbacks
Les rolling updates permettent de déployer une nouvelle version d'une application progressivement, Pod par Pod, sans interruption de service. Si la nouvelle version présente des problèmes, un rollback en un seul kubectl permet de revenir instantanément à la version précédente.
C'est l'un des mécanismes les plus précieux de Kubernetes en production : il élimine les fenêtres de maintenance et réduit drastiquement le risque de chaque déploiement.
Ingress : routage du trafic externe
L'Ingress est la ressource Kubernetes qui gère le routage du trafic HTTP/HTTPS entrant vers les services internes. Il permet de définir des règles de routage basées sur le nom de domaine ou le chemin URL, de centraliser la terminaison TLS et de mettre en place des politiques d'authentification.
kubectl : la ligne de commande Kubernetes
kubectl est l'interface en ligne de commande pour interagir avec un cluster Kubernetes. Les commandes kubectl get permettent de lister les ressources (Pods, Services, Deployments). Les commandes kubectl logs donnent accès aux logs d'un Pod en temps réel. C'est l'outil incontournable de tout ingénieur qui opère un cluster Kubernetes au quotidien.
Helm : le gestionnaire de packages Kubernetes
Helm est le gestionnaire de packages de Kubernetes. Il permet de packager, distribuer et déployer des applications Kubernetes complexes via des "charts", des ensembles de templates YAML paramétrables. Plutôt que de maintenir des dizaines de fichiers YAML manuellement, Helm permet de déployer une application complète en une commande et de gérer ses versions.
Kubernetes managé vs auto-hébergé
Les services managés
Les trois grands cloud providers proposent des clusters Kubernetes entièrement managés.
AKS (Azure Kubernetes Service) est la solution Microsoft, particulièrement bien intégrée dans l'écosystème Azure (Active Directory, Azure Monitor, Azure Container Registry). C'est le choix naturel pour les organisations déjà sur Microsoft Azure.
EKS (Elastic Kubernetes Service) est la solution AWS. Sa profondeur d'intégration dans l'écosystème AWS (IAM, CloudWatch, ECR) en fait le choix privilégié des organisations AWS-first.
GKE (Google Kubernetes Engine) est historiquement considéré comme le service managé le plus mature techniquement, ce qui est logique puisque Google est le créateur de Kubernetes. Son mode Autopilotautomatise complètement la gestion des nodes.
Tableau comparatif
CritèreAKSEKSGKEIntégration cloudAzureAWSGCPMaturité KubernetesTrès bonneTrès bonneExcellenteGestion des nodesSemi-managéeSemi-managéeAutopilot disponibleSouveraineté FranceVia BleuNon disponibleVia S3NSComplexité administrationFaibleMoyenneFaibleCoûtComparableComparableLégèrement inférieur
Kubernetes auto-hébergé
Déployer et administrer soi-même un cluster Kubernetes (avec kubeadm, k3s ou Rancher) offre un contrôle total mais impose une charge opérationnelle significative. C'est le choix des organisations avec des contraintes de souveraineté strictes ou qui ne veulent pas dépendre d'un cloud provider. Cela nécessite une équipe avec une expertise Kubernetes approfondie.
Écosystème et outils complémentaires
Service Mesh : Istio et Linkerd
Le service mesh gère la communication entre les services dans le cluster : chiffrement mTLS, circuit breaking, retry automatiques, observabilité du trafic. Istio est le plus complet mais aussi le plus complexe à opérer. Linkerd est plus léger et plus simple à adopter pour les équipes qui démarrent.
Observabilité : Prometheus et Grafana
Prometheus collecte et stocke les métriques de tous les composants du cluster et des applications. Grafana visualise ces métriques dans des tableaux de bord personnalisables. Ensemble, ils constituent le stack d'observabilité de référence de l'écosystème Kubernetes, complété par Jaeger ou Tempo pour le tracing distribué.
GitOps : ArgoCD et Flux
ArgoCD et Flux implémentent le GitOps sur Kubernetes : l'état désiré du cluster est décrit dans Git, et un opérateur synchronise en permanence l'état réel du cluster avec ce qui est décrit dans les fichiers YAML ou les charts Helm versionnés. C'est le standard de facto pour la gestion de la configuration en production.
Smile et Kubernetes : notre expertise cloud native
Chez Smile, nous déployons et opérons des clusters Kubernetes en production depuis les premières versions stables de la plateforme. Notre expertise couvre l'intégralité de la stack : conception de l'architecture du cluster, déploiement sur AKS, EKS ou GKE, mise en place de l'observabilité, implémentation du GitOps avec ArgoCD et sécurisation des clusters en production.
Notre approche est pragmatique. Nous aidons nos clients à choisir entre Kubernetes managé et auto-hébergé selon leurs contraintes réelles de souveraineté, de coût et de maturité opérationnelle. Nous formons aussi les équipes DevOps et les ingénieurs qui découvrent Kubernetes, avec des parcours adaptés à tous les niveaux, du devops junior qui débute jusqu'à l'architecte cloud senior.
Vous souhaitez déployer Kubernetes en production ? Découvrez notre expertise en orchestration Kubernetes.
Questions fréquentes sur Kubernetes
Faut-il obligatoirement utiliser Docker avec Kubernetes ?
Non. Kubernetes supporte plusieurs runtimes de conteneurs via l'interface CRI (Container Runtime Interface) : containerd, CRI-O et Docker (via dockershim, désormais déprécié). En pratique, containerd est le runtime le plus utilisé dans les clusters Kubernetes modernes. Docker reste l'outil de référence pour construire les images conteneurs localement, mais il n'est plus nécessaire en production sur les nodes Kubernetes.
Quelle est la différence entre un Deployment et un StatefulSet ?
Un Deployment gère des applications stateless où chaque réplica est identique et interchangeable. Un StatefulSet gère des applications stateful (bases de données, systèmes de fichiers distribués) où chaque Pod a une identité stable, un stockage persistant propre et un ordre de démarrage et d'arrêt défini. On utilise un Deployment pour une API REST, un StatefulSet pour PostgreSQL ou Elasticsearch.
Comment sécuriser un cluster Kubernetes en production ?
Cinq pratiques fondamentales : activer le RBAC (contrôle d'accès basé sur les rôles) pour limiter les permissions de chaque composant, utiliser des Network Policies pour contrôler le trafic entre Pods, scanner les images conteneurs avant déploiement, activer le chiffrement des Secrets au repos dans etcd, et mettre en place un Pod Security Admission pour empêcher l'exécution de conteneurs avec des privilèges excessifs.
Quand Kubernetes n'est-il pas la bonne solution ?
Kubernetes introduit une complexité opérationnelle significative. Pour une petite équipe avec peu de services, une application à faible trafic ou une startup en phase early, des alternatives plus simples (Docker Compose, AWS Fargate, Fly.io, Railway) offrent un meilleur rapport valeur/complexité. Kubernetes devient pertinent quand les besoins de scalabilité, de haute disponibilité et de déploiement de nombreux microservices justifient l'investissement dans son apprentissage et son opération.