etcd latency peak K8s API server lent

Posté par uevrard le 29/08/2025
RÉSOLU

uevrard

Membre depuis le 08/11/2024

actif

yo la team K8s ! on a des gros soucis de latence sur l'API server depuis quelques jours. des pics de 500ms sur les requêtes genre list pods. les métriques etcd montrent des `etcd_server_proposals_applied_total` qui chutent et `etcd_server_slow_apply_total` qui monte en flèche. des idées d'où ça peut venir ? on est sur 3 nœuds etcd dédiés.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: etcd-monitor
spec:
  selector:
    matchLabels:
      app: etcd-monitor
  template:
    metadata:
      labels:
        app: etcd-monitor
    spec:
      hostNetwork: true
      containers:
      - name: etcd-healthz
        image: busybox
        command: ["sh", "-c", "while true; do wget -qO- localhost:2379/health; sleep 1; done"]

Commentaires

peltier-michelle

Membre depuis le 30/10/2024

actif secouriste

salut ! ouais ça sent le problème etcd. c quoi la version d'etcd et de k8s ? quel backend storage pour etcd ? typiquement c un problème de disque ou de fragmentation.

uevrard

Membre depuis le 08/11/2024

actif

k8s 1.25. etcd 3.5.0. backend c'est des volumes gp3 sur AWS avec 3000 IOPS provisionnés. le disque semble pas saturé en IOPS mais le CPU sur les etcd est parfois à 80-90%.

peltier-michelle

Membre depuis le 30/10/2024

actif secouriste

ok gp3 c'est pas mal. 3000 iops c'est correct pour bcp de clusters. le cpu à 80-90% c'est bizarre. tu as une idée de la taille de ta base etcd ? `etcd_debugging_mvcc_db_total_size_in_bytes` ? des fois c'est la compaction qui galère.

uevrard

Membre depuis le 08/11/2024

actif

la db fait 8GB. c'est pas énorme. la compaction est à 1h, `auto-compaction-retention=1h`.

peltier-michelle

Membre depuis le 30/10/2024

actif secouriste

8GB c'est pas non plus super petit. t'as vérifié les `etcd_mvcc_delete_total_count` et `etcd_mvcc_put_total_count` ? voir si y'a pas un bailleur qui spamme des writes/deletes. une fragmentation peut aussi ralentir le CPU pendant la compaction ou les reads.

uevrard

Membre depuis le 08/11/2024

actif

les puts/deletes sont hauts. on a un contrôleur qui sync pas mal d'objets. et pour la fragmentation, euh, j'ai `etcdctl defrag status` qui dit que la db est fragmentée à 60%.

peltier-michelle

Membre depuis le 30/10/2024

actif secouriste

60% de fragmentation ! bah voilà. quand c'est fragmenté, etcd doit faire plus de travail pour lire et écrire. la compaction devient plus lourde aussi. il faut défragmenter. ça va impacter les perfs pendant l'opération mais c'est nécessaire.

ETCDCTL_API=3 etcdctl --endpoints=https://etcd-0:2379,https://etcd-1:2379,https://etcd-2:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/apiserver-etcd-client.crt \
  --key=/etc/kubernetes/pki/apiserver-etcd-client.key defrag start

uevrard

Membre depuis le 08/11/2024

actif

ok j'ai lancé le defrag. ça a fait baisser la fragmentation à 20% mais le CPU est toujours haut par intermittence. la latence API server est un peu mieux mais pas top.

peltier-michelle

Membre depuis le 30/10/2024

actif secouriste

hm intéressant. defrag aide mais ne résout pas tout. on a éliminé le disque et la fragmentation majeure. la prochaine piste c'est le nombre de requêtes clients. qui interroge etcd le plus ? tu peux regarder les logs de l'API server ou `etcd_server_client_requests_total` par type de requête.

uevrard

Membre depuis le 08/11/2024

actif

c clair qu'on a bcp de list/watch. en regardant les logs de l'API server, y'a un opérateur custom qui spamme les listes sur un CRD toutes les 2 secondes. on dirait qu'il refait un full sync à chaque fois.

peltier-michelle

Membre depuis le 30/10/2024

actif secouriste

bingo ! c'est ça qui te tue. un opérateur qui fait du full list/watch toutes les 2s sur des milliers d'objets, ça pèse énormément sur etcd. surtout si le CRD est gros. faut voir s'il peut pas faire du delta sync ou avoir un informer plus intelligent.

uevrard

Membre depuis le 08/11/2024

actif

je vais checker le code de l'opérateur. c un vieux truc. ptete qu'on peut optimiser le watch plutôt qu'un list complet. thx pour l'aide ça m'a fait avancer pas mal.

peltier-michelle

Membre depuis le 30/10/2024

actif secouriste

pas de souci. les opérateurs mal codés c'est une source fréquente de perf issues sur k8s. bonne chasse à l'optimisation !

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