Managé on Zwindler's Reflection

Test de CKE, le Kubernetes managé chez Clever Cloud (partie 2 - stockage)

Sun, 24 May 2026 18:00:00 +0200

Rappel de la partie 1

Dans la partie 1, on avait vu comment créer un cluster CKE, parcouru son anatomie (Exherbo Linux, Cilium, Materia etcd, konnectivity…), mesuré les temps de boot (~57s pour le control plane, excellent), testé les NodeGroups, et activé le CSI.

Dans cette deuxième partie, on va creuser ce qui touche au stockage et à des cas d’usages “un peu” avancés : cycle de vie des volumes, resize online, snapshots, et déploiement de vCluster avec données persistantes.

Activer le CSI et monter son premier volume

Comme on l’a vu en partie 1, le CSI n’est pas activé par défaut, mais un petit coup de CLI corrige ça rapidement :

clever k8s add-persistent-storage moncluster

Cette commande déploie le provisioner Ceph RBD et crée une StorageClass csi-rbd-sc qui devient la classe par défaut.

$ kubectl get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION
csi-rbd-sc (default) rbd.csi.ceph.com Delete Immediate true

On notera au passage ALLOWVOLUMEEXPANSION: true : on y reviendra.

Créons un PVC tout bête :

# pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: mon-pvc
spec:
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 1Gi
 storageClassName: csi-rbd-sc

$ kubectl apply -f pvc.yaml
$ kubectl get pvc mon-pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES
mon-pvc Bound pvc-2c2f058c-dc85-4006-865c-3437856462f5 1Gi RWO

Le binding prend environ 30 secondes (le temps que le provisioner crée l’image RBD dans le pool Ceph et l’attache). Rien de spécial, c’est du Kubernetes standard.

On monte le volume dans un pod, on écrit un fichier, on supprime le pod, on le recrée : les données sont toujours là. Jusque là, pas de surprise.

vCluster : un cas d’usage concret du stockage persistant

Maintenant qu’on a du stockage persistant, on peut faire des choses intéressantes. Généralement mon troll préféré, c’est de déployer Wordpress parce que évidemment Kubernetes c’est la meilleure plateforme pour déployer un Wordpress (/s).

Bon, cette fois ci j’ai décidé d’innover un peu et on va déployer vCluster (un cluster Kubernetes virtuel qui tourne dans votre cluster).

Note : à quoi ça sert, me direz vous ? Et bien, les usecases sont pas aussi clairs qu’on pourrait penser. vCluster vous donne un cluster Kubernetes complet, isolé, mais qui partage l’infrastructure du cluster hôte, y compris le CSI. En théorie ça permet de donner le cluster-admin à des gens sans donner les clés de l’infra complète à tout le monde. Je suis pas hyper convaincu par cette approche. Un usecase qui me parait moins dangereux, c’est pour des usages de type CI sans devoir monter un cluster complet, mais il y a des limitations aussi.

Installation :

vcluster create test-vcluster -n vcluster-test

Deux options pour s’y connecter :

Option 1 —> port-forward (le plus simple) :

$ vcluster connect test-vcluster -n vcluster-test -- kubectl get nodes
NAME STATUS ROLES AGE
control-plane-c367382a-22b1-4cef-b0cd-372bf83263c4-node Ready <none> 2m

vcluster connect monte un tunnel port-forward via l’API server (comme kubectl port-forward) et exécute la commande dans le contexte du vCluster. Ça marche sur CKE comme sur n’importe quel cluster Kubernetes.

Option 2 —> LoadBalancer (pour un accès durable sans tunnel) :

vcluster delete test-vcluster -n vcluster-test
vcluster create test-vcluster -n vcluster-test --expose --connect=false

Le flag --expose crée un Service LoadBalancer. On récupère l’IP et on génère un kubeconfig autonome :

$ LB_IP=$(kubectl get svc -n vcluster-test test-vcluster -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
$ vcluster connect test-vcluster -n vcluster-test \
 --server https://$LB_IP:443 \
 --insecure --print > /tmp/kube-vcluster.config

Le flag --insecure évite les soucis de certificat auto-signé, avec les risques de sécu que ça implique. A vos risques et périls… 💀

$ kubectl --kubeconfig /tmp/kube-vcluster.config get nodes
NAME STATUS ROLES AGE
test-vcluster Ready <none> 2m

Ce node test-vcluster contient tout notre cluster virtuel. Maintenant, la partie intéressante : créer un PVC dans le vCluster :

$ kubectl --kubeconfig /tmp/kube-vcluster.config apply -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: test-pvc
spec:
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 1Gi
 storageClassName: csi-rbd-sc
EOF

C’est là où c’est sympa : le vCluster délègue la création du volume au cluster hôte, qui le provisionne via Ceph RBD. On a pas besoin de reconfigurer le CSI, les storage classes, les secrets, etc. C’est totalement transparent.

Petite vérification côté CKE :

$ kubectl get pvc -A | grep test-vcluster
vcluster-test pvc-<...> Bound 1Gi RWO csi-rbd-sc

Le PVC est bien créé dans le namespace du vCluster sur le cluster hôte.

Overhead mesuré :

Pod	CPU	RAM
`test-vcluster-0`	~80m	~342 Mi
coredns (vCluster)	~2m	~13 Mi

C’est tout à fait raisonnable. 342 MiB pour un control plane K8s complet, c’est dans les clous.

Conclusion vCluster : ça marche, y compris avec de la persistance. Si vous avez besoin d’isoler des environnements tout en gardant accès au CSI, vCluster sur CKE est une option fonctionnelle.

Note : il est aussi possible d’exposer le vCluster via un LoadBalancer (flag --expose) pour un accès direct sans tunnel. Pratique si le vCluster doit rester accessible après la fermeture de votre terminal.

Volume expansion : agrandir un volume à chaud

Vous avez une base de données qui grossit, vous avez provisionné 1Gi au départ et maintenant c’est juste. Avec allowVolumeExpansion: true sur la StorageClass, on peut agrandir le volume sans downtime.

kubectl patch pvc mon-pvc -p '{"spec":{"resources":{"requests":{"storage":"2Gi"}}}}'

Côté Ceph, l’image RBD est redimensionnée immédiatement. Le PV passe à 2Gi :

$ kubectl get pv
NAME CAPACITY ACCESS MODES STATUS CLAIM
pvc-<...> 2Gi RWO Bound default/mon-pvc

Mais le PVC côté utilisateur reste à 1Gi et le filesystem XFS n’a pas encore été agrandi. Le kubelet finira par détecter le changement et déclencher le NodeExpandVolume tout seul (la synchronisation est périodique), mais on peut accélérer en supprimant et recréant le pod qui monte le volume :

$ kubectl delete pod mon-app --force --grace-period=0
$ kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
 name: mon-app
spec:
 containers:
 - name: app
 image: alpine
 command: ["sleep", "3600"]
 volumeMounts:
 - mountPath: /data
 name: data
 volumes:
 - name: data
 persistentVolumeClaim:
 claimName: mon-pvc
EOF

Dès que le volume est monté, le kubelet détecte qu’il a grandi et appelle le driver CSI pour un NodeExpandVolume. Le filesystem XFS est agrandi à chaud (xfs_growfs) et le PVC passe effectivement à 2Gi :

$ kubectl exec mon-app -- df -h /data
Filesystem Size Used Avail Use% Mounted on
/dev/rbd0 1.9G 47M 1.9G 1% /data

$ kubectl get pvc mon-pvc
NAME STATUS CAPACITY ACCESS MODES
mon-pvc Bound 2Gi RWO

VolumeSnapshots : le plus technique

Dernière fonctionnalité, et pas la plus simple : les snapshots de volumes.

Le driver Ceph RBD supporte les snapshots nativement. On le vérifie en regardant les logs du sidecar csi-snapshotter au moment de la création :

$ kubectl logs -n kube-system deployment/csi-rbdplugin-provisioner -c csi-snapshotter --tail=5
I0524 19:50:53.470970 snapshot_controller.go:339] createSnapshotWrapper: Creating snapshot for content snapcontent-<...> through the plugin ...

Pas d’erreur côté driver, la demande est acceptée et traitée.

Mais sur CKE, rien n’est pré-installé pour utiliser les snapshots. Il faut assembler les briques soi-même :

Étape 1 : installer les CRDs et le snapshot-controller

Les CRDs volumesnapshot* ne sont pas déployées sur CKE. Il faut les installer depuis le projet upstream external-snapshotter, ainsi que le snapshot-controller :

VERSION=v8.4.0
# CRDs
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/$VERSION/client/config/crd/snapshot.storage.k8s.io_volumesnapshotclasses.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/$VERSION/client/config/crd/snapshot.storage.k8s.io_volumesnapshotcontents.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/$VERSION/client/config/crd/snapshot.storage.k8s.io_volumesnapshots.yaml
# Snapshot-controller (RBAC + deployment)
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/$VERSION/deploy/kubernetes/snapshot-controller/rbac-snapshot-controller.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/$VERSION/deploy/kubernetes/snapshot-controller/setup-snapshot-controller.yaml

Deux composants travaillent ensemble :

Le snapshot-controller (standalone) écoute les objets VolumeSnapshot et crée les VolumeSnapshotContent correspondants
Le csi-snapshotter (sidecar dans le provisioner) détecte les VolumeSnapshotContent et appelle le driver Ceph RBD pour créer/supprimer les snapshots

Les deux sont nécessaires.

Étape 2 : le piège des GroupSnapshot CRDs

Une fois les CRDs installées, vous créez votre VolumeSnapshotClass, votre VolumeSnapshot, et… rien ne se passe. Le VolumeSnapshotContent reste readyToUse: false indéfiniment.

Si vous regardez les logs du sidecar csi-snapshotter dans le provisioner, vous ne voyez aucune tentative de création de snapshot.

Pourquoi ? Parce que le sidecar est lancé avec un feature gate activé :

--feature-gates=CSIVolumeGroupSnapshot=true

Ce feature gate active le support des VolumeGroupSnapshot (la possibilité de snapshotter plusieurs volumes en une fois). Mais le sidecar attend les CRDs correspondantes pour initialiser son cache. Sans ces CRDs, le cache sync est bloqué, et le controller ne traite aucun VolumeSnapshot, pas même les snapshots unitaires (normaux, pas “group” quoi).

La solution : installer les CRDs groupsnapshot* :

kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/$VERSION/client/config/crd/groupsnapshot.storage.k8s.io_volumegroupsnapshotclasses.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/$VERSION/client/config/crd/groupsnapshot.storage.k8s.io_volumegroupsnapshotcontents.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/$VERSION/client/config/crd/groupsnapshot.storage.k8s.io_volumegroupsnapshots.yaml

Puis redémarrer le provisioner pour que le sidecar recharge sa config. Attention : le provisioner a une anti-affinity qui empêche deux pods de cohabiter sur le même node. Sur un cluster ALL_IN_ONE (1 node), ça bloque le rollout. Il faut supprimer directement l’ancien pod :

kubectl delete pod -n kube-system -l app=csi-rbdplugin-provisioner --force

Ce problème est spécifique aux clusters ALL_IN_ONE. Sur DEDICATED_COMPUTE ou DISTRIBUTED (multi-nodes), l’anti-affinity ne sera probablement pas bloquante.

Étape 3 : le secret Ceph dans le VolumeSnapshotClass

Une fois le sidecar relancé, les logs montrent… une erreur :

rpc error: code = Internal desc = provided secret is empty

Le driver Ceph RBD a besoin des credentials Ceph pour créer un snapshot, exactement comme pour créer un volume. Vous les trouverez dans le secret csi-rbd-secret du namespace kube-system. La StorageClass les référence déjà pour le provisionning :

parameters:
 csi.storage.k8s.io/provisioner-secret-name: csi-rbd-secret
 csi.storage.k8s.io/provisioner-secret-namespace: kube-system

Mais ces paramètres ne sont pas reportés automatiquement dans le VolumeSnapshotClass. Il faut les ajouter manuellement :

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
 name: csi-rbd-snapclass
driver: rbd.csi.ceph.com
deletionPolicy: Delete
parameters:
 clusterID: <votre-cluster-id>
 csi.storage.k8s.io/snapshotter-secret-name: csi-rbd-secret
 csi.storage.k8s.io/snapshotter-secret-namespace: kube-system

Le clusterID est celui de la StorageClass (visible dans kubectl get sc csi-rbd-sc -o yaml).

Étape 4 : le snapshot fonctionne

$ kubectl apply -f - <<EOF
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
 name: mon-snapshot
spec:
 volumeSnapshotClassName: csi-rbd-snapclass
 source:
 persistentVolumeClaimName: mon-pvc
EOF

$ kubectl get volumesnapshot mon-snapshot
NAME READYTOUSE SOURCEPVC RESTORESIZE AGE
mon-snapshot true mon-pvc 1Gi 6s

READYTOUSE: true immédiatement. Le snapshot Ceph RBD est créé en quelques secondes.

Étape 5 : restaurer un volume depuis un snapshot

Pour être VRAIMENT sûr que ça fonctionne, on peut faire un test (et oui, ça fonctionne)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: pvc-restored
spec:
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 1Gi
 dataSource:
 name: mon-snapshot
 kind: VolumeSnapshot
 apiGroup: snapshot.storage.k8s.io
 storageClassName: csi-rbd-sc

$ kubectl apply -f pvc-restored.yaml
$ kubectl get pvc pvc-restored
NAME STATUS VOLUME CAPACITY
pvc-restored Bound pvc-... 1Gi

Bilan global

Deuxième partie, deuxième bilan. Qu’est-ce qu’on retient ?

Les points forts :

CSI Ceph RBD : là encore, un bon choix. Ceph, ça fonctionne bien dans Kubernetes. Provisionning, persistence, resize online — tout fonctionne et ce n’est pas une surprise.
vCluster + CSI : pour faire plaisir à Akanoa, j’ai fait du kubeception (Kubernetes in Kubernetes) et ça m’a permis de tester une feature de vCluster que j’avais jamais essayée => la délégation transparente du CSI vers le CSI de l’hôte

Les points d’attention :

Les snapshots ne sont pas “out of the box” : CRDs manquantes, feature gate inattendu, secret à recopier. Je ferai un petit email aux copain⋅es parce que ça me parait dommage de pas l’ajouter

Encore merci à l’équipe Clever Cloud pour m’avoir donné accès en avant-première et pour avoir pris le temps d’échanger sur mes retours. Je ne sais pas s’il y aura un 3ème article ou non. Wait and see ;-P

Test de CKE, le Kubernetes managé chez Clever Cloud (partie 1)

Tue, 12 May 2026 12:00:00 +0200

La suite de ma saga avec Clever Cloud

Ça fait maintenant quelques années que je teste les produits de Clever Cloud sur ce blog. En 2022, j’avais testé le Clever Kubernetes Operator, qui permet de provisionner des services managés (MySQL, Redis, Pulsar…) directement depuis un cluster Kubernetes via des CRDs. En 2025, j’ai réessayé leur offre d’hébergement de sites statiques, et j’ai même poussé le délire jusqu’à déployer un control plane Kubernetes sur leurs apps Linux, pour rigoler en attendant leur offre managée.

Bref, à la fin de cet article, je concluais avec un trollface et un “j’attends mon accès au k8s managé de Clever Cloud”. Et bien… c’est maintenant !

Clever Cloud a lancé CKE (Clever Kubernetes Engine) en bêta publique. J’ai eu accès en avant-première pour tester et je leur ai fait quelques retours. Maintenant que le produit est public, j’ai enfin le droit de vous partager mes impressions.

CKE c’est quoi exactement ?

CKE est l’offre Kubernetes managée de Clever Cloud. Le positionnement est clair : Vanilla Kubernetes, pas de lock-in, le plus standard possible dans l’usage du cluster.

Ce qui distingue CKE des offres plus conventionnelles, c’est ça :

Materia etcd : leur implémentation maison de l’API etcd, construite sur FoundationDB (pas d’etcd VM à provisionner ou dimensionner, c’est serverless). C’était pas gagné, cf cet article de Pierre Zemb “Diving into Kubernetes’ Watch Cache”
Infrastructure souveraine et isolée des autres clients : tout tourne sur des VMs dédiées, en France. Rien de mutualisé entre tenants.
Cilium + eBPF natif, avec WireGuard pour le chiffrement inter-nodes.

Activation : c’est un peu caché

CKE est en bêta publique, mais l’accès n’est pas actif par défaut. Il faut l’activer, soit via la CLI :

clever features enable k8s

Note : les commandes clever k8s sont disponibles dans la CLI à partir d’une version récente de leur CLI, idéalement version 4.9+.

Soit depuis l’interface web, dans l’onglet Labs de votre compte : https://console.clever-cloud.com/users/me/feature-list

L’onglet Labs n’est pas particulièrement mis en avant dans la console (il faut savoir où chercher). Une fois le feature flag activé, un nouveau menu apparaît dans la console.

Création d’un cluster

Depuis la CLI, voici la commande minimale pour créer un cluster :

clever k8s create moncluster --watch

--watch suit le déploiement jusqu’à ce que le cluster soit ACTIVE. En pratique, ça ressemble à ça :

⏳ Cluster status: DEPLOYING. Waiting for 10s before checking again...
✓ Cluster moncluster (kubernetes_01KRDDW6YNMDE7ZT0RYD3MY0GE) deployed successfully

On peut passer tout un tas d’options : version K8s (--cluster-version 1.36), topology, flavor du control plane, replication factor, autoscaling, CSI… On y reviendra.

Mais il est aussi possible, depuis peu, de créer un cluster via formulaire de création, avec un récapitulatif en temps réel.

On y retrouve tous les paramètres : version K8s, topology, flavor, replication factor, autoscaling, persistent storage. C’est bien fait, les topologies sont expliquées inline. Le nom de cluster est généré aléatoirement (style cunning-arcane-runic-corsair, modifiable bien sûr).

Les 3 topologies : Essential, Business, Enterprise

C’est l’un des aspects les plus inhabituel de CKE. Trois topologies sont disponibles à la création (et immutables après, ce qui oblige à bien choisir dès le départ).

Topology	Offre	Ce que vous payez	Usage typique
`ALL_IN_ONE`	Essential	rf (replication factor) × VM bundle (CP + worker intégré)	Dev, test, petits clusters
`DEDICATED_COMPUTE`	Business	rf × VM CP + chaque worker VM	Prod avec isolation CP/workers
`DISTRIBUTED`	Enterprise	5 composants × rf × VM + workers	Prod HA fine par composant

ALL_IN_ONE est la topologie par défaut. Le control plane et un worker node partagent la même VM (c’est le mode k3s-style, pour reprendre la description de la console). Ça a une conséquence concrète : kubectl get nodes liste le node du control plane comme worker disponible pour les pods.

DEDICATED_COMPUTE isole le CP sur ses propres VMs, les workers sont dans des node groups séparés. Avec un replication factor de 3, les VMs sont réparties sur les 3 datacenters parisiens de Clever Cloud (un datacenter peut tomber sans impacter le control plane).

DISTRIBUTED pousse l’isolation plus loin : chaque composant du CP (apiserver, controller-manager, scheduler, cloud-controller-manager, node-group-operator) tourne sur sa propre VM, avec sa propre flavor et son propre replication factor. J’ai du mal à voir dans quel cas c’est utile, mais pourquoi pas.

Un mot sur la tarification

Contrairement à certains cloud providers (de moins en moins cela dit…) qui offrent parfois le control plane quand il est mutualisé et ne facturent que les workers, Clever Cloud facture une vraie VM dédiée par cluster (rien de mutualisé entre tenants).

En ALL_IN_ONE, cette VM fait aussi office de worker, ce qui en fait paradoxalement l’option la moins chère. La flavor S (8 vCPU / 12 GB RAM) revient à 64 €/mois, CP et workers inclus sur la même machine. L’isolation se paye davantage : DEDICATED_COMPUTE commence à 96 €/mois pour le CP seul (+ workers séparés), DISTRIBUTED à 180 €/mois minimum pour 5 composants CP en 2XS.

Ce n’est pas donné pour du dev, mais le prix s’explique par le choix architectural : vous avez vraiment 8 vCPU / 12 GB de RAM rien que pour vous, pas un dixième de VM partagée entre dix clients.

Note : pendant la bêta publique, le CSI (Ceph) et les LoadBalancers ne sont pas encore facturés. Seuls le CP et les workers le sont.

Récupérer le kubeconfig

clever k8s get-kubeconfig moncluster > ~/.kube/clever.yaml
kubectl --kubeconfig ~/.kube/clever.yaml get nodes

Un détail à noter : l’API server écoute sur un port non standard (1032 ou 1022 selon les clusters). Ce n’est pas bloquant dans la plupart des environnements, mais j’ai eu la surprise de me retrouver bloqué depuis un réseau qui filtre les ports non-standards. À garder en tête si vous devez accéder au cluster depuis un réseau d’entreprise restrictif.

Anatomie du cluster

Une fois connecté, quelques observations :

$ kubectl get nodes -o wide
NAME STATUS VERSION OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
control-plane-be4e3383-...-node Ready v1.36.0 Exherbo Linux 6.19.14-clevercloud-vm-dirty (amd64) containerd://2.3.0

Exherbo Linux : on retrouve bien la marque de fabrique de Clever Cloud. Pour celleux qui ne connaissent pas, Exherbo est une distro minimaliste et source-based, peu connue en dehors de cercles très spécialisés. Le kernel est un build custom Clever Cloud (clevercloud-vm-dirty), et le container runtime est containerd 2.3.0.

Les composants pré-installés dans kube-system :

$ kubectl get pods -A
NAMESPACE NAME READY
kube-system cilium-tv9m7 1/1 # CNI
kube-system cilium-operator-7db7f998d7-z5zq8 1/1
kube-system coredns-5986bf5c44-wkzb9 1/1
kube-system konnectivity-agent-l26kl 2/2 # proxy CP->workers
kube-system kube-state-metrics-75b86d74f6-6slx8 2/2
kube-system kubelet-csr-approver-68d5bfcb6b-kgz5c 1/1
kube-system metrics-server-559c9b85f9-wflvk 1/1
kube-system cc-collector-wwpld 1/1 # collecteur OTel Clever Cloud

Quelques absences notables par rapport à une install classique : pas de kube-proxy (remplacé par Cilium en mode eBPF kube-proxy replacement).

Pour la petite histoire, les premiers teasers de CKE avaient montré l’usage de flannel. Heureusement que les équipes de clever ont écouté la communauté et migré vers cilium.

Konnectivity : l’isolation réseau du control plane

Le pod konnectivity-agent mérite une mention. C’est un composant qu’on retrouve assez souvent sur les Kubernetes managés et certaines distribution de Kubernetes. Il tourne sur chaque node (2 containers : proxy-agent + haproxy) et sert de proxy entre le control plane et les workers. Le CP ne parle pas directement aux pods : tout le trafic CP->workers (logs, exec, port-forward, métriques) passe par ce tunnel.

Pour un service managé, c’est la bonne pratique : le control plane n’a pas besoin d’accès réseau direct aux pods, et les workers n’ont pas besoin d’exposer kubelet directement au CP.

Materia etcd

Pas de pod etcd dans le cluster : c’est normal. Clever Cloud utilise Materia etcd, leur implémentation serverless de l’API etcd construite sur FoundationDB. C’est transparent pour vous.

Cilium

Le CNI est Cilium v1.19.1. Pour aller plus loin sur l’intégration Cilium/CKE, je vous recommande l’article de Joseph qui est le premier à en avoir parlé publiquement et qui s’y connaît bien mieux que moi sur le sujet.

Les NodeGroups

Les workers sont gérés via une CRD custom NodeGroup (groupe api.clever-cloud.com/v1).

apiVersion: api.clever-cloud.com/v1
kind: NodeGroup
metadata:
 name: mes-workers
spec:
 flavor: S
 nodeCount: 3

kubectl apply -f nodegroup.yaml

Les nodes apparaissent dans kubectl get nodes environ 35-40 secondes après la création du NodeGroup. La CRD supporte le subresource scale, ce qui permet de faire :

kubectl scale nodegroup mes-workers --replicas=5

Les flavors disponibles en ALL_IN_ONE : S (8 vCPU / 12 GB), M (10 vCPU / 16 GB), L (12 vCPU / 24 GB), XL (16 vCPU / 32 GB). Un quota global s’applique au niveau de l’organisation (40 vCPU / 40 GB RAM par défaut, tous clusters confondus). Ca peut probablement être augmenté en faisant une demande au support, mais j’ai pas assez d’argent à crâmer pour justifier une telle demande 😅.

En cas de dépassement de quota, le NodeGroup passe en phase QuotaExceeded avec un message d’erreur très lisible :

'Quota exceeded: RAM max: limit = 40.0 GB | actual = 48.0 GB | excess = 8.0 GB'

C’est appréciable : on sait exactement ce qui bloque et de combien.

La CLI propose aussi une gestion des node groups :

clever k8s nodegroups create moncluster workers M:3
clever k8s nodegroups update moncluster workers --count 5
clever k8s nodegroups update moncluster workers --autoscaling --min 2 --max 10

Combien de temps pour booter ?

Un des points forts mis en avant par Clever Cloud. J’ai mesuré avec un script de benchmark (3 runs) et via la commande clever k8s activity qui expose les timestamps précis de chaque étape :

clever k8s activity moncluster --format json

[
 { "operation": "CREATE", "stepName": "Deploy Control Plane", "status": "STARTED", "createdAt": "2026-05-12T06:27:11Z" },
 { "operation": "CREATE", "stepName": "Deploy Control Plane", "status": "COMPLETED", "createdAt": "2026-05-12T06:27:28Z" },
 { "operation": "CREATE", "stepName": "Install Plugins", "status": "STARTED", "createdAt": "2026-05-12T06:27:28Z" },
 { "operation": "CREATE", "stepName": "Install Plugins", "status": "COMPLETED", "createdAt": "2026-05-12T06:28:01Z" }
]

activity détaille chaque étape du bootstrap : création du réseau, déploiement de Materia LogicalDB, déploiement du control plane, configuration du load balancer, installation des plugins. Elle couvre aussi les opérations sur les NodeGroups.

Résultats mesurés (K8s 1.35, 3 runs, 5 nodes S) :

Étape	Moyenne
Cluster DEPLOYING -> ACTIVE	~57s
NodeGroup -> 1er node Ready	~38s
NodeGroup -> tous les nodes Ready	~46s (donc 8s après le premier node)
Suppression du cluster (API)	~244ms

Pour comparaison, SKS d’Exoscale bootstrappe le control plane en ~2 minutes (on me souffle dans l’oreille que ça a peut être baissé depuis). Et à la bonne époque où je faisais du AKS, c’était carrément 20+ minutes (j’espère qu’ils se sont améliorés depuis). Clever Cloud se place très haut sur ce critère.

Réseau, services, sécurité

LoadBalancer: chaque service de type LoadBalancer provisionne un L4 LB avec deux IPs publiques dédiées.

Ingress : pas d’ingress controller préinstallé. Traefik s’installe sans problème via Helm.

NetworkPolicies : Cilium étant le CNI natif, les NetworkPolicies sont enforced nativement. Pas besoin d’installer quoi que ce soit en plus.

Note pour ceux qui auraient lu mon article de mars sur le CNI chaining Flannel/Cilium : cet article était né des tests sur la bêta privée de CKE, qui utilisait Flannel à l’époque. Depuis le passage en bêta publique, CKE livre Cilium nativement (les NetworkPolicies fonctionnent out of the box).

Pod Security Admission : aucun namespace n’a de labels PSA par défaut (ni kube-system, ni default). Ça signifie que les pods sont en mode privileged implicite, sans restriction. On peut bien sûr configurer ça soi-même, mais sur un cluster managé on s’attendrait à avoir au minimum des profils baseline ou restricted préconfigurés sur les namespaces utilisateur.

RBAC : pas de surprise, le kubeconfig fourni donne un accès cluster-admin. A ne pas utiliser au delà de l’administration initiale ;-).

Stockage (CSI)

Le CSI n’est pas activé par défaut. Pour l’activer :

clever k8s add-persistent-storage moncluster

Activation en ~1 minute. Une StorageClass csi-rbd-sc (défaut) est créée, provisionnée par rbd.csi.ceph.com (Ceph RBD), filesystem XFS, volume expansion activée.

Les tests complets du cycle de vie (PVC, resize, snapshots) feront l’objet de la partie 2.

Un vrai déploiement : GroROTI

Histoire de valider que tout fonctionne de bout en bout, j’ai déployé GroROTI (ma propre application web en golang de ROTI) via Helm, avec Traefik en ingress controller et un certificat TLS.

helm install traefik traefik/traefik -n traefik --create-namespace
helm install groroti oci://ghcr.io/zwindler/groroti-chart \
 -f values-clever.yaml \
 --namespace groroti --create-namespace

Au bout de quelques minutes, l’application tourne sur groroti.zwindler.fr, accessible publiquement, TLS inclus. Ça fonctionne.

Bugs rencontrés (alpha / bêta oblige)

LoadBalancer : lors de mes premiers tests (alpha / bêta privée), j’avais eu un cas où l’EXTERNAL-IP restait en <pending> pendant… 32 heures. Ce problème semble avoir disparu en bêta publique.

Cluster FAILED sans diagnostic : lors de mes tests, j’ai eu plusieurs clusters qui passaient en FAILED ~25 secondes après la création, sans aucun message d’erreur exploitable. clever k8s get <ID> retourne juste Status: FAILED, même avec --verbose. Aucune commande logs ou events pour un cluster n’existe dans la CLI.

C’est d’autant plus frustrant que le status QuotaExceeded des NodeGroups est, lui, extrêmement bien documenté dans le message d’erreur. Il y a une belle asymétrie là.

Le bug a été résolu côté Clever Cloud dans la nuit. Mais le manque de diagnostic reste un point à améliorer. L’UI est aussi encore clairement en bêta, avec un petit bug graphique que j’ai pu remonter.

Conclusion (partie 1)

Première impression globalement positive. CKE est impressionnant pour une bêta :

Boot time excellent : ~57s pour le cluster (CP à part ou All in one), ~38s pour le premier node quand on ajoute des NodeGroups (dans le haut du panier des Kubernetes managés que j’ai testé au fil des années)
Cilium natif avec WireGuard inter-nodes, NetworkPolicies out of the box
Materia etcd sur FoundationDB : une approche originale pour gérer les problématiques etcd (scalabilité, multi tenancy) d’un cloud provider
Design CRD propre pour les NodeGroups, compatible kubectl scale
Konnectivity : isolation réseau du CP comme chez les grands cloud providers

Les points à améliorer : diagnostic du status FAILED, PSA non configurée par défaut, pas d’ingress controller inclus.

J’ai aussi une petite feature que j’ai demandé à Antoine chez Clever, l’audit logging, c’est en cours. Wait and see ;-).

La tarification du control plane me parait un poil élevée, typiquement face à des concurrents européens comme SKS ou Kapsule (mode mutualisé), mais elle s’explique par le choix architectural (VMs dédiées, rien de mutualisé). Pour une équipe déjà sur Clever Cloud, l’intégration avec le Clever Kubernetes Operator et les add-ons managés est un vrai argument.

Dans la partie 2, on creusera sûrement plus de fonctionnalités, comme le CSI (lifecycle PVC, resize, snapshots), les upgrades de cluster, l’intégration avec Clever Cloud operator (justement). Peut être aussi qu’on testera vCluster ou k3k ?

Test de SKS, le Kubernetes managé chez Exoscale !

Mon, 03 May 2021 06:20:00 +0000

Kewa ? Exoscale a un Kubernetes Managé ?

Lorsque Mathieu Corbin m’a parlé du Kubernetes managé qu’ils étaient en train de monter chez Exoscale, je lui ai tout de suite proposé de me le montrer, pour que je lui donne mon point de vue.

Sans être un expert absolu des offres Kubernetes en SaaS, j’en ai quand même testé quelques uns, notamment AKS d’Azure, OVH et quelques autres (GCP, Kapsule, … pour lesquels je n’ai pas fait d’article).

Et puis, bon, Kubernetes, c’est un peu mon métier maintenant ;-).

Au moment où j’ai rédigé le premier brouillon de cet article, on était encore en bêta fermée. Il n’y avait pas d’interface graphique dans le portail (uniquement la CLI), certains paramètres étaient pas totalement dans les règles de l’art (problèmes connus chez eux), …

Et puis le temps a passé et je n’ai pas sorti l’article (comme souvent par manque de temps) avant que la solution passe GA.

Heureusement, le passage en GA c’est aussi une bonne occasion pour moi de refaire le test et de comparer le boulot qui a été accompli (en peu de temps) pour gommer les quelques défauts de jeunesse que la solution pouvait encore avoir.

Mais d’abord, Exoscale ?

J’vais pas mentir, même si j’avais déjà croisé le nom d’Exoscale plusieurs fois, je n’avais jamais pris le temps de tester leur offre. Pour ceux qui l’ignorent donc, Exoscale est un cloud provider avec plusieurs points de présence en Europe.

Niveau taille de l’acteur, on est pas du tout comparables à un OVH (ou même Scaleway), mais ils sont suffisamment nombreux pour se permettre d’avoir une team dédiée à la release d’un Kubernetes managé. Tout en gardant suffisamment de bande passante pour quand même avoir une API ouverte et documentée, comme les grands.

Et donc, SKS ?

Cette micro introduction d’Exoscale passée, revenons donc à nos nuages.

L’offre Kubernetes managée d’Exoscale s’appelle SKS (pour Scalable Kubernetes Service).

On nous promet donc sur le site d’Exoscale un service scalable (horizontalement), qui démarre normalement en 90 secondes.

La gestion du cycle de vie du control plane est entièrement gérée, on peut le déployer via CLI, API, depuis le portail et il existe aussi un provider terraform.

Enfin, Exoscale a développé un composant permettant de faciliter l’intégration de son load balancer managé dans SKS (pour l’instant).

Et comme je vous l’avais promis, l’API de SKS est documentée ici si jamais vous aimez faire des cURL.

Et ça coute cher ?

Dans les offres managées de Kubernetes, il y a plusieurs clans. Ceux qui proposent un SLA sur le control plane et ceux qui n’en proposent pas. Et il y a ceux qui font payer le control plane et ceux qui ne le font pas payer.

Souvent, ceux qui ne font pas payer le control plane sont également les mêmes qui ne proposent pas de SLA sur le control plane.

Et pour avoir discuté avec un commercial de chez Azure en fait il y a une certaine logique à ne pas proposer de SLA sur un control plane gratuit. Un SLA étant un contrat, difficile de s’engager sur un service gratuit (et encore plus, difficile de vous rembourser ce que vous ne payer pas en cas de problème).

Chez Exoscale, c’est fromage ou dessert, vous avez le choix. SKS est offert en 2 offres distinctes :

une payante, avec SLA (99,95%)
l’autre gratuite, sans SLA

Classiquement, les workers sont quant à eux facturés au même prix que n’importe quelle machine IaaS chez Exoscale.

Petite subtilité qui m’a fait sourire, là où les clouds providers se battaient sur qui bill à l’unité de temps la plus petite il y a 10 ans (d’abord l’heure, puis progressivement à la minute), chez Exoscale, vous êtes billé à la seconde. Difficile de faire plus précis.

Pour tout ce qui concerne le pricing, je vous laisse aller voir ici. N’ayant aucun intérêt financier à vous pousser vers Exoscale (ou OVH, ou Azure), je ne vais pas insister plus que ça ;-).

Bon, on teste ?

Maintenant qu’on a fait le tour de la question, et si on essayait un peu de voir ce que ça donne ?

La première chose à faire est de se créer un compte sur www.exoscale.com et aussi télécharger la dernière version de la CLI.

J’insiste bien sur la « dernière version » car pendant la bêta j’avais téléchargé la mauvaise version et l’API et les paramètres avaient changé de manière significative en peu de temps.

A l’heure où j’écris l’article, la dernière version est la 1.28 (1.23 quand j’ai testé la bêta en début d’année) mais les releases sont dispos ici : github.com/exoscale/cli/releases

wget https://github.com/exoscale/cli/releases/download/v1.28.0/exoscale-cli_1.28.0_linux_amd64.tar.gz
tar xzf exoscale-cli_1.28.0_linux_amd64.tar.gz
➜ ./exo
Manage your Exoscale infrastructure easily
[...]

A noter, il existe aussi pour les distributions linux des packages (.deb, .rpm, etc).

Configuration du compte

Maintenant qu’on a notre CLI sur notre poste, on va aller dans le portail créer une clé d’API qui va nous servir à nous authentifier.

La documentation officielle est disponible ici.

Une fois que vous aurez cliqué sur « Create », l’ID de la clé ainsi que la clé apparaitra. Attention, comme toujours avec ce genre de mécanisme, la clé ne sera visible que cette fois ci. Sauvegardez là donc bien précieusement (sinon au pire il faudra en générer une nouvelle).

On peut ensuite configurer notre CLI

./exo config

Et on teste que la connexion marche bien avec la commande permettant de lister les versions de Kubernetes disponibles sur SKS

./exo sks versions

Bon, je sais pas vous mais moi a me donne le sourire de voir que fin avril, Exoscale a déjà la 1.21 dispo :-)

Création du security group

Exoscale dispose, comme tous les cloud providers, d’un système de firewalling qui permet d’appliquer des règles de sécurité à nos futures machines.

Même si la création d’un groupe de sécurité n’est pas obligatoire pour instancier notre cluster SKS, c’est mieux si on le fait dès le début.

Tout peut se faire via la CLI ou via le portail, comme pour le reste chez Exoscale

./exo firewall create sks-zwindler-sg
./exo firewall add sks-zwindler-sg -d "NodePort services" -p tcp -P 30000-32767
./exo firewall add sks-zwindler-sg -d "SKS Logs" -p tcp -P 10250
./exo firewall add sks-zwindler-sg -d "Calico traffic" -p udp -P 4789 -s sks-zwindler-sg

Si vous préférez le faie sur le portail, ça ressemblera à ça :

J’ai juste repris les valeurs par défaut dans la doc de Quick Start

Créer un cluster

La commande exo sks create permet de créer notre cluster. On peut rajouter des flags pour modifier certains paramètres :

exo sks create -h

Au delà des options pour choisir la taille du cluster et le type de node, les options intéressantes sont les 3 « –no- » qui vous permettent de désactiver l’installation automatique de :

la CNI (Calico par défaut). Calico par défaut est un bon choix mais si vous préférez Cillium ou kube-router (ou flannel… nan j’déconne !).
la CCM (Cloud Controller Manager), composant développé en interne par Exoscale et qui permettra à Kube d’interagir avec les autres services d’Exoscale (notamment le loadbalancer)
metrics-server mais là je vois pas pourquoi vous ne voudriez pas metrics-server …

./exo sks create sks-zwindler --description "Test SKS cluster" --nodepool-name "sks-zwindler-pool" --nodepool-size 3 --nodepool-security-group "sks-zwindler-sg" --zone de-fra-1 --service-level pro
&#x2714; Creating SKS cluster "sks-zwindler"... 1m57s
&#x2714; Adding Nodepool "sks-zwindler-pool"... 3s

Je ne sais pas si je n’ai pas eu de chance car il me semblait que ça allait un peu plus vite que les deux minutes que j’affiche dans cet extrait de shell. Mais 2 minutes c’est déjà plus que respectable quand on sait que chez Azure, AKS met plus de 20 minutes à poper (quand ça ne plante pas), sans compter les VMs (qui elles aussi mettent parfois 10 minutes avant d’être disponibles)…

kubeconfig

Disponible… ok … Mais comment on s’y connecte en fait ?

Pas de panique, la CLI permet de générer le kubeconfig qui va vous permettre de vous connecter à l’API server ! (ouf)

Un point intéressant de l’implémentation d’Exoscale est que vous pouvez tuner un peu le kubeconfig qu’il va vous générer (là où la plupart du temps, c’est un kubeconfig admin, point). Vous pouvez notamment choisir le groupe RBAC ainsi qu’une durée de vie.

Dans un environnement de production avec beaucoup d’utilisateurs, on préfèrera surement ajouter une authentification tierce (coucou OIDC), cependant, c’est quand même « nice to have ».

./exo sks kubeconfig sks-zwindler kube-admin --group system:masters --zone de-fra-1 > sks-zwindler-30d.kubeconfig

L’authentification se fait donc par certificat avec une durée que vous pouvez configurer en secondes (par défaut 30 jours). Bon, comme je vois que ce que je crois, j’ai fait le test avec 60 secondes et a priori ça marche ;-).

./exo sks kubeconfig sks-zwindler kube-admin --group system:masters --zone de-fra-1 --ttl 60 > test-60s.kubeconfig
kubectl --kubeconfig test-60s.kubeconfig get nodes
NAME STATUS ROLES AGE VERSION
pool-afa3f-apzqy Ready <none> 6h v1.21.0
pool-afa3f-iehif Ready <none> 6h v1.21.0
pool-afa3f-ysvki Ready <none> 6h v1.21.0
#plus tard
kubectl --kubeconfig test-60s.kubeconfig get nodes
error: You must be logged in to the server (Unauthorized)

Déployer une application disponible sur Internet

Comme la CCM nous permet de faire communiquer notre Kubernetes et Exoscale, on va en profiter pour créer un service Kubernetes de type Loadbalancer.

Ce service Loadbalancer va commander à Exoscale un NLB chez eux, ce qui va nous permettre de router le trafic Internet directement dans notre cluster (il vaudrait mieux passer par un IngressController brancher sur ce service Loadbalancer dans la vraie vie).

kubectl --kubeconfig sks-zwindler-30d.kubeconfig create service loadbalancer toto --tcp=80:80
kubectl --kubeconfig sks-zwindler-30d.kubeconfig get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 8h
toto LoadBalancer 10.111.39.139 <pending> 80:30001/TCP 22s
kubectl --kubeconfig sks-zwindler-30d.kubeconfig get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 8h
toto LoadBalancer 10.111.39.139 89.145.161.242 80:30001/TCP 23s

Puis on déploie un nginx de test avec un label similaire à celui créé par défaut par le service (app=toto)

kubectl --kubeconfig sks-zwindler-30d.kubeconfig run --image nginx --labels app=toto toto

Très rapidement, vous devriez avoir accès à votre pod via l’IP du NLB Exoscale

Nettoyage

Si vous avez mis votre carte de crédit, n’oubliez de supprimer votre cluster de test avant de partir ;-)

./exo sks delete sks-zwindler -n
[+] Are you sure you want to delete Nodepool "sks-zwindler-pool"? [yN]: y
&#x2714; Deleting Nodepool "sks-zwindler-pool"... 6s
[+] Are you sure you want to delete SKS cluster "sks-zwindler"? [yN]: y
&#x2714; Deleting SKS cluster "sks-zwindler"... 18s

Et faites pareil si vous avez un instancié un Loadbalancer pour connecter vos services dans Kubernetes avec l’extérieur (j’avais oublié… oups).

Conclusion

J’avais été impressionné par l’implémentation d’OVH de Kubernetes managé, mais je dois reconnaitre que je le suis encore plus par celui d’Exoscale.

Le cluster (control plane) est créé TRES vite, mais surtout les VMs popent également extrêmement vite (quelques secondes versus 10 minutes chez Azure !!!). C’est vraiment chouette !

De ce que j’ai vu (et pu échanger) des entrailles de SKS, tout me parait très sain et bien conçu (sécurité, best practices). Et pourtant, Exoscale donne quand même pas mal de libertés sur la customisation du cluster (CCM, CNI, configuration kubeconfig).

Les petits bugs de jeunesses (quelques erreurs de configuration du kubelet, des erreurs cosmétiques dans les commands lines, le CCM à installer soit même, …) que j’avais pu remonter à Mathieu lors de mon test en janvier/février ont toutes été gommés en moins de 2 mois.

Donc, selon moi, si vous cherchez un kube managé, SKS est une alternative viable.