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

Commentaires

Laisser une réponse

Création de notre playbook Ansible (stack LAMP)

Les méthodes pour ajouter des fichiers à votre projet GitLab

Les backends et les workspaces

Rejoindre la communauté