7.11. Sur-engagement au niveau du nœud
Vous pouvez utiliser différents moyens pour contrôler le surengagement sur des nœuds spécifiques, tels que les garanties de qualité de service (QOS), les limites de CPU ou les ressources de réserve. Vous pouvez également désactiver le surengagement pour des nœuds et des projets spécifiques.
7.11.1. Comprendre les ressources informatiques et les conteneurs
Le comportement renforcé par le nœud pour les ressources de calcul est spécifique au type de ressource.
7.11.1.1. Comprendre les demandes d'unité centrale des conteneurs
Un conteneur se voit garantir la quantité de CPU qu'il demande et peut en outre consommer le surplus de CPU disponible sur le nœud, jusqu'à une limite spécifiée par le conteneur. Si plusieurs conteneurs tentent d'utiliser l'unité centrale excédentaire, le temps d'utilisation de l'unité centrale est réparti en fonction de la quantité d'unité centrale demandée par chaque conteneur.
Par exemple, si un conteneur demande 500 m de temps CPU et qu'un autre conteneur demande 250 m de temps CPU, le temps CPU supplémentaire disponible sur le nœud est réparti entre les conteneurs dans un rapport de 2:1. Si un conteneur a spécifié une limite, il sera limité pour ne pas utiliser plus de CPU que la limite spécifiée. Les demandes de CPU sont appliquées en utilisant le support des parts CFS dans le noyau Linux. Par défaut, les limites de CPU sont appliquées en utilisant le support des quotas CFS dans le noyau Linux sur un intervalle de mesure de 100ms, bien que cela puisse être désactivé.
7.11.1.2. Comprendre les demandes de mémoire des conteneurs
Un conteneur se voit garantir la quantité de mémoire qu'il demande. Un conteneur peut utiliser plus de mémoire que celle demandée, mais une fois qu'il dépasse la quantité demandée, il peut être interrompu en cas de manque de mémoire sur le nœud. Si un conteneur utilise moins de mémoire que la quantité demandée, il ne sera pas interrompu, sauf si des tâches ou des démons du système ont besoin de plus de mémoire que ce qui a été pris en compte dans la réservation des ressources du nœud. Si un conteneur spécifie une limite de mémoire, il est immédiatement interrompu s'il dépasse cette limite.
7.11.2. Comprendre le surengagement et les classes de qualité de service
Un nœud est overcommitted lorsqu'un pod programmé n'effectue aucune demande ou lorsque la somme des limites de tous les pods sur ce nœud dépasse la capacité disponible de la machine.
Dans un environnement surengagé, il est possible que les pods sur le nœud tentent d'utiliser plus de ressources de calcul que celles disponibles à un moment donné. Dans ce cas, le nœud doit donner la priorité à un module plutôt qu'à un autre. La fonction utilisée pour prendre cette décision est appelée classe de qualité de service (QoS).
Un pod est désigné comme l'une des trois classes de qualité de service, par ordre de priorité décroissant :
| Priorité | Nom de la classe | Description |
|---|---|---|
| 1 (le plus élevé) | Guaranteed | Si des limites et, éventuellement, des demandes sont fixées (et non égales à 0) pour toutes les ressources et qu'elles sont égales, le pod est classé comme Guaranteed. |
| 2 | Burstable | Si des demandes et éventuellement des limites sont définies (différentes de 0) pour toutes les ressources, et qu'elles ne sont pas égales, le pod est classé comme Burstable. |
| 3 (le plus bas) | BestEffort | Si les demandes et les limites ne sont définies pour aucune des ressources, le pod est classé comme BestEffort. |
La mémoire étant une ressource incompressible, dans les situations où la mémoire est faible, les conteneurs qui ont la priorité la plus basse sont terminés en premier :
- Guaranteed sont considérés comme prioritaires et ne seront interrompus que s'ils dépassent leurs limites ou si le système est sous pression de mémoire et qu'il n'y a pas de conteneurs de moindre priorité pouvant être expulsés.
- Burstable les conteneurs soumis à la pression de la mémoire du système sont plus susceptibles d'être interrompus lorsqu'ils dépassent leurs demandes et qu'il n'existe pas d'autres conteneurs BestEffort.
- BestEffort sont traités avec la priorité la plus basse. Les processus de ces conteneurs sont les premiers à être interrompus si le système manque de mémoire.
7.11.2.1. Comprendre comment réserver de la mémoire entre les différents niveaux de qualité de service
Vous pouvez utiliser le paramètre qos-reserved pour spécifier un pourcentage de mémoire à réserver par un module dans un niveau de qualité de service particulier. Cette fonctionnalité tente de réserver les ressources demandées afin d'empêcher les pods des classes de qualité de service inférieures d'utiliser les ressources demandées par les pods des classes de qualité de service supérieures.
OpenShift Container Platform utilise le paramètre qos-reserved comme suit :
-
Une valeur de
qos-reserved=memory=100%empêchera les classes de qualité de serviceBurstableetBestEffortde consommer la mémoire demandée par une classe de qualité de service supérieure. Cela augmente le risque d'induire des OOM sur les charges de travailBestEffortetBurstableen faveur d'une augmentation des garanties de ressources mémoire pour les charges de travailGuaranteedetBurstable. -
Une valeur de
qos-reserved=memory=50%permet aux classes de qualité de serviceBurstableetBestEffortde consommer la moitié de la mémoire demandée par une classe de qualité de service supérieure. -
Une valeur de
qos-reserved=memory=0%permet aux classes de qualité de serviceBurstableetBestEffortde consommer la totalité de la quantité allouable au nœud si elle est disponible, mais augmente le risque qu'une charge de travailGuaranteedn'ait pas accès à la mémoire demandée. Cette condition désactive effectivement cette fonctionnalité.
7.11.3. Comprendre la mémoire d'échange et le QOS
Vous pouvez désactiver le swap par défaut sur vos nœuds afin de préserver les garanties de qualité de service (QOS). Dans le cas contraire, les ressources physiques d'un nœud peuvent se surinscrire, ce qui affecte les garanties de ressources que le planificateur Kubernetes apporte lors du placement des pods.
Par exemple, si deux modules garantis ont atteint leur limite de mémoire, chaque conteneur peut commencer à utiliser la mémoire d'échange. Finalement, s'il n'y a pas assez d'espace d'échange, les processus dans les modules peuvent être interrompus parce que le système est sursouscrit.
Si l'échange n'est pas désactivé, les nœuds ne reconnaissent pas qu'ils sont confrontés à MemoryPressure, ce qui fait que les modules ne reçoivent pas la mémoire qu'ils ont demandée dans leur requête de planification. En conséquence, des modules supplémentaires sont placés sur le nœud, ce qui augmente encore la pression sur la mémoire et, en fin de compte, le risque d'une panne de mémoire du système (OOM).
Si la permutation est activée, les seuils d'éviction de la mémoire disponible pour la gestion des ressources ne fonctionneront pas comme prévu. Tirez parti de la gestion des ressources manquantes pour permettre aux pods d'être expulsés d'un nœud lorsqu'il est soumis à une pression de mémoire, et replanifiés sur un autre nœud qui n'est pas soumis à une telle pression.
7.11.4. Comprendre le surengagement des nœuds
Dans un environnement surchargé, il est important de configurer correctement votre nœud afin d'obtenir le meilleur comportement possible du système.
Lorsque le nœud démarre, il s'assure que les drapeaux ajustables du noyau pour la gestion de la mémoire sont correctement définis. Le noyau ne devrait jamais échouer dans l'allocation de la mémoire à moins qu'il ne soit à court de mémoire physique.
Pour garantir ce comportement, OpenShift Container Platform configure le noyau pour qu'il surengage toujours de la mémoire en définissant le paramètre vm.overcommit_memory sur 1, ce qui annule le paramètre par défaut du système d'exploitation.
OpenShift Container Platform configure également le noyau pour qu'il ne panique pas lorsqu'il manque de mémoire en définissant le paramètre vm.panic_on_oom sur 0. Un paramètre de 0 indique au noyau d'appeler oom_killer dans une condition de manque de mémoire (OOM), ce qui tue les processus en fonction de leur priorité
Vous pouvez afficher le paramètre actuel en exécutant les commandes suivantes sur vos nœuds :
$ sysctl -a |grep commit
Exemple de sortie
vm.overcommit_memory = 1
$ sysctl -a |grep panic
Exemple de sortie
vm.panic_on_oom = 0
Les drapeaux ci-dessus devraient déjà être activés sur les nœuds, et aucune autre action n'est nécessaire.
Vous pouvez également effectuer les configurations suivantes pour chaque nœud :
- Désactiver ou appliquer les limites de l'unité centrale à l'aide des quotas CFS de l'unité centrale
- Réserver des ressources pour les processus du système
- Réserve de mémoire pour les différents niveaux de qualité de service
7.11.5. Désactivation ou application des limites de l'unité centrale à l'aide des quotas CFS de l'unité centrale
Les nœuds appliquent par défaut les limites de CPU spécifiées en utilisant la prise en charge des quotas CFS (Completely Fair Scheduler) dans le noyau Linux.
Si vous désactivez l'application de la limite du CPU, il est important de comprendre l'impact sur votre nœud :
- Si un conteneur a une demande d'unité centrale, la demande continue d'être exécutée par les parts CFS dans le noyau Linux.
- Si un conteneur n'a pas de demande de CPU, mais a une limite de CPU, la demande de CPU est fixée par défaut à la limite de CPU spécifiée, et est appliquée par les parts CFS dans le noyau Linux.
- Si un conteneur a à la fois une demande et une limite de CPU, la demande de CPU est appliquée par les parts CFS dans le noyau Linux, et la limite de CPU n'a pas d'impact sur le nœud.
Conditions préalables
Obtenez l'étiquette associée au CRD statique
MachineConfigPoolpour le type de nœud que vous souhaitez configurer en entrant la commande suivante :oc edit machineconfigpool <name> $ oc edit machineconfigpool <name>
Par exemple :
$ oc edit machineconfigpool worker
Exemple de sortie
apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfigPool metadata: creationTimestamp: "2022-11-16T15:34:25Z" generation: 4 labels: pools.operator.machineconfiguration.openshift.io/worker: "" 1 name: worker- 1
- L'étiquette apparaît sous Étiquettes.
AstuceSi l'étiquette n'est pas présente, ajoutez une paire clé/valeur comme par exemple :
$ oc label machineconfigpool worker custom-kubelet=small-pods
Procédure
Créez une ressource personnalisée (CR) pour votre changement de configuration.
Exemple de configuration pour la désactivation des limites de l'unité centrale
apiVersion: machineconfiguration.openshift.io/v1 kind: KubeletConfig metadata: name: disable-cpu-units 1 spec: machineConfigPoolSelector: matchLabels: pools.operator.machineconfiguration.openshift.io/worker: "" 2 kubeletConfig: cpuCfsQuota: 3 - "true"
Exécutez la commande suivante pour créer le CR :
oc create -f <nom_du_fichier>.yaml
7.11.6. Réserver des ressources pour les processus du système
Pour assurer une planification plus fiable et minimiser le surengagement des ressources des nœuds, chaque nœud peut réserver une partie de ses ressources aux démons du système qui doivent être exécutés sur le nœud pour que la grappe fonctionne. Il est notamment recommandé de réserver des ressources incompressibles telles que la mémoire.
Procédure
Pour réserver explicitement des ressources aux processus qui ne sont pas des nœuds, allouez des ressources aux nœuds en spécifiant les ressources disponibles pour l'ordonnancement. Pour plus de détails, voir Allocation de ressources pour les nœuds.
7.11.7. Désactivation du surengagement pour un nœud
Lorsqu'il est activé, le surengagement peut être désactivé sur chaque nœud.
Procédure
Pour désactiver le surengagement dans un nœud, exécutez la commande suivante sur ce nœud :
$ sysctl -w vm.overcommit_memory=0
