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 k8sOn 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> --watchLa 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: 2Et vous l’appliquez avec kubectl :
kubectl create -f example-nodegroup.yamlSoixante à 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=4Avec 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 nginxQuelques 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.