Etcd en k8s ça tient la route pour du gros cluster

etcd c'est le standard pour k8s faut tuner les disques ssd rapide io_uring ptete nvme et le réseau dedicated pas de shared infra

nan etcd c'est pas fait pour ça a ces échelles c'est un single point of failure a la base faut revoir l'architecture générale pas juste etcd

500 nodes wtf c'est un peu overkill pour bcp de workloads. et etcd bien configuré avec 5 members en quorum et des snapshots réguliers ça tient

vous avez monitoré les metrics de etcd ? leader changes ? network partitions ? disk io latency ? souvent c'est la config de base qui est nulle

faut voir les compaction aussi et le history retention si c'est trop long ça explose la db size et les writes

un cluster de cette taille j'aurais regardé tidb ou autre truc distribué mais bon c'est pas drop-in pour k8s

tidb pour la control plane vous êtes fous ça va exploser le budget et la complexité c'est pas le même use-case

le truc c'est de bien dimensionner les cpu et ram des etcd nodes. et éviter de faire des millions de configmap ou secret updates inutiles

et la latency entre les etcd members c'est critique si t'es sur du cross-az c'est mort

ouais mais la data consistency avec raft c'est lourd. pour de l'observability ou des logs tu peux te permettre moins de strictness

on parle de la control plane là c'est pas des logs si etcd meurt ton cluster est mort

avez-vous testé avec une version plus récente de etcd ? les perfs s'améliorent souvent. et le client-side cache de l'api server peut aider

et le disk fsync si tu es sur du nfs ou san c'est mort de base

le tuning c'est bien mais quand l'architecture de base est poussée a ses limites faut pas s'étonner

c'est pas pousser l'architecture c'est juste mal scale des composants critiques. etcd peut tenir des millions de writes si tuned

regardez les wal files et la retention et l'snapshotting faut pas que ça se batte avec les writes

y'a pas de solution miracle juste du hardening de config et de l'infra sous jacente

perso je reste sur l'idée que si t'es a cette échelle faut se poser la question d'un multi-cluster ou federated k8s

multi-cluster c'est encore plus de gestion et de complexité pour pas grand chose si le problème est juste etcd

kubernetes a des limits aussi faut pas l'oublier