SupportConsoleDéveloppeursCommencer un essaiContact

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é.

Note

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.
Note

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écifications Pod 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 :

  1. Dans la console web d'OpenShift Container Platform, naviguez vers Home Projects

    1. Cliquez sur Create Project.
    2. Spécifiez clusterresourceoverride-operator comme nom du projet.
    3. Cliquez sur Create.

  2. Naviguez jusqu'à Operators OperatorHub.

    1. Choisissez ClusterResourceOverride Operator dans la liste des opérateurs disponibles et cliquez sur Install.
    2. Sur la page Install Operator, assurez-vous que A specific Namespace on the cluster est sélectionné pour Installation Mode.
    3. Assurez-vous que clusterresourceoverride-operator est sélectionné pour Installed Namespace.
    4. Sélectionnez une adresse Update Channel et Approval Strategy.
    5. Cliquez sur Install.

  3. Sur la page Installed Operators, cliquez sur ClusterResourceOverride.

    1. Sur la page de détails ClusterResourceOverride Operator, cliquez sur Create Instance.

    2. 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.
    3. Cliquez sur Create.

  4. Vérifier l'état actuel du webhook d'admission en vérifiant l'état de la ressource personnalisée cluster :

    1. Sur la page ClusterResourceOverride Operator, cliquez sur cluster.

    2. 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écifications Pod 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 :

  1. Créez un espace de noms pour l'opérateur de remplacement des ressources de cluster :

    1. 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

    2. Créer l'espace de noms : 

      oc create -f <nom-de-fichier>.yaml

      Par exemple : 

      $ oc create -f cro-namespace.yaml

  2. Créer un groupe d'opérateurs :

    1. 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

    2. Créer le groupe d'opérateurs : 

      oc create -f <nom-de-fichier>.yaml

      Par exemple : 

      $ oc create -f cro-og.yaml

  3. Créer un abonnement :

    1. 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

    2. Créer l'abonnement : 

      oc create -f <nom-de-fichier>.yaml

      Par exemple : 

      $ oc create -f cro-sub.yaml

  4. Créer un objet ressource personnalisée (CR) ClusterResourceOverride dans l'espace de noms clusterresourceoverride-operator:

    1. Passage à l'espace de noms clusterresourceoverride-operator. 

      $ oc project clusterresourceoverride-operator

    2. 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.

    3. Créer l'objet ClusterResourceOverride: 

      oc create -f <nom-de-fichier>.yaml

      Par exemple : 

      $ oc create -f cro-cr.yaml

  5. 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écifications Pod pour que les surcharges s'appliquent.

Procédure

Pour modifier l'overcommit au niveau du cluster :

  1. 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.

  2. 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 :

Tableau 7.19. Classes de qualité de service
PrioritéNom de la classeDescription

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 service Burstable et BestEffort 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 travail BestEffort et Burstable en faveur d'une augmentation des garanties de ressources mémoire pour les charges de travail Guaranteed et Burstable.
  • Une valeur de qos-reserved=memory=50% permet aux classes de qualité de service Burstable et BestEffort 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 service Burstable et BestEffort de consommer la totalité de la quantité allouable au nœud si elle est disponible, mais augmente le risque qu'une charge de travail Guaranteed 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).

Important

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

Note

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

  1. 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.
    Astuce

    Si 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

  1. 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"

    1
    Attribuer un nom au CR.
    2
    Spécifiez l'étiquette du pool de configuration de la machine.
    3
    Réglez le paramètre cpuCfsQuota sur true.

  2. 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 :

  1. Modifier le fichier de l'élément de projet

  2. Ajouter l'annotation suivante : 

    quota.openshift.io/cluster-resource-override-enabled: "false"

  3. Créer l'élément de projet : 

    oc create -f <nom-de-fichier>.yaml

7.5.5. Ressources supplémentaires

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.