Les serveurs qui composent le cluster de DEV sur OVH tombent souvent.
CPU stuck
l'hypothèse probable sur la cause est lié à la charge des noeuds :
notre sous estimation des requests sur les POD
l'ajout de workload plus potentiellement plus lourd (pg)
la robustesse des hyperviseurs qui hébergent nos noeuds (vs Azure)
De faibles requests sur kubernetes lui donnent la possibilité de positionner plus de ressources que ce que le noeud et capable de supporter lorsque les PODs sont en fonctionnement nominal.
Pour préserver les noeuds nous devons limiter la sur allocation de ressources. Cela peut se faire via la mise en place de requests et limits pour informer kubenetes de la charge à prévisible sur le noeud
La mise en place de priorityClass est une seconde étape qui permettra de prioriser un déploiement par rapport à la kubelet et définir l'ordre de priorité de survis d'un POD sur kurbenetes.
Démarche de résolution
Valider l'hypothése :
[x] Positionner des requests limits sur les PODs de type CNPG, Builkit
Aller plus loin :
Positionner des requests limits sur les PODs de type infrastructure
Positionner des priority class sur les POD de de type CNPG et infrastructures
DoD
[ ] Les noeuds sur le cluster OVH-DEV sont stables
lister les ressources CNPG qui n'ont pas de requests
ajouter sur buildkit-service
augmenter / adapter
priority class : BDD -> < à guaranted et > à burstable
gary-van-woerkens
commented
8 months ago
Contexte
Les serveurs qui composent le cluster de DEV sur OVH tombent souvent.
l'hypothèse probable sur la cause est lié à la charge des noeuds :
De faibles requests sur kubernetes lui donnent la possibilité de positionner plus de ressources que ce que le noeud et capable de supporter lorsque les PODs sont en fonctionnement nominal.
Pour préserver les noeuds nous devons limiter la sur allocation de ressources. Cela peut se faire via la mise en place de requests et limits pour informer kubenetes de la charge à prévisible sur le noeud
La mise en place de priorityClass est une seconde étape qui permettra de prioriser un déploiement par rapport à la kubelet et définir l'ordre de priorité de survis d'un POD sur kurbenetes.
Démarche de résolution
Valider l'hypothése :
Aller plus loin :
Positionner des requests limits sur les PODs de type infrastructure
Positionner des priority class sur les POD de de type CNPG et infrastructures
DoD
[ ] Les noeuds sur le cluster OVH-DEV sont stables
ajouter sur buildkit-service
augmenter / adapter
priority class : BDD -> < à guaranted et > à burstable
taille des noeuds actuelle : 8cpu et 30Go