Resources requests et limits
Request ? Limit ? Ou les deux ?
Pour ce qui est des valeurs absolues il n’existe pas de règle prédéfinie, cela dépendra très fortement de vos applications.
Cependant, pour ce qui est du ratio limit vs request, il existe des règles pour ne pas rencontrer des problèmes lors de l’exécution.
- La valeur request sera la valeur minimale requise pour démarrer
- La valeur limit sera la valeur maximale autorisée à être allouée
CPU vs Memory
Maintenant que les définitions osnt posées, quelles valeurs mettre pour le CPU et la mémoire ? Faut-il mettre l’un plus grand que l’autre ?
CPU
Pour ce qui est du CPU, c’est assez simple:
- Si limit == request
- Votre application n’aura jamais plus ou moins de CPU alloué que ce qui est indiqué dans la request
- Si limit > request
- Si des ressources sont disponibles et que votre application a besoin de plus de CPU, elle pourra les utiliser et s’exécuter plus vite.
Lorsque les ressources ne seront plus disponibles votre application se mettra juste à utiliser moins de CPU jusqu’à redescendre à la valeur request
Si vous en avez l’utilité donc, vous pouvez mettre une limit au-dessus de la request sans risque. Ces ressources supplémentaires ne seront pas garanties, mais permettront un gain de performances lorsque le cluster aura des ressources inutilisées.
Mémoire
Pour la mémoire, il y a quelques pièges à éviter:
- Si limit == request
- Comme pour le CPU, votre application n’aura jamais plus ou moins de mémoire allouée que celle de la request
- Si limit > request
- Comme pour le CPU, si des ressources sont disponibles et que application a besoin de plus de mémoire, elle pourra en avoir plus.
En revanche, si la mémoire venait à manquer sur le cluster, et que votre application consommait plus de mémoire que celle de la request, contrairement au cas du CPU ici votre pod sera OOMKill
par le cluster qui va essayer de la redémarrer avec sa request seulement.
Dans ce cas, comme votre pod utilisait en fait plus de mémoire qu’indiqué dans la request, vous pouvez vous retrouver dans un cas où il ne peut plus réussir à démarrer et rester coincé dans un CrashLoopbackOff
!