Etcd leader election storms kube-apiserver timeout

Question

Salut l'équipe. On a des gros soucis sur un cluster k8s. etcd part en vrille régulièrement des leader elections toutes les 30s. ça timeoute le kube-apiserver et les pods deviennent NotReady. L'infra est sur des instances assez puissantes pourtant. des pistes ?
kubectl get pods --all-namespaces | grep -E "etcd|kube-apiserver"
kube-system   etcd-master-1         1/1     Running
kube-system   etcd-master-2         1/1     Running
kube-system   etcd-master-3         1/1     Running
kube-system   kube-apiserver-master-1   1/1     Running
kube-system   kube-apiserver-master-2   1/1     Running
kube-system   kube-apiserver-master-3   1/1     Running

alice38 · Answer

ptete un pb de réseau entre tes noeuds etcd ? des latences sur le rtt des peers ? regarde si y a pas du packet loss sur l'interface ou des drops côté firewall

duhamel-elisabeth · Answer

ouais carrément faut monitorer le etcd_network_peer_round_trip_time_seconds. si ça peak c'est le réseau. et la latence disque sur l'iops de etcd_disk_wal_fsync_duration_seconds ça donne quoi

francois-albert · Answer

j'ai checké le réseau les pings entre les noeuds etcd sont stables genre 0.2ms. pas de packet loss. par contre le wal_fsync duration peak à 100ms par moments c'est pas normal si ?

alice38 · Answer

100ms c'est énorme etcd a besoin de latences très faibles pour le wal typiquement sous les 10ms voir 1ms. t'es sur quel type de stockage ? ssd local ou ebs/azure disk ?

francois-albert · Answer

c'est du gp2 sur aws. je pensais que c'était suffisant pour des petits clusters

duhamel-elisabeth · Answer

gp2 c'est pas top pour etcd. tu peux avoir des iops burstables mais la baseline est pas folle. faut du io1/io2 ou local ssd nvme si t'es sur ec2 direct. pour etcd il faut de la latence garantie

alice38 · Answer

exact gp2 peut throttle si tu consommes trop de crédits. regarde tes métriques cloudwatch pour le VolumeReadOps/WriteOps et VolumeQueueLength

francois-albert · Answer

ok je vois des queues length monter à 20-30 pendant les pics de leader election. ça confirme la latence disque

duhamel-elisabeth · Answer

tu peux aussi vérifier la version de etcd. des anciennes versions sont moins résilientes aux latences disque. et la taille de tes snapshots etcd ça grossit vite ?

francois-albert · Answer

etcd en 3.5.x c'est la dernière. les snapshots sont gérés par kube-apiserver via les apiserver-count-quorum. la taille est stable genre quelques centaines de Mo

alice38 · Answer

t'as des gros volumes de writes sur ton cluster ? des apps qui créent/suppriment bcp de ressources k8s ?

francois-albert · Answer

on a un operator qui créé plein de CRDs temporaires pour des jobs ça pourrait être ça

duhamel-elisabeth · Answer

ouais ça peut être ça. chaque modification sur etcd c'est une write. si l'operator spamme ça peut mettre la pression sur le disque. regarde etcd_mvcc_db_total_size_in_bytes et etcd_mvcc_delete_total

alice38 · Answer

pour tester tu peux scaler ton etcd sur du io2 ou local nvme direct. ou sinon réduire le nombre de CRD créé par l'opérateur si c'est possible

francois-albert · Answer

ok je vais tenter de passer les volumes etcd sur du io2 provisionné à 5000 iops. et je vais optimiser l'opérateur pour qu'il soit moins verbeux. je vous dis si ça améliore

francois-albert · Answer

bon ben on est passé sur de l'io2 5000 iops et y a plus aucun pic de latence. le cluster est rock solid. merci pour l'aide c'était bien le stockage

Etcd leader election storms kube-apiserver timeout

16 commentaires

Laisser une réponse

Les channels dans le langage de programmation Go

Téléchargement et compilation d’un projet SDL

Les Datas Source sur Terraform

Les Pages Wiki sur GitLab pour centraliser votre documentation

Les variables CI/CD dans GitLab pour gérer vos secrets

Rejoindre la communauté