5.9. Allocation de ressources pour les nœuds d'un cluster OpenShift Container Platform

La quantité allouée d'une ressource est calculée sur la base de la formule suivante :

[Allocatable] = [Node Capacity] - [system-reserved] - [Hard-Eviction-Thresholds]

Si Allocatable est négatif, il est fixé à 0.

Chaque nœud indique les ressources système utilisées par l'exécution du conteneur et le kubelet. Pour simplifier la configuration du paramètre system-reserved, affichez l'utilisation des ressources pour le nœud en utilisant l'API de résumé du nœud. Le résumé du nœud est disponible à l'adresse /api/v1/nodes/<node>/proxy/stats/summary.

Le nœud peut limiter la quantité totale de ressources que les modules peuvent consommer en fonction de la valeur d'allocation configurée. Cette fonction améliore considérablement la fiabilité du nœud en empêchant les modules d'utiliser les ressources de CPU et de mémoire dont ont besoin les services système tels que le moteur d'exécution du conteneur et l'agent du nœud. Pour améliorer la fiabilité du nœud, les administrateurs doivent réserver des ressources en fonction d'un objectif d'utilisation des ressources.

Le nœud impose des contraintes de ressources en utilisant une nouvelle hiérarchie de cgroupes qui assure la qualité du service. Tous les pods sont lancés dans une hiérarchie de cgroup dédiée, séparée des démons du système.

Les administrateurs doivent traiter les démons système de la même manière que les pods qui ont une qualité de service garantie. Les démons système peuvent éclater au sein de leurs groupes de contrôle et ce comportement doit être géré dans le cadre des déploiements de clusters. Réservez des ressources de CPU et de mémoire aux démons système en spécifiant la quantité de ressources de CPU et de mémoire dans system-reserved.

L'application des limites de system-reserved peut empêcher les services système critiques de recevoir des ressources de CPU et de mémoire. Par conséquent, un service système critique peut être interrompu par le "out-of-memory killer". Il est recommandé d'appliquer system-reserved uniquement si vous avez profilé les nœuds de manière exhaustive afin de déterminer des estimations précises et si vous êtes certain que les services système critiques peuvent se rétablir si l'un des processus de ce groupe est interrompu par le tueur de mémoire.

Si un nœud subit une pression de mémoire, cela peut avoir un impact sur l'ensemble du nœud et sur tous les pods s'exécutant sur le nœud. Par exemple, un démon système qui utilise plus que la quantité de mémoire qui lui est réservée peut déclencher un événement de sortie de mémoire. Pour éviter ou réduire la probabilité d'événements de sortie de mémoire du système, le nœud fournit une gestion des ressources manquantes.

Vous pouvez réserver de la mémoire en utilisant l'option --eviction-hard. Le nœud tente d'expulser les modules chaque fois que la disponibilité de la mémoire sur le nœud tombe en dessous de la valeur absolue ou du pourcentage. Si les démons système n'existent pas sur un nœud, les modules sont limités à la mémoire capacity - eviction-hard. Pour cette raison, les ressources mises de côté en tant que tampon pour l'expulsion avant d'atteindre les conditions d'épuisement de la mémoire ne sont pas disponibles pour les modules.

L'exemple suivant illustre l'impact du nœud allouable pour la mémoire :

Pour ce nœud, la valeur allouable effective du nœud est 28.9Gi. Si le nœud et les composants du système utilisent toutes leurs réservations, la mémoire disponible pour les pods est 28.9Gi, et le kubelet évince les pods lorsqu'elle dépasse ce seuil.

Si vous imposez l'allocation de nœuds, 28.9Gi, avec des cgroups de premier niveau, les pods ne peuvent jamais dépasser 28.9Gi. Les expulsions ne sont pas effectuées à moins que les démons du système ne consomment plus de 3.1Gi de mémoire.

Si les démons du système n'utilisent pas toute leur réservation, dans l'exemple ci-dessus, les pods devraient faire face à des destructions OOM memcg de leur cgroup limitant avant que les évictions de nœuds ne démarrent. Pour mieux appliquer la QoS dans cette situation, le nœud applique les seuils d'éviction durs au cgroup de niveau supérieur pour tous les pods devant être Node Allocatable Eviction Hard Thresholds.

Si les démons du système n'utilisent pas toute leur réserve, le nœud expulse les modules dès qu'ils consomment plus de 28.9Gi de mémoire. Si l'éviction n'a pas lieu à temps, un pod sera tué par OOM si les pods consomment 29Gi de mémoire.

L'ordonnanceur utilise la valeur de node.Status.Allocatable au lieu de node.Status.Capacity pour décider si un nœud sera candidat à l'ordonnancement de pods.

Par défaut, le nœud indique que la capacité de sa machine est entièrement planifiable par le cluster.