7.5. Configurer votre cluster pour placer des pods sur des nœuds sur-engagés
Dans un état overcommitted, la somme des demandes et des limites des ressources de calcul du conteneur dépasse les ressources disponibles sur le système. Par exemple, vous pouvez utiliser le surengagement dans les environnements de développement où un compromis entre les performances garanties et la capacité est acceptable.
Les conteneurs peuvent spécifier des demandes et des limites de ressources de calcul. Les demandes sont utilisées pour planifier votre conteneur et fournissent une garantie de service minimum. Les limites restreignent la quantité de ressources de calcul qui peut être consommée sur votre nœud.
L'ordonnanceur tente d'optimiser l'utilisation des ressources de calcul sur tous les nœuds de votre cluster. Il place les pods sur des nœuds spécifiques, en tenant compte des demandes de ressources de calcul des pods et de la capacité disponible des nœuds.
Les administrateurs d'OpenShift Container Platform peuvent contrôler le niveau de surengagement et gérer la densité des conteneurs sur les nœuds. Vous pouvez configurer le surengagement au niveau du cluster à l'aide de l'opérateur ClusterResourceOverride pour remplacer le rapport entre les demandes et les limites définies sur les conteneurs de développement. En conjonction avec le surengagement des nœuds et les limites et valeurs par défaut de la mémoire et de l'unité centrale du projet, vous pouvez ajuster la limite et la demande de ressources afin d'atteindre le niveau de surengagement souhaité.
Dans OpenShift Container Platform, vous devez activer le surengagement au niveau du cluster. Le surengagement au niveau du nœud est activé par défaut. Voir Désactivation du surengagement pour un nœud.
7.5.1. Demandes de ressources et surengagement
Pour chaque ressource informatique, un conteneur peut spécifier une demande de ressource et une limite. Les décisions d'ordonnancement sont prises en fonction de la demande afin de s'assurer qu'un nœud dispose d'une capacité suffisante pour répondre à la valeur demandée. Si un conteneur spécifie des limites, mais omet des demandes, les demandes sont définies par défaut en fonction des limites. Un conteneur ne peut pas dépasser la limite spécifiée sur le nœud.
L'application des limites dépend du type de ressource de calcul. Si un conteneur ne formule aucune demande ou limite, il est programmé sur un nœud sans garantie de ressources. En pratique, le conteneur est capable de consommer autant de ressources spécifiées qu'il est disponible avec la priorité locale la plus basse. Dans les situations où les ressources sont faibles, les conteneurs qui ne formulent aucune demande de ressources bénéficient de la qualité de service la plus faible.
L'ordonnancement est basé sur les ressources demandées, tandis que les quotas et les limites strictes font référence aux limites de ressources, qui peuvent être plus élevées que les ressources demandées. La différence entre la demande et la limite détermine le niveau de surengagement ; par exemple, si un conteneur reçoit une demande de mémoire de 1Gi et une limite de mémoire de 2Gi, il est ordonnancé sur la base de la demande de 1Gi disponible sur le nœud, mais pourrait utiliser jusqu'à 2Gi ; il est donc surengagé à 200%.
7.5.2. Surengagement au niveau du cluster à l'aide de l'opérateur d'annulation des ressources du cluster
Le Cluster Resource Override Operator est un webhook d'admission qui vous permet de contrôler le niveau d'overcommit et de gérer la densité des conteneurs sur tous les nœuds de votre cluster. L'opérateur contrôle la façon dont les nœuds de projets spécifiques peuvent dépasser les limites de mémoire et de CPU définies.
Vous devez installer le Cluster Resource Override Operator à l'aide de la console OpenShift Container Platform ou du CLI, comme indiqué dans les sections suivantes. Lors de l'installation, vous créez une ressource personnalisée (CR) ClusterResourceOverride
, dans laquelle vous définissez le niveau de surengagement, comme le montre l'exemple suivant :
apiVersion: operator.autoscaling.openshift.io/v1 kind: ClusterResourceOverride metadata: name: cluster 1 spec: podResourceOverride: spec: memoryRequestToLimitPercent: 50 2 cpuRequestToLimitPercent: 25 3 limitCPUToMemoryPercent: 200 4
- 1
- Le nom doit être
cluster
. - 2
- Facultatif. Si une limite de mémoire de conteneur a été spécifiée ou définie par défaut, la demande de mémoire est remplacée par ce pourcentage de la limite, compris entre 1 et 100. La valeur par défaut est 50.
- 3
- Facultatif. Si une limite de CPU pour le conteneur a été spécifiée ou définie par défaut, la demande de CPU est remplacée par ce pourcentage de la limite, compris entre 1 et 100. La valeur par défaut est 25.
- 4
- Facultatif. Si une limite de mémoire de conteneur a été spécifiée ou définie par défaut, la limite de CPU est remplacée par un pourcentage de la limite de mémoire, si elle est spécifiée. La mise à l'échelle de 1Gi de RAM à 100 % équivaut à 1 cœur de CPU. Cette opération est effectuée avant de passer outre la demande de CPU (si elle est configurée). La valeur par défaut est 200.
Les dérogations de l'opérateur de dérogations des ressources du cluster n'ont aucun effet si des limites n'ont pas été définies pour les conteneurs. Créez un objet LimitRange
avec des limites par défaut pour chaque projet ou configurez des limites dans les spécifications Pod
pour que les dérogations s'appliquent.
Lorsqu'elles sont configurées, les dérogations peuvent être activées par projet en appliquant l'étiquette suivante à l'objet Namespace pour chaque projet :
apiVersion: v1 kind: Namespace metadata: .... labels: clusterresourceoverrides.admission.autoscaling.openshift.io/enabled: "true" ....
L'opérateur guette le CR ClusterResourceOverride
et s'assure que le webhook d'admission ClusterResourceOverride
est installé dans le même espace de noms que l'opérateur.
7.5.2.1. Installation de l'opérateur de remplacement des ressources de cluster à l'aide de la console web
Vous pouvez utiliser la console web d'OpenShift Container Platform pour installer le Cluster Resource Override Operator afin de contrôler l'overcommit dans votre cluster.
Conditions préalables
-
L'opérateur d'annulation des ressources de cluster n'a aucun effet si des limites n'ont pas été définies pour les conteneurs. Vous devez spécifier des limites par défaut pour un projet à l'aide d'un objet
LimitRange
ou configurer des limites dans les spécificationsPod
pour que les surcharges s'appliquent.
Procédure
Pour installer le Cluster Resource Override Operator à l'aide de la console web d'OpenShift Container Platform :
Dans la console web d'OpenShift Container Platform, naviguez vers Home
Projects - Cliquez sur Create Project.
-
Spécifiez
clusterresourceoverride-operator
comme nom du projet. - Cliquez sur Create.
Naviguez jusqu'à Operators
OperatorHub. - Choisissez ClusterResourceOverride Operator dans la liste des opérateurs disponibles et cliquez sur Install.
- Sur la page Install Operator, assurez-vous que A specific Namespace on the cluster est sélectionné pour Installation Mode.
- Assurez-vous que clusterresourceoverride-operator est sélectionné pour Installed Namespace.
- Sélectionnez une adresse Update Channel et Approval Strategy.
- Cliquez sur Install.
Sur la page Installed Operators, cliquez sur ClusterResourceOverride.
- Sur la page de détails ClusterResourceOverride Operator, cliquez sur Create Instance.
Sur la page Create ClusterResourceOverride, modifiez le modèle YAML pour définir les valeurs de surengagement selon les besoins :
apiVersion: operator.autoscaling.openshift.io/v1 kind: ClusterResourceOverride metadata: name: cluster 1 spec: podResourceOverride: spec: memoryRequestToLimitPercent: 50 2 cpuRequestToLimitPercent: 25 3 limitCPUToMemoryPercent: 200 4
- 1
- Le nom doit être
cluster
. - 2
- Facultatif. Indiquez le pourcentage de dépassement de la limite de mémoire du conteneur, s'il est utilisé, entre 1 et 100. La valeur par défaut est 50.
- 3
- Facultatif. Spécifiez le pourcentage de dépassement de la limite de CPU du conteneur, s'il est utilisé, entre 1 et 100. La valeur par défaut est 25.
- 4
- Facultatif. Indiquez le pourcentage qui doit remplacer la limite de mémoire du conteneur, si elle est utilisée. La mise à l'échelle de 1Gi de RAM à 100 % équivaut à 1 cœur de CPU. Ceci est traité avant d'outrepasser la demande de CPU, si elle est configurée. La valeur par défaut est 200.
- Cliquez sur Create.
Vérifier l'état actuel du webhook d'admission en vérifiant l'état de la ressource personnalisée cluster :
- Sur la page ClusterResourceOverride Operator, cliquez sur cluster.
Sur la page ClusterResourceOverride Details, cliquez sur YAML. La section
mutatingWebhookConfigurationRef
s'affiche lorsque le webhook est appelé.apiVersion: operator.autoscaling.openshift.io/v1 kind: ClusterResourceOverride metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"operator.autoscaling.openshift.io/v1","kind":"ClusterResourceOverride","metadata":{"annotations":{},"name":"cluster"},"spec":{"podResourceOverride":{"spec":{"cpuRequestToLimitPercent":25,"limitCPUToMemoryPercent":200,"memoryRequestToLimitPercent":50}}}} creationTimestamp: "2019-12-18T22:35:02Z" generation: 1 name: cluster resourceVersion: "127622" selfLink: /apis/operator.autoscaling.openshift.io/v1/clusterresourceoverrides/cluster uid: 978fc959-1717-4bd1-97d0-ae00ee111e8d spec: podResourceOverride: spec: cpuRequestToLimitPercent: 25 limitCPUToMemoryPercent: 200 memoryRequestToLimitPercent: 50 status: .... mutatingWebhookConfigurationRef: 1 apiVersion: admissionregistration.k8s.io/v1beta1 kind: MutatingWebhookConfiguration name: clusterresourceoverrides.admission.autoscaling.openshift.io resourceVersion: "127621" uid: 98b3b8ae-d5ce-462b-8ab5-a729ea8f38f3 ....
- 1
- Référence au webhook d'admission
ClusterResourceOverride
.
7.5.2.2. Installation de l'opérateur de remplacement des ressources de cluster à l'aide de l'interface de ligne de commande (CLI)
Vous pouvez utiliser le CLI d'OpenShift Container Platform pour installer le Cluster Resource Override Operator afin de contrôler l'overcommit dans votre cluster.
Conditions préalables
-
L'opérateur d'annulation des ressources de cluster n'a aucun effet si des limites n'ont pas été définies pour les conteneurs. Vous devez spécifier des limites par défaut pour un projet à l'aide d'un objet
LimitRange
ou configurer des limites dans les spécificationsPod
pour que les surcharges s'appliquent.
Procédure
Pour installer l'opérateur de remplacement des ressources de cluster à l'aide de l'interface de ligne de commande :
Créez un espace de noms pour l'opérateur de remplacement des ressources de cluster :
Créez un fichier YAML de l'objet
Namespace
(par exemple,cro-namespace.yaml
) pour l'opérateur de remplacement des ressources du cluster :apiVersion: v1 kind: Namespace metadata: name: clusterresourceoverride-operator
Créer l'espace de noms :
oc create -f <nom-de-fichier>.yaml
Par exemple :
$ oc create -f cro-namespace.yaml
Créer un groupe d'opérateurs :
Créez un fichier YAML de l'objet
OperatorGroup
(par exemple, cro-og.yaml) pour l'opérateur de remplacement des ressources de cluster :apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: clusterresourceoverride-operator namespace: clusterresourceoverride-operator spec: targetNamespaces: - clusterresourceoverride-operator
Créer le groupe d'opérateurs :
oc create -f <nom-de-fichier>.yaml
Par exemple :
$ oc create -f cro-og.yaml
Créer un abonnement :
Créez un fichier YAML de l'objet
Subscription
(par exemple, cro-sub.yaml) pour l'opérateur de remplacement des ressources du cluster :apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: clusterresourceoverride namespace: clusterresourceoverride-operator spec: channel: "4.12" name: clusterresourceoverride source: redhat-operators sourceNamespace: openshift-marketplace
Créer l'abonnement :
oc create -f <nom-de-fichier>.yaml
Par exemple :
$ oc create -f cro-sub.yaml
Créer un objet ressource personnalisée (CR)
ClusterResourceOverride
dans l'espace de nomsclusterresourceoverride-operator
:Passage à l'espace de noms
clusterresourceoverride-operator
.$ oc project clusterresourceoverride-operator
Créez un fichier YAML de l'objet
ClusterResourceOverride
(par exemple, cro-cr.yaml) pour l'opérateur de remplacement des ressources de cluster :apiVersion: operator.autoscaling.openshift.io/v1 kind: ClusterResourceOverride metadata: name: cluster 1 spec: podResourceOverride: spec: memoryRequestToLimitPercent: 50 2 cpuRequestToLimitPercent: 25 3 limitCPUToMemoryPercent: 200 4
- 1
- Le nom doit être
cluster
. - 2
- Facultatif. Indiquez le pourcentage de dépassement de la limite de mémoire du conteneur, s'il est utilisé, entre 1 et 100. La valeur par défaut est 50.
- 3
- Facultatif. Spécifiez le pourcentage de dépassement de la limite de CPU du conteneur, s'il est utilisé, entre 1 et 100. La valeur par défaut est 25.
- 4
- Facultatif. Indiquez le pourcentage qui doit remplacer la limite de mémoire du conteneur, si elle est utilisée. La mise à l'échelle de 1Gi de RAM à 100 % équivaut à 1 cœur de CPU. Ceci est traité avant d'outrepasser la demande de CPU, si elle est configurée. La valeur par défaut est 200.
Créer l'objet
ClusterResourceOverride
:oc create -f <nom-de-fichier>.yaml
Par exemple :
$ oc create -f cro-cr.yaml
Vérifiez l'état actuel du webhook d'admission en contrôlant l'état de la ressource personnalisée cluster.
$ oc get clusterresourceoverride cluster -n clusterresourceoverride-operator -o yaml
La section
mutatingWebhookConfigurationRef
s'affiche lorsque le webhook est appelé.Exemple de sortie
apiVersion: operator.autoscaling.openshift.io/v1 kind: ClusterResourceOverride metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"operator.autoscaling.openshift.io/v1","kind":"ClusterResourceOverride","metadata":{"annotations":{},"name":"cluster"},"spec":{"podResourceOverride":{"spec":{"cpuRequestToLimitPercent":25,"limitCPUToMemoryPercent":200,"memoryRequestToLimitPercent":50}}}} creationTimestamp: "2019-12-18T22:35:02Z" generation: 1 name: cluster resourceVersion: "127622" selfLink: /apis/operator.autoscaling.openshift.io/v1/clusterresourceoverrides/cluster uid: 978fc959-1717-4bd1-97d0-ae00ee111e8d spec: podResourceOverride: spec: cpuRequestToLimitPercent: 25 limitCPUToMemoryPercent: 200 memoryRequestToLimitPercent: 50 status: .... mutatingWebhookConfigurationRef: 1 apiVersion: admissionregistration.k8s.io/v1beta1 kind: MutatingWebhookConfiguration name: clusterresourceoverrides.admission.autoscaling.openshift.io resourceVersion: "127621" uid: 98b3b8ae-d5ce-462b-8ab5-a729ea8f38f3 ....
- 1
- Référence au webhook d'admission
ClusterResourceOverride
.
7.5.2.3. Configuration de l'overcommit au niveau du cluster
L'opérateur d'annulation des ressources de cluster a besoin d'une ressource personnalisée (CR) ClusterResourceOverride
et d'un libellé pour chaque projet sur lequel vous souhaitez que l'opérateur contrôle le surengagement.
Conditions préalables
-
L'opérateur d'annulation des ressources de cluster n'a aucun effet si des limites n'ont pas été définies pour les conteneurs. Vous devez spécifier des limites par défaut pour un projet à l'aide d'un objet
LimitRange
ou configurer des limites dans les spécificationsPod
pour que les surcharges s'appliquent.
Procédure
Pour modifier l'overcommit au niveau du cluster :
Modifier le CR
ClusterResourceOverride
:apiVersion: operator.autoscaling.openshift.io/v1 kind: ClusterResourceOverride metadata: name: cluster spec: podResourceOverride: spec: memoryRequestToLimitPercent: 50 1 cpuRequestToLimitPercent: 25 2 limitCPUToMemoryPercent: 200 3
- 1
- Facultatif. Indiquez le pourcentage de dépassement de la limite de mémoire du conteneur, s'il est utilisé, entre 1 et 100. La valeur par défaut est 50.
- 2
- Facultatif. Spécifiez le pourcentage de dépassement de la limite de CPU du conteneur, s'il est utilisé, entre 1 et 100. La valeur par défaut est 25.
- 3
- Facultatif. Indiquez le pourcentage qui doit remplacer la limite de mémoire du conteneur, si elle est utilisée. La mise à l'échelle de 1Gi de RAM à 100 % équivaut à 1 cœur de CPU. Ceci est traité avant d'outrepasser la demande de CPU, si elle est configurée. La valeur par défaut est 200.
Assurez-vous que l'étiquette suivante a été ajoutée à l'objet Namespace pour chaque projet dans lequel vous souhaitez que l'opérateur de remplacement des ressources de cluster contrôle le surengagement :
apiVersion: v1 kind: Namespace metadata: ... labels: clusterresourceoverrides.admission.autoscaling.openshift.io/enabled: "true" 1 ...
- 1
- Ajoutez cette étiquette à chaque projet.
7.5.3. 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.5.3.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.5.3.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.5.3.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.5.3.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.5.3.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 serviceBurstable
etBestEffort
de 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 travailBestEffort
etBurstable
en faveur d'une augmentation des garanties de ressources mémoire pour les charges de travailGuaranteed
etBurstable
. -
Une valeur de
qos-reserved=memory=50%
permet aux classes de qualité de serviceBurstable
etBestEffort
de 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 serviceBurstable
etBestEffort
de consommer la totalité de la quantité allouable au nœud si elle est disponible, mais augmente le risque qu'une charge de travailGuaranteed
n'ait pas accès à la mémoire demandée. Cette condition désactive effectivement cette fonctionnalité.
7.5.3.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.5.3.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.5.3.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
MachineConfigPool
pour 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.5.3.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.5.3.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
7.5.4. Limites au niveau du projet
Pour contrôler l'overcommit, vous pouvez définir des plages de limites de ressources par projet, en spécifiant des limites de mémoire et de CPU et des valeurs par défaut pour un projet que l'overcommit ne peut pas dépasser.
Pour plus d'informations sur les limites de ressources au niveau du projet, voir Ressources supplémentaires.
Vous pouvez également désactiver le surengagement pour des projets spécifiques.
7.5.4.1. Désactiver le surengagement pour un projet
Lorsqu'il est activé, le surengagement peut être désactivé par projet. Par exemple, vous pouvez autoriser la configuration des composants d'infrastructure indépendamment du surengagement.
Procédure
Pour désactiver le surengagement dans un projet :
- Modifier le fichier de l'élément de projet
Ajouter l'annotation suivante :
quota.openshift.io/cluster-resource-override-enabled: "false"
Créer l'élément de projet :
oc create -f <nom-de-fichier>.yaml