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.

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.