C’est une fonction distincte de la conteneurisation elle-même, qui consiste à empaqueter une application avec ses dépendances dans un format standard. Les différences entre Docker et Kubernetes reposent précisément sur cette distinction : Docker fabrique et exécute les conteneurs, Kubernetes les orchestre. Aujourd’hui, Kubernetes est l’orchestrateur de référence, mais l’orchestration en tant que concept existe indépendamment de l’outil qui la met en œuvre.
Pourquoi l’orchestration existe ?
Faire tourner trois conteneurs sur un serveur ne demande pas d’orchestration. On démarre, on supervise à l’œil, on redémarre à la main si quelque chose plante. Le problème change de nature à partir du moment où une application devient un système distribué : plusieurs services, plusieurs machines, du trafic variable, des déploiements fréquents. Les questions opérationnelles qui apparaissent alors sont concrètes. Sur quelle machine placer ce nouveau conteneur ? Que faire si un nœud tombe la nuit ? Comment passer de la version 1.4 à la 1.5 sans interruption visible ? Comment un service interne en trouve un autre quand les adresses IP changent à chaque redémarrage ?
Chacune de ces questions a une réponse manuelle possible, scriptable même. L’orchestration consiste à les automatiser de manière cohérente, sous un modèle unique.
Les cinq fonctions principales de l’orchestration
Kubernetes traite ces questions via un modèle déclaratif construit sur des boucles de réconciliation : on décrit l’état souhaité du système, et l’orchestrateur compare en permanence cet état désiré à l’état réel pour les rapprocher. Les cinq fonctions qui suivent sont des instanciations de ce mécanisme général.
Scheduling : placer les conteneurs sur les bonnes machines
Le scheduling répond à une question : quand un nouveau conteneur doit démarrer, sur quelle machine du cluster doit-il s’exécuter ? Sur un cluster de quelques nœuds aux profils homogènes, la décision est triviale. Sur un cluster réel, elle ne l’est pas : certaines machines ont du GPU, d’autres pas, certaines sont déjà chargées, certaines applications doivent être isolées, d’autres doivent au contraire être co-localisées pour des raisons de latence.
Le composant kube-scheduler effectue ce choix en deux étapes : filtering, qui élimine les nœuds qui ne peuvent pas accueillir le pod (capacité insuffisante, contraintes d’affinité, taints et tolerations), et scoring, qui note les nœuds restants selon plusieurs critères. Le pod est ensuite assigné au nœud retenu via une opération de binding auprès de l’API server. La qualité de la décision dépend des informations fournies au scheduler. Ce sont les requests de ressources déclarées sur les pods qui déterminent le placement : le scheduler cherche un nœud dont la capacité disponible couvre ces requests. Les limits, elles, ne servent pas au placement mais plafonnent la consommation d’un conteneur une fois qu’il tourne.
Scaling : ajuster la capacité au trafic réel
Le scaling automatise une décision simple à formuler : combien de copies d’un service doivent tourner à un instant donné ? Trop de copies coûte cher. Trop peu provoque des incidents au moindre pic.
Le scaling est une fonction commune à tous les orchestrateurs ; les mécanismes varient selon l’implémentation. Dans Kubernetes, il repose sur trois briques distinctes. Le Horizontal Pod Autoscaler (HPA), inclus dans le cœur de Kubernetes, ajuste le nombre de pods d’un déploiement en fonction d’une métrique. Il s’appuie pour cela sur le Metrics Server, un composant à installer séparément, car la collecte de métriques n’est pas fournie par défaut. Le Vertical Pod Autoscaler (VPA), livré lui aussi comme projet séparé, ajuste les ressources allouées à chaque pod. Le Cluster Autoscaler, enfin, ajoute ou retire des nœuds entiers selon les besoins agrégés. Ces mécanismes supposent des métriques fiables : un HPA piloté sur le CPU, alors que le service est en réalité contraint par les I/O disque, ne produit pas le résultat attendu.
Self-healing : remplacer ce qui tombe
À partir d’un certain nombre de machines, les pannes ne sont plus des événements exceptionnels mais une donnée d’arrière-plan. Un disque défaille, un kernel panic survient, un conteneur fuit de la mémoire et finit OOM-killed. Sans orchestration, chaque panne déclenche une intervention humaine, plus ou moins urgente. Avec orchestration, ces événements sont absorbés sans intervention.
Au sein de Kubernetes, le mécanisme repose sur deux éléments. D’abord, des sondes (liveness, readiness, startup) qui lui permettent de savoir si un conteneur fonctionne réellement, et pas seulement s’il a démarré. Ensuite, le principe que tout objet géré par un controller (Deployment, StatefulSet, DaemonSet) est en permanence comparé à l’état désiré : si un pod disparaît, le controller en demande un nouveau. La précision des sondes conditionne la qualité du self-healing : des sondes trop strictes provoquent des redémarrages inutiles, des sondes trop laxistes laissent passer des conteneurs cassés.
Service discovery et load balancing interne
Dans un parc de conteneurs en mouvement, où chaque pod a une adresse IP éphémère, deux services qui doivent communiquer ne peuvent pas s’appuyer sur des configurations IP statiques. Le service discovery résout ce problème par une couche d’indirection. Dans Kubernetes, un objet Service regroupe un ensemble de pods (sélectionnés par labels) sous un nom DNS stable et une IP virtuelle. CoreDNS, le serveur DNS interne du cluster, résout ces noms. Le trafic envoyé à l’IP du Service est distribué entre les pods prêts via kube-proxy. Ce principe n’est pas propre à Kubernetes : d’autres orchestrateurs répondent au même besoin autrement. Sur Clever Cloud, par exemple, les services se découvrent via l’injection de configuration entre applications et via les Network Groups, un réseau privé chiffré doté d’une résolution DNS interne.
Plusieurs types de Services existent (ClusterIP pour l’interne, NodePort et LoadBalancer pour l’externe), auxquels s’ajoute la notion d’Ingress pour le routage HTTP au niveau applicatif. Cette couche réseau, simple en apparence, contient une part substantielle de la complexité d’exploitation de Kubernetes : choix du plugin CNI, politiques réseau, observabilité du trafic est-ouest.
Rolling updates et rollbacks
Mettre en production une nouvelle version sans interrompre le service est une opération risquée si elle est faite à la main. Kubernetes la traite comme une transition d’état : on modifie le manifeste du Deployment pour pointer vers la nouvelle version d’image, et le controller applique la stratégie de rollout configurée.
La stratégie RollingUpdate (par défaut) remplace progressivement les anciens pods par des nouveaux, en garantissant qu’un nombre minimal reste disponible à tout moment. La stratégie Recreate arrête tout puis redémarre, utile pour des migrations de schéma incompatibles. En cas d’échec, le rollout ne revient pas seul à l’état antérieur : il s’interrompt, les nouveaux pods qui échouent aux sondes ne remplacent pas les anciens, et c’est un opérateur qui déclenche le retour à la version précédente avec kubectl rollout undo. La condition pour que cela fonctionne est que les versions soient compatibles entre elles pendant la transition, ce qui implique une discipline côté contrats d’API et migrations de base de données.
Au-delà des cinq fonctions de base
L’orchestration de Kubernetes ne se limite pas à ces cinq fonctions. En pratique, un cluster Kubernetes en production gère aussi la configuration applicative (ConfigMaps), les secrets (avec ou sans chiffrement au repos), le stockage persistant via les PersistentVolumeClaims, l’autorisation (RBAC), l’isolation réseau (NetworkPolicies), l’observabilité (logs, métriques, traces), et la gestion du cycle de vie des certificats. Chacune de ces fonctions est elle-même une responsabilité opérationnelle qui s’ajoute au socle.
Sans orchestrateur vs avec Kubernetes : comparaison fonction par fonction
| Fonction | Sans orchestrateur | Avec Kubernetes |
|---|---|---|
| Scheduling | Placement manuel ou scripts d’allocation custom | kube-scheduler avec contraintes déclaratives |
| Scaling | Provisioning manuel ou règles externes | HPA, VPA, Cluster Autoscaler |
| Self-healing | Supervision externe et scripts de redémarrage | Sondes intégrées et controllers |
| Service discovery | Fichiers de configuration, Consul, etcd à part | Services et DNS interne natifs |
| Rolling updates | Scripts de déploiement custom et bascule manuelle de load balancer | Deployment controller et stratégies déclaratives |
Le tableau ne hiérarchise pas les deux colonnes. Il montre que Kubernetes fournit un modèle unifié pour ces cinq fonctions, là où une approche sans orchestrateur les traite séparément avec des outils différents. Pour un système qui n’a pas besoin de cette unification, la colonne de gauche reste pertinente.
Pratiques fréquentes à connaître
Choisir l’outil en fonction du besoin, pas par défaut. Toutes les applications n’ont pas besoin de scheduling, de scaling automatique ou de service discovery au niveau qu’offre Kubernetes. Un PaaS, un déploiement sur VM, ou un binaire systemd répondent à de nombreux besoins avec un autre modèle d’exploitation.
Penser l’observabilité dès le départ. Un cluster Kubernetes sans logs centralisés, sans métriques agrégées et sans traces devient rapidement difficile à exploiter au-delà de quelques services. L’observabilité fait partie intégrante de l’orchestration, pas d’un ajout optionnel.
Définir requests et limits avant d’activer l’autoscaling. Le HPA et le Cluster Autoscaler s’appuient sur les ressources déclarées des pods pour décider du scaling. Sans déclaration, leurs décisions reposent sur des informations partielles.
Soigner la configuration des sondes. Les liveness et readiness probes conditionnent à la fois le self-healing et l’acheminement du trafic. Une configuration approximative dégrade ces deux fonctions simultanément.
Quand l’orchestration Kubernetes devient pertinente
Aucune des cinq fonctions, prise isolément, ne justifie d’introduire Kubernetes dans un système. Un script de déploiement, un load balancer correctement configuré, un outil de monitoring avec restart automatique peuvent couvrir individuellement chacune d’elles. Ce qui justifie l’adoption d’un orchestrateur, c’est le moment où les cinq fonctions deviennent simultanément nécessaires sur une infrastructure suffisamment distribuée pour rendre les solutions ad hoc coûteuses à maintenir.
Concrètement, cela correspond à des architectures avec une dizaine de services ou plus, déployés sur plusieurs machines, avec des cycles de déploiement fréquents, des variations de charge significatives et des exigences de résilience qui ne tolèrent plus l’intervention manuelle. Pour des contextes plus contraints en ressources (edge, IoT, machines de développement, petits clusters), une distribution Kubernetes allégée comme K3s peut convenir. Un PaaS répond également à ces besoins, comme à bien d’autres profils d’applications (déploiement industrialisé, scaling automatique, résilience, mises à jour), avec un modèle d’exploitation distinct de Kubernetes.
Lorsque Kubernetes devient pertinent, la question suivante porte rarement sur l’installation et plus souvent sur l’exploitation au quotidien : mises à jour du control plane, gestion d’etcd, rotation des certificats, observabilité, sauvegardes. C’est ce constat qui explique l’adoption croissante des services Kubernetes managés. Côté Clever Cloud, Clever Kubernetes Engine répond à ce besoin avec Materia etcd, une implémentation serverless de l’API etcd bâtie sur FoundationDB qui prend le relais de l’etcd standard, devenu un goulot d’étranglement à grande échelle, sur une infrastructure souveraine répartie sur nos trois datacenters parisiens.
L’orchestration de conteneurs en synthèse
L’orchestration de conteneurs automatise plusieurs catégories de décisions opérationnelles, dont cinq grandes classes principales : où placer un conteneur, quand en démarrer plus, que faire quand l’un d’eux tombe, comment ils se trouvent entre eux, comment passer d’une version à la suivante sans interruption. Kubernetes regroupe ces fonctions sous un modèle unifié, ce qui en fait l’outil de référence pour les systèmes distribués qui en ont besoin simultanément. La question utile, face à un projet, n’est pas de savoir si on doit faire de l’orchestration, mais lesquelles de ces fonctions sont réellement nécessaires, et à quel niveau d’automatisation.
FAQ – Kubernetes orchestration
Quelle est la différence entre conteneurisation et orchestration ?
La conteneurisation empaquette une application et ses dépendances dans un format standardisé exécutable de manière identique sur n’importe quel hôte compatible. L’orchestration automatise la gestion d’un parc de conteneurs en production : placement, scaling, self-healing, service discovery, mises à jour. Docker est l’outil de référence pour la première, Kubernetes pour la seconde.
Faut-il forcément Kubernetes pour orchestrer des conteneurs ?
Non. Kubernetes est l’orchestrateur le plus largement adopté, mais d’autres existent : Nomad de HashiCorp, qui orchestre conteneurs, VM et binaires dans un même cluster, ou Docker Swarm, toujours maintenu mais dont l’adoption a reculé. Apache Mesos, longtemps cité comme alternative, a été retiré dans l’Apache Attic en octobre 2025 et n’est plus en développement actif. Par ailleurs, un PaaS comme Clever Cloud assure l’ensemble de ces fonctions d’orchestration (placement, scaling automatique, self-healing, rolling updates, service discovery) avec son propre control plane, indépendant de Kubernetes. C’est ce control plane qui orchestre aussi bien les applications exécutées en VM que les conteneurs du runtime Docker de la plateforme.
L’orchestration de conteneurs est-elle nécessaire pour CI/CD ?
Non, mais elle est souvent utilisée conjointement. Les pipelines CI/CD modernes produisent des images de conteneurs comme artefact final, et l’orchestrateur (Kubernetes ou autre) prend le relais pour déployer et exploiter ces images. CI/CD et orchestration sont deux étapes complémentaires du cycle de vie applicatif.
K3s permet-il l’orchestration en environnement contraint ?
Oui. K3s est une distribution Kubernetes certifiée CNCF, conçue pour les environnements aux ressources limitées (edge, IoT, machines de développement, petits clusters). Elle conserve les API standards de Kubernetes tout en réduisant l’empreinte ressources et la complexité de déploiement.
Un Kubernetes managé change-t-il les fonctions d’orchestration disponibles ?
Non. Un Kubernetes managé fournit le même ensemble de fonctions d’orchestration qu’un cluster auto-hébergé, puisqu’il s’agit du même Kubernetes. La différence porte sur la répartition des responsabilités opérationnelles : le fournisseur prend en charge la gestion du control plane, les mises à jour, la supervision sous-jacente. Les utilisateurs se concentrent alors sur leurs workloads applicatifs.
Quelle est la fonction d’orchestration la plus difficile à maîtriser ?
Le réseau est fréquemment cité comme la plus complexe. Service discovery, load balancing interne, NetworkPolicies, Ingress, plugin CNI, observabilité du trafic est-ouest : la couche réseau de Kubernetes concentre une part significative des sujets opérationnels avancés et reste une source fréquente d’incidents en production.