devopssec
n'est en aucun cas responsable du contenu généré par l'utilisateur. Le contenu posté
exprime les opinions de leur auteur seulement.
Les textes et messages publiés sont la propriété de ceux qui les postent.
je fais de mon mieux pour modérer les propos inappropriés qui pourraient être postés ici,
mais je me dégage de toute responsabilité sur ce que vous postez.
Vous demeurez le seul responsable de vos actes et de vos messages au regard de la loi.
Vous acceptez de ne pas utiliser le service pour poster ou lier vers un contenu qui est
diffamatoire, injurieux, haineux, menaçant, spams ou pourriels, étant de nature à offenser,
ayant un contenu réservé aux adultes ou répréhensible, contenant des renseignements
personnels des autres, risquant de violer les droits d'auteurs, encourageant une activité
illégale ou contraire à toutes les lois.
Le respect est la principale qualité de notre communauté. En conséquence, veillez à l'être envers
vos camarades ici présents, en particulier les nouveaux membres qui comme vous, cherchent
à découvrir l'univers DEVOPS, et n'ont pas toutes vos connaissances.
Tout manque de respect à l'encontre d'un membre, néophyte ou non, entraînera également des sanctions,
à savoir avertissements, bannissements voire poursuites selon la gravité de la situation.
devopssec
décline toute responsabilité concernant les rencontres réelles.
Commentaires
claude90
Membre depuis le 31/12/2024
le plus gros levier souvent c'est le redimensionnement des pods et des nodes. utilise kube-cost ou goldilocks pour analyser les request/limit et voir où tu peux réduire. beaucoup de gens sur-provisionnent le cpu et la ram "au cas où"
hugues47
Membre depuis le 17/12/2024
vertical pod autoscaler (vpa) est pas mal pour les requests/limits mais faut faire gaffe en prod. sinon pour les nodes cluster autoscaler avec des groupes de noeuds variés (spot on-demand arm x86) ça aide. et karpenter c'est la Rolls pour l'optim auto des nodes
roy-paulette
Membre depuis le 09/01/2025
regarde aussi les ebs volumes si t'as des gp2 qui traînent passe en gp3 c'est moins cher pour les mêmes perfs de base. et vire les volumes non attachés ou super vieux. ça paraît con mais ça s'accumule vite
pasquier-benoit
Membre depuis le 10/01/2025
ouais vpa j'ai un peu peur mais faut que je me penche dessus. karpenter on l'a pas encore on est sur cluster autoscaler standard. les volumes ebs j'ai déjà un peu nettoyé mais je peux faire un audit plus poussé. bonne idée gp3
claude90
Membre depuis le 31/12/2024
si t'as des bases de données rds check les types d'instances. on-demand vs reserved vs savings plans. et regarde si t'as pas des vieux snapshots qui dorment. aussi les logs cloudwatch si tu les gardes trop longtemps ça coûte. faut une bonne rétention policy
hugues47
Membre depuis le 17/12/2024
pour les workloads batch tu peux les basculer sur fargate si le profiling le permet. pas de nodes à gérer tu paies juste la conso des pods. ou si c'est vraiment des jobs court tu les fais tourner sur lambdas ou step functions
roy-paulette
Membre depuis le 09/01/2025
pense au network egress. si tes pods ou tes services envoient beaucoup de données vers internet ou entre régions différentes ça monte très vite. utilise un vpc endpoint si c'est vers un service aws pour rester dans le réseau aws
pasquier-benoit
Membre depuis le 10/01/2025
ok plein de bonnes pistes là. je vais prioriser le redimensionnement des pods avec goldilocks voir ce que ça donne. et audit des snapshots/logs et le passage en gp3. fargate c'est intéressant pour le batch faudra creuser. merci à tous pour l'aide ça va bien m'aider à justifier mon budget !