4.4. En plaçant des gousses sur des nœuds surengagés

Les requêtes et les limites permettent aux administrateurs d’autoriser et de gérer l’engagement excessif des ressources sur un nœud. Le planificateur utilise des demandes pour planifier votre conteneur et fournir une garantie de service minimale. Les limites limitent la quantité de ressources de calcul qui peuvent être consommées sur votre nœud.

Le service OpenShift Red Hat sur AWS peut contrôler le niveau de surengagement et gérer la densité des conteneurs sur les nœuds en configurant les maîtres pour outrepasser le rapport entre la requête et la limite définie sur les conteneurs développeurs. En conjonction avec un objet LimitRange par projet spécifiant les limites et les valeurs par défaut, cela ajuste la limite de conteneur et demande pour atteindre le niveau souhaité de surengagement.

Après ces dépassements, les limites de conteneur et les demandes doivent toujours être validées par tout objet LimitRange dans le projet. Il est possible, par exemple, que les développeurs spécifient une limite proche de la limite minimale, et que la demande soit alors dépassée en dessous de la limite minimale, ce qui rend la pod interdite. Cette expérience utilisateur malheureuse devrait être traitée avec un travail futur, mais pour l’instant, configurez cette capacité et les objets LimitRange avec prudence.

Dans un environnement surengagé, il est important de configurer correctement votre nœud pour fournir le meilleur comportement du système.

Lorsque le nœud démarre, il s’assure que les drapeaux tunables du noyau pour la gestion de la mémoire sont correctement définis. Le noyau ne devrait jamais échouer aux allocations de mémoire à moins qu’il ne soit épuisé de mémoire physique.

Afin d’assurer ce comportement, Red Hat OpenShift Service sur AWS configure le noyau pour toujours surengager la mémoire en définissant le paramètre vm.overcommit_memory sur 1, outrepassant le paramètre système d’exploitation par défaut.

Le service OpenShift Red Hat sur AWS configure également le noyau pour ne pas paniquer lorsqu’il n’est plus en mémoire en définissant le paramètre vm.panic_on_oom à 0. Le paramètre 0 ordonne au noyau d’appeler oom_killer dans une condition hors mémoire (OOM), qui tue les processus en fonction de la priorité.

En exécutant les commandes suivantes sur vos nœuds, vous pouvez afficher le paramètre actuel:

sysctl -a |grep commit

$ sysctl -a |grep commit

#...
vm.overcommit_memory = 0
#...

#...
vm.overcommit_memory = 0
#...

sysctl -a |grep panic

$ sysctl -a |grep panic

#...
vm.panic_on_oom = 0
#...

#...
vm.panic_on_oom = 0
#...

Il est également possible d’effectuer les configurations suivantes pour chaque nœud: