etcd lent sur k8s avec bcp de CRD writes
Commentaires
hmm bcp de CRD d'un coup ça peut secouer etcd. vous avez quelle version d'etcd et k8s ? et le disk iops c'est quoi comme type ? gp2 gp3 ou local nvme ?
k8s 1.25 etcd 3.5.x. c du gp3 en 3000 iops. la latence disk est < 1ms d'habitude
les watch requests sur etcd vous avez des clients qui watch des milliers d'objets ? ça peut mettre une pression énorme sur le leader etcd
on a des operators qui watch pas mal de CRD mais pas 5000 simultanément. genre 50-100 max par operator. mais quand le déplo commence le api-server répond plus trop
le compaction de etcd est bien configuré ? genre "quota-backend-bytes" et "auto-compaction-mode/retain" ? si y'a trop de révisions qui s'accumulent ça ralentit
oui default values pour le compaction. "auto-compaction-retention" c'est 1h je crois. on génère des milliers de révisions d'un coup c'est vrai
et le journaling disk ? t'es sûr que le wal file est sur un volume séparé avec de bonnes perf ? et la latence réseau inter-etcd ? des fois c'est juste la comm entre members
wal est sur le même volume pour l'instant ptete ça le souci. latence inter-etcd c < 5ms. j'ai vu des alertes "etcd_server_leader_changes_total" un peu élevées pendant les phases de perf dégradée
haaa leader changes c'est pas bon du tout ça. ça indique une instabilité du quorum. vérifie bien "etcd_server_proposals_failed_total" et "etcd_server_apply_snapshot_total"
la validation des CRD par l'api-server aussi ça coûte cher. si tes schémas sont complexes et que tu crées 5000 objets d'un coup ça peut faire suer le api-server. as-tu des validating admission webhooks qui sont lents ?
non pas de validating webhooks pour ces crd. j'ai essayé de mettre le wal sur un volume séparé avec 6000 iops et ça a l'air un peu mieux mais tjrs pas parfait. les "proposals_failed" sont ok par contre.
ptete un souci avec le "max-wals-snapshots" ou "snapshot-count" si etcd fait trop de snapshots. si tu as bcp de données etcd ça peut être coûteux
essayez de monter le "commit-timeout" et "election-timeout" pour voir si ça stabilise les leaders. des fois le réseau est un peu "flaky" et les timeouts par défaut sont trop courts
ok je vais essayer de tuner "snapshot-count" et mettre "commit-timeout" un peu plus haut. pour le moment j'ai splité le wal et ça réduit un peu les spikes de latence. je reviens dès que j'ai des chiffres.
bonne chance c'est relou etcd quand ça fait des siennes
les gars j'ai monté le "commit-timeout" de 100ms à 200ms et "election-timeout" à 2000ms. j'ai aussi mis "snapshot-count" à 50000. ça a bien stabilisé le leader et les latences ont baissé drastiquement. on est autour de 50ms maintenant c'est jouable. merci beaucoup pour l'aide précieuse !
Laisser une réponse
Vous devez être connecté pour poster un message !
Rejoindre la communauté
Recevoir les derniers articles gratuitement en créant un compte !
S'inscrire
apetit
Membre depuis le 13/03/2019actif
salut la gang on a un souci de perf monstrueux sur un cluster k8s. dès qu'on déploie une flopée de CRD custom (genre 5000 objets d'un coup) le kube-api-server commence à ramer comme pas possible et etcd prend 500ms+ sur les writes. l'infra est ok genre cpu/mem/disk sont pas saturés. j'ai checké les logs etcd y a rien d'évident. des idées sur ce qui pourrait causer ça ?