Ce qu'un pod a dit lui survit — Loki et Alloy, sous plafond (#38) #40
+20
-1
@@ -98,7 +98,26 @@ alloy:
|
||||
limits:
|
||||
# Pas de limite CPU (l'étranglement d'un agent lui fait perdre des
|
||||
# lignes en silence, ce qui est le défaut qu'on essaie de supprimer).
|
||||
memory: 256Mi
|
||||
#
|
||||
# ⚠ 384 Mi, ET C'EST UN CHIFFRE MESURÉ, PAS UN CHIFFRE ROND.
|
||||
# Le premier jet plafonnait à 256 Mi. Relevé sur la pile qui tourne,
|
||||
# pendant la reprise de l'historique (`kubectl top pods --containers`) :
|
||||
#
|
||||
# agent de pi1 214 Mi ← 84 % du plafond de 256 Mi
|
||||
# agent de pi2 98 Mi
|
||||
# agent de pi3 83 Mi
|
||||
#
|
||||
# Aucun OOMKill constaté (0 redémarrage sur les trois), mais 84 % n'est
|
||||
# pas une marge : un agent tué perd sa position de lecture, et un trou
|
||||
# dans la collecte est exactement ce que ce lot existe pour supprimer.
|
||||
#
|
||||
# ⚠ Relever un PLAFOND ne consomme rien : il borne le pire cas. C'est la
|
||||
# REQUÊTE (128 Mi, inchangée) que le planificateur réserve.
|
||||
#
|
||||
# ⚠ L'écart entre les trois nœuds n'est pas du bruit : il suit le nombre
|
||||
# de fichiers suivis, donc le nombre de conteneurs du nœud. Un nœud qui
|
||||
# se remplit fera monter son agent.
|
||||
memory: 384Mi
|
||||
|
||||
# Pas de grappe : chaque agent lit SON nœud, il n'a rien à coordonner.
|
||||
clustering:
|
||||
|
||||
Reference in New Issue
Block a user