Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

5.3. Configuration des ressources personnalisées liées au MCO

Outre la gestion des objets MachineConfig, le MCO gère deux ressources personnalisées (CR) : KubeletConfig et ContainerRuntimeConfig. Ces CR vous permettent de modifier les paramètres au niveau du nœud ayant un impact sur le comportement des services d'exécution des conteneurs Kubelet et CRI-O.

La configuration du kubelet est actuellement sérialisée comme une configuration Ignition, elle peut donc être directement éditée. Cependant, une nouvelle adresse kubelet-config-controller a été ajoutée au contrôleur de configuration de la machine (MCC). Cela vous permet d'utiliser une ressource personnalisée (CR) KubeletConfig pour modifier les paramètres du kubelet.

Note

Comme les champs de l'objet kubeletConfig sont transmis directement au kubelet par Kubernetes en amont, le kubelet valide ces valeurs directement. Des valeurs non valides dans l'objet kubeletConfig peuvent entraîner l'indisponibilité des nœuds du cluster. Pour connaître les valeurs valides, consultez la documentation de Kubernetes.

Examinez les conseils suivants :

  • Créez un CR KubeletConfig pour chaque pool de configuration de machine avec toutes les modifications de configuration que vous souhaitez pour ce pool. Si vous appliquez le même contenu à tous les pools, vous n'avez besoin que d'un seul CR KubeletConfig pour tous les pools.
  • Modifiez un CR KubeletConfig existant pour modifier les paramètres existants ou en ajouter de nouveaux, au lieu de créer un CR pour chaque changement. Il est recommandé de ne créer un CR que pour modifier un pool de configuration de machine différent, ou pour des changements qui sont censés être temporaires, afin de pouvoir revenir sur les modifications.
  • Si nécessaire, créez plusieurs CR KubeletConfig dans la limite de 10 par cluster. Pour le premier CR KubeletConfig, l'opérateur de configuration de machine (MCO) crée une configuration de machine avec l'extension kubelet. Pour chaque CR suivant, le contrôleur crée une autre configuration machine kubelet avec un suffixe numérique. Par exemple, si vous avez une configuration machine kubelet avec un suffixe -2, la configuration machine kubelet suivante est complétée par -3.

Si vous souhaitez supprimer les configurations de machine, supprimez-les dans l'ordre inverse pour éviter de dépasser la limite. Par exemple, vous supprimez la configuration de la machine kubelet-3 avant de supprimer la configuration de la machine kubelet-2.

Note

Si vous avez une configuration de machine avec un suffixe kubelet-9 et que vous créez une autre CR KubeletConfig, une nouvelle configuration de machine n'est pas créée, même s'il y a moins de 10 configurations de machine kubelet.

Exemple KubeletConfig CR

$ oc get kubeletconfig
 

NAME                AGE
set-max-pods        15m

Exemple de configuration d'une machine KubeletConfig 

$ oc get mc | grep kubelet
 

...
99-worker-generated-kubelet-1                  b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             26m
...

La procédure suivante est un exemple qui montre comment configurer le nombre maximum de pods par nœud sur les nœuds de travail.

Conditions préalables

  1. Obtenez l'étiquette associée au CR statique MachineConfigPool pour le type de nœud que vous souhaitez configurer. Effectuez l'une des opérations suivantes :

    1. Voir le pool de configuration de la machine : 

      oc describe machineconfigpool <name> $ oc describe machineconfigpool <name>

      Par exemple : 

      $ oc describe machineconfigpool worker

      Exemple de sortie

      apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  creationTimestamp: 2019-02-08T14:52:39Z
  generation: 1
  labels:
    custom-kubelet: set-max-pods
      1

      1
      Si un label a été ajouté, il apparaît sous labels.

    2. Si l'étiquette n'est pas présente, ajoutez une paire clé/valeur : 

      $ oc label machineconfigpool worker custom-kubelet=set-max-pods

Procédure

  1. Affichez les objets de configuration de la machine disponibles que vous pouvez sélectionner : 

    $ oc get machineconfig

    Par défaut, les deux configurations liées à kubelet sont 01-master-kubelet et 01-worker-kubelet.

  2. Vérifier la valeur actuelle du nombre maximum de pods par nœud : 

    oc describe node <node_name>

    Par exemple : 

    $ oc describe node ci-ln-5grqprb-f76d1-ncnqq-worker-a-mdv94

    Cherchez value: pods: <value> dans la strophe Allocatable:

    Exemple de sortie

    Allocatable:
 attachable-volumes-aws-ebs:  25
 cpu:                         3500m
 hugepages-1Gi:               0
 hugepages-2Mi:               0
 memory:                      15341844Ki
 pods:                        250

  3. Définissez le nombre maximum de pods par nœud sur les nœuds de travail en créant un fichier de ressources personnalisé qui contient la configuration du kubelet : 

    apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: set-max-pods
spec:
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: set-max-pods
    1 
    
  kubeletConfig:
    maxPods: 500
    2
    1
    Saisissez l'étiquette du pool de configuration de la machine.
    2
    Ajoutez la configuration du kubelet. Dans cet exemple, utilisez maxPods pour définir le nombre maximum de pods par nœud.
    Note

    Le taux auquel le kubelet parle au serveur API dépend des requêtes par seconde (QPS) et des valeurs de rafale. Les valeurs par défaut, 50 pour kubeAPIQPS et 100 pour kubeAPIBurst, sont suffisantes si le nombre de pods fonctionnant sur chaque nœud est limité. Il est recommandé de mettre à jour les taux de QPS et de burst du kubelet s'il y a suffisamment de ressources de CPU et de mémoire sur le nœud. 

    apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: set-max-pods
spec:
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: set-max-pods
  kubeletConfig:
    maxPods: <pod_count>
    kubeAPIBurst: <burst_rate>
    kubeAPIQPS: <QPS>

    1. Mettre à jour le pool de configuration des machines pour les travailleurs avec le label : 

      $ oc label machineconfigpool worker custom-kubelet=set-max-pods

    2. Créer l'objet KubeletConfig: 

      $ oc create -f change-maxPods-cr.yaml

    3. Vérifiez que l'objet KubeletConfig est créé : 

      $ oc get kubeletconfig

      Exemple de sortie

      NAME                AGE
set-max-pods        15m

      En fonction du nombre de nœuds de travail dans la grappe, attendez que les nœuds de travail soient redémarrés un par un. Pour une grappe de 3 nœuds de travail, cela peut prendre de 10 à 15 minutes.

  4. Vérifiez que les modifications sont appliquées au nœud :

    1. Vérifier sur un nœud de travail que la valeur de maxPods a changé : 

      oc describe node <node_name>

    2. Repérez la strophe Allocatable: 

       ...
Allocatable:
  attachable-volumes-gce-pd:  127
  cpu:                        3500m
  ephemeral-storage:          123201474766
  hugepages-1Gi:              0
  hugepages-2Mi:              0
  memory:                     14225400Ki
  pods:                       500
      1 
      
 ...
      1
      Dans cet exemple, le paramètre pods doit indiquer la valeur que vous avez définie dans l'objet KubeletConfig.

  5. Vérifiez la modification de l'objet KubeletConfig: 

    $ oc get kubeletconfigs set-max-pods -o yaml

    L'état de True et type:Success devrait apparaître, comme le montre l'exemple suivant : 

    spec:
  kubeletConfig:
    maxPods: 500
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: set-max-pods
status:
  conditions:
  - lastTransitionTime: "2021-06-30T17:04:07Z"
    message: Success
    status: "True"
    type: Success

Vous pouvez modifier certains paramètres associés au runtime CRI-O d'OpenShift Container Platform pour les nœuds associés à un pool de configuration machine (MCP) spécifique. En utilisant une ressource personnalisée (CR) ContainerRuntimeConfig, vous définissez les valeurs de configuration et ajoutez un label correspondant au MCP. Le MCO reconstruit ensuite les fichiers de configuration crio.conf et storage.conf sur les nœuds associés avec les valeurs mises à jour.

Note

Pour annuler les modifications apportées par l'utilisation d'un CR ContainerRuntimeConfig, vous devez supprimer le CR. La suppression de l'étiquette du pool de configuration de la machine n'annule pas les modifications.

Vous pouvez modifier les paramètres suivants à l'aide d'un CR ContainerRuntimeConfig:

  • PIDs limit: La définition de la limite des PIDs sur le site ContainerRuntimeConfig devrait être obsolète. Si des limites de PIDs sont nécessaires, il est recommandé d'utiliser le champ podPidsLimit dans le CR KubeletConfig. La valeur par défaut du champ podPidsLimit est 4096.

    Note

    Le drapeau CRI-O est appliqué sur le cgroup du conteneur, tandis que le drapeau Kubelet est défini sur le cgroup du pod. Veuillez ajuster la limite des PIDs en conséquence.

  • Log level: Le paramètre logLevel définit le paramètre CRI-O log_level, qui est le niveau de verbosité des messages de journalisation. La valeur par défaut est info (log_level = info). Les autres options sont fatal, panic, error, warn, debug et trace.
  • Overlay size: Le paramètre overlaySize définit le paramètre du pilote de stockage de CRI-O Overlay size, qui est la taille maximale d'une image de conteneur.
  • Maximum log size: La définition de la taille maximale du journal dans le champ ContainerRuntimeConfig devrait être obsolète. Si une taille maximale de journal est requise, il est recommandé d'utiliser le champ containerLogMaxSize dans le CR KubeletConfig.
  • Container runtime: Le paramètre defaultRuntime définit la durée d'exécution du conteneur sur runc ou crun. La valeur par défaut est runc.
Important

La prise en charge du moteur d'exécution de conteneur crun est une fonctionnalité d'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Red Hat ne recommande pas leur utilisation en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

Vous devez avoir un CR ContainerRuntimeConfig pour chaque pool de configuration de machine avec toutes les modifications de configuration que vous souhaitez pour ce pool. Si vous appliquez le même contenu à tous les pools, vous n'avez besoin que d'un seul CR ContainerRuntimeConfig pour tous les pools.

Vous devez éditer un CR ContainerRuntimeConfig existant pour modifier les paramètres existants ou en ajouter de nouveaux au lieu de créer un nouveau CR pour chaque changement. Il est recommandé de créer un nouveau CR ContainerRuntimeConfig uniquement pour modifier un pool de configuration machine différent, ou pour des changements qui sont censés être temporaires afin que vous puissiez revenir sur les modifications.

Vous pouvez créer plusieurs ContainerRuntimeConfig CR, selon vos besoins, dans la limite de 10 par cluster. Pour le premier CR ContainerRuntimeConfig, le MCO crée une configuration de machine avec l'extension containerruntime. Pour chaque CR suivant, le contrôleur crée une nouvelle configuration machine containerruntime avec un suffixe numérique. Par exemple, si vous avez une configuration de machine containerruntime avec un suffixe -2, la prochaine configuration de machine containerruntime est complétée par -3.

Si vous souhaitez supprimer les configurations de machine, vous devez les supprimer dans l'ordre inverse pour éviter de dépasser la limite. Par exemple, vous devez supprimer la configuration de la machine containerruntime-3 avant de supprimer la configuration de la machine containerruntime-2.

Note

Si vous avez une configuration de machine avec un suffixe containerruntime-9 et que vous créez une autre CR ContainerRuntimeConfig, une nouvelle configuration de machine n'est pas créée, même s'il y a moins de 10 configurations de machine containerruntime.

Exemple montrant plusieurs CR ContainerRuntimeConfig 

$ oc get ctrcfg

Exemple de sortie

NAME         AGE
ctr-pid      24m
ctr-overlay  15m
ctr-level    5m45s

Exemple de configuration de plusieurs machines containerruntime 

$ oc get mc | grep container

Exemple de sortie

...
01-master-container-runtime                        b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             57m
...
01-worker-container-runtime                        b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             57m
...
99-worker-generated-containerruntime               b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             26m
99-worker-generated-containerruntime-1             b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             17m
99-worker-generated-containerruntime-2             b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             7m26s
...

L'exemple suivant augmente la valeur de pids_limit à 2048, définit la valeur de log_level à debug, définit la taille de la superposition à 8 Go et définit la valeur de log_size_max à illimité :

Exemple ContainerRuntimeConfig CR

apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
 name: overlay-size
spec:
 machineConfigPoolSelector:
   matchLabels:
     pools.operator.machineconfiguration.openshift.io/worker: ''
1 

 containerRuntimeConfig:
   pidsLimit: 2048
2 

   logLevel: debug
3 

   overlaySize: 8G
4 

   logSizeMax: "-1"
5 

   defaultRuntime: "crun"
6

1
Spécifie l'étiquette du pool de configuration de la machine.
2
Facultatif : Spécifie le nombre maximum de processus autorisés dans un conteneur.
3
Facultatif : Spécifie le niveau de verbosité des messages du journal.
4
Facultatif : Spécifie la taille maximale d'une image de conteneur.
5
Facultatif : Spécifie la taille maximale autorisée pour le fichier journal du conteneur. S'il s'agit d'un nombre positif, il doit être au moins égal à 8192.
6
Facultatif : Spécifie l'exécution du conteneur à déployer dans les nouveaux conteneurs. La valeur par défaut est runc.

Prérequis

  • Pour activer crun, vous devez activer le jeu de fonctionnalités TechPreviewNoUpgrade.

    Note

    L'activation de l'ensemble de fonctionnalités TechPreviewNoUpgrade ne peut être annulée et empêche les mises à jour mineures de la version. Ces jeux de fonctionnalités ne sont pas recommandés sur les clusters de production.

Procédure

Pour modifier les paramètres CRI-O à l'aide de ContainerRuntimeConfig CR :

  1. Créer un fichier YAML pour le CR ContainerRuntimeConfig: 

    apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
 name: overlay-size
spec:
 machineConfigPoolSelector:
   matchLabels:
     pools.operator.machineconfiguration.openshift.io/worker: ''
    1 
    
 containerRuntimeConfig:
    2 
    
   pidsLimit: 2048
   logLevel: debug
   overlaySize: 8G
   logSizeMax: "-1"
    1
    Spécifiez une étiquette pour le pool de configuration de la machine que vous souhaitez modifier.
    2
    Réglez les paramètres selon vos besoins.

  2. Créer le CR ContainerRuntimeConfig: 

    oc create -f <nom_du_fichier>.yaml

  3. Vérifiez que la CR est créée : 

    $ oc get ContainerRuntimeConfig

    Exemple de sortie

    NAME           AGE
overlay-size   3m19s

  4. Vérifier qu'une nouvelle configuration de la machine containerruntime est créée : 

    $ oc get machineconfigs | grep containerrun

    Exemple de sortie

    99-worker-generated-containerruntime   2c9371fbb673b97a6fe8b1c52691999ed3a1bfc2  3.2.0  31s

  5. Surveillez le pool de configuration des machines jusqu'à ce qu'elles soient toutes prêtes : 

    $ oc get mcp worker

    Exemple de sortie

    NAME    CONFIG               UPDATED  UPDATING  DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT  DEGRADEDMACHINECOUNT  AGE
worker  rendered-worker-169  False    True      False     3             1                  1                    0                     9h

  6. Vérifier que les réglages ont été appliqués en CRI-O :

    1. Ouvrez une session oc debug sur un nœud du pool de configuration de la machine et exécutez chroot /host. 

      oc debug node/<node_name>
       
      sh-4.4# chroot /host

    2. Vérifiez les changements dans le fichier crio.conf: 

      sh-4.4# crio config | egrep 'log_level|pids_limit|log_size_max'

      Exemple de sortie

      pids_limit = 2048
log_size_max = -1
log_level = "debug"

    3. Vérifiez les changements dans le fichier `storage.conf` : 

      sh-4.4# head -n 7 /etc/containers/storage.conf

      Exemple de sortie

      [storage]
  driver = "overlay"
  runroot = "/var/run/containers/storage"
  graphroot = "/var/lib/containers/storage"
  [storage.options]
    additionalimagestores = []
    size = "8G"

La partition racine de chaque conteneur affiche tout l'espace disque disponible de l'hôte sous-jacent. Suivez ces instructions pour définir une taille de partition maximale pour le disque racine de tous les conteneurs.

Pour configurer la taille maximale de la superposition, ainsi que d'autres options de CRI-O telles que le niveau de journalisation et la limite de PID, vous pouvez créer la définition de ressource personnalisée (CRD) suivante : ContainerRuntimeConfig: 

apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
 name: overlay-size
spec:
 machineConfigPoolSelector:
   matchLabels:
     custom-crio: overlay-size
 containerRuntimeConfig:
   pidsLimit: 2048
   logLevel: debug
   overlaySize: 8G

Procédure

  1. Créer l'objet de configuration : 

    $ oc apply -f overlaysize.yml

  2. Pour appliquer la nouvelle configuration CRI-O à vos nœuds de travail, modifiez le pool de configuration de la machine de travail : 

    $ oc edit machineconfigpool worker

  3. Ajoutez l'étiquette custom-crio en fonction du nom matchLabels que vous avez défini dans le CRD ContainerRuntimeConfig: 

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  creationTimestamp: "2020-07-09T15:46:34Z"
  generation: 3
  labels:
    custom-crio: overlay-size
    machineconfiguration.openshift.io/mco-built-in: ""

  4. Enregistrez les modifications, puis affichez les configurations de la machine : 

    $ oc get machineconfigs

    De nouveaux objets 99-worker-generated-containerruntime et rendered-worker-xyz sont créés :

    Exemple de sortie

    99-worker-generated-containerruntime  4173030d89fbf4a7a0976d1665491a4d9a6e54f1   3.2.0             7m42s
rendered-worker-xyz                   4173030d89fbf4a7a0976d1665491a4d9a6e54f1   3.2.0             7m36s

  5. Une fois ces objets créés, surveillez le pool de configuration de la machine pour que les modifications soient appliquées : 

    $ oc get mcp worker

    Les nœuds ouvriers affichent UPDATING sous la forme True, ainsi que le nombre de machines, le nombre de mises à jour et d'autres détails :

    Exemple de sortie

    NAME   CONFIG              UPDATED   UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
worker rendered-worker-xyz False True False     3             2                   2                    0                      20h

    Une fois l'opération terminée, les nœuds de travail reviennent à UPDATING en tant que False, et le numéro de UPDATEDMACHINECOUNT correspond à celui de MACHINECOUNT:

    Exemple de sortie

    NAME   CONFIG              UPDATED   UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
worker   rendered-worker-xyz   True      False      False      3         3            3             0           20h

    En examinant une machine de travail, vous constatez que la nouvelle configuration de taille maximale de 8 Go est appliquée à toutes les machines de travail :

    Exemple de sortie

    head -n 7 /etc/containers/storage.conf
[storage]
  driver = "overlay"
  runroot = "/var/run/containers/storage"
  graphroot = "/var/lib/containers/storage"
  [storage.options]
    additionalimagestores = []
    size = "8G"

    En regardant à l'intérieur d'un conteneur, vous constatez que la partition racine est maintenant de 8 Go :

    Exemple de sortie

    ~ $ df -h
Filesystem                Size      Used Available Use% Mounted on
overlay                   8.0G      8.0K      8.0G   0% /

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. Découvrez nos récentes mises à jour.

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 le Blog 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.

Theme

© 2026 Red HatRetour au début