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

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

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"

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% /