10 commentaires
y'a aussi karpenter qui est bien plus agressif que le cluster autoscaler pour le scale down. ça peut virer des noeuds plus vite et de manière plus optimale. ça vaut le coup de regarder. ou sinon des managed node groups avec un min de 0 et des scale-in protection désactivées
un truc con mais tu n'aurais pas de pods qui demandent des ressources fixes (cpu/mem requests) mais qui en utilisent très peu ? le ca voit le request et pas l'usage réel donc ça peut garder des noeuds si les requests sont hautes même si le pod est idle
check les affinités/anti-affinités de tes pods. si t'as des contraintes trop strictes ça peut forcer des noeuds à rester pour satisfaire une affinité inter-pod même s'il y a peu de pods. et des node local storage si tes pods utilisent des emptyDir ou hostPath
ok pour les logs du ca je vais fouiller. les pdb c'est une piste aussi je les ai ptete laissés trop permissifs pour certains services. karpenter j'y ai pensé mais c'est un gros chantier de migration pour l'instant je voudrais optimiser l'existant. mes requests/limits sont plutôt bien réglés je pense. affinités j'en ai peu. storage pas de hostpath. je pense vraiment aux pdb là ou aux pods système
focus sur les pdb et les pods système. souvent un seul pod comme le kube-proxy ou un aws-node ou un metrics-server mal configuré peut empêcher un noeud de partir s'il a une tolérance à la défaillance NoExecute et qu'il n'y a pas d'autre nœud disponible pour lui
et n'oublie pas le pod anti-affinity aussi. si tu dis "ne mets jamais deux replicas de mon service sur le même nœud" et que tu n'as que 2 nœuds et 2 replicas, si tu veux en virer un, l'autre réplica n'a plus où aller si le cluster autoscaler ne peut pas en créer un troisième
bingo ! j'ai trouvé un pdb sur un service critique qui avait un minAvailable: 1 et comme y'avait que 2 replicas et 2 noeuds... bah impossible de virer le noeud sans violer le pdb. j'ai ajusté le pdb et réduit le minAvailable à 0 pendant le scale down. et j'ai vu des logs du ca qui disaient "not ready for deletion, pod disruption budget prevents deletion". clair comme de l'eau de roche une fois qu'on sait où chercher.
ouais carrément ! merci pour toutes les pistes j'aurais jamais pensé aux pdb direct. ça va nous faire économiser un paquet. thx !
Laisser une réponse
Vous devez être connecté pour poster un message !
bonsoir les finops warriors j'ai un gros coup de mou. nos clusters eks bouffent un max de thunes même quand y'a quasi rien qui tourne dessus. on a l'autoscaler de cluster (cluster autoscaler) mais j'ai l'impression qu'il est aveugle. les noeuds restent up pendant des plombes alors qu'ils sont vides. comment vous gérez ça pour vraiment couper les coûts sur de l'eks à vide ?