7.4. Pratiques recommandées pour les hôtes de nœuds

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

Procédure

1. Modifiez le pool de configuration de la machine worker:

   $ oc edit machineconfigpool worker

2. Ajoutez le champ maxUnavailable et définissez sa valeur :

   spec:
     maxUnavailable: <node_count>

   Important

   Lors de la définition de cette valeur, il faut tenir compte du nombre de nœuds de travail qui peuvent être indisponibles sans affecter les applications fonctionnant sur le cluster.

Procédure

1. Facultatif : Étiqueter un nœud :

   # oc label node perf-node.example.com cpumanager=true

2. Modifiez le site MachineConfigPool des nœuds pour lesquels le gestionnaire de CPU doit être activé. Dans cet exemple, tous les travailleurs ont activé le gestionnaire de CPU :

   # oc edit machineconfigpool worker

3. Ajouter une étiquette au pool de configuration de la machine de travail :

   metadata:
     creationTimestamp: 2020-xx-xxx
     generation: 3
     labels:
       custom-kubelet: cpumanager-enabled

4. Créez une ressource personnalisée (CR) KubeletConfig, cpumanager-kubeletconfig.yaml. Référez-vous à l'étiquette créée à l'étape précédente pour que les nœuds corrects soient mis à jour avec la nouvelle configuration du kubelet. Voir la section machineConfigPoolSelector:

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: cpumanager-enabled
   spec:
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: cpumanager-enabled
     kubeletConfig:
        cpuManagerPolicy: static 1
        cpuManagerReconcilePeriod: 5s 2

   1

   Spécifier une politique :

   • none. Cette politique active explicitement le schéma d'affinité CPU par défaut existant, ne fournissant aucune affinité au-delà de ce que le planificateur fait automatiquement. Il s'agit de la stratégie par défaut.
   • static. Cette politique autorise les conteneurs dans les pods garantis avec des demandes de CPU entières. Elle limite également l'accès aux CPU exclusifs sur le nœud. Si static, vous devez utiliser une minuscule s.

   2

   Facultatif. Indiquez la fréquence de rapprochement du gestionnaire de CPU. La valeur par défaut est 5s.

5. Créer la configuration dynamique du kubelet :

   # oc create -f cpumanager-kubeletconfig.yaml

   Cela ajoute la fonction CPU Manager à la configuration du kubelet et, si nécessaire, le Machine Config Operator (MCO) redémarre le nœud. Pour activer le gestionnaire de CPU, un redémarrage n'est pas nécessaire.

6. Vérifier la configuration du kubelet fusionné :

   # oc get machineconfig 99-worker-XXXXXX-XXXXX-XXXX-XXXXX-kubelet -o json | grep ownerReference -A7

   Exemple de sortie

          "ownerReferences": [
               {
                   "apiVersion": "machineconfiguration.openshift.io/v1",
                   "kind": "KubeletConfig",
                   "name": "cpumanager-enabled",
                   "uid": "7ed5616d-6b72-11e9-aae1-021e1ce18878"
               }
           ]

7. Consultez le travailleur pour obtenir la mise à jour de kubelet.conf:

   # oc debug node/perf-node.example.com
   sh-4.2# cat /host/etc/kubernetes/kubelet.conf | grep cpuManager

   Exemple de sortie

   cpuManagerPolicy: static        1
   cpuManagerReconcilePeriod: 5s   2

   1

   cpuManagerPolicy est défini lorsque vous créez le CR KubeletConfig.

   2

   cpuManagerReconcilePeriod est défini lorsque vous créez le CR KubeletConfig.

8. Créer un pod qui demande un ou plusieurs cœurs. Les limites et les demandes doivent avoir une valeur CPU égale à un entier. Il s'agit du nombre de cœurs qui seront dédiés à ce module :

   # cat cpumanager-pod.yaml

   Exemple de sortie

   apiVersion: v1
   kind: Pod
   metadata:
     generateName: cpumanager-
   spec:
     containers:
     - name: cpumanager
       image: gcr.io/google_containers/pause-amd64:3.0
       resources:
         requests:
           cpu: 1
           memory: "1G"
         limits:
           cpu: 1
           memory: "1G"
     nodeSelector:
       cpumanager: "true"

9. Créer la capsule :

   # oc create -f cpumanager-pod.yaml

10. Vérifiez que le pod est planifié sur le nœud que vous avez étiqueté :

    # oc describe pod cpumanager

    Exemple de sortie

    Name:               cpumanager-6cqz7
    Namespace:          default
    Priority:           0
    PriorityClassName:  <none>
    Node:  perf-node.example.com/xxx.xx.xx.xxx
    ...
     Limits:
          cpu:     1
          memory:  1G
        Requests:
          cpu:        1
          memory:     1G
    ...
    QoS Class:       Guaranteed
    Node-Selectors:  cpumanager=true

11. Vérifiez que l'adresse cgroups est correctement configurée. Obtenir l'ID du processus (PID) du processus pause:

    # ├─init.scope
    │ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 17
    └─kubepods.slice
      ├─kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice
      │ ├─crio-b5437308f1a574c542bdf08563b865c0345c8f8c0b0a655612c.scope
      │ └─32706 /pause

    Les pods du niveau de qualité de service (QoS) Guaranteed sont placés à l'intérieur du site kubepods.slice. Les pods des autres niveaux de QoS se retrouvent dans les enfants cgroups de kubepods:

    # cd /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice/crio-b5437308f1ad1a7db0574c542bdf08563b865c0345c86e9585f8c0b0a655612c.scope
    # for i in `ls cpuset.cpus tasks` ; do echo -n "$i "; cat $i ; done

    Exemple de sortie

    cpuset.cpus 1
    tasks 32706

12. Vérifiez la liste des unités centrales autorisées pour la tâche :

    # grep ^Cpus_allowed_list /proc/32706/status

    Exemple de sortie

     Cpus_allowed_list:    1

13. Vérifiez qu'un autre pod (dans ce cas, le pod du niveau de qualité de service burstable ) sur le système ne peut pas fonctionner sur le cœur alloué au pod Guaranteed:

    # cat /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-podc494a073_6b77_11e9_98c0_06bba5c387ea.slice/crio-c56982f57b75a2420947f0afc6cafe7534c5734efc34157525fa9abbf99e3849.scope/cpuset.cpus
    0
    # oc describe node perf-node.example.com

    Exemple de sortie

    ...
    Capacity:
     attachable-volumes-aws-ebs:  39
     cpu:                         2
     ephemeral-storage:           124768236Ki
     hugepages-1Gi:               0
     hugepages-2Mi:               0
     memory:                      8162900Ki
     pods:                        250
    Allocatable:
     attachable-volumes-aws-ebs:  39
     cpu:                         1500m
     ephemeral-storage:           124768236Ki
     hugepages-1Gi:               0
     hugepages-2Mi:               0
     memory:                      7548500Ki
     pods:                        250
    -------                               ----                           ------------  ----------  ---------------  -------------  ---
      default                                 cpumanager-6cqz7               1 (66%)       1 (66%)     1G (12%)         1G (12%)       29m
    
    Allocated resources:
      (Total limits may be over 100 percent, i.e., overcommitted.)
      Resource                    Requests          Limits
      --------                    --------          ------
      cpu                         1440m (96%)       1 (66%)

    Cette VM dispose de deux cœurs de processeur. Le paramètre system-reserved réserve 500 millicores, ce qui signifie que la moitié d'un cœur est soustraite de la capacité totale du nœud pour obtenir la quantité Node Allocatable. Vous pouvez voir que Allocatable CPU est de 1500 millicores. Cela signifie que vous pouvez exécuter l'un des pods du gestionnaire de CPU, puisque chacun d'entre eux prendra un cœur entier. Un cœur entier est équivalent à 1000 millicores. Si vous essayez de planifier un deuxième module, le système acceptera le module, mais il ne sera jamais planifié :

    NAME                    READY   STATUS    RESTARTS   AGE
    cpumanager-6cqz7        1/1     Running   0          33m
    cpumanager-7qc2t        0/1     Pending   0          11s