etcd dérive de latence sur gros cluster K8s genre WTF

hello pour etcd sur gros cluster c'est souvent la mort. 500 nodes c'est déjà pas mal. t'as quelle version d'etcd et de k8s déjà ? et c'est quel backend storage pour etcd là ?

k8s 1.25 et etcd 3.5.7. le backend c'est du gp3 aws provisioned iops à 16k iops et 250 mbps de throughput. on pensait que c'était large

gp3 c'est bien mais le p99 latency peut être trompeur. regarde plutôt les iops max que t'atteins et la queue depth. souvent c'est le disque même avec du nvme. et la taille de ta base etcd ? elle grossit vite ?

ouais la base est à genre 100gb. elle prend 10gb par semaine facile. on fait des snapshots réguliers mais la compaction prend aussi du temps

100gb c'est énorme. c'est là le souci. etcd c'est pas fait pour stocker des téraoctets. quelle est ta rétention ? et vous utilisez des custom resources qui ont des objets super lourds ?

on a 24h de rétention par défaut. pour les custom resources on a pas mal d'operators qui gèrent des objets avec des crd assez verbeuses. genre des istio virtualservices et gateways en masse

ok donc double peine. gros volume + forte churn sur des objets lourds. première chose à faire c'est revoir vos crd et leurs tailles. est-ce que tout doit être dans etcd ? genre une ressource avec 1000 lignes de yaml c'est pas fait pour etcd

on peut pas trop réduire les CRD là c'est des produits tiers. mais pour la rétention on pourrait la réduire à 12h ptete ? ça soulagerait un peu non ?

ouais ça aiderait un peu mais c'est pas la solution miracle. la fragmentation et le churn sont les vrais problèmes. tu as déjà check les métriques etcd_disk_wal_fsync_duration_seconds_bucket et etcd_mvcc_db_total_size_in_bytes ?

j'ai les métriques wal fsync oui et le p99 est un peu haut parfois 50ms mais c'est pas constant. la taille de la db on la monitore et c'est bien à 100gb

il faut aussi regarder la compaction si elle arrive à suivre. si etcd n'arrive pas à compacter assez vite les versions d'objets s'accumulent et la db grossit. la metric etcd_mvcc_delete_total et etcd_mvcc_put_total peuvent te donner une idée de la dynamique

on a beaucoup de puts et de deletes ouais. c'est la vie d'un gros cluster avec beaucoup de déploiements et de services qui changent. c'est notre CI/CD qui tourne à fond

si t'as plein de changements, la solution c'est pas d'avoir un etcd géant. c'est soit de segmenter le cluster k8s si possible ou alors revoir comment tes operators gèrent leurs states. est-ce qu'ils stockent pas des infos temporaires dans etcd qui pourraient aller ailleurs ?

hum c'est une piste. je vais voir avec les équipes infra s'ils peuvent auditer les operators les plus gourmands. et la rétention à 12h ça peut aider en attendant. thx pour les pistes c'est plus clair

bon on a réduit la rétention et audité un operator qui balançait trop de CRD inutiles. la base a déjà un peu dégonflé c'est pas encore parfait mais on est repassé sous les 100ms p99. on va continuer l'audit. merci pour les conseils !