Qu’est-ce qu’un Kubernetes français ?

Un Kubernetes français est un service Kubernetes managé fourni par une entreprise française. Selon les offres, l’infrastructure peut être localisée en France ou dans d’autres pays européens, et selon le fournisseur, il peut reposer sur un cloud public, un cloud privé ou des machines dédiées.

Pourquoi rechercher un Kubernetes français ?

Réduire la dépendance aux hyperscalers

Confier son orchestration à AWS, Google Cloud ou Azure expose à un écosystème propriétaire et à un cadre juridique extra-européen. S'appuyer sur un acteur national limite cette dépendance et nourrit une démarche de souveraineté, au-delà de la seule réversibilité technique.

Maîtriser la localisation de l'infrastructure

Savoir précisément où s'exécutent le control plane et les workers, et sous quelle responsabilité, devient un critère de sélection à part entière pour les secteurs régulés comme pour les acheteurs publics.

Simplifier la conformité

Une infrastructure opérée en Europe peut simplifier certaines démarches de conformité liées à la localisation des données et aux transferts hors Union européenne.

Bénéficier d'un support de proximité

Un interlocuteur dans le même fuseau horaire, une facturation en euros et une documentation en français raccourcissent les délais de résolution et fluidifient la relation contractuelle.

Les principales offres Kubernetes françaises

Les descriptions ci-dessous reflètent l'état des offres au moment de la rédaction. Ces services évoluent vite : vérifiez toujours la page officielle du fournisseur avant une décision.

OVHcloud Managed Kubernetes Service (MKS)

OVHcloud propose MKS, son Kubernetes managé en cloud public, décliné en deux niveaux. MKS Free met à disposition un control plane managé gratuit. MKS Standard, lancée en septembre 2025, ajoute un SLA de 99,99 % avec un control plane réparti sur une région 3-AZ (Paris d'abord, puis Milan), un stockage etcd dédié pouvant atteindre 8 Go et le choix de la CNI, dont Cilium. L'offre s'intègre à l'écosystème Public Cloud OVHcloud.

Scaleway Kubernetes Kapsule

Kapsule est un Kubernetes managé en cloud public, certifié CNCF. Le control plane mutualisé est gratuit, avec une option de control plane dédié pour les charges critiques, et l'autoscaling est natif. L'offre s'intègre aux services Scaleway et met en avant un positionnement de souveraineté et de conformité RGPD pour le marché européen.

Clever Kubernetes Engine (CKE)

CKE est le Kubernetes managé de Clever Cloud. Le service repose sur une infrastructure située en France, sans dépendance à un hyperscaler étranger. Chaque cluster s'exécute sur ses propres VM, sans mutualisation entre clients ; la répartition du control plane est configurable selon la topologie choisie, d'un bundle tout-en-un jusqu'à une VM par composant. L’expérience reste fidèle à Kubernetes, sans mécanisme de verrouillage ni réécriture des manifestes. L’état du cluster est stocké dans Materia etcd, une implémentation du protocole etcd développée en France et bâtie sur FoundationDB. CKE s’intègre aux bases de données managées, au stockage objet compatible S3, à l’IAM, à l’observabilité et au réseau privé via Network Groups. Le produit est actuellement en bêta publique.

OVHcloud, Scaleway, Clever Cloud : le comparatif

Les offres Kubernetes françaises reposent sur des architectures et des modèles d’exploitation différents. Les critères les plus utiles pour les comparer sont la localisation de l’infrastructure, le mode d’hébergement, les garanties de disponibilité, le niveau d’intégration aux services cloud et la compatibilité avec l’écosystème Kubernetes standard.

Aucune de ces offres n'est supérieure dans l'absolu : le bon choix dépend du modèle d'exploitation recherché et du niveau de garantie attendu.

Kubernetes français ou hyperscaler (AWS, Google, Azure) ?

AWS EKS, Google GKE et Azure AKS restent les services Kubernetes managés les plus complets en matière de catalogue annexe et de portée mondiale. En contrepartie, ils renforcent la dépendance à leur écosystème. Une offre française répond aux mêmes besoins d'orchestration tout en gardant le control plane et les données sous droit européen.

Les offres françaises placent l'infrastructure en France ou en Europe, sous droit européen, avec une intégration locale. Les hyperscalers offrent un catalogue de services plus large et une présence mondiale, au prix d'une dépendance accrue à leur écosystème.

Les critères généraux de sélection d'un cluster managé, indépendants de la dimension nationale (politique de versions, autoscaling, stockage, modèle de responsabilité) méritent par ailleurs un examen à part entière.

Ce qu'il faut retenir

Le meilleur Kubernetes français dépend avant tout de votre contexte. Certaines organisations privilégieront une offre en disponibilité générale avec des garanties contractuelles fortes, tandis que d’autres rechercheront une intégration poussée avec leur plateforme cloud ou leur environnement existant. OVHcloud, Scaleway et Clever Cloud proposent aujourd’hui des approches différentes de Kubernetes managé. Le choix dépend principalement des contraintes d’exploitation, de gouvernance, de conformité et du niveau de maturité attendu.

FAQ

Existe-t-il des fournisseurs français de Kubernetes managé ?

Oui. Plusieurs entreprises françaises proposent des offres Kubernetes managées, notamment OVHcloud (Managed Kubernetes Service), Scaleway (Kubernetes Kapsule) et Clever Cloud (Clever Kubernetes Engine). Ces solutions se distinguent par leur modèle d’infrastructure, leur niveau d’infogérance et leur intégration à l’écosystème cloud du fournisseur.

Kubernetes français ou Kubernetes européen : quelle différence ?

Un Kubernetes français est fourni par une entreprise française ; un Kubernetes européen l’est par une entreprise établie dans l’Union européenne. Dans les deux cas, il convient d’examiner la localisation effective de l’infrastructure, l’opérateur réel du service et le droit applicable aux données.

Un Kubernetes français est-il forcément souverain ?

Non. La nationalité de l’éditeur ne suffit pas à garantir la souveraineté. Celle-ci dépend notamment de l’opérateur de l’infrastructure, des sous-traitants impliqués dans la chaîne d’hébergement et du cadre juridique auquel ils sont soumis.

Peut-on utiliser Helm et Terraform avec un Kubernetes français ?

Oui, dès lors que l’offre repose sur une implémentation standard de Kubernetes. Les services proposés par OVHcloud, Scaleway et Clever Cloud restent compatibles avec les outils courants de l’écosystème tels que kubectl, Helm, Terraform ou les approches GitOps.

Kubernetes français ou AWS EKS : lequel choisir ?

AWS EKS bénéficie d’un vaste catalogue de services cloud et d’une présence mondiale. Les offres françaises mettent généralement en avant une exploitation réalisée en Europe, un support de proximité et une intégration avec des infrastructures opérées localement. Le choix dépend des contraintes techniques, réglementaires et organisationnelles de chaque projet.

Quelle différence entre un Kubernetes managé et un Kubernetes auto-hébergé ?

La principale différence réside dans la responsabilité de l’exploitation. Avec un Kubernetes managé, le fournisseur opère le control plane et prend en charge une partie de la maintenance de la plateforme. Avec un Kubernetes auto-hébergé, l’organisation reste responsable de l’installation, des mises à jour, de la supervision, de la sécurité et de la disponibilité du cluster. Le Kubernetes managé réduit la charge opérationnelle, tandis que l’auto-hébergement offre un contrôle plus important sur l’infrastructure.

Peut-on migrer d’un fournisseur Kubernetes à un autre ?

Oui, à condition d’utiliser une implémentation standard de Kubernetes. Les manifestes YAML, charts Helm et outils de déploiement restent généralement portables d’un fournisseur à l’autre. Certaines dépendances spécifiques (stockage, réseau, services managés) peuvent toutefois nécessiter des adaptations.

Quel Kubernetes français pour une PME ?

Le choix dépend des besoins du projet. Une PME peut privilégier une offre disposant d’un control plane gratuit pour ses premiers déploiements, ou rechercher une intégration plus poussée avec un écosystème cloud particulier. La compatibilité standard de Kubernetes facilite dans tous les cas l’évolution vers une autre offre si les besoins changent.

Le control plane regroupe les composants standards de Kubernetes : apiserver, etcd (le datastore qui contient l'état du cluster), scheduler et controller-manager. Sa défaillance ne stoppe pas les workloads déjà en cours d'exécution, mais fait perdre le pilotage du cluster : plus de déploiements, plus de scaling, plus de réponse aux commandes kubectl. C'est précisément cette couche que les offres managées soustraient à la responsabilité des équipes.

Pourquoi Kubernetes est-il difficile à opérer soi-même ?

Kubernetes est un standard d'orchestration de conteneurs, pas un produit clé en main. Déployer un cluster sans couche managée implique de gérer :

• les mises à jour de version (le projet Kubernetes maintient les trois dernières versions mineures en support actif) ;
• la rotation des certificats TLS internes ;
• la haute disponibilité du control plane sur plusieurs nœuds ;
• la sauvegarde et la cohérence du datastore etcd ;
• les correctifs de sécurité, souvent sous contrainte de temps.

Ces tâches sont répétitives, consommatrices de temps d'ingénierie, et sources d'incidents lorsqu'elles sont mal exécutées. Les offres managées ont précisément pour objectif de retirer cette charge des équipes produit.

Cas d'usage : quand Kubernetes managé apporte de la valeur

Kubernetes (managé ou non) devient pertinent dans des contextes précis. Il ne remplace pas systématiquement un PaaS : les deux approches répondent à des besoins différents.

Kubernetes managé est adapté lorsque :

• l'architecture comporte plusieurs services interdépendants qui nécessitent une orchestration fine (rolling updates, gestion des ressources par namespace) ;
• les workloads sont déjà écrits pour Kubernetes et livrés sous forme de charts Helm ou de manifestes YAML ;
• l'équipe a besoin d'environnements multi-cluster ou hybrides (on-premise + cloud) ;
• la charge opérationnelle du control plane représente un coût réel et mesurable pour les équipes SRE ou DevOps.

Un PaaS reste plus adapté lorsque :

• le modèle de déploiement applicatif (push du code, build et run gérés par la plateforme) correspond à votre façon de travailler ;
• vous voulez vous concentrer sur le code applicatif sans piloter les primitives d'orchestration (réseau, scheduling, gestion des nœuds) ;
• vos applications n'ont pas besoin de contrôle fin sur le placement des workloads ou sur la topologie réseau du cluster.

Tableau comparatif : Kubernetes self-managed vs managé vs PaaS

Note : "vanilla" désigne ici une expérience Kubernetes standard, sans modification du comportement natif ni outils propriétaires imposés.

Erreurs fréquentes lors du choix ou de l'adoption de Kubernetes managé

Kubernetes managé en Europe : quels critères de souveraineté ?

Pour les organisations soumises au RGPD, à des contraintes sectorielles (santé, secteur public, défense) ou à des politiques de localisation des données, l'hébergement du cluster est un critère de conformité, pas seulement de performance.

Les points à vérifier :

• localisation physique des datacenters (pays, juridiction applicable) ;
• identité de l'opérateur et présence de sous-traitants étrangers dans la chaîne d'hébergement ;
• certification des infrastructures (SecNumCloud, ISO 27001, HDS selon les fournisseurs et les offres) ;
• accès aux données par des tiers non-européens, notamment au titre de lois extraterritoriales.

Un service Kubernetes managé opéré en France par un acteur français répond à ces contraintes sans configuration supplémentaire côté utilisateur. C'est l'approche retenue par Clever Kubernetes Engine (CKE), opéré de bout en bout en France par Clever Cloud, sans hyperscaler étranger dans la chaîne d'hébergement.

Ce qu'il faut retenir

Kubernetes managé est pertinent dès lors que votre organisation utilise Kubernetes et que la maintenance du control plane représente une charge réelle. Il n'est pas universel : quand le modèle de déploiement d'un PaaS correspond à votre façon de travailler, il reste souvent le choix le plus direct. Pour des besoins de souveraineté européenne, le choix du fournisseur et de sa localisation est déterminant.

Les critères de sélection essentiels sont : la compatibilité vanilla (absence de lock-in), la politique de versionnement, la répartition claire des responsabilités entre fournisseur et utilisateur, et le modèle de coût complet - tarif affiché plus coût d'ingénierie interne.

FAQ

Qu'est-ce que Kubernetes managé ?

Un service dans lequel le fournisseur cloud opère le control plane Kubernetes (provisioning, mises à jour, disponibilité). L'utilisateur gère ses workloads et ses node pools, mais pas l'infrastructure critique du cluster.

Quelle est la différence entre Kubernetes managé et un PaaS ?

Un PaaS prend en charge le build, le déploiement et l'exécution à partir de ce que vous livrez (code source ou image de conteneur) sans que vous ayez à décrire l'orchestration sous-jacente. Kubernetes managé conserve l'interface standard de Kubernetes (kubectl, Helm, manifestes YAML) et vous laisse piloter ces primitives, tout en déléguant l'exploitation du control plane au fournisseur. Les deux approches sont deux modèles opérationnels distincts, complémentaires plutôt que substituables.

Kubernetes managé implique-t-il un risque de lock-in ?

Cela dépend de l'implémentation. Une offre "vanilla" (sans modification du comportement natif de Kubernetes ni imposition d'outils propriétaires) permet de migrer les workloads sans réécriture. A contrario, des CRDs non standards ou des intégrations réseau exclusives peuvent créer une dépendance.

Qui est responsable de quoi dans un cluster Kubernetes managé ?

Le fournisseur opère le control plane : mises à jour, disponibilité, patching. L'utilisateur reste responsable de ses node pools (dimensionnement, scaling), de ses workloads, de la sécurité applicative et des politiques RBAC.

Comment savoir si mon organisation a besoin de Kubernetes managé plutôt que d'un PaaS ?

La question clé est la complexité architecturale. Si vos applications nécessitent une orchestration multi-services, des interactions réseau avancées ou sont déjà conçues pour Kubernetes, le managé est adapté. Si vous déployez des services relativement standards, un PaaS sera plus rapide et moins coûteux à opérer.

Kubernetes managé en France : quelles options souveraines ?

En France, plusieurs acteurs proposent du Kubernetes managé sur une infrastructure souveraine, parmi lesquels Scaleway (Kubernetes Kapsule), OVHcloud (Managed Kubernetes Service) et Clever Cloud avec CKE. Au-delà de la localisation, les critères de différenciation portent sur le niveau de souveraineté réel (opérateur, sous-traitants dans la chaîne d'hébergement), la compatibilité vanilla et le modèle de responsabilité entre fournisseur et utilisateur.

Kubernetes est un orchestrateur de conteneurs, le cloud est l'endroit où on le fait le plus souvent tourner. L'expression « Kubernetes cloud » recouvre donc deux réalités liées : exécuter Kubernetes sur une infrastructure cloud, et s'appuyer sur un service Kubernetes managé opéré par un fournisseur.

Kubernetes n'est pas un cloud

Kubernetes est un orchestrateur de conteneurs open source. Le fonctionnement de Kubernetes repose sur l'orchestration de conteneurs répartis sur un ensemble de machines : il planifie leur placement, les déploie, supervise leur cycle de vie, gère leur mise à l'échelle et leur exposition réseau. Ces conteneurs sont souvent construits avec Docker, et la distinction entre Kubernetes et Docker prête d'ailleurs elle-même à confusion.

Ce que Kubernetes ne fait pas, c'est fournir les machines, le stockage et le réseau sous-jacents. Il a besoin d'une infrastructure pour s'exécuter, et cette infrastructure peut prendre plusieurs formes : des serveurs physiques (bare metal), des machines virtuelles, un cloud privé ou un cloud public. C'est cette couche que fournit un fournisseur cloud.

De là vient une confusion fréquente, celle qui consiste à comparer « Kubernetes » et « AWS », ou Kubernetes et un fournisseur cloud en général. Les deux n'occupent pas la même couche. Un fournisseur cloud vend de l'infrastructure, et propose fréquemment un Kubernetes managé par-dessus. Kubernetes, lui, orchestre les conteneurs qui tournent sur cette infrastructure. On ne choisit pas entre Kubernetes et le cloud : on peut faire tourner Kubernetes sur un cloud, ou utiliser le service Kubernetes managé que ce cloud propose.

Autrement dit, choisir une infrastructure et choisir qui opère le cluster sont deux décisions distinctes. C'est ce qui structure les familles d'offres que nous allons décrire ensuite.

Faire tourner Kubernetes dans le cloud : managé ou auto-géré

Une fois posée cette relation, deux modèles d'exploitation se présentent. Soit vous installez et opérez Kubernetes vous-même sur des machines louées à un fournisseur cloud, soit vous passez par un service managé, où le fournisseur opère le control plane à votre place.

Le control plane est la ligne de partage entre les deux. Il regroupe les composants qui pilotent le cluster : l'apiserver, etcd (le datastore qui conserve l'état du cluster), le scheduler et le controller-manager. L'opérer soi-même implique de gérer les montées de version, que le projet Kubernetes impose de suivre puisqu'il ne maintient en support que ses trois versions mineures les plus récentes, la rotation des certificats TLS internes, la haute disponibilité de ces composants sur plusieurs nœuds, la sauvegarde et la cohérence d'etcd, ainsi que les correctifs de sécurité sous contrainte de temps. Un service managé retire cette couche de vos responsabilités : vous conservez la maîtrise de vos workloads, de vos node pools et de leur sécurité, mais n'administrez plus l'infrastructure critique du cluster.

Tous les besoins ne justifient pas un cluster complet. Des distributions plus légères, comme K3s, existent et méritent d'être évaluées selon la charge et le contexte. Et Kubernetes, managé ou non, reste un modèle opérationnel parmi d'autres. Un PaaS relève d'un autre modèle : vous livrez du code, la plateforme se charge du build, de l'exécution et de la mise à l'échelle, sans que vous ayez à opérer d'orchestrateur. PaaS et Kubernetes répondent à des besoins différents et complémentaires, et une même organisation peut recourir aux deux.

Les trois familles d'offres pour faire tourner Kubernetes dans le cloud

Les offres se répartissent en trois familles : selon que vous opérez le cluster vous-même ou qu'un fournisseur s'en charge, et, dans ce second cas, selon que ce fournisseur est un hyperscaler mondial ou un acteur européen.

Le self-managed sur infrastructure cloud

Vous louez le calcul, le stockage et le réseau auprès d'un fournisseur, puis installez et opérez Kubernetes vous-même. Cette approche offre le contrôle le plus complet sur le cluster et sur l'infrastructure sous-jacente, au prix de la charge opérationnelle décrite plus haut. Elle a du sens lorsque des contraintes précises d'infrastructure, de réseau ou de conformité ne sont pas couvertes par les offres managées disponibles. C'est aussi l'approche des équipes qui veulent garder la main sur chaque composant du cluster, du runtime de conteneurs à la configuration de l'ordonnancement et du réseau interne.

Le managé chez un hyperscaler

Les grands fournisseurs cloud mondiaux proposent des services Kubernetes managés : Amazon EKS, Google GKE, Microsoft AKS. Le fournisseur opère le control plane, et vous déployez vos workloads avec l'outillage standard de Kubernetes. Ces offres sont étroitement intégrées à l'écosystème de chaque fournisseur, ce qui fait leur intérêt lorsque vos autres services y résident déjà, et le point de vigilance si vous envisagez d'en changer. Leurs opérateurs relèvent en revanche de juridictions non européennes, y compris pour les régions qu'ils exploitent en Europe. Ces offres ne répondent donc pas à une exigence de souveraineté européenne, critère déterminant pour certains secteurs et certains types de données.

Le managé chez un fournisseur européen

Plusieurs fournisseurs européens proposent un Kubernetes managé sur une infrastructure située dans l'Union européenne. La localisation compte, mais elle ne fait pas la souveraineté. Un datacenter installé en Europe reste soumis aux législations extraterritoriales si l'entreprise qui l'exploite relève d'une juridiction étrangère : la région européenne d'un fournisseur américain demeure exposée au Cloud Act. Ce qui détermine la souveraineté, c'est le contrôle juridique et capitalistique de l'opérateur, pas l'emplacement des serveurs.

Sur ce terrain, plusieurs acteurs proposent un Kubernetes managé : OVHcloud (Managed Kubernetes Service) ou Scaleway (Kubernetes Kapsule). Clever Cloud propose Clever Kubernetes Engine, un Kubernetes managé opéré par une entreprise française. Au-delà de la localisation, ces offres se distinguent par le niveau réel de souveraineté, qui dépend de l'opérateur et de la chaîne de sous-traitance, et par leur compatibilité avec les outils déjà en place. Pour aller plus loin, les offres françaises de Kubernetes managé font l'objet d'un article dédié.

Kubernetes cloud : ce qu'il faut retenir

« Kubernetes cloud » désigne le fait de faire tourner Kubernetes sur une infrastructure cloud, ainsi que les services managés que les fournisseurs proposent pour éviter d'opérer le cluster soi-même. La ligne de partage entre auto-géré et managé passe par le control plane, cette couche que le fournisseur prend ou non en charge. Trois familles d'offres se présentent alors : le self-managed sur infrastructure cloud, le managé chez un hyperscaler, et le managé chez un fournisseur européen, étant entendu que la localisation en Europe ne suffit pas à elle seule à rendre une offre souveraine. Laquelle convient dépend de vos contraintes d'infrastructure, de l'outillage déjà en place, et de vos exigences en matière de données et de souveraineté. L'essentiel tient en une distinction : le cloud fournit l'infrastructure, Kubernetes orchestre ce qui tourne dessus, et le modèle managé détermine qui, du fournisseur ou de vous, opère le cluster entre les deux.

Reste ensuite à déterminer quand un Kubernetes managé se justifie et comment le choisir, et à préciser ce que recouvre réellement un Kubernetes souverain.

FAQ

Kubernetes est-il un cloud ?

Non. Kubernetes est un orchestrateur de conteneurs, pas un fournisseur d'infrastructure. Un cloud fournit les serveurs, le stockage et le réseau ; Kubernetes orchestre les conteneurs qui s'exécutent dessus. On peut le faire tourner sur un cloud, ou utiliser le service Kubernetes managé qu'un cloud propose.

Peut-on faire tourner Kubernetes en dehors du cloud, sur du bare metal ou de l'on-premise ?

Oui. Kubernetes est agnostique de l'infrastructure : il fonctionne sur des serveurs physiques, des machines virtuelles, un cloud privé ou public, et sur des environnements hybrides combinant plusieurs de ces options. Le cloud est le contexte le plus courant, pas une obligation.

« Kubernetes cloud » et « Kubernetes managé », est-ce la même chose ?

Pas exactement. « Kubernetes cloud » désigne au sens large le fait de faire tourner Kubernetes sur une infrastructure cloud, ce qui inclut aussi bien un cluster que vous opérez vous-même qu'un service managé. « Kubernetes managé » désigne spécifiquement l'offre dans laquelle un fournisseur opère le control plane à votre place. Tout Kubernetes managé est du Kubernetes dans le cloud, mais l'inverse n'est pas toujours vrai.

Quelle différence entre Kubernetes et un fournisseur cloud comme AWS ?

Ils opèrent à des couches différentes. AWS est un fournisseur cloud : il vend de l'infrastructure et propose, par-dessus, un Kubernetes managé (Amazon EKS). Kubernetes est l'orchestrateur qui pilote les conteneurs sur cette infrastructure. Les opposer revient à confondre l'entrepôt et le système qui organise ce qu'on y range.

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

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.

En résumé : K3s est une distribution Kubernetes certifiée CNCF, optimisée pour les environnements contraints (edge, IoT, labs). K8s désigne le projet Kubernetes originel, conçu pour des clusters de production à grande échelle. Le choix dépend de vos ressources disponibles, de votre contexte de déploiement et de votre charge opérationnelle.

K8s : le Kubernetes standard entreprise

K8s est l'abréviation de Kubernetes, le « 8 » représentant les huit lettres entre le « K » et le « s ». Il s'agit du projet open source original, maintenu par la Cloud Native Computing Foundation (CNCF) et initialement développé par Google.

Kubernetes est conçu pour des environnements de production à grande échelle : clusters multi-nœuds, haute disponibilité, intégration avec les clouds publics (AWS, GCP, Azure) ou des datacenters on-premises. Son plan de contrôle comprend plusieurs composants distincts : API server, scheduler, controller manager, etcd, déployés séparément, ce qui offre une flexibilité maximale mais requiert une expertise opérationnelle significative.

Prérequis typiques pour un nœud control plane en production : 2 vCPU et 2 Go de RAM au minimum pour les composants Kubernetes seuls, sans compter etcd ni les charges applicatives.

K3s : une distribution Kubernetes certifiée CNCF, pas un fork

K3s est une distribution certifiée de Kubernetes, pas une version allégée non officielle ni un fork. Créé par Rancher Labs, il a été donné à la CNCF en juin 2020 et passe les mêmes tests de conformité Sonobuoy que toutes les distributions certifiées. Tout manifeste Kubernetes valide fonctionne sur K3s.

Son objectif principal : réduire drastiquement les ressources nécessaires pour faire tourner Kubernetes sur des environnements contraints (edge, IoT, CI/CD, labs)  sans renoncer à la compatibilité API.

Ce que K3s change par rapport à K8s

• Binary unique de moins de 70 Mo (x86, ARM64, ARMv7 et S390X supportés), incluant le runtime containerd, le CNI Flannel, un Ingress Traefik et un load balancer Klipper.
• SQLite comme datastore par défaut en single-node, au lieu d'etcd. En configuration haute disponibilité (3 nœuds serveur minimum), K3s peut utiliser etcd embarqué ou un datastore externe (MySQL, PostgreSQL, etcd externe).
• Composants alpha/beta retirés pour réduire la surface d'attaque et l'empreinte mémoire.

Point important : K3s ne supprime pas etcd ; il le rend optionnel. En single-node, SQLite suffit. En haute disponibilité, etcd embarqué ou externe est supporté - mais ce dernier n'est pas officiellement pris en charge par l'équipe K3s.

Empreinte ressources

K3s fonctionne à partir de 512 Mo de RAM sur un nœud agent. Un server node (control plane) requiert 2 Go de RAM et 2 cœurs CPU selon la documentation officielle (mise à jour mai 2026), hors charge applicative. Un profil mesuré à la charge est disponible dans le guide de resource profiling K3s. À noter : en test sur du matériel avec 1 Go de RAM total, les distributions K3s, k0s et MicroK8s ont montré des instabilités lors du déploiement de charges applicatives réelles (un seul cluster Kubernetes, même léger, consomme des ressources de contrôle non négligeables).

Différences techniques clés

Datastore

Runtime et packaging

K8s ne fournit pas de runtime par défaut depuis la suppression de dockershim (v1.24, 2022). À partir de Kubernetes 1.24, vous devez installer un runtime CRI-compatible (containerd ou CRI-O). K3s embarque containerd directement dans son binaire.

Architecture du plan de contrôle

Dans K8s, les composants du plan de contrôle (API server, scheduler, controller manager) sont des processus séparés. Dans K3s, ils sont fusionnés en un seul binaire, ce qui réduit l'overhead mais limite certaines configurations avancées d'isolation.

Scalabilité

K3s est adapté à des clusters de taille modérée. En configuration haute disponibilité (3 server nodes, 4 vCPU / 8 Go de RAM), la documentation officielle indique une capacité d'environ 1 200 agents. Pour des clusters de très grande taille (plusieurs milliers de nœuds), K8s  reste la référence.

Tableau comparatif K3s vs K8s

Cas d'usage : lequel choisir ?

Choisissez K3s si :

• Vous déployez sur du matériel contraint (Raspberry Pi, appliances industrielles, serveurs edge avec peu de RAM).
• Vous gérez des clusters IoT ou edge distants, potentiellement en mode déconnecté.
• Vous avez besoin d'un cluster de développement ou de CI démarrant rapidement, y compris sur matériel modeste.
• Vous souhaitez un cluster opérationnel avec un minimum de configuration initiale.

Choisissez K8s (ou une distribution enterprise) si :

• Vous orchestrez des centaines ou milliers de nœuds en production.
• Vos workloads requièrent des intégrations cloud-natives avancées (stockage, load balancers, IAM) fournies par les hyperscalers.
• Vous avez besoin de composants API en alpha/beta non disponibles dans K3s.
• Votre organisation dispose d'une équipe SRE dédiée à l'exploitation de clusters.

Cas hybrides : K3s et K8s ensemble

K3s et K8s ne sont pas mutuellement exclusifs. Plusieurs architectures hybrides sont documentées en production :

Fleet management avec Rancher

Des clusters K3s edge sont pilotés depuis un plan de contrôle central tournant sur K8s ou RKE2. The Home Depot (grande distribution américaine, plus de 2 300 magasins) gère ainsi ses sites avec K3s supervisé depuis Rancher.

Clusters de dev et staging K3s, prod K8s

La compatibilité API garantit que les manifests et charts Helm testés sur K3s fonctionnent en production sur un cluster enterprise. Cette parité réduit les surprises en promotion d'environnements.

CI/CD

Des pipelines de test tournent sur K3s (faible coût, démarrage rapide) pendant que les environnements de production utilisent un cluster K8s managé.

Kubernetes managé : une troisième voie

Ni K3s ni K8s ne résolvent la question de l'opération quotidienne : mises à jour, certificats, surveillance du plan de contrôle, gestion des défaillances. C'est précisément ce que couvrent les solutions de Kubernetes managé.

Les hyperscalers (EKS, GKE, AKS) proposent cette gestion dans leurs propres clouds. Mais des solutions managées existent aussi en dehors de ces écosystèmes, notamment pour des organisations qui souhaitent conserver la maîtrise de leurs données et opter pour un Kubernetes souverain, voire un Kubernetes français.

Clever Kubernetes Engine (CKE) est le service Kubernetes managé de Clever Cloud, conçu pour des équipes qui utilisent déjà Kubernetes et souhaitent déléguer la gestion du plan de contrôle (updates, haute disponibilité, monitoring) sans être contraints dans un seul hyperscaler. CKE s'adresse explicitement aux équipes que le modèle PaaS traditionnel ne couvre pas (cas multi-runtime, workloads non-twelve-factor, ou besoin de contrôle granulaire sur les ressources).

FAQ

K3s est-il un fork de Kubernetes ?

Non. K3s est une distribution certifiée CNCF de Kubernetes. Il passe les tests de conformité Sonobuoy et respecte les mêmes APIs que K8s Il n'est pas maintenu en parallèle de Kubernetes : il suit les releases du projet originel.

Peut-on utiliser K3s en production ?

Oui, avec des nuances. K3s est documenté pour des charges de production dans des environnements contraints (edge, IoT). Pour des clusters à grande échelle ou des workloads critiques avec des exigences de SLA élevées, le K8s  (ou une distribution enterprise comme RKE2) est plus adapté.

K3s supporte-t-il Helm ?

Oui. K3s inclut un contrôleur Helm intégré et est compatible avec toute chart Helm valide.

Quelle est la différence entre K3s et K3d ?

K3d est un outil qui fait tourner K3s dans des conteneurs Docker. Il simplifie encore davantage la création de clusters K3s locaux pour le développement, mais n'est pas destiné à la production.

K3s fonctionne-t-il sur ARM ?

Oui. ARM64 et ARMv7 sont nativement supportés, ce qui explique sa popularité sur Raspberry Pi et les appliances industrielles.

Kubernetes managé vs K3s auto-hébergé : quoi choisir ?

K3s auto-hébergé vous donne un contrôle total mais vous rend responsable des opérations (updates, sécurité, haute disponibilité). Un Kubernetes managé délègue cette responsabilité à un opérateur, au prix d'une dépendance envers ce fournisseur. Le choix dépend de vos ressources opérationnelles et de vos exigences de contrôle.

La question Kubernetes vs Docker mérite une réponse précise, parce que les deux technologies ne répondent pas au même besoin.

Docker sert principalement à créer et exécuter des conteneurs. Kubernetes sert à orchestrer ces conteneurs lorsqu’une infrastructure devient plus complexe. Les deux technologies sont donc souvent complémentaires, même si elles sont régulièrement opposées à tort.

Comprendre cette différence permet surtout de mieux savoir quand utiliser Docker seul, quand Kubernetes devient pertinent, et pourquoi toutes les applications n’ont pas forcément besoin d’un cluster Kubernetes.

Docker : standardiser l’exécution d’une application

Docker a popularisé la conteneurisation moderne. Son objectif est simple : permettre à une application de fonctionner de manière identique, quel que soit l'environnement dans lequel elle est exécutée.

Avant Docker, il était fréquent qu'une application fonctionne sur le poste d'un développeur mais rencontre des problèmes une fois déployée sur un serveur. Différences de versions système, dépendances manquantes, configurations incohérentes : ces écarts compliquaient fortement les déploiements.

Docker a largement réduit ce problème en encapsulant une application et ses dépendances dans un conteneur isolé. Concrètement, ce conteneur embarque l'application, ses bibliothèques, ses dépendances, et certains éléments système nécessaires à son exécution.

L'environnement devient alors portable et reproductible. Une image Docker peut être exécutée sur n'importe quelle machine compatible, avec un comportement prévisible. C'est cette standardisation qui explique l'adoption massive de Docker dans les pipelines CI/CD, les environnements de développement et les architectures modernes.

Docker ne sert pas uniquement à “faire tourner des conteneurs”

Dans beaucoup d'équipes, Docker est devenu un outil quotidien. Un développeur peut lancer localement une API Node.js, une base PostgreSQL, Redis ou encore un service Nginx, sans avoir à installer manuellement tous ces composants sur sa machine. Tout est isolé dans des conteneurs indépendants.

Cette approche simplifie énormément le développement local, les tests, les environnements de démonstration, les intégrations continues, et les déploiements applicatifs.

Pour des applications relativement simples, Docker peut suffire à lui seul. C'est notamment le cas lorsqu'une équipe exploite quelques services seulement, une infrastructure limitée, un faible besoin de montée en charge, ou peu d'automatisation d'exploitation. Dans ce contexte, ajouter Kubernetes peut même introduire une complexité inutile.

Là où Docker atteint ses limites

Docker fonctionne très bien pour exécuter des conteneurs. En revanche, il ne résout pas automatiquement les problématiques d'orchestration à grande échelle.

Lorsque le nombre de services augmente, plusieurs questions apparaissent rapidement :

• Comment répartir les conteneurs sur plusieurs serveurs ?
• Comment redémarrer automatiquement un service qui tombe ?
• Comment gérer les mises à jour sans interruption ?
• Comment absorber automatiquement un pic de trafic ?
• Comment superviser des dizaines ou centaines de workloads distribués ?

Docker n'a pas été conçu pour gérer seul ce niveau de complexité opérationnelle. C'est précisément le rôle de l’orchestration de conteneurs, dont Kubernetes est aujourd’hui le standard le plus utilisé.

Kubernetes : automatiser l’exploitation des conteneurs

Kubernetes est un orchestrateur de conteneurs. Son objectif n'est pas de remplacer Docker dans la création des images ou dans la logique de conteneurisation. Kubernetes intervient à un niveau supérieur : celui de l'exploitation et de l'automatisation de l'infrastructure.

Il permet notamment de déployer des applications automatiquement, répartir les workloads sur plusieurs machines, redémarrer des conteneurs en cas de panne, gérer la haute disponibilité, effectuer de l'auto-scaling, piloter des architectures distribuées.

Autrement dit, Docker exécute les conteneurs. Kubernetes organise leur fonctionnement global. Cette différence est essentielle.

Un exemple concret : Docker seul vs Kubernetes

Prenons une plateforme e-commerce moderne. Au départ, l'application peut être relativement simple : un backend, un frontend et une base de données. Docker suffit souvent à faire fonctionner cet ensemble.

Mais avec le temps, l'architecture évolue : plusieurs microservices apparaissent, certaines fonctionnalités doivent scaler indépendamment, des files de messages sont ajoutées, plusieurs environnements doivent être synchronisés, la disponibilité devient critique.

À ce stade, gérer manuellement tous les conteneurs devient rapidement difficile. Kubernetes apporte alors des mécanismes d'automatisation : redémarrage automatique des workloads, répartition des charges, duplication des services, déploiements progressifs, maintien automatique de l'état attendu du cluster.

C'est ce qui explique pourquoi Kubernetes est devenu le standard de facto de l'orchestration cloud-native.

Kubernetes vs Docker : lequel remplace l'autre ?

C'est l'une des questions les plus fréquentes, et la réponse est claire : Kubernetes ne remplace pas Docker.

Pendant longtemps, Kubernetes utilisait Docker comme runtime de conteneurs. Ce n'est plus le cas par défaut. À partir de la version 1.20 (décembre 2020), Kubernetes a déprécié le support direct de Docker via le composant "dockershim". Ce support a été définitivement supprimé dans la version 1.24, publiée en mai 2022. Depuis, Kubernetes s'appuie sur des runtimes compatibles avec l'interface CRI (Container Runtime Interface), comme containerd ou CRI-O.

Ce changement ne concerne pas les développeurs au quotidien. Les images créées avec Docker respectent le standard OCI (Open Container Initiative) et restent parfaitement utilisables sur Kubernetes. Autrement dit, le format d'image n'a pas changé : c'est la couche d'exécution interne au cluster qui a évolué.

En pratique, Docker et Kubernetes continuent de fonctionner ensemble dans de nombreux environnements. Docker sert à construire et tester les images localement. Kubernetes les déploie et les orchestre en production. La confusion vient souvent du fait que Docker était historiquement présent aux deux étapes. Ce n'est plus le cas côté runtime Kubernetes, mais Docker reste très utilisé côté build et développement.

La distinction Kubernetes vs Docker n'est donc pas une question de remplacement, mais de rôle : chacun intervient à une étape différente du cycle de vie d'une application conteneurisée.

Quand utiliser Docker sans Kubernetes ?

Docker seul reste pertinent dans beaucoup de situations. C'est souvent le bon choix pour un projet simple, une application interne, un environnement de développement, un prototype, une petite plateforme web, ou des besoins d'exploitation limités.

Dans ces cas, Kubernetes peut représenter une surcharge opérationnelle importante par rapport au besoin réel. Dans certains cas, une distribution allégée comme K3S peut également être plus adaptée qu’un cluster Kubernetes complet.

Kubernetes n'est pas automatiquement la meilleure réponse pour toutes les applications, c'est d'ailleurs une position explicitement assumée chez Clever Cloud, y compris dans le contexte du lancement de Clever Kubernetes Engine (CKE), un Kubernetes managé développé et opéré par Clever Cloud.

Quand Kubernetes devient réellement utile

Kubernetes devient intéressant lorsque l'architecture nécessite un niveau d'orchestration avancé. C'est notamment le cas lorsque plusieurs services doivent être coordonnés, que les déploiements deviennent fréquents, que la résilience devient critique, que les charges varient fortement, que les équipes utilisent déjà des pratiques GitOps, ou que l'infrastructure devient distribuée ou hybride.Certaines organisations utilisent également Kubernetes pour standardiser leurs déploiements entre plusieurs environnements ou plusieurs fournisseurs cloud. Dans ce contexte, le choix d'un Kubernetes managé devient souvent central pour limiter la dette opérationnelle.

C'est précisément ce type d'usage qui motive le développement de solutions comme CKE, conçu pour rester compatible avec les outils standards de l'écosystème Kubernetes tout en s'intégrant au reste de la plateforme.  

Kubernetes ou PaaS : ce n’est pas toujours un duel

Une autre confusion fréquente consiste à penser que Kubernetes remplace forcément un PaaS (Platform as a Service). Dans la pratique, beaucoup d'applications fonctionnent très bien sur un PaaS classique, avec moins d'exploitation et moins de complexité.

Même dans le cadre de CKE, le positionnement affiché est explicite : Kubernetes ne remplace pas le PaaS. Les deux répondent à des modèles opérationnels différents, pas à des niveaux de complexité différents : le PaaS prend en charge l'exploitation, Kubernetes en donne le contrôle. L'un comme l'autre font tourner des charges de production sérieuses. L'objectif n'est donc pas de mettre systématiquement toutes les applications sur Kubernetes, mais de l'utiliser lorsqu'il apporte une vraie valeur technique ou opérationnelle.

Docker vs Kubernetes : les différences à retenir

Docker et Kubernetes ne sont pas des technologies concurrentes

La question Kubernetes vs Docker n'est pas une question de choix : chacune répond à un besoin distinct à une étape différente du cycle de vie applicatif.

Docker a simplifié la création et l'exécution des applications conteneurisées. Kubernetes a automatisé leur exploitation à grande échelle.

Toutes les applications n'ont pas besoin de Kubernetes. Dans de nombreux cas, Docker seul suffit. Et pour déléguer entièrement l'exploitation, un PaaS prend le relais, y compris sur des architectures distribuées et des exigences de résilience élevées. Kubernetes, lui, devient pertinent lorsqu'on a besoin d'un contrôle explicite sur l'orchestration, d'une intégration avec l'écosystème CNCF ou d'une portabilité multi-cloud sur des standards ouverts. C'est un choix de modèle opérationnel et de besoins d'équipe, pas un niveau de complexité applicative.

L'enjeu n'est donc pas de choisir « Docker ou Kubernetes », mais de reconnaître à partir de quel besoin d'orchestration Kubernetes apporte une réelle valeur.

FAQ

Docker et Kubernetes sont-ils concurrents ?

Non. Docker et Kubernetes répondent à des besoins différents. Docker sert principalement à créer et exécuter des conteneurs, tandis que Kubernetes orchestre leur fonctionnement à grande échelle.

Kubernetes remplace-t-il Docker ?

Non. Depuis la version 1.24 de Kubernetes (mai 2022), Docker n'est plus utilisé comme runtime interne du cluster. Kubernetes s'appuie désormais sur des runtimes compatibles CRI comme containerd ou CRI-O. En revanche, les images Docker, conformes au standard OCI, restent pleinement compatibles avec Kubernetes.

Pourquoi Kubernetes est-il devenu un standard ?

Kubernetes s'est imposé grâce à son modèle déclaratif, sa portabilité entre environnements et l'écosystème cloud-native construit autour de la CNCF, dont il est un projet graduated depuis 2016, notamment avec des outils comme Helm, Prometheus ou ArgoCD.

Quelle différence entre K3S et Kubernetes classique ?

K3S est une distribution Kubernetes allégée, adaptée aux environnements edge, IoT, développement ou petits clusters, avec une consommation de ressources plus faible.

Un Kubernetes managé est-il préférable ?

Dans beaucoup d'organisations, oui. Un Kubernetes managé réduit la charge opérationnelle liée au control plane, aux mises à jour, à la sécurité et à la résilience des clusters. C'est l'approche retenue par Clever Kubernetes Engine.

En une décennie, K8S s'est imposé comme la base technique sur laquelle s'exécute une part majoritaire des applications cloud modernes.

Comment fonctionne Kubernetes : un orchestrateur déclaratif

La plupart des descriptions de Kubernetes énumèrent ses composants, pods, deployments, services, sans expliquer le mécanisme central. Or le concept fondamental est ailleurs : Kubernetes est avant tout un orchestrateur, et son moteur central repose sur des boucles de réconciliation.

Vous ne dites pas à Kubernetes quoi faire. Vous lui dites à quoi vous voulez que votre système ressemble. Cette distinction, déclaratif contre impératif, change tout.

Concrètement, vous décrivez l'état désiré dans des fichiers manifestes, généralement au format YAML : « je veux 3 répliques de cette image, exposées sur le port 80, avec ces variables d'environnement ». Vous envoyez ce manifeste à l'API Kubernetes via kubectl. À partir de là, Kubernetes compare en permanence l'état réel du cluster (ce qui tourne effectivement) à l'état désiré (ce que vous avez déclaré), et agit pour les rapprocher. Si un nœud meurt, ses pods sont reprogrammés ailleurs. Si vous passez de 3 à 10 répliques dans le manifeste, Kubernetes en démarre 7 de plus. Si un conteneur plante, il est redémarré.

Cette boucle de réconciliation est le cœur de tout ce que fait Kubernetes : auto-réparation, scaling, déploiements progressifs (rolling updates), retours arrière. Pour creuser ce mécanisme et les autres fonctions qu'il rend possibles, découvrez en détail à quoi sert l'orchestration de conteneurs.

Architecture en bref : control plane, nodes, pods

Un cluster Kubernetes se divise en deux ensembles. Le control plane est le cerveau : il prend les décisions globales, accepte les requêtes API, planifie les charges de travail, et surveille l'état du cluster. Il s'appuie sur quelques composants clés comme le serveur API (kube-apiserver), le planificateur (kube-scheduler) et le gestionnaire de contrôleurs (kube-controller-manager), ainsi que sur un magasin de données distribué qui mémorise tout l'état du cluster, traditionnellement etcd.

Les nodes sont les machines qui exécutent réellement les charges de travail. Sur chacune, un agent appelé kubelet reçoit ses instructions du control plane et lance les conteneurs via un moteur d'exécution (containerd, CRI-O, etc.). La plus petite unité déployable n'est pas un conteneur isolé mais un pod : un ou plusieurs conteneurs qui partagent un réseau et un stockage. Au-dessus, des objets de plus haut niveau (Deployment, Service, Ingress, ConfigMap, Secret) décrivent comment les pods doivent être gérés, exposés et configurés.

Cette architecture est aussi la source d'une confusion fréquente avec Docker, dont les rôles sont en réalité complémentaires de ceux de Kubernetes plutôt que concurrents.

Pourquoi K8S est devenu le standard de l'orchestration

Selon le CNCF Annual Cloud Native Survey 2025, publié en janvier 2026, 98 % des organisations interrogées ont adopté des techniques cloud native, et 82 % des utilisateurs de conteneurs déploient Kubernetes en production, contre 66 % en 2023. La domination est massive. Mais l'expliquer uniquement par des qualités techniques serait incomplet, c'est aussi une histoire d'écosystème et d'alignement d'intérêts.

Sur le plan technique, trois propriétés expliquent l'adoption. D'abord, le modèle déclaratif décrit plus haut : il rend les déploiements reproductibles, versionnables dans Git, et résistants aux pannes. Ensuite, la portabilité : un même manifeste fonctionne sur une machine de développement (Minikube, kind, k3d), sur un cluster on-premise et sur n'importe quel cloud. Enfin, l'extensibilité : l'API de Kubernetes accepte des objets personnalisés (Custom Resource Definitions) et des contrôleurs personnalisés (Operators), ce qui en a fait une plateforme pour étendre la plateforme. Cet effet a déclenché une dynamique d'écosystème massive.

Sur le plan stratégique, l'histoire est moins racontée. En 2014, Google avait plus d'une décennie d'expérience dans la gestion de conteneurs à grande échelle avec ses systèmes internes Borg et Omega, dont les principes ont été partagés publiquement via des papiers de recherche académiques (Omega en 2013, Borg en 2015). Plutôt que d'open-sourcer Borg lui-même, qui restait étroitement couplé à l'infrastructure Google, l'équipe a créé Kubernetes comme un nouveau projet inspiré de cette expérience, avec une implémentation distincte conçue dès le départ pour une adoption externe. Le projet a été publié en open source en juin 2014 puis donné à la Cloud Native Computing Foundation en 2015. Cette neutralité, un projet hébergé par une fondation Linux et non par un cloud, a été déterminante. Aucun concurrent ne pouvait se permettre de ne pas l'adopter sous peine d'être marginalisé hors de l'écosystème cloud-native naissant. AWS, qui poussait initialement sa propre solution propriétaire (ECS), a annoncé EKS fin 2017 et l'a lancé en disponibilité générale en juin 2018. À ce moment-là, le standard était scellé.

Sur le plan de l'écosystème, l'effet réseau a fait le reste : Helm pour empaqueter les applications, Prometheus pour la supervision, Istio et Linkerd pour le service mesh, ArgoCD et Flux pour le GitOps, Trivy et Falco pour la sécurité. Chaque outil supplémentaire renforce la valeur du standard. Côté ressources humaines, les compétences Kubernetes sont devenues massivement demandées sur les offres DevOps et SRE, ce qui crée un cercle vertueux : plus d'ingénieurs formés, plus d'entreprises qui adoptent, plus d'ingénieurs qui se forment.

Dans le rapport CNCF 2025, la communauté qualifie aujourd'hui Kubernetes de « boring », au sens noble du terme : un outil mature, prévisible, dont les API ne se cassent plus à chaque release. C'est précisément ce qu'on attend d'une infrastructure standard.

Quand utiliser Kubernetes, et quand privilégier le PaaS ?

Le fait que K8S soit le standard ne signifie pas qu'il soit la bonne réponse à tous les problèmes. Choisir Kubernetes, un PaaS, ou une combinaison des deux dépend du contexte technique et organisationnel ; chez Clever Cloud, beaucoup d'équipes utilisent les deux en parallèle pour des workloads différents.

Kubernetes apporte une vraie valeur dans plusieurs contextes :

• portabilité forte attendue : multi-cloud, hybride, on-premise associé à du cloud, où le manifeste Kubernetes devient un dénominateur commun ;
• architectures distribuées qui appliquent les principes du 12-factor app et l'approche « cattle » (instances interchangeables, sans état) avec des besoins d'orchestration sophistiqués ;
• alignement stratégique sur l'écosystème CNCF (Helm, Operators, ArgoCD, Istio…) ou prérequis client / partenaire qui imposent ce standard ;
• besoin d'une plateforme commune pour des équipes nombreuses, avec une équipe plateforme dédiée ou la volonté d'externaliser cette responsabilité à un service managé.

À l'inverse, dans d'autres contextes, un PaaS comme Clever Cloud répond directement aux mêmes besoins que Kubernetes (déploiements industrialisés, autoscaling, résilience) sans la complexité opérationnelle de l'orchestrateur. C'est notamment vrai pour les architectures applicatives classiques (web + backend + base de données) où l'effort de configuration et d'opération de Kubernetes ne se traduit pas en valeur ajoutée concrète.

Et pour les charges intermédiaires (IoT, edge, environnements de développement, petits clusters), les différences entre K3S et K8S méritent d'être pesées avant de trancher : la distribution allégée est souvent plus adaptée. Le standard de facto n'est pas une obligation morale. C'est un outil puissant et coûteux à opérer, dont l'usage doit être choisi en fonction des problèmes qu'il résout, souvent en complément des autres approches plutôt qu'en remplacement.

Les limites du standard : la dette opérationnelle

Faire tourner Kubernetes en production n'est pas trivial. C'est l'une des raisons pour lesquelles beaucoup d'entreprises qui adoptent K8S optent pour un service managé plutôt qu'une installation auto-gérée.

Les sources de complexité sont multiples : configurer correctement le contrôle d'accès (RBAC), choisir et opérer un plugin réseau (CNI), brancher du stockage persistant (CSI), mettre en place une observabilité, gérer les certificats, faire les mises à jour mineures et majeures sans interruption, durcir la sécurité, gérer les sauvegardes du control plane. Chacun de ces sujets est un métier en soi. Le rapport CNCF 2025 montre d'ailleurs que les défis se sont déplacés du purement technique vers l'organisationnel : 47 % des organisations citent désormais les « changements culturels avec l'équipe de développement » comme principal obstacle, devant la complexité technique brute.

Au cœur de cette dette se trouve un composant moins discuté : etcd. C'est la base de données clé-valeur distribuée qui stocke l'état complet du cluster. etcd est solide pour les clusters de taille modérée, mais devient un goulot d'étranglement à l'échelle. Ce n'est pas un hasard si Google a annoncé fin 2024 le remplacement d'etcd par Spanner pour son offre GKE, en conservant uniquement la compatibilité API. AWS, de son côté, a réécrit une « nouvelle génération » de son architecture etcd pour soutenir l'échelle. K3S, conçu pour les environnements légers, a poussé la logique plus loin en proposant plusieurs alternatives à etcd, dont SQLite par défaut. Quand un composant central doit être reconçu pour soutenir l'usage en production, c'est un indice révélateur.

C'est ce constat qui nous a poussés, chez Clever Cloud, à reconsidérer cette pièce. Notre Clever Kubernetes Engine remplace l'etcd standard par Materia etcd, notre réimplémentation du protocole etcd construite sur Materia KV, et FoundationDB, répliquée  sur trois datacenters parisiens. Cette approche, c'est aussi ce qui rend Clever Cloud unique : un control plane multi-tenant qui scale horizontalement sans dégrader les performances, hérite de la simulation continue de pannes de FoundationDB, et libère les équipes de la gestion de milliers d'instances etcd fragiles.

Mais que vous choisissiez CKE ou un autre service, le principe vaut : si vous voulez Kubernetes en production sans bâtir une équipe plateforme dédiée, un Kubernetes managé est presque toujours la bonne décision.

En résumé

Kubernetes s'est imposé comme standard pour de bonnes raisons techniques, mais aussi grâce à un alignement d'intérêts qui a fait converger l'industrie autour d'un projet neutre porté par la CNCF. Le mécanisme central, la boucle de réconciliation et le modèle déclaratif, explique sa robustesse. L'écosystème qui s'est construit autour explique sa pérennité.

Cela ne signifie pas qu'il faut l'adopter pour tout. Pour beaucoup de contextes, un PaaS ou une autre approche est mieux adaptée, et bien souvent, les deux cohabitent dans une même architecture, chacun là où il apporte le plus de valeur. Pour des architectures distribuées sérieuses, il reste l'outil de référence, à condition de mesurer la dette opérationnelle qu'il introduit, et de choisir entre l'opérer soi-même ou s'appuyer sur un service managé.C'est précisément la promesse que Clever Kubernetes Engine, notre Kubernetes managé, cherche à tenir : Kubernetes standard, opéré en France sur une infrastructure souveraine, avec un control plane reconçu pour éliminer la friction d'etcd à l'échelle. Et pour les équipes qui n'ont pas besoin de Kubernetes, notre PaaS reste la voie la plus directe vers la mise en production.

FAQ

K8S et Kubernetes, c'est la même chose ?

Oui. K8S est une abréviation : la lettre K, les huit lettres d'« ubernete » condensées en 8, et la lettre S finale. Les deux désignent le même système d'orchestration de conteneurs.

Quelle est la différence entre Docker et Kubernetes ?

Docker est un moteur de conteneurisation : il empaquette une application avec ses dépendances dans une image qui s'exécute comme un conteneur. Kubernetes est un orchestrateur : il déploie, supervise et fait évoluer ces conteneurs sur un parc de serveurs. Cette distinction est l'une des plus mal comprises de l'écosystème, alors queles deux outils répondent en réalité à des besoins différents et complémentaires.

Kubernetes est-il gratuit ?

Le logiciel est open source et gratuit, sous licence Apache 2.0. Mais l'infrastructure sur laquelle il tourne, le temps d'ingénierie pour le maintenir et les outils complémentaires (supervision, sauvegardes, sécurité) ont un coût réel. C'est pourquoi de nombreuses entreprises optent pour un Kubernetes managé.

Faut-il toujours Kubernetes pour déployer en production ?

Non. Kubernetes apporte une orchestration sophistiquée, particulièrement adaptée aux architectures distribuées exigeant portabilité, écosystème CNCF, ou orchestration avancée. Pour beaucoup d'autres contextes, un PaaS répond aux mêmes objectifs (déploiement industrialisé, autoscaling, résilience) sans la complexité opérationnelle. Et dans la pratique, les deux approches cohabitent souvent dans une même architecture.

Quelle différence entre K3S et K8S ?

K3S est une distribution Kubernetes certifiée par la CNCF (donc pas un fork), allégée et conçue pour les environnements aux ressources limitées : edge, IoT, machines de développement, petits clusters. Elle remplace certains composants par des alternatives plus légères et tient dans un binaire unique. Les différences entre K3S et K8S tiennent à plusieurs choix d'architecture précis qu'il faut peser avant de choisir.

Comment commencer avec Kubernetes ?

Le plus rapide est de monter un cluster local avec Minikube, kind ou k3d, puis de déployer une application simple via un manifeste YAML. Pour passer en production, le choix raisonnable pour la majorité des équipes est un Kubernetes managé.

Nous avons donc construit notre propre orchestrateur. Il repose sur des micro-VMs et nous donne une frontière kernel propre entre les workloads, sans partage de noyau entre tenants. C'est ce qui fait tourner aujourd'hui des dizaines de milliers d'applications en production sur notre PaaS, et c'est encore, pour la plupart des projets, le chemin le plus court entre un commit et de la production.

Quand Docker est arrivé, certains workloads se prêtaient mieux à une image conteneurisée qu'à nos runtimes natifs. Nous avons donc ajouté un runtime Docker à la plateforme, là où ça avait du sens. Pas pour remplacer notre approche, mais pour l'élargir.

Puis Kubernetes s'est imposé comme le standard de fait de l'orchestration de conteneurs. Son écosystème (Helm, opérateurs, GitOps…) est devenu incontournable pour de nombreuses équipes.

Nous aurions pu continuer à répondre que, dans beaucoup de cas, Kubernetes n'est pas le meilleur chemin vers la production. C'est toujours vrai.

Mais ça ne suffisait plus.

C'est pour ça que nous lançons CKE, notre Clever Kubernetes Engine, aujourd'hui disponible en bêta publique.

Comme beaucoup le savent, pendant des années, nous avons résisté à l'idée de proposer Kubernetes comme une case à cocher de plus dans la Console. Non pas parce que Kubernetes ne sert à rien, mais parce qu'il est trop souvent devenu une réponse par défaut à des problèmes que le PaaS résout plus simplement : déployer une application, la scaler, la superviser, l'isoler, lui connecter une base de données, gérer ses variables d'environnement, ses logs et son cycle de vie. Et nous le pensons toujours.

Mais Kubernetes est devenu le langage commun d'une grande partie de l'écosystème cloud-native. Helm, les opérateurs, GitOps, les workloads déjà conteneurisés, les plateformes internes et les chaînes d'outillage existantes font partie de la réalité quotidienne de nombreuses équipes. Et notre raison d'être est de faciliter la vie des équipes techniques.

La question n'était donc plus "faut-il faire du Kubernetes ?", mais "peut-on faire du Kubernetes sans renier ce qui fait Clever Cloud ?"

Pas un Kubernetes empaqueté à la va-vite

Le chemin le plus rapide pour proposer du Kubernetes managé, c'est d'empaqueter une distribution upstream derrière une console d’administration, d'ajouter une API de provisioning, et de facturer le cluster à l'heure.

C'est une stratégie valide pour sortir vite.

Ce n'est pas celle que nous voulions.

Pour CKE, nous avions trois exigences qui ne se résolvent pas en ajoutant simplement Kubernetes à côté du reste de la plateforme.

La première, c'est la souveraineté. CKE est opéré en Europe, sur notre infrastructure et celle de nos partenaires, et peut aussi être déployé sur les infrastructures on-premises de nos clients qui en ont besoin. Pas de dépendance aux hyperscalers américains, pas de zones grises sur la juridiction des données, pas de promesse floue sur la localisation réelle de l'infrastructure.

La deuxième, c'est l'intégration avec le reste de Clever Cloud. Nous ne voulions pas créer un silo Kubernetes à côté du PaaS, des bases de données managées, du stockage objet et du réseau privé. Nous voulions un Kubernetes qui s'inscrive dans la même plateforme, avec la même Console, le même outillage, la même facturation, les mêmes règles de gouvernance et les mêmes services managés.

La troisième, c'est la prévisibilité opérationnelle. Kubernetes est un système distribué complexe, et son comportement sous charge dépend beaucoup de ses fondations. Nous ne voulions pas opérer un produit dont la couche basse resterait une boîte noire ou une limite acceptée par défaut.

C'est ce qui nous a amenés à travailler à un endroit que peu de fournisseurs touchent : la couche de cohérence interne de Kubernetes.

Sous le capot : Materia etcd sur FoundationDB

Dans Kubernetes, etcd est le composant qui stocke l'état du cluster : les manifests, les ressources, les secrets, l'état des nœuds. C'est la source de vérité de tout l'orchestrateur.

C'est aussi l'un des composants les plus sensibles du système.

etcd fonctionne très bien dans le cadre pour lequel il a été conçu. Mais ses limites à grande échelle sont connues : taille du store, latences sous forte charge en écriture, comportement en cas de partition réseau, opérations de sauvegarde et restauration, besoin de compaction et de surveillance fine. Quand Kubernetes devient une fondation critique, etcd devient un sujet d'exploitation à part entière.

Nous ne voulions pas construire CKE sur une brique que nous considérerions ensuite comme une boîte noire fragile.

Nous avons donc repris le problème à sa racine : conserver le contrat attendu par Kubernetes, mais remplacer la couche de cohérence interne par une implémentation adossée à FoundationDB. C'est ce que nous appelons Materia etcd.

FoundationDB nous apporte des transactions ACID distribuées, un modèle de cohérence robuste, et une approche de testing par simulation déterministe qui correspond très bien à notre manière de construire de l'infrastructure critique.

Pour l'utilisateur final, ce travail est invisible. C'est précisément le but. Sous le capot, cette fondation nous permet de construire CKE avec l'auto-scaling, l'auto-healing et la prévisibilité opérationnelle que nous attendons d'un service Clever Cloud.

Nous reviendrons bientôt plus en détail sur Materia etcd, parce que le sujet mérite un article dédié.

Du Kubernetes standard côté développeur

Tout ce travail sur la couche basse a un objectif simple : côté utilisateur, CKE doit être du Kubernetes standard.

Vos manifests fonctionnent sans modification. Vos charts Helm s'installent normalement. Votre Argo CD ou votre Flux se branche comme sur n'importe quel cluster. Vos opérateurs Kubernetes tournent sans surprise.

CKE ne cherche pas à réinventer l'interface développeur de Kubernetes. Ce serait contre-productif. Si vous avez déjà une chaîne de déploiement Kubernetes, l'objectif est qu'elle puisse fonctionner sur CKE avec le moins de friction possible.

La différence se joue ailleurs : dans la manière dont ce Kubernetes s'intègre au reste de la plateforme Clever Cloud.

Kubernetes quand vous en avez besoin, le PaaS quand il suffit

CKE ne remplace pas notre PaaS. Il le complète.

Pour beaucoup d'applications, le PaaS reste le meilleur choix : moins d'exploitation, moins de configuration, moins de YAML, moins de surface de maintenance. Si votre application rentre naturellement dans un runtime Clever Cloud, le PaaS reste souvent le chemin le plus simple et le plus robuste.

Mais il y a des cas où Kubernetes est le bon outil.

Vous avez peut-être besoin :

• D'installer un opérateur ;
• De reprendre des manifests existants ;
• De standardiser une chaîne GitOps ;
• De déployer un workload déjà distribué sous forme de chart Helm ;
• De faire tourner une plateforme interne construite autour de l'API Kubernetes ;
• Ou simplement de répondre aux habitudes d'une équipe qui travaille déjà avec Kubernetes au quotidien.

Dans ces cas-là, le problème n'est pas Kubernetes en soi. Le problème, c'est Kubernetes isolé du reste de votre système.

C'est là que CKE change les choses. Vous pouvez garder une API Node.js sur le PaaS, un frontend statique sur Cellar, une base PostgreSQL managée, et faire tourner sur CKE uniquement le composant, l'opérateur ou le workload qui a réellement besoin de Kubernetes.

Le tout dans le même environnement Clever Cloud.

Une intégration native avec l'écosystème Clever Cloud

CKE a été conçu pour s'intégrer avec les services que vous utilisez déjà sur Clever Cloud.

• Cellar, notre stockage objet compatible S3, peut être utilisé depuis vos workloads Kubernetes.
• Les bases de données managées (PostgreSQL, MySQL, MongoDB, Redis, Materia) s'attachent à votre cluster comme aux autres applications Clever Cloud.
• IAM as a Service permet de gérer l'authentification et les permissions sur le cluster et sur les équipes qui y accèdent.
• Network Groups permet de relier votre cluster CKE à vos applications PaaS Clever Cloud existantes, dans le même réseau privé.

L’intégration avec Network Groups est probablement celle qui change le plus le quotidien.

Kubernetes est souvent introduit dans les organisations comme une nouvelle île : nouvelle console, nouveau réseau, nouveaux secrets, nouvelles règles d'accès, nouvelle facturation, nouvelle façon de connecter les services entre eux.

Avec CKE, l'objectif est inverse. Kubernetes devient une brique de plus dans l'architecture Clever Cloud, pas un monde parallèle.

Vous pouvez donc construire une architecture hybride sans bricolage : une partie sur le PaaS, une partie sur CKE, des bases de données managées, du stockage objet, du réseau privé, et une gouvernance commune.

Activer CKE et déployer une première application

Pour cette démo, on va rester sur le minimum vital : activer la fonctionnalité, créer un cluster, récupérer un kubeconfig, ajouter un node group et déployer une première application avec un service de type LoadBalancer.

Côté prérequis, il faut avoir Clever Tools en version 4.3 ou supérieure, et kubectl installé sur votre poste.

Depuis l'ouverture de la bêta publique le 27 avril, la fonctionnalité Kubernetes peut être activée par tous les clients Clever Cloud, en une commande :

clever features enable k8s

On peut alors créer un cluster. Donnez-lui un nom, précisez votre organisation, et l'option --watch permet de suivre l'avancement du déploiement :

clever k8s create my-cluster --org <your-org-id> --watch

La création prend environ une minute. À tout moment, on peut lister les clusters de l'organisation avec clever k8s list.

Une fois le cluster prêt, on récupère son kubeconfig et on l'écrit directement comme configuration locale par défaut :

clever k8s get-kubeconfig my-cluster --org <your-org-id> > ~/.kube/config

À partir de là, c'est du Kubernetes standard. kubectl parle au cluster, et tout votre outillage habituel suit. On peut commencer par vérifier que tout est en place :

kubectl get nodes

À ce stade, la liste est vide : le cluster est créé mais sans capacité de calcul. C'est l'occasion d'introduire la première spécificité de CKE côté API : le NodeGroup. Un node group est un ensemble de nœuds Kubernetes de même profil (même flavor, même région), gérés comme un tout. Vous le décrivez comme n'importe quelle ressource Kubernetes, dans un fichier YAML :

apiVersion: api.clever-cloud.com/v1
kind: NodeGroup
metadata:
  name: example-nodegroup
spec:
  flavor: M
  nodeCount: 2

Et vous l'appliquez avec kubectl :

kubectl create -f example-nodegroup.yaml

Soixante à quatre-vingt-dix secondes plus tard, les nœuds rejoignent le cluster :

kubectl get nodegroups
NAME                DESIREDNODECOUNT   CURRENTNODECOUNT   FLAVOR   STATUS   AGE
example-nodegroup   2                  2                  M        Synced   2m

kubectl get nodes
NAME                      STATUS   ROLES    AGE   VERSION
example-nodegroup-node0   Ready       2m    v1.35.0
example-nodegroup-node1   Ready       2m    v1.35.0

Pour ajuster la taille du node group, on reste dans l'API Kubernetes :

kubectl scale nodegroup example-nodegroup --replicas=4

Avec un cluster qui dispose maintenant de capacité de calcul, on peut déployer une première application. Pour faire simple, un nginx exposé via un service de type LoadBalancer, ce qui provisionnera automatiquement un load balancer côté Clever Cloud :

kubectl create deployment nginx --image=nginx:alpine --replicas=2 
kubectl expose deployment/nginx --type=LoadBalancer --port 80 
kubectl get service nginx

Quelques secondes plus tard, le service expose une adresse publique. C'est exactement le comportement réactif évoqué plus haut sur la phase de test privé : provisionner un node group, le scaler ou exposer un service ne demande ni attente ni configuration manuelle.

À partir d'ici, c'est du Kubernetes comme partout ailleurs. Vous pouvez ajouter du persistent storage via le CSI Clever Cloud, installer le Clever Kubernetes Operator pour provisionner depuis vos manifests une base de données managée, ou brancher votre chaîne GitOps habituelle. Le cluster supporte les versions Kubernetes 1.34, 1.35 et 1.36, avec 1.35 par défaut. Tout est détaillé dans la documentation CKE.

Ce qu'on a vu en test privé et à Devoxx, et la suite

CKE est désormais en bêta publique, mais certains de nos clients y ont accès en test privé depuis plusieurs mois. Cette phase a été très utile pour confronter le produit à des usages réels avant de l'ouvrir plus largement.

Les retours sont très positifs. Le cluster se comporte comme attendu, et les opérations qui touchent souvent au quotidien d'une équipe Kubernetes, comme l'ajout d'un nœud ou la mise en place d'un load balancer, sont rapides et prévisibles. C'est précisément le comportement que nous visions en investissant autant de temps sur la couche de cohérence interne.

À Devoxx France, nous avons présenté CKE sur le stand Clever Cloud pendant trois jours. Les discussions ont confirmé deux choses que nous observions déjà.

D'abord, les équipes ne cherchent pas seulement un cluster Kubernetes. Elles cherchent un Kubernetes qui s'intègre proprement à leur plateforme, à leur réseau, à leurs bases de données, à leurs contraintes de sécurité et à leurs pratiques existantes.

Ensuite, et c'est sans doute le retour le plus marquant, les développeurs ne cherchent pas à tout mettre sur Kubernetes. Beaucoup veulent garder leurs applications classiques sur notre PaaS, là où il est le plus efficace, et déployer sur Kubernetes uniquement les composants qui le méritent vraiment, par leur complexité, par leur architecture distribuée ou par les contraintes de l'écosystème dans lequel ils s'inscrivent.

C’est exactement le genre d’architecture hybride que CKE est conçu pour permettre.

C’est aussi pour ça que nous avions construit, en amont du lancement, le Clever Kubernetes Operator. Il permet à un workload qui tourne dans un cluster Kubernetes, qu’il soit hébergé chez nous ou ailleurs, de provisionner et de consommer nos services managés directement depuis l’API Kubernetes : PostgreSQL, MySQL, MongoDB, Redis, Cellar ou Materia.

Pour vos équipes, c’est du kubectl apply qui crée une base de données managée. Pour CKE, c’est l’outil naturel pour faire le pont entre les workloads Kubernetes et le reste de la plateforme Clever Cloud.

La bêta est ouverte à tous les clients Clever Cloud. Vous pouvez l'activer dès maintenant, déployer vos premiers workloads, et nous faire remonter ce qui vous manque, ce qui vous surprend ou ce que vous aimeriez voir arriver ensuite.

La discussion est ouverte sur notre communauté GitHub, et la documentation est disponible ici.

CKE ne remplace pas notre PaaS. Il le complète.

Pour beaucoup d'applications, le PaaS reste le chemin le plus simple entre un commit et de la production. Mais quand vous avez besoin de Kubernetes, pour un opérateur, un chart Helm, une chaîne GitOps, un workload déjà standardisé ou une plateforme interne, vous pouvez maintenant le faire dans l'environnement Clever Cloud, avec nos choix d'infrastructure, notre réseau, nos services managés et nos exigences de souveraineté.

C'est ce Kubernetes-là que nous voulions construire.

Nantes, France — Clever Cloud, fournisseur européen de solutions cloud, annonce l'ouverture en bêta publique de Clever Kubernetes Engine (CKE) le 27 avril 2026 dans l’après-midi. Le produit sera présenté en avant-première au Devoxx à partir du 22 avril, où les participants pourront le tester directement sur le stand Clever Cloud.

Conçu pour la production et la scalabilité

Kubernetes est devenu le standard de l'orchestration de conteneurs. Clever Cloud a travaillé pendant deux ans pour proposer une version managée et souveraine, conçue pour s'intégrer naturellement dans l'écosystème Clever Cloud et s'opérer avec la même simplicité que les autres services de la plateforme. CKE est pensé pour accompagner des charges de production réelles, avec une scalabilité élevée et un comportement prévisible à grande échelle.

Pour y parvenir, Clever Cloud a notamment développé Materia etcd, une réimplémentation de la couche de cohérence interne de Kubernetes construite sur FoundationDB. C'est ce travail de fond, invisible pour l'utilisateur final, qui garantit à CKE sa robustesse et sa stabilité en production, notamment grâce à de l’auto-scalabilité et de “l'auto-healingde façon native.

CKE s'intègre nativement aux services Clever Cloud existants — stockage objet Cellar (compatible S3), bases de données managées, IAM as a Service, Network Groups — et reste accessible via les outils standard du marché : kubectl, Helm ou GitOps.

Souverain par conception

Hébergé et opéré en Europe par Clever Cloud sur son cloud public, CKE offre aux organisations une alternative concrète aux offres Kubernetes des grandes plateformes américaines, sans compromis sur les performances ni sur la maîtrise juridique des données. CKE peut aussi être déployé sur les infrastructures on-premises du client. 

Modalités d'accès

La bêta publique est ouverte à tous les clients de Clever Cloud à partir du 27 avril 2026, via l'activation de fonctionnalités à réaliser par l’utilisateur. À noter : certains clients bénéficient d'un accès en test privé depuis plus de six mois déjà, ce qui a permis d'affiner le produit avant cette ouverture générale.

"Clever Cloud a longtemps développé des alternatives à Kubernetes. Nos clients nous ont exprimé un besoin clair pour cette technologie, et nous avons décidé de la construire à leurs côtés, avec le niveau d'exigence technique et de souveraineté qui définit notre plateforme." Quentin Adam, CEO de Clever Cloud

En savoir plus

Il a été conçu pour gérer de l'infrastructure, et en ce sens, il vient avec de la complexité et donc des coûts cachés. Or, chez Clever Cloud notre boussole est d’améliorer la productivité, la sécurité et l’autonomie des développeurs.

Depuis, le contexte a changé. Le marché évolue, nos clients également. Nous avons désormais la maturité technologique pour répondre à un tel besoin… à notre manière. Voici pourquoi nous avons pris le temps de créer notre propre version d'ETCD, et pourquoi Kubernetes arrive enfin chez Clever Cloud

Pourquoi nous n’avons pas sauté sur Kubernetes plus tôt

Historiquement, nous n’avons jamais vu Kubernetes comme un levier de simplification. Il est parfois vécu comme une complexité supplémentaire, surtout pour des équipes qui veulent juste déployer, passer à l’échelle et sécuriser leurs applications : se focaliser sur la création de valeur sans consacrer trop de temps sur le reste. 

Or le passage à l'échelle engendre souvent des machines à gaz. Nous sommes hébergeurs, autant vous dire que c'est une sacrée échelle qu'il nous faut. Notre orchestrateur développé et enrichi de 15 ans d’ expériences en production permet cela. Via une exécution directe des runtimes (une quinzaine, dont Node.JS, PHP, Rust, Scala, Docker etc), notre orchestration va plus loin dans la finesse du provisionnement et du scaling automatique, la pertinence des mises à jour et la sécurité.

Pour nous, la containerisation n’est pas une fin en soi. Si un runtime existe, nous préférons en simplifier l’usage, le supporter nativement. Cela permet de contrôler les mises à jour de sécurité de l’image de base, sans dépendre du bon vouloir de l’équipe applicative. Pour tout code qui ne correspond pas à un runtime existant, nous proposons naturellement le déploiement dans une image Docker. Cependant, il faut avoir à l’esprit que cette image, nous pouvons la mettre à jour, mais naturellement, nous ne pouvons pas patcher ou mettre à jour le code encapsulé.

Néanmoins, au fil de notre croissance nous rencontrons des prospects de plus en plus gros et utilisateurs de Kubernetes. Le marché demande Kubernetes. De plus en plus de clients veulent une interopérabilité avec leurs outils habituels, une gestion fine de leurs workloads, ou simplement un standard pour leurs équipes. Nous ne pouvions pas l’ignorer.

Le maillon faible de Kubernetes : ETCD

Kubernetes est souvent qualifié de « système d’exploitation du cloud ». Mais comme tout OS, il repose sur un élément données critique : ETCD, une base de données clé-valeur distribuée censée stocker l’état global du cluster. Et là, les ennuis commencent.

ETCD ne tient pas la charge. Son architecture, pensée pour des cas modestes, impose une limite technique dure à 8 Go. Les performances chutent dès qu’on passe à l’échelle, la documentation est lacunaire, et la gouvernance du projet a été fragilisée par des changements successifs de mainteneurs.

Et ce n'est pas pour rien que Google, Microsoft et autres hyperscalers ont réécrit leur version d'ETCD, comme pour le projet k3s qui utilise une base de données PostgreSQL. Quand chaque client possède son propre cluster Kubernetes, cela signifie potentiellement des milliers d’instances ETCD à gérer, chacune avec ses subtilités, ses backups, ses performances variables. C'est un cauchemar opérationnel quand notre métier est le maintien en conditions opérationnelles.

Repenser ETCD à la racine : notre stack maison

Nous avons donc fait ce que Clever Cloud sait faire de mieux : repenser intelligemment. En nous appuyant sur Materia KV, notre base de données serverless clé-valeur, bâtie sur FoundationDB, nous avons réimplémenté ETCD.

Concrètement, nous avons recréé les APIs clés de compatibilité (KeyValue, Watch, Lease, Compaction…) en les interfaçant sur une infrastructure que nous maîtrisons, avec :

• une architecture multi-tenant, pensée pour l’échelle car en utilisant FoundationDB comme base de données, nous pouvons utiliser du scaling horizontal. Habituellement, chaque noeud ajouté dans ETCD ralentit ses performances. Ici, chaque noeud ajouté dans MateriaETCD permet d'accueillir plus de clients sans impact autre;
• une gestion fine des transactions, des droits, des quotas, des statistiques ;
• une stack cohérente et maintenue par nos équipes.

Le résultat : une base de données logiques compatible avec le protocole d'ETCD, rapide, fiable et scalable, le tout reposant sur FoundationDB, et opéré à l’échelle Clever Cloud. Fini les clusters fragiles et les équipes DBA sur-sollicitées : tout est intégré, industrialisé, et instrumentable, profitant de notre écosystème, intégration et application. Mais surtout, cette solution bénéficie d’un fort niveau de résilience, hérité directement de FoundationDB. Grâce à sa simulation continue en environnement distribué, nous sommes capables de valider chaque release logicielle dans des milliers de scénarios de panne simulée. C’est un niveau de robustesse rare, qui nous permet d’anticiper les comportements extrêmes et de garantir une très haute disponibilité de nos services — et donc des vôtres.

Cette approche nous donne une confiance sans précédent dans notre capacité à maintenir des milliers de clusters Kubernetes sans tomber dans le piège d’une complexité opérationnelle exponentielle.

Kubernetes managé par Clever Cloud : une approche souveraine et pragmatique

Nous ne changeons pas notre vision : notre PaaS reste la meilleure solution pour les équipes qui veulent un maximum de productivité et de sécurité avec un minimum d’efforts. Mais nous savons aussi que certaines organisations ont besoin de Kubernetes pour des raisons d’architecture, de portabilité ou de standardisation.

C’est pourquoi notre Kubernetes managé entre aujourd’hui en phase de test privé. Si vous êtes client Clever Cloud et que vous souhaitez le tester, vous pouvez nous contacter dès maintenant pour y accéder.

Notre promesse ? Un Kubernetes intégré, sécurisé, maîtrisé, qui repose sur une fondation technique solide. Un K8S qui respecte l’état de l’art — mais sans les défauts de ses briques historiques, et qui vous laisse, enfin, vous concentrer sur votre métier.