16 commentaires
ouais classique les leader elections ça pue. t'as des métriques sur etcd_server_proposals_failed_total ou etcd_server_leader_changes_total et le etcd_mvcc_db_total_size_in_bytes il grossit de ouf
les proposals_failed sont à quelques milliers par jour et les leader_changes genre 5-10 par heure. le db_total_size est à 20GB alors que ça devrait être moins de 10GB. ça semble s'accumuler même avec la compaction par défaut
20GB c'est déjà gros t'as une idée de ce qui prend de la place genre bcp de CRDs ou des objects persistents pour tes PVCs qui sont pas nettoyés correctement
on a pas mal de crds pour le csi driver mais c'est surtout les pv et pvc objets qui churnent. chaque job crée un nouveau pvc temporaire
ok si c'est les objets PV/PVC en churn regarde ta politique de reclaimPolicy sur tes StorageClass c'est ptete Retain au lieu de Delete ce qui laisse des PVs orphelins et ça fait gonfler etcd
non on est bien en delete pour nos classes de stockage. les pv sont bien delete après les jobs mais l'historique dans etcd semble persister ou la compaction galère
la compaction c'est tous les combien chez toi par défaut c'est 5 minutes. et le etcd_mvcc_blobs_total_bytes il est aussi en hausse
compaction est par défaut ouais. blobs_total_bytes est aussi en hausse. j'ai l'impression que le disque I/O est pas top non plus pour etcd pourtant c'est des NVMe dédiés
I/O disk c'est super critique pour etcd. fais un fio sur le volume etcd avec des petits blocs et du fsync pour voir les vraies latences en écriture synchrone. et tu peux augmenter etcd_max_txn_ops si t'as bcp de transactions simultanées
j'ai lancé un fio sur le volume etcd les latences en écriture synchrone sont à 20-30ms ce qui est affreux pour du NVMe. ça devrait être sous la milliseconde
20-30ms c'est la mort pour etcd. c'est quoi ton CSI driver et ton backend de stockage. y'a ptete un bug dans le driver ou une config réseau / raid qui limite les perfs
le driver CSI est custom comme j'ai dit c'est pour du stockage hyperconvergé et le support nous dit que c'est ok. mais je suspecte le driver ou l'intégration k8s avec le driver
si le fio est pourri c'est une piste solide. ton CSI driver il utilise des volumes block direct ou des filesystems montés sur les workers et si c'est des FS comment ils sont montés noatime nodiratime barrier=0 ça peut aider
c'est des volumes block formatés en XFS montés avec noatime. on avait pas touché à barrier. je vais voir si le CSI driver a des options pour optimiser la latence de ses volumes
demande au support du CSI s'ils ont des options genre fsGroupChangePolicy: Always ou ReadOnlyMany pour alléger les opérations sur etcd. parfois les drivers font des opérations de validation en background qui tapent fort sur le control plane
j'ai contacté le support du CSI driver et ils m'ont confirmé une option optimizeStorageIO: true pour les volumes etcd qu'on avait pas activé. après l'avoir mis en place et recréé les volumes les latences fio sont tombées à 0.5ms. etcd respire enfin et plus de leader elections. c'était bien le stockage bas niveau via le CSI. merci pour les pistes encore
Laisser une réponse
Vous devez être connecté pour poster un message !
salut les pros ! notre cluster k8s a des problèmes de latence etcd monstrueux ça entraîne des leader elections à répétition et les apiserver sont lents à répondre. on a bcp de churn de pods surtout des jobs qui créent/détruisent des pvcs et on a un driver csi custom pour du stockage un peu exotique