Houston, on a un problème avec ETCD

Derrière chaque cluster Kubernetes se cache le même composant critique : ETCD. Tout y passe : la configuration, l’état des pods, les secrets, et la moindre seconde d’indisponibilité fait vaciller le control-plane. Pourtant, quand on opère du Kubernetes managé à grande échelle, ce data-store peut rapidement devenir un goulot d’étranglement.

Après des années à opérer ETCD chez différents cloud providers, nous nous sommes rendus à l’évidence : on ne peut pas se contenter d’empiler des clusters standalones. Plutôt que de continuer à contourner ses limites, nous avons choisi chez Clever Cloud de le réécrire. Plus précisément, construire une couche stateless compatible avec son protocole, en s’appuyant sur FoundationDB pour le stockage, le Key-Value distribué transactionnel utilisé par Apple pour iCloud et OpenAI.

Lors de ce deep-dive, nous partagerons notre retour d’expérience : pourquoi ETCD nous a poussés à le réécrire, ce qu’on découvre quand on plonge dans ses internals (watchers, révisions, ce qui se passe à chaque kubectl apply), et comment cette réécriture en couche stateless au-dessus de FoundationDB change la donne pour servir du Kubernetes à grande échelle.