Comment allouer des ressources à vos applications

La Memoire

Allocation

Une fois alloué à un processus ou à un conteneur, le noyau ne peut pas récupérer cette mémoire. En effet, sur cet espace, le processus stocke probablement des résultats de calculs, des fichiers, des ressources nécessaires à son bon fonctionnement.

Le processus ne peut pas perdre une partie de sa mémoire et continuer à fonctionner correctement. Par conséquent, le noyau ne peut reprendre la mémoire allouée, sauf en demandant au processus qui consomme cette mémoire de s’arrêter et de libérer la mémoire.

Paramétrage

Pour la mémoire, il est recommandé de mettre des limites égales aux requêtes. Comme expliqué plus tôt, la mémoire ne peut être reprise qu’en arrêtant le processus ou le conteneur. Ainsi il n’est généralement pas souhaitable d’être au dessus de sa requête car si le nœud manque de mémoire, elle sera la première à se faire tuer par kubelet pour libérer de la mémoire.

Le CPU

Allocation

Le CPU est plus flexible et peut être repris sans nécessairement tuer un processus. Contrairement à la mémoire, le CPU est une ressource partagée, ce qui le rend plus difficile à délimiter.

Le CPU est donc partagé dans le temps. On parle ainsi de temps CPU. Ce temps est divisé en part par rapport à la période.

Le Completely Fair scheduler(CFS), le scheduler par défaut, le programme du noyau linux chargé de planifier l’utilisation CPU, découpe par période de 100ms. Cela peut être ajusté, cependant, plus la période est longue, meilleure est la performance globale, mais cela se fait au détriment de la réactivité du système.

Dans cette période de temps de 100ms, un quota de temps CPU est alloué à chacun des Cgroup, c’est-à- dire la quantité maximale de milliseconde qu’un processus peut utiliser le CPU sur la période.

Une fois qu’un processus a utilisé tout le temps CPU qui lui a été alloué pendant la période, il doit attendre la fin de la période pour recevoir à nouveau du temps CPU lui permettant d’utiliser le CPU.

Parametrage

Pour le CPU, le mieux est de renseigner les requêtes et de ne pas remplir les limites. Lorsque le champ des limites CPU est rempli, elles s’appliquent par période de 100 ms.

Par exemple:

resources:
  requests:
    cpu: "1"
  limits:
    cpu: "1"

En voyant cet exemple, il est possible de penser qu’un cœur CPU entier est attribué à votre application. Cependant, en réalité, vous attribuez 100 ms de temps CPU à chaque période de 100 ms, donc toutes les 100 ms réelles. Le CPU disponible au-delà de ces 100 ms de temps n’est pas disponible pour le conteneur.

Sur une machine monocœur, cela équivaut à 100 % du temps CPU, sur une machine bicœur, à 50 %, et ainsi de suite. Par conséquent, il est crucial de définir correctement les requêtes, car c’est la seule chose garantie. Il est préférable de ne pas définir de limites afin de pouvoir tirer parti du CPU disponible lorsque cela est possible.

Pour l’exemple, si le conteneur exécute une application qui prend avantage de plusieurs fils d’exécution sur une machine dotée de 4 cœurs CPU, en 25 ms, il pourrait techniquement avoir utilisé tout son temps CPU. Le processus serait alors en attente pendant les 75 ms restantes. On dit qu’il subit un throttling, ce qui signifie qu’il attend.

Ainsi on veut avoir des requêtes, réglées correctement, car c’est la seule chose qui est garantie. Mais on ne veut pas de limites. Si du CPU est disponible, c’est-à- dire qu’il n’est demandé par aucun container, on veut pouvoir en prendre avantage.

Le phénomène de throttle ne se voit pas dans les graphiques d’utilisation CPU, car les périodes de temps sont extrêmement faibles, même si vous avez configuré votre prometheus pour scrape toutes les 10s on parle de période de 100 ms, ça ne se voit pas dans les graphs, mais ca se ressent dans les performances.

Quelques métriques peuvent vous aider à voir le throttle:

• container_cpu_cfs_throttled_seconds_total: Temps total ou le container a été throttle.
• container_cpu_cfs_periods_total: nombre total de période depuis la création du container

Avec ces deux métriques, on peut facilement calculer le pourcentage de temps passé en throttle d’un container.

Pour aller plus loin :

• https://medium.com/@ramandumcs/cpu-throttling-unbundled-eae883e7e494
• https://home.robusta.dev/blog/stop-using-cpu-limits
• https://www.datadoghq.com/blog/kubernetes-cpu-requests-limits/

TLDR

• Memoire : des requests égale au limits
• CPU : des requests & pas de limits