etcd c'est le goulot d'étranglement de Kubernetes non faut pas se mentir

Sérieusement etcd c'est le Raft sous K8s c'est le seul truc qui garantit que ton cluster est consistent. T'as 3 masters tu répliques le state pour la tolérance de pannes. Sans ça K8s est un tas de machines qui parlent dans le vide.

Vouloir une alternative c'est pas comprendre pourquoi etcd est là.

Comprendre pourquoi c'est une chose l'opérer c'en est une autre. etcd demande des ressources I/O monstrueuses et une latence réseau quasi nulle entre les nœuds. Pour un cluster K8s de 500 nœuds et 100 000 pods t'es mort sans NVMe et 100Gbit.

Et même là la compaction régulière c'est un calvaire ça te met le cluster en PLS.

Le problème c'est pas etcd en soi c'est les devs d'opérateurs qui ne pigent rien à la persistance distribuée. Ils créent des CRD géantes avec des centaines de champs ils les update toutes les secondes.

Chaque write c'est un append dans le WAL de Raft c'est répliqué sur le quorum. C'est le design qui est merdique pas etcd.

Mais etcd est fait pour ça. Il a des optimisations pour les accès pattern de l'API server. Si tu commences à mettre du PostgreSQL ou du Consul pour ton control plane tu perds la sémantique de K8s.

Les watchers K8s s'appuient sur etcd pour la notification des changements. Comment tu gères ça avec une base SQL sans polling intensif et coûteux ?

Personne a dit de remplacer etcd pour le control plane pur. Mais pour les états d'opérateurs les queues de tâches la config non critique on peut externaliser ça.

On a des opérateurs qui foutent des logs de 100Ko dans des CRD c'est ça le problème. Pour du simple KV on peut utiliser Redis pour du transient ou une vraie base de données pour du plus gros.

C'est facile de blâmer les opérateurs. K8s lui-même a ses propres problèmes de scaling d'objets. Un grand nombre de ConfigMap ou de Secrets ça pèse aussi sur etcd.

Et la gestion des secrets c'est un bordel tu veux pas les logger dans etcd en clair. Faut du Vault avec l'external-secrets-operator.

Vault c'est une autre couche. Etcd gère les secrets mais K8s chiffre les données at rest. On fait pas ça n'importe comment. L'intégration de etcd est profonde.

Si on commence à découpler le stockage de l'état du control plane on rentre dans une complexité pas possible pour maintenir la cohérence transactionnelle.

La complexité opérationnelle d'etcd elle est déjà pas possible. Faut monitorer le disque le réseau le nombre de requêtes le nombre de wal files. C'est un SRE nightmare.

Avec des outils comme Prometheus et Thanos on arrive à collecter les métriques mais ça n'enlève pas la difficulté de debugging un quorum perdu à 3h du mat.

La vraie difficulté c'est le tuning du kernel et de la couche I/O. Faut que ton système de fichiers supporte les fsync à gogo. L'intégration de io_uring dans Linux pourrait aider mais etcd est une bête à part.

Un Raft sur trois nœuds c'est sensible. La latence du réseau la saturation d'un CPU n'importe quoi peut casser le quorum et là c'est la panique.

Mais c'est le prix de la strong consistency. Si tu veux une plateforme fiable tu dois payer ce prix. L'éventual consistency ça pète des trucs en prod à coup sûr pour le control plane.

Les microservices peuvent se permettre de l'eventual consistency mais pas K8s lui-même.

Et le FinOps dans tout ça ? Des nœuds masters avec des NVMe surdimensionnés ça coûte un bras. Si 80% des writes c'est des opérateurs qui spamment etcd avec des infos inutiles on paye cher pour de la merde.

Une stratégie de déchargement de l'état non critique pourrait faire économiser des millions sur des grosses infra.

C'est une discussion de conception d'application en fait. Les opérateurs doivent être conçus pour être "etcd-friendly". Stocker uniquement ce qui est nécessaire pour le control loop et pas plus.

Utiliser des ConfigMap pour de la config statique et pas des CRD géantes.

C'est de la bonne pratique mais ça ne change pas que etcd est fondamental pour K8s. La solution c'est de mieux gérer etcd pas de le remplacer par un truc qui ne fait pas le job.

Bien monitorer avec eBPF pour voir les latences exactes sur les syscalls et comprendre pourquoi ça rame.

eBPF c'est un super outil pour l'observabilité du kernel et de l'I/O mais ça va pas réécrire le code de etcd ni des opérateurs. Si ton disque est saturé eBPF va te dire qu'il est saturé c'est tout.

On doit repenser ce qu'on met dans etcd.

Absolument. Il y a des cas d'usage où des bases de données de graphe ou même des systèmes de messaging distribué seraient plus adaptés pour la coordination complexe entre microservices que d'abuser de etcd.

etcd c'est pour l'état K8s pas pour le stateful de tes applications custom.

Totalement d'accord sur le fait de pas mettre n'importe quoi dans etcd. Mais ça reste le garant de K8s. On peut pas juste le jeter.

Il faut juste qu'on arrête de le traiter comme une base de données générique.

Ok je vois le point sur la nécessité d'etcd pour le cœur de K8s et sa strong consistency. On ne peut pas juste le remplacer.

Mais les arguments sur le FinOps les coûts opérationnels les I/O et les abus par les opérateurs ça me parle. Je vais pousser pour qu'on impose des guidelines strictes aux devs d'opérateurs pour éviter de polluer etcd avec de l'état non critique.

On pourrait même envisager d'externaliser certains types d'état vers des bases plus adaptées. Merci pour ce débat.