Clever Cloud 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 ?

Créer un cluster Kubernetes sur Clever Cloud avec les apps Linux

Sat, 19 Jul 2025 13:00:00 +0200

Introduction

Après avoir testé les apps statiques chez Clever Cloud, j’ai voulu pousser plus loin l’exploration des nouvelles fonctionnalités.

Clever Cloud a en effet lancé récemment un nouveau type d’application : les apps Linux. Ces dernières permettent de déployer des applications génériques sur une machine Linux, sans runtime prédéfini. Un peu comme avoir sa propre VM, mais managée par Clever Cloud.

Du coup, pour “rigoler” (et par pure curiosité technique), j’ai décidé de créer un control plane Kubernetes complet sur ce type d’instance. Pourquoi ?

D’abord parce que je parle tout le temps de Kubernetes. Et ensuite, pour faire un petit clin d’œil aux copains de chez Clever Cloud : ils annoncent depuis des mois leur offre Kubernetes managée qui devrait sortir (soon™).

Et en poussant les runtimes Linux dans leurs retranchements, ça m’a permis de découvrir pas mal de fonctionnalités que (j’avoue) je ne connaissais pas chez Clever.

Disclaimer : ce projet est purement éducatif et expérimental. Ne l’utilisez pas, même pour un usage personnel !

Le projet : k8s-on-clever-linux

J’ai créé un dépôt GitHub dédié à ce projet : k8s-on-clever-linux.

Le principe est simple : déployer tous les composants du control plane Kubernetes (etcd, kube-apiserver, kube-controller-manager, kube-scheduler) comme des processus sur une app Linux Clever Cloud.

Le projet s’inspire fortement de mon tutoriel demystifions-kubernetes. Et d’ailleurs, pour tester le proof of concept, c’est ce que j’ai bêtement déroulé, pour valider la faisabilité.

Cependant, dans le cas de Clever, plutôt que de lancer tous les composants un par un en déroulant un script bash (ce qui est fait dans github.com/zwindler/demystifions-kubernetes), j’ai fait un poil plus rusé…

Découverte de Mise.

Mais d’abord un peu de contexte :

Clever Cloud platform provides a multi-runtime environment, including many tools to deploy and run your applications. The Linux runtime is a versatile solution to build and deploy any kind of application. The Mise package manager helps you to install and manage any supported dependencies Clever Cloud doesn’t provide by default such as Dart, Gleam, Zig for example.

Documentation officielle des Linux runtimes chez Clever Cloud

Déjà, ça parle d’un truc qui s’appelle Mise package manager. C’est quoi ça ?

Il s’agit d’un projet de Jeff Dickey (jdx.dev). Sur nos apps Linux, ça va nous permettre d’installer une partie des dépendances d’une part, et d’ordonnancer le lancement de commandes pour build, puis pour run notre projet dans l’instance Linux

mise.jdx.dev

Découpage de l’application

Maintenant qu’on en sait plus, voilà comment j’ai découpé l’application avec Mise :

Initialisation (mise.toml)

Même si tous les prérequis ne sont pas tous disponibles dans Mise, je peux quand même déléguer le téléchargement d’une partie d’entre eux, ce qui va alléger le script de téléchargement des dépendances par rapport à démystifions kubernetes. C’est toujours bon à prendre :

[tools]
cfssl = "latest"
etcd = "latest"
kubectl = "latest"
helm = "latest"

Phase de build (.mise-tasks/build)

Télécharge tous les binaires Kubernetes
Génère les certificats pour l’authentification des composants
Configure les paramètres statiques
Mise en cache : cette phase n’est exécutée que lors des changements de code

De cette manière, en cas de reboot de l’application, on ne perd pas les certificats et on gagne un peu de temps pour le redéploiement.

Phase de run (.mise-tasks/run)

Lancer tous les composants de notre control plane Kubernetes
Génère un bootstrap token pour ajouter des Nodes
Lance un serveur HTTP qui écoute sur le port 8080 et ne sert… rien.

Pourquoi un serveur HTTP ? Eh bien tout simplement parce que

Linux runtime only requires a CC_RUN_COMMAND to execute, with a working web application listening on 0.0.0.0:8080.

Si je ne mets rien en écoute sur le port 8080, Clever va logguer que mon app est en panne (alors que non).

Focus sur Mise pour installer les dépendances

Concrêtement, comment ça se présente quand on lance une app dans Clever Cloud avec un mise.toml ?

Ben tout simplement comme ça :

2025-07-20T15:54:04.304Z mise etcd@3.6.2 install
2025-07-20T15:54:05.302Z mise etcd@3.6.2 download etcd-v3.6.2-linux-amd64.tar.gz
2025-07-20T15:54:06.403Z mise etcd@3.6.2 checksum etcd-v3.6.2-linux-amd64.tar.gz
2025-07-20T15:54:06.422Z mise etcd@3.6.2 extract etcd-v3.6.2-linux-amd64.tar.gz
2025-07-20T15:54:06.705Z mise etcd@3.6.2 ✓ installed

La liste des tools disponibles avec mise est ici :

mise.jdx.dev/registry

Et on peut remarquer que les tools viennent de différentes sources telles qu’aqua, pipx, ubi, asdf… Ça me donne envie de tester ça pour les dépendances qui me manquent donc attendez-vous à un prochain article sur le sujet :).

Mais… ils sont où les binaires du control plane de Kubernetes ?

Initialement, j’avais mis tout ça dans la phase de run. Sauf que David m’a proposé de découvrir une autre fonctionnalité de Clever Cloud que je n’avais jamais utilisée : les Workers.

Les Workers sont des processus en arrière-plan qui tournent en parallèle de votre application principale.

Pour notre cluster Kubernetes, c’est parfait ! Plutôt que de lancer tous les composants dans un script bash, chaque composant du control plane devient un worker dédié :

Worker 0: ./run-scripts/start-etcd.sh
Worker 1: ./run-scripts/start-kube-apiserver.sh
Worker 2: ./run-scripts/start-kube-controller-manager.sh
Worker 3: ./run-scripts/start-kube-scheduler.sh
Worker 4: ./run-scripts/post-boot.sh - bootstrap tokens, RBAC, worker scripts

Avec en bonus la possibilité de configurer le comportement de redémarrage :

CC_WORKER_RESTART=on-failure (par défaut) : redémarre seulement en cas d’erreur
CC_WORKER_RESTART=always : redémarre toujours
CC_WORKER_RESTART_DELAY=1 : délai en secondes avant redémarrage

Installation et configuration

Bon, clairement, cette partie n’est pas la plus user-friendly du tutoriel. Si vous voulez plus de détails sur ce qui est fait et pourquoi, vous pouvez aller jeter un œil directement sur le dépôt github.com/zwindler/k8s-on-clever-linux.

Les grandes étapes sont :

Créer l’app Linux clever create --type linux --github zwindler/k8s-on-clever-linux
Configuration de la redirection TCP

Linux runtime only requires a CC_RUN_COMMAND to execute, with a working web application listening on 0.0.0.0:8080.

Pour rappel, Clever Cloud s’attend à ce qu’on expose une app en HTTP non sécurisé sur le port 8080. Sauf que moi, je veux exposer l’API server Kubernetes en HTTPS. On va donc activer la “redirection TCP” : Clever Cloud attribue un port aléatoire (dans les 5XXX) qui redirige vers le port 4040 de votre application (et donc je dois dire à l’API server de ne pas écouter sur le 6443, mais 4040) :

$ clever tcp-redirs add --namespace default
Successfully added tcp redirection on port: 5131

Configuration du domaine

Une fois le port TCP connu, on peut configurer notre domaine.

clever domain add k8soncleverlinux.domain.org

Dans mon cas, l’API server sera accessible sur le domaine k8soncleverlinux.zwindler.fr et sur le port 5131. Comme ces deux valeurs seront différentes pour vous, j’ai vite codé un script qui permet de prendre les valeurs par défaut pour moi, mais vous permettre de les écraser si vous spécifiez des valeurs sur VOTRE app Clever Cloud :

clever env set K8S_DOMAIN k8soncleverlinux.zwindler.fr
clever env set K8S_TCP_PORT 5131

Je suis vraiment sympa.

Configuration des workers : pour ça j’ai fait un script ./setup-clever-workers.sh

Ce script configure 5 workers dont j’ai parlé plus haut et qui sont gérés par systemd.

Déploiement et test

Si tout s’est bien passé, l’app devrait correctement se lancer, Mise devrait lancer la phase de build (surtout télécharger les dépendances qui manquent), puis la phase de run (les dépendances connues de Mise, et les workers une fois que run se termine) :

2025-07-19T13:10:45.130Z Successfully deployed in 0 minutes and 18 seconds

Les workers en tâche de fond devraient démarrer tous les composants de notre control plane Kubernetes. Au bout de quelques secondes (1 minute max), on devrait avoir un control plane fonctionnel, et tout un tas de certificats et autres secrets.

Mais comment le tester ? Via SSH sur l’instance Clever Cloud ! Car oui, on peut SSH sur cette instance :)

$ clever ssh
Last login: Fri Jul 18 20:17:00 UTC 2025 on pts/0

$ kubectl version
Client Version: v1.33.2
Kustomize Version: v5.6.0
Server Version: v1.33.2

🎉 Ça marche ! On a bien un control plane Kubernetes qui tourne sur Clever Cloud !

Et si vous avez bien travaillé (c’est à dire correctement configuré votre domaine et le port), on peut même l’utiliser depuis l’extérieur en copiant le fichier admin.conf localement et en modifiant l’endpoint dans le YAML :

$ kubectl cluster-info
Kubernetes control plane is running at https://k8soncleverlinux.zwindler.fr:5131

Ajout d’un worker node

Deuxième hic dans mon histoire. Un control plane sans worker, c’est pas terrible.

Et je ne peux pas utiliser l’app de type Linux de chez Clever car je n’ai pas assez de privilèges pour changer les options kernel (routage) et installer containerd.

Mais je n’allais pas en rester là. Dans mon projet “Démystifions Kubernetes”, j’installe un worker directement sur la machine du control plane et j’utilise le admin.conf (cluster-admin) pour enrôler l’hôte courant en tant que Node.

C’est cracra, mais quand je suis en conf et que j’ai 20 minutes pour speedrun, c’est acceptable.

Ici, j’ai fait l’effort d’aller regarder comment faire pour enrôler des Nodes avec un bootstrap token et c’est assez intéressant.

La doc officielle de kube est plutôt bien faite et je ferai peut-être un article à part sur le sujet, c’est assez facile en fait, avec un flag à ajouter dans l’API server, quelques RBAC et un secret bien spécifique à générer.

https://kubernetes.io/docs/reference/access-authn-authz/bootstrap-tokens/

Je vous épargne les détails, le projet va générer automatiquement un script pour ajouter des nodes externes :

2025-07-19T13:51:47.848Z ✓ Worker setup script generated: setup-worker-node.sh
2025-07-19T13:51:47.849Z 📋 Next steps:
2025-07-19T13:51:47.849Z 1. Copy setup-worker-node.sh to your external worker node
2025-07-19T13:51:47.849Z 2. (Optional) Edit NODE_NAME_OVERRIDE and NODE_IP_OVERRIDE if auto-detection is incorrect
2025-07-19T13:51:47.849Z 3. Ensure your worker node has sudo privileges and internet access
2025-07-19T13:51:47.849Z 4. Run the script on your worker node: sudo ./setup-worker-node.sh
2025-07-19T13:51:47.849Z 5. Check the node joined with: kubectl get nodes

# Script généré automatiquement
#!/bin/bash
# External Worker Node Setup Script for Kubernetes

API_SERVER_ENDPOINT="https://k8soncleverlinux.zwindler.fr:5131"
BOOTSTRAP_TOKEN="xxxxxx.xxxxxxxxxxxxxxxx"
# ... (configuration complète et certificats/secrets inclus)

Il suffit de copier ce script sur une VM Linux quelconque et de l’exécuter. Le script :

Installe containerd, kubelet, kube-proxy
Configure automatiquement l’authentification via bootstrap token
Démarre les services

✓ Worker node setup completed!

$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
coucou1 NotReady <none> 13m v1.33.3

Le node apparaît en “NotReady” car il manque le plugin CNI. Flannel fonctionne parfaitement :

$ kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml

$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
coucou1 Ready <none> 30m v1.33.3

$ kubectl get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-flannel kube-flannel-ds-b65jg 1/1 Running 0 14m

Le cluster est fonctionnel 😎😎😎 !

On a maintenant un cluster Kubernetes complet avec control plane sur Clever Cloud et worker externe… Avant la sortie du kube managé de Clever.

Limitations et évolutions possibles

Le worker externe n’étant pas dans le réseau Clever Cloud, l’API server ne peut pas communiquer avec le kubelet (dans le sens api-server -> kubelet uniquement). Cela limite les fonctionnalités comme kubectl logs, kubectl exec, etc. Une solution possible serait d’utiliser les Network Groups de Clever Cloud pour créer un réseau privé sécurisé.

Si ce projet continue de m’amuser, plusieurs améliorations sont envisageables :

exploration des Network Groups (dont je viens de parler)
intégration de Kine. Cela permettrait d’utiliser les bases de données existantes de Clever Cloud (PostgreSQL, MySQL) comme DB pour Kubernetes, ce qui permettrait éventuellement de rendre cette install “HA” ce qui serait aussi débile que rigolo
création des packages aqua/ubi manquants (les binaires de kubernetes et cfssljson)

Conclusion

J’ai commencé ce projet comme une blague et j’ai finalement mis le doigt dans plein de petites fonctionnalités cools de chez Clever Cloud et dont j’ignorais l’existence (ou alors, que j’avais vu passer mais pas creusé).

Même si ça m’a pris quelques soirées, c’était super intéressant. La première itération a été très vite fonctionnelle et je me suis pris au jeu des améliorations successives.

Le code complet est disponible sur GitHub si vous voulez reproduire l’expérience ou contribuer !

Et vous, quels projets fous avez-vous envie de tester avec les apps Linux ? 😄 Moi, j’attends mon accès au k8s managé de Clever Cloud maintenant 😝 (comment ça, je suis un gros forceur ???)

Je réessaye les sites statiques (Bloggrify) chez Clever Cloud

Mon, 07 Jul 2025 09:00:00 +0200

Introduction

Pour celles et ceux qui suivent mes péripéties d’hébergement de blog, vous savez que j’ai une relation compliquée (le fameux “it’s complicated” sur Facebook) avec Clever Cloud. J’ai déjà écrit à ce sujet dans deux articles précédents :

Pour finalement abandonner Clever Cloud et revenir sur une VM IONOS que je gère moi-même (voir Ça bouge encore sur le blog).

Mais depuis, Clever Cloud a ajouté les apps statiques à son catalogue. Plus besoin de passer par un runtime Apache + PHP, ce qui était effectivement un peu overkill pour un site Hugo statique (et pas compatible avec l’offre Pico, donc fallait prendre au minimum Nano à ~7€ par mois).

Du coup, je me suis dit : pourquoi ne pas retenter l’expérience ?

Comme Julien Wittouck m’a devancé de 3 semaines et a fait un article sur l’hébergement de sites statiques avec Hugo via ce nouveau type d’app chez Clever Cloud, vous pouvez aller lire son post ici, je n’ai pas envie de faire la même chose.

Pour ce test, j’ai choisi d’utiliser un autre site que celui-ci : 50ndk.zwindler.fr, qui me sert pour faire la promotion de mon livre.

Il est actuellement hébergé sur GitHub Pages et utilise le moteur Bloggrify (un des projets d’Hugo Lassiège, quelqu’un que j’apprécie énormément dans l’écosystème tech français).

Le principe est globalement le même qu’avec Hugo, à quelques petites différences près. C’est un site statique généré tout pareil, mais c’est Nuxt sous le capot et ça va nous être utile. Il y a quelques petites différences aussi depuis mon dernier test de 2023 que je ne manquerai pas de souligner.

Les sources du site sont disponibles ici si vous êtes curieux / curieuse :

https://github.com/zwindler/50ndk

Prérequis

On pourrait aller créer l’application dans l’UI. Normalement, les “tuiles” Static, Linux et VLang sont disponibles à tout le monde depuis le 4 juillet. J’ai un petit accès anticipé (merci David) mais je n’en ai pas beaucoup profité 🙃 (occupé avec le livre). Grosso modo c’est comme les autres types d’Apps chez Clever, vous ne serez pas perdus.

Bon, en WebUI c’est bien mais c’est plus rigolo de le faire en CLI.

clever login
Opening https://console.clever-cloud.com/cli-oauth?cli_version=3.0.2&cli_token=xxxxxxxxxxxxx in your browser to log you in…
Login successful as Denis GERMAIN <denis@domain.org>

Euh, je vois 3.0.2 dans l’URL ??? Je ne suis pas à jour. Visiblement j’avais installé la CLI clever avec npm (je ne m’en souviens pas). Plus simple, il y a aussi des dépôts .deb (ou brew, autre selon votre distribution).

clever version
3.0.2
╭─────────────────────────────────────────╮
│ │
│ Update available 3.0.2 → 3.13.1 │
│ Run npm i -g clever-tools to update │
│ │
╰─────────────────────────────────────────╯

Un petit npm i -g clever-tools et ça va mieux :)

$ clever version
3.13.1

Configuration de l’app

Un petit clever create avec le type de l’app et c’est parti !

denis@coucou % clever create --type static
✓ Application 50ndk successfully created!
Type ⬢ Static
ID app_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Org ID user_yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy
Name 50ndk
Zone par
Next steps:
! Commit your changes first:
$ git add .
$ git commit -m "My changes"
→ Run clever deploy to deploy your application
→ Manage your application at: https://console.clever-cloud.com/goto/app_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Note : si votre app est hébergée sur GitHub, vous pouvez rajouter aussi --github OWNER/REPO à la ligne de commande précédente. J’en parle plus tard, mais lisez tout avant de le faire.

Comme fin 2023, je vais avoir besoin de 2 machines différentes. Une qui va construire mon site statique, une qui va le servir. Et du coup, là comme je n’ai pas Apache, je peux avoir accès à une pico et économiser quelques euros à la fin de l’année :

$ clever scale --build-flavor M
App rescaled successfully
$ clever scale --flavor pico
App rescaled successfully

Dans mon test précédent avec Hugo+Clever, j’avais besoin de spécifier dans quel dossier le contenu statique doit être servi (et aussi quel dossier la machine qui construit doit partager avec la machine qui sert).

Dans le cas de Bloggrify, tout est dans .output/public. MAIS comme c’est du Nuxt, David m’a dit que je n’en avais pas besoin parce que Clever détecte automatiquement que c’est du Nuxt grâce au fichier nuxt.config.ts à la racine du projet.

Inutile donc de spécifier les variables CC_WEBROOT, CC_OVERRIDE_BUILDCACHE (pour pointer sur .output/public) CC_PRE_BUILD_HOOK et CC_BUILD_COMMAND (les commandes npm).

Plutôt une bonne surprise :).

Déploiement de l’application

À partir de là, on peut essayer de faire un premier déploiement à la main. Pour rappel, soit on envoie un commit sur le remote spécial créé par Clever (cf le message lors de la commande clever create), mais je vais préférer utiliser la commande clever deploy, déjà disponible en 2023 lors de mon premier test, car je l’utiliserai pour automatiser le workflow plus tard.

dgermain@dgermain-mac 50ndk % clever deploy
🚀 Deploying 50ndk
 Application ID app_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
 Org ID user_yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy

🔀 Git information
 ! App is brand new, no commits on remote yet
 Local commit aaaaaa [will be deployed]

La première partie du processus va donc lancer une machine de taille M dans le but d’accélérer un peu le temps de construction :

🔄 Deployment progress
 → Pushing source code to Clever Cloud…
 ✓ Code pushed to Clever Cloud
 → Waiting for deployment to start…
 ✓ Deployment started (deployment_zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz)
 → Waiting for application logs…
 ...

Clever va détecter tout seul que j’ai du Nuxt, lancer un npm install pour installer les prérequis pour Bloggrify, puis le npm run generate pour générer le code HTML statique.

[...]
2025-07-07T10:23:47.847Z Deploying commit ID defc0be02d44ace246127e11a17d4f359262ccfb
2025-07-07T10:23:47.847Z Nuxt.js configuration file detected
2025-07-07T10:23:47.847Z Running build command: npm i && npm run generate && mv .output/public cc_static_autobuilt
[...]
2025-07-07T10:24:48.809Z [nitro] ℹ Initializing prerenderer
2025-07-07T10:24:52.533Z [nitro] ℹ Prerendering 8 initial routes with crawler
2025-07-07T10:24:52.598Z [nitro] ├─ /robots.txt (17ms)
2025-07-07T10:24:52.841Z [nitro] ├─ /200.html (296ms)
2025-07-07T10:24:52.842Z [nitro] ├─ /404.html (297ms)
2025-07-07T10:24:52.964Z [nitro] ├─ /api/search (415ms)
2025-07-07T10:24:52.965Z [nitro] ├─ /sitemap.xml (417ms)
2025-07-07T10:24:52.965Z [nitro] ├─ /rss.xml (416ms)
2025-07-07T10:24:53.105Z [nitro] ├─ / (564ms)
[...]

Une fois le generate terminé, la machine de construction génère un artefact contenant notre site, et passe la main à la machine qui va servir le trafic :

2025-07-07T10:24:55.843Z ✔ You can now deploy .output/public to any static hosting!
2025-07-07T10:24:56.137Z Creating build cache archive…
2025-07-07T10:24:56.197Z build cache archive successfully created
2025-07-07T10:24:56.197Z No cron to setup
2025-07-07T10:24:56.213Z Uploading application build cache archive… file is 21M before compression.
2025-07-07T10:24:56.899Z 2025-07-07T10:24:56.899385Z INFO multipart_upload_lib::uploader: Uploaded part=1
2025-07-07T10:24:57.041Z 2025-07-07T10:24:57.041879Z INFO multipart_upload_lib::uploader: Completed the multipart upload
2025-07-07T10:24:57.350Z Done uploading build cache archive
2025-07-07T10:24:57.350Z Build succeeded in 1 minute and 14 seconds

11 secondes plus tard, le site de promotion de mon livre est déployé sur Clever Cloud

2025-07-07T10:25:28.425Z Serving static website from /cc_static_autobuilt
2025-07-07T10:25:28.425Z Launching 'static-web-server' on port 8080
2025-07-07T10:25:28.425Z No cron to setup
2025-07-07T10:25:28.425Z Successfully deployed in 0 minutes and 10 seconds

✓ Access your application: https://app-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.cleverapps.io
→ Manage your application: https://console.clever-cloud.com/goto/app_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Ajouter un domaine

Comme chez tous les PaaS, il est évidemment possible d’ajouter un domaine de manière à ce que les requêtes entrantes n’aient pas besoin de se faire sur l’URL en cleverapps.io

% clever domain add 50ndk.zwindler.fr
Your domain has been successfully saved

Une fois le FQDN associé, il est possible d’ajouter un CNAME chez votre gestionnaire de nom de domaine :

Automatiser le `clever deploy`

Imaginons que je sois un fainéant ou que je n’aie pas envie d’installer clever CLI sur tous les postes où je travaille. Admettons que j’aie envie qu’une nouvelle version de mon site soit automatiquement déployée dès que je pousse un commit sur GitHub.

deploy-to-clever-cloud

Dans l’article Planifier les posts de mon blog Hugo sur Clever Cloud, j’avais exploré la piste d’un Cron pour redéployer régulièrement mon site, notamment pour que les posts publiés dans le futur soient postés “au bon moment”.

J’avais aussi trouvé une GitHub Action tierce de quelqu’un (47ng) qui a l’air très bien mais que je ne connais pas :

https://github.com/marketplace/actions/deploy-to-clever-cloud

J’ai testé, elle fonctionne, mais j’étais moyen chaud à l’époque de déléguer mes creds à Github (les fameuses variables CLEVER_TOKEN et CLEVER_SECRET affichées lors du clever login), qui en retour les aurait injecté à cette “action”.

Et ben ça tombe bien parce qu’il y a deux nouvelles pour répondre à ces problématiques.

preview par PR

La première, c’est qu’il existe plusieurs façons d’automatiser les déploiements avec Clever Cloud. Je ne sais pas si elle existait à l’époque, mais en tout cas je l’ai trouvée aujourd’hui ;-P.

On peut faire des environnements de preview par PR (depuis 2024) :

Je ne vais pas dans cet article aborder cette action qui permet de déployer des apps en préview par PR car je n’en ai pas du tout le besoin pour ce site secondaire. Cela dit, si jamais j’ai une grosse mise à jour avec breaking changes, ça pourra valoir le coup de jeter un œil.

Créer des tokens de CI

La seconde, c’est qu’il est possible de créer des tokens (là encore, je ne sais plus si c’était possible en 2023), qu’il sera possible de révoquer en cas de leak.

https://www.clever-cloud.com/developers/api/howto/#request-the-api

Et avec ces tokens, on peut se faire sa propre CI :

https://www.clever-cloud.com/developers/doc/ci-cd/custom-scripts/

Note : j’ai cependant l’impression qu’il n’y a pas encore de scope sur le token. Donc en termes de sécu, c’est mieux car je peux les révoquer, mais s’il y a un leak, on a accès à tout mon compte, pour l’instant (sauf si j’ai mal compris).

Déploiements depuis GitHub (ou GitLab)

Mais le plus simple ici, c’est d’utiliser une fonctionnalité de Clever qui existe depuis “toujours” mais dont j’ignorais l’existance : les déploiements via Github.

Si vous voulez utiliser cette fonctionnalité, il faudra par contre autoriser Clever Cloud à lister vos dépôts préalablement (ce qui peut être un problème pour vous), et vous ne pourrez plus pousser des commits avec clever deploy ou git push sur le git remote de clever (vous prendrez une erreur 401).

Clever Cloud provides a GitHub integration to deploy any repository hosted on GitHub to Clever Cloud

On configure ça grâce au --github de tout à l’heure !

A partir du moment où c’est fait, il n’y a rien à faire… le rebuild sera déclenché dès que je pousserai un nouveau commit sur ma branche Github :)

commit 788465fb980c09e597872a3b510ac44fdaa27d48 (HEAD -> main, origin/main, origin/HEAD)
Author: Denis GERMAIN <denis@example.com>
Date: Fri Jul 4 16:31:11 2025 +0200
test commit

Note : on peut spécifier quelle branche on veut envoyer en prod dans les paramètres de l’application :

Conclusion

Clever Cloud a énormément bougé ces derniers mois, avec beaucoup de nouvelles apps, de nouvelles fonctionnalités (la plus grosse étant Materia, ainsi que tout le travail autour de l’IA).

Les static apps (et Linux, et V) pourraient presque paraître anecdotiques, mais couplées aux autres améliorations (tokens, Grafana managé avec les stats), ce n’est pas le même produit qu’en 2023.

C’est cool à voir :)

Planifier les posts de mon blog Hugo sur Clever Cloud

Mon, 29 Jan 2024 06:00:00 +0200

Suite de la migration

Fin décembre, j’ai migré ce blog sur Clever Cloud.

Cependant, David Legrand m’a fait remarquer que je n’avais plus de méthode pour planifier mes posts.

Depuis quelque temps, je poste à flux tendu donc ça ne m’a pas encore gêné (j’écris un post, je le rends public dans la foulée) mais c’est vrai qu’il me manque cette possibilité par rapport à précédent mon hébergement (une VM).

Cependant, il existe une solution sur Clever Cloud pour le faire. David en a d’ailleurs écrit un petit article sur son blog perso, adapté pour “Astro” son générateur de site statique.

Je vais donc faire pareil pour mon propre blog avec Hugo.

Adaptations

Repartons donc d’où j’en étais au post précédent. Nous avons un blog avec Hugo qui se déploie quand on fait des clever deploy (ou des commits sur le git remote de clever).

La première chose qu’on va devoir faire, c’est récupérer un token. En effet, c’est notre blog qui va déclencher de lui même les redéploiements, on va donc devoir lui donner de quoi s’authentifier.

Si vous n’avez pas de token sous la main, on peut en retrouver un en faisant clever login depuis un terminal, comme je l’expliquais dans l’article précédent.

Et on va rajouter le TOKEN dans la liste des variables d’environnement de notre app :

$ clever env set CC_SECRET "aaaaaaaaaaaaaaaaaaaaaaaaaa"
$ clever env set CC_TOKEN "aaaaaaaaaaaaaaaaaaaaaaaaaa"

A partir de là on va créer plusieurs fichiers. D’abord, un script qui va déclencher ce fameux redéploiement :

cat > clever_rebuild.sh << EOF
#!/bin/bash -l
clever link ${APP_ID}
clever restart --quiet --without-cache
EOF
chmod +x clever_rebuild.sh

Ensuite, je vais créer un fichier qui sera lu par clever-cloud et qui va déclencher ce redéploiement aux heures où je publie mes posts planifiés (le matin, un peu avant 9h) :

mkdir clevercloud
echo '["00 08 * * * $ROOT/clever_rebuild.sh"]' > clevercloud/cron.json

Attention aux petites blaguounettes de timezone. Comme tous sysadmins qui se respectent, les gens de clever utilisent le temps UTC sur leurs serveurs (moi aussi). Cependant, ça nécessite une petite gymnastique intellectuelle si jamais vous n’utilisez pas aussi le temps UTC dans votre tête pour planifier les posts ;-P.

Si tout se passe bien, vous verrez qu’il remarque qu’il y a un cron dans les logs :

[...]
2024-01-25T14:05:21+01:00 Importing cronjobs
2024-01-25T14:05:21+01:00 Starting crons setup
[...]
2024-01-25T14:06:05+01:00 (CRON) INFO (running with inotify support)
2024-01-25T14:06:05+01:00 (CRON) INFO (RANDOM_DELAY will be scaled with factor 89% if used.)
2024-01-25T14:06:05+01:00 (CRON) STARTUP (1.7.0)
[...]

Tout dernier point que j’ai éludé jusqu’à présent, il est possible de redémarrer une application à partir d’un cache (pour que ça aille plus vite). Cependant, il est nécessaire d’indiquer à clever cloud quoi mettre dans ce cache. On va donc ajouter “/clevercloud/cron.json:/clever_rebuild.sh” à la variable existante :

# précédemment CC_OVERRIDE_BUILDCACHE "/public"
$ clever env set CC_OVERRIDE_BUILDCACHE "/public:/clevercloud/cron.json:/clever_rebuild.sh"

(Fail to) hack the template

Si Hugo a bien un flag pour permettre de “builder” les posts dont la date de sortie est postérieure à la date actuelle (buildFuture), mon thème “Stack” les affiche par défaut dans la liste des derniers posts ainsi que dans le flux RSS.

La solution la plus simple à ce problème est de laisser les paramètres par défaut, et d’attendre que la date de publication soit dépassée (idéalement juste avant le passage d’un cron) et le tour est joué.

Mais David a eu une autre approche qui m’a bien plu : ajouter une condition dans le template pour que le post ne soit pas visible dans la liste des posts, mais quand même publié.

Avantage : on peut consulter l’article à paraître, si on a le lien. Il se rajoute à la liste des articles de la homepage de lui-même lors du prochain rebuild, une fois la date dépassée.

Dans mon thème, la page d’accueil qui liste les posts est définie ici dans le code :

 {{ define "main" }}
 {{ $pages := where .Site.RegularPages "Type" "in" .Site.Params.mainSections }}
 {{ $notHidden := where .Site.RegularPages "Params.hidden" "!=" true }}
+ {{ $notFuture := where .Site.RegularPages ".Date" "le" now }}
+ {{ $filtered := ($pages | intersect $notHidden | intersect $notFuture) }}
- {{ $filtered := ($pages | intersect $notHidden) }}
 {{ $pag := .Paginate ($filtered) }}

 <section class="article-list">
 {{ range $index, $element := $pag.Pages }}
 {{ partial "article-list/default" . }}
 {{ end }}
 </section>

 {{- partial "pagination.html" . -}}
 {{- partial "footer/footer" . -}}
 {{ end }}
[...]

En théorie, ça fonctionne. Sauf que je n’ai pas réussi à le faire marcher avec le thème “Stack” que j’utilise sur le site (j’ai réussi avec un thème “blank”).

C’est peut-être lié à un problème d’appel multiple à la fonction .Paginate(), qui “cache” la pagination la première fois qu’elle est lancée.

If you call .Paginator or .Paginate multiple times on the same page, you should ensure all the calls are identical. Once either .Paginator or .Paginate is called while generating a page, its result is cached, and any subsequent similar call will reuse the cached result. This means that any such calls which do not match the first one will not behave as written.

https://gohugo.io/templates/pagination/

Même en partant du principe que j’arrive à le faire marcher, reste encore la problématique du flux RSS, comme j’ai pu le remarquer avec Seboss666 ;-)

J’ai donc laissé tomber cette idée. De toute façon, je n’avais jamais vraiment eu besoin jusqu’à présent puisque je n’y avais pas pensé ;-P.

J’ai donc, comme avant, mes posts “planifiés” qui sont visible le matin de leur publication et c’est déjà bien comme ça (pour l’instant).

Have fun !

Migration du blog sur Clever Cloud

Sat, 30 Dec 2023 16:00:00 +0200

It’s groundhog migration day, again

Tous les 6 mois environ, une mouche me pique.

Après avoir migré un nombre incalculable de fois mon blog wordpress à droite / à gauche, puis migré sur Hugo, autohébergé, utilisé du managé chez vercel, chez froggit, autohébergé encore…

J’ai décidé (un peu sur un coup de tête) de migrer le blog chez les copain⋅es de chez Clever Cloud.

Et je vous montre comment j’ai fait.

Prérequis

Je pars du principe que vous avez comme moi un dépôt git / site hugo déjà fonctionnel. Et je ne vais pas non plus détailler la procédure pour activer un compte chez Clever Cloud.

Je commence par installer la CLI, les “clever tools”. Pour les installer, il nous faut npm. J’utilise rarement npm, mais quand je le fais, j’utilise un autre tool, volta (volta.sh), qui va me permettre de choisir la version dont j’ai besoin

$ curl https://get.volta.sh | bash

Une fois installé, je peux télécharger la version qui m’intéresse de npm (18 par exemple, la version minimum pour installer les clever tools)

$ volta install node@20
success: installed and set node@20.10.0 (with npm@10.2.3) as default

Je peux donc maintenant installer les clever tools :

npm i -g clever-tools

Puis me loguer depuis mon terminal

$ clever login
Opening https://console.clever-cloud.com/cli-oauth?cli_version=3.0.2&cli_token=xxxxxxxxxxxxxxxxx in your browser to log you in…
Login successful as [unspecified name] <xxx.yyy@example.org>

Si jamais comme indiqué sur l’écran de login, vous avez besoin d’un token + secret (pour de la CI par exemple), sachez qu’ils sont stockés dans un fichier ~/.config/clever-cloud/clever-tools.json

Denier prérequis, je vais ajouter une clé SSH dans ma console clever

Création de l’application

A partir de maintenant, je suis capable d’interagir avec clever cloud en CLI. Je vais commencer par créer l’application qui va héberger mon site statique :

$ clever create -t static-apache blog-zwindler
Your application has been successfully created!

Clever Cloud offre la possibilité de dissocier la taille des instances pour la partie run et la partie build. Je vais donc créer l’instance la plus petite possible pour le run (une nano), et une plus pêchue (une M) pour le build, histoire d’être plus réactif sur les commits de modifications :

$ clever scale --build-flavor M
App rescaled successfully
$ clever scale --flavor nano
App rescaled successfully

Je peux ensuite configurer quelques variables d’environnement (trouvées sur la doc de clever cloud) pour générer mon site statique avec l’image static-apache de clever.

$ clever env set CC_WEBROOT "/public"
$ clever env set CC_OVERRIDE_BUILDCACHE "/public"
$ clever env set CC_PRE_BUILD_HOOK "bash setup_hugo.sh"
$ clever env set CC_POST_BUILD_HOOK "hugo --minify --gc"

Pour finir, on crée le script setup_hugo.sh à la racine de notre site statique Hugo :

cat > setup_hugo.sh << EOF
HUGO_VERSION="0.121.1"
HUGO_URL="https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.tar.gz"
DEST_BIN="${HOME}/.local/bin"
FILENAME="hugo.tar.gz"

# Download Hugo Extended and place it in a folder in the $PATH
curl --create-dirs -s -L -o ${DEST_BIN}/${FILENAME} ${HUGO_URL}
cd ${DEST_BIN}
tar xvf ${FILENAME} -C ${DEST_BIN}
rm ${FILENAME}
EOF

On commit les fichiers créés :

git add .
git commit -m "Add clever"

Déployer notre code

A partir de là, on a notre instance qui est prête à démarrer, dès qu’elle aura reçu du code.

Ici, clever cloud attend un push sur un dépôt git.

La méthode la plus “simple” pour pousser du code sur clever à ce moment-là est donc de créer un dépôt distance (remote) :

git remote add clever git+ssh://git@push-n3-par-clevercloud-customers.services.clever-cloud.com/app_xxxxxxxxxxxxxxxxxxxx.git
git push clever master

Le “problème” dans mon cas est que (pour l’instant), le nom de la branche n’est pas configurable et est forcément “master”, ce qui ne m’arrange pas puisque je bosse habituellement sur “main”.

remote: Error: You tried to push to a custom branch. This is not allowed.
remote: error: hook declined to update refs/heads/main
To git+ssh://push-n3-par-clevercloud-customers.services.clever-cloud.com/app_xxxxxxxxxxxxxxxxxxxx.git
! [remote rejected] main -> main (hook declined)
error: impossible de pousser des références vers 'git+ssh://push-n3-par-clevercloud-customers.services.clever-cloud.com/app_xxxxxxxxxxxxxxxxxxxx.git'

2 manières de contourner ce problème :

soit je force la branche master sur le remote clever dans git
soit j’utilise la CLI clever deploy

Dans un premier temps, je me contente de feinter git :

git push clever main:master
Énumération des objets: 30, fait.
Décompte des objets: 100% (24/24), fait.
Compression par delta en utilisant jusqu'à 16 fils d'exécution
Compression des objets: 100% (16/16), fait.
Écriture des objets: 100% (16/16), 287.70 Kio | 31.97 Mio/s, fait.
Total 16 (delta 8), réutilisés 0 (delta 0), réutilisés du pack 0
remote: [SUCCESS] The application has successfully been queued for redeploy.
To git+ssh://push-n3-par-clevercloud-customers.services.clever-cloud.com/app_xxxxxxxxxxxxxxxxxxxx.git
54ff42f..960ce62 main -> master

On termine par la configuration du nom de domaine :

$ clever domain add blog.zwindler.fr
Your domain has been successfully saved

Il ne nous reste plus qu’à mettre à jour le CNAME dans notre DNS (domain.par.clever-cloud.com. dans mon cas, mais la bonne configuration est visible dans l’onglet Domain names de l’application)

Et avec `clever deploy` ?

Eh bien en fait, c’est “encore plus simple”. Il me suffit juste de faire une modif, de commit

git add .
git commit -m "test clever deploy"

Puis de simplement lancer la commande clever deploy.

$ clever deploy
Remote git head commit is c4e3c283585cafff44f07c7d78d860065318cd68
Current deployed commit is c4e3c283585cafff44f07c7d78d860065318cd68
New local commit to push is 0b3536a9f1d61178a99f6238831ccb4197989ddf (from refs/heads/main)
Pushing source code to Clever Cloud…
Your source code has been pushed to Clever Cloud.
Waiting for deployment to start…
Deployment started (deployment_b5f841ff-a233-4bb4-8a16-f618ee69ef28)
Waiting for application logs…
[...]

Quelle est donc cette diablerie ?

En réalité, les informations nécessaires pour pousser le code sont en réalité simplement dans un fichier .clever.json qui a été créé à la racine lorsqu’on a lancé la commande clever create -t static-apache blog-zwindler au tout début du tuto.

{
 "apps": [
 {
 "app_id": "app_xxxxxxxxxxxxxxxxxxx",
 "org_id": "user_yyyyyyyyyyyyyyyyyyyyy",
 "deploy_url": "https://push-n3-par-clevercloud-customers.services.clever-cloud.com/xxxxxxxxxxxxxxxxxxxx.git",
 "name": "blog-zwindler",
 "alias": "blog-zwindler"
 }
 ]
}

Évidemment, je ne vais pas m’amuser à faire un clever login / clever deploy à chaque fois que je veux pousser une modif sur mon blog. Et c’est là où nos CLEVER_TOKEN / CLEVER_SECRET seront utiles !

Conclusion

Après quelques heures d’usage, je peux dire que dans le cadre de l’hébergement de mon blog, j’aime bien utiliser Clever Cloud.

Qu’on soit bien clair, c’est pour mon cas d’usage et comparé à :

Vercel : l’expérience utilisateur est incroyable sur Vercel, mais j’ai toujours été un peu gêné par le côté “boite noire” (on a pas accès à beaucoup plus que des variables d’environnement). Et je ne parle pas des problématiques de privacy…
Deux serveurs physiques avec Proxmox VE en cluster étendu chez One-provider : à l’inverse héberger moi-même mon blog sur une machine (en vrai, 2) louée résout les problèmes de privacy et j’ai la main sur toute la stack, mais ça me demande de la maintenance pour des perfs minables. Ok, c’est pas cher, mais j’ai 2 à 3 minutes de rebuild avec le CPU à 100% sur mon Atom de 2010 chez Online…
Froggit : c’était du Gitlab + Gitlab pages et c’était très cool car c’est plus flexible que Vercel, mais j’avais dû passer un peu de temps à configurer la pipeline et leur faire pousser les murs pour que mon site rentre (les 400 Mo de médias n’étaient pas supportés au début et les transferts Gitlab => Gitlab pages étaient un peu longs).

Avec Clever, mes 450 articles (3600 pages générées, 400 Mo de média) sont très rapidement générés, transférés, et enfin mis à disposition (< 1 minute tout compris, plus rapide que les 3 solutions précédentes).

Le tout avec une disponibilité/fiabilité sans aucun doute bien meilleure que ce que j’aurais pu faire moi-même en auto hébergé avec un coût similaire, et en très peu de temps.

J’ai passé beaucoup plus de temps à écrire cet article qu’à migrer le blog, puisque la doc est bien écrite, le site est intuitif, et je n’ai été bloqué à aucun moment.

Il me reste encore à optimiser l’étape de déploiement, pour qu’un commit/push sur mon dépôt git déclenche automatiquement un déploiement côté clever. Objectivement, ça ne devrait pas prendre trop longtemps (github action / gitlab CI)…

Et par contre, ça manque d’IPv6 natif, screugneugneu !

Et si on testait le Clever Operator pour Kubernetes ?

Tue, 17 May 2022 10:00:00 +0000

Clever Operator

Il y a quelques mois, je suis tombé sur cet article de Clever Cloud qui disait avoir annonçait la sortie de l’Operator pour Kubernetes.

Nous avons commencé à travailler sur le Clever Operator suite aux retours de certains de nos clients utilisant k8s ou Openshift qui n’étaient pas vraiment satisfaits des solutions de gestion de base de données fournies par ces plateformes.

C’est pas un secret, j’ai beaucoup râlé sur les gens qui disent que Kubernetes c’est compliqué et/ou que ça apporte plus de problèmes que ça n’en résout (cf https://blog.zwindler.fr/2019/09/03/concerning-kubernetes-combien-de-problemes-ces-stacks-ont-generes/). On en a notamment parle avec Quentin ADAM ;-).

Mais ce que je ne disais pas clairement à cette époque, c’est que Kubernetes, c’est quand même plus simple quand il s’agit d’autonomiser les devs sur des workloads stateless.

Ou alors du stateful, mais pas trop violent : genre stockage de fichiers (Prometheus par exemple), voire fichiers partagés (avec un FS distribué, partagé entre plusieurs apps ou instances d’une même app).

Par contre, les bases de données, là, on rigole tout de suite beaucoup moins…

Attention, je ne dis pas que c’est impossible. Plein de gens le font, en prod (moi compris). Mais c’est tout de suite un autre niveau de complexité, car il faut gérer le cycle de vie de la base de données, les mises à jours, les pertes de noeuds proprement, etc.

Pour faciliter ça, il existe les “Opérateurs” dans Kubernetes, qui ont pour but d’ajouter toute une logique fonctionnelle pour gérer ça (comme celui pour MongoDB dont je parle dans cet article), mais c’est pas encore parfait.

Ajoutez à cela le fait que DBA, c’est un job “à part”, avec des compétences bien spécifiques et qui nécessite vraiment de savoir ce qu’on fait.

Du coup… j’aurais pu dire (en moins classe) :

Les DBs dans Kube, c’est ch**nt. Ca serait cool si quelqu’un dont c’est l’expertise pouvait gérer ça pour moi, en dehors de Kube.

Qui a dit “Clever Cloud” ?

Clever Operator

Ok, admettons qu’on ait un Kubernetes fonctionnel. On va plugger Clever Cloud dessus pour voir ce qu’on peut faire. Le billet sur le blog de Clever indique 2 manières de déployer l’operator (plot twist, il y en a une 3ème qui est mieux).

La première consiste à utiliser operatorhub.io, un site communautaire pour partager des opérateurs Kubernetes.

Pour utiliser cette méthode, il faut déployer le operator-lifecycle-manager, lui-même un opérateur, dans notre kubernetes. J’ai essayé et j’ai plein de critiques à faire sur ce tool.

Déjà, la doc nous demande de faire un curl | bash (déjà une hérésie en soit), ensuite, il se déploie sans prévenir sur mon contexte Kubernetes par défaut. Enfin, c’est pas bien clair ce qu’il faut faire pour le customiser (notamment pour ajouter nos credentials).

J’ai essayé 1h, j’ai laissé tomber, mais si vous avez l’habitude d’utiliser Operatorhub.io vous aurez peut être des infos que je n’ai pas.

La seconde méthode proposée est de déployer (ou de builder) soit même le container Docker dans notre cluster Kubernetes.

Vous pouvez le built à partir du code source sur Github ou utiliser notre image docker sur Docker Hub. Puis, configurez le. Ça se résume à paramétrer les variables d’environnement CLEVER_OPERATOR_*. Par exemple, vous devez créer un token pour vous connecter à l’API.

Je suis un poil sceptique sur le “ça se résume à” 😏.

Quand on va voir le code du clever operator (ici), on se rend tout de suite compte qu’il va falloir déployer beaucoup de ressources Kube et pas juste un container (~650 lignes de YAML).

En même temps c’est logique, il y a le fichier du Deployment, des Roles, plusieurs définitions de CRDs, bref…

DIY

Edit du 24/05 : depuis la rédaction de l’article, j’ai proposé une PR à Florentin (le dev de la feature chez Clever) pour ajouter une Helm Chart. Le principe est le même, on va devoir renseigner des valeurs dans values.yaml donc vous pouvez quand même dérouler l’article.

cd deployments/kubernetes/helm
helm install clever-operator -n clever-operator --create-namespace -f values.yaml .

Du coup, j’ai déjà spoilé la solution (qui est d’ailleurs mise en avant dans le README.md du dépot Github.com). On va déployer le YAML à la main.

On installe les CRDs :

kubectl apply -f https://raw.githubusercontent.com/CleverCloud/clever-operator/main/deployments/kubernetes/v1.21.0/10-custom-resource-definition.yaml
customresourcedefinition.apiextensions.k8s.io/postgresqls.api.clever-cloud.com configured
customresourcedefinition.apiextensions.k8s.io/redis.api.clever-cloud.com configured
customresourcedefinition.apiextensions.k8s.io/mysqls.api.clever-cloud.com configured
customresourcedefinition.apiextensions.k8s.io/mongodbs.api.clever-cloud.com configured
customresourcedefinition.apiextensions.k8s.io/pulsars.api.clever-cloud.com configured
customresourcedefinition.apiextensions.k8s.io/configproviders.api.clever-cloud.com configured
customresourcedefinition.apiextensions.k8s.io/elasticsearches.api.clever-cloud.com configured

kubectl api-resources --api-group=api.clever-cloud.com
 NAME SHORTNAMES APIVERSION NAMESPACED KIND
 mongodbs mo api.clever-cloud.com/v1 true MongoDb
 mysqls my api.clever-cloud.com/v1 true MySql
 postgresqls pg api.clever-cloud.com/v1 true PostgreSql
 pulsars pulse,pul api.clever-cloud.com/v1beta1 true Pulsar
 redis r api.clever-cloud.com/v1 true Redis

Si je peux me permettre ce commentaire, je trouve ça audacieux, ces shortnames 😱… Attention aux collisions avec d’autres CRDs 🤔.

Et ensuite on récupère et on va modifier le fichier du Deployment

curl -LO https://raw.githubusercontent.com/CleverCloud/clever-operator/main/deployments/kubernetes/v1.21.0/20-deployment.yaml

Préparer la configuration

Bon, à un moment donné, il va bien falloir que je connecte l’API clever cloud avec mon operator, notamment en renseignant les fameuses variables d’environnement CLEVER_OPERATOR_* dont parle l’article.

Si on regarde la tête de notre fichier 20-deployment.yaml, on remarque qu’il existe une ressource ConfigMap prévue pour renseigner les credentials (ligne 100).

---
apiVersion: v1
kind: ConfigMap
metadata:
namespace: clever-operator-system
name: clever-operator-configuration
data:
config.toml: |
[api]
token = ""
secret = ""
consumerKey = ""
consumerSecret = ""

Si vous êtes curieux (c’est mon cas), ce volume est ensuite appelé dans le Deployment

 volumes:
- name: config
configMap:
name: clever-operator-configuration
items:
- key: "config.toml"
path: "config.toml"

Puis monté dans la spec du template de container

 volumeMounts:
- name: config
mountPath: "/etc/clever-operator"
readOnly: true

Note : Idéalement, on voudra éviter de faire ça, dans la vraie vie. Les ConfigMaps (comme les Secrets) dans Kubernetes sont lisibles par beaucoup de monde (la seule différence pour les Secrets, c’est que les chaines de caractères sont base64ifiée. Si si, c’est dans le dico, “base64ifier”) et donc absolument pas adaptés pour la gestion de secrets. On pourrait aussi ajouter ces secrets comme variables d’environnement dans le Deployment (comme proposé dans la méthode 2 par l’article), mais c’est pire (on peut en débattre) encore niveau sécu. Idéalement, il faudra injecter ces valeurs avec un gestionnaire de secret tier, comme Vault par exemple.

Mais où on les trouve, ces valeurs à renseigner ?

Alors je n’avais jamais utilisé Clever Cloud avant, donc ça n’était pas super évident pour moi 😅.

On va d’abord devoir créer une organisation et récupérer son ID (en haut à droite de l’interface). Elle a la forme orga_xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx

Pour la partie consumerKey et consumerSecret, j’ai trouvé avec la documentation officielle. Dans mon organisation côté UI de Clever Cloud, on peut cliquer sur “Create… / an oauth consumer”

Pour la partie token et secret, je n’ai pas trouvé comment en créer un en console web et je n’ai pas trouvé dans la doc.

En bidouillant un peu (monkey testing), j’ai trouvé qu’on pouvait en récupérer en utilisant la CLI de clever cloud

curl -fsSL https://clever-tools.clever-cloud.com/gpg/cc-nexus-deb.public.gpg.key | gpg --dearmor -o /usr/share/keyrings/cc-nexus-deb.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/cc-nexus-deb.gpg] https://nexus.clever-cloud.com/repository/deb stable main" | tee -a /etc/apt/sources.list
sudo apt-get update
sudo apt-get install clever-tools

clever login
Opening https://console.clever-cloud.com/cli-oauth?cli_version=2.9.1&cli_token=... in your browser to log you in…
We're still waiting for the login process (in your browser) to be completed…
Login successful as Denis GERMAIN <...>

Une fenêtre de navigateur s’ouvre pour se loguer et magie magie, on a un token et un secret

CLEVER_TOKEN=aaa
CLEVER_SECRET=aaa

Tadaa !

Deployer l’opérateur

Tout est prêt, allons-y.

On peut apply le manifest et déployer le deployment

kubectl apply -f 20-deployment.yaml
namespace/clever-operator-system created
serviceaccount/clever-operator created
clusterrole.rbac.authorization.k8s.io/system:clever-operator created
clusterrolebinding.rbac.authorization.k8s.io/system:clever-operator created
poddisruptionbudget.policy/clever-operator created
networkpolicy.networking.k8s.io/clever-operator created
configmap/clever-operator-configuration created
deployment.apps/clever-operator created

Note: la dernière version de l’image Docker du Clever Operator a “un bug” du à une version trop ancienne de la GLIBC. Florentin de chez Clever est en discussion avec Redhat pour fix ça (`GLIBC_2.29’ not found).

~~Il “suffit” de prendre une version plus ancienne de l’image et ça remarche, en attendant un fix définitif.~~ (FIXED)

On teste tout ça

Normalement, là on est bons.

Dans la liste des bases (des add-ons dans la terminology Clever Cloud) supportées par ce operator, il y a donc :

ElasticSearch
MongoDb
MySql
PostgreSql
Pulsar
Redis

La documentation des CRDs est disponible ici et elle est bien faite.

Je ferai des tests plus poussés (déployer une vraie application) plus tard, mais déjà pour tester, j’ai pu lancer un mysql managée;

cat mysql.yml
---
apiVersion: api.clever-cloud.com/v1
kind: MySql
metadata:
namespace: default
name: mysql
spec:
organisation: orga_xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx
options:
version: 80
encryption: false
instance:
region: par
plan: dev
kubectl apply -f mysql.yml
mysql.api.clever-cloud.com/mysql created
kubectl get my
NAME AGE
mysql 14s

L’opérateur a également la gentillesse de nous créer un Secret avec les variables de connexion. C’est donc hyper simple de relier notre app à notre nouvelle DB :

kubectl get secret mysql-secrets -o yaml
apiVersion: v1
data:
 MYSQL_ADDON_DB: aaa=
 MYSQL_ADDON_HOST: aaa==
 MYSQL_ADDON_PASSWORD: aaa=
 MYSQL_ADDON_PORT: aaa==
 MYSQL_ADDON_URI: aaa==
 MYSQL_ADDON_USER: aaa==
 MYSQL_ADDON_VERSION: aaa
kind: Secret

kubectl run -it mysqlclient --image mysql /bin/bash
root@mysqlclient:/# mysql aaa --host aaa-mysql.services.clever-cloud.com --user aaa -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
[...]
mysql>

Conclusion

J’ai été très content de tester cet operator, et surtout de pouvoir échanger avec son développeur, Florentin DUBOIS, qui m’a aidé et à qui j’ai pu remonter quelques petits défauts de jeunesse de l’outil.

L’intégration entre Clever et Kubernetes marche vraiment bien, c’est fluide. La documentation des CRDs est bien faite, on est pas perdus. Enfin, la génération à la volée du Secret contenant les informations de connexion directement dans Kubernetes est vraiment une fonctionnalité bien pratique, puisqu’on voudra souvent monter directement les informations qu’il contient dans un Pod du même namespace.

~~De mon point de vue, il manque une Chart Helm, pour rentre le déploiement simple et flexible de l’opérateur, et sans trop spoiler ça devrait arriver bientôt ;-).~~ (FIXED)

A moi le pouvoir tout puissant des bases de données que je n’ai pas à gérer !

Clever Cloud on Zwindler's Reflection

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

Rappel de la partie 1

Activer le CSI et monter son premier volume

vCluster : un cas d’usage concret du stockage persistant

Volume expansion : agrandir un volume à chaud

VolumeSnapshots : le plus technique

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

Étape 2 : le piège des GroupSnapshot CRDs

Étape 3 : le secret Ceph dans le VolumeSnapshotClass

Étape 4 : le snapshot fonctionne

Étape 5 : restaurer un volume depuis un snapshot

Bilan global

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

La suite de ma saga avec Clever Cloud

CKE c’est quoi exactement ?

Activation : c’est un peu caché

Création d’un cluster

Les 3 topologies : Essential, Business, Enterprise

Un mot sur la tarification

Récupérer le kubeconfig

Anatomie du cluster

Les NodeGroups

Combien de temps pour booter ?

Réseau, services, sécurité

Stockage (CSI)

Un vrai déploiement : GroROTI

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

Conclusion (partie 1)

Créer un cluster Kubernetes sur Clever Cloud avec les apps Linux

Introduction

Le projet : k8s-on-clever-linux

Découverte de Mise.

Découpage de l’application

Focus sur Mise pour installer les dépendances

Mais… ils sont où les binaires du control plane de Kubernetes ?

Installation et configuration

Déploiement et test

Ajout d’un worker node

Limitations et évolutions possibles

Conclusion

Je réessaye les sites statiques (Bloggrify) chez Clever Cloud

Introduction

Prérequis

Configuration de l’app

Déploiement de l’application

Ajouter un domaine

Automatiser le clever deploy

deploy-to-clever-cloud

preview par PR

Créer des tokens de CI

Déploiements depuis GitHub (ou GitLab)

Conclusion

Planifier les posts de mon blog Hugo sur Clever Cloud

Suite de la migration

Adaptations

(Fail to) hack the template

Migration du blog sur Clever Cloud

It’s groundhog migration day, again

Prérequis

Création de l’application

Déployer notre code

Et avec clever deploy ?

Conclusion

Et si on testait le Clever Operator pour Kubernetes ?

Clever Operator

Clever Operator

DIY

Préparer la configuration

Mais où on les trouve, ces valeurs à renseigner ?

Deployer l’opérateur

On teste tout ça

Conclusion

Automatiser le `clever deploy`

Et avec `clever deploy` ?