7.4. Configuration de la mémoire des clusters pour répondre aux exigences en matière de mémoire des conteneurs et de risque

1. Surcharge de la taille maximale du tas de la JVM.
2. Encourager la JVM à libérer la mémoire inutilisée au profit du système d'exploitation, le cas échéant.
3. S'assurer que tous les processus JVM au sein d'un conteneur sont correctement configurés.

Procédure

1. Configurez le pod pour ajouter les strophes MEMORY_REQUEST et MEMORY_LIMIT:

   apiVersion: v1
   kind: Pod
   metadata:
     name: test
   spec:
     containers:
     - name: test
       image: fedora:latest
       command:
       - sleep
       - "3600"
       env:
       - name: MEMORY_REQUEST 1
         valueFrom:
           resourceFieldRef:
             containerName: test
             resource: requests.memory
       - name: MEMORY_LIMIT 2
         valueFrom:
           resourceFieldRef:
             containerName: test
             resource: limits.memory
       resources:
         requests:
           memory: 384Mi
         limits:
           memory: 512Mi

   1

   Ajoutez ce paragraphe pour découvrir la valeur de la demande de mémoire de l'application.

   2

   Ajoutez cette strophe pour découvrir la valeur de la limite de mémoire de l'application.

2. Créer la capsule :

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

3. Accéder au pod à l'aide d'un shell distant :

   $ oc rsh test

4. Vérifier que les valeurs demandées ont été appliquées :

   $ env | grep MEMORY | sort

   Exemple de sortie

   MEMORY_LIMIT=536870912
   MEMORY_REQUEST=402653184

1. Accéder au pod à l'aide d'un shell distant :

   # oc rsh test

2. Exécutez la commande suivante pour voir le nombre actuel de morts OOM dans /sys/fs/cgroup/memory/memory.oom_control:

   $ grep '^oom_kill ' /sys/fs/cgroup/memory/memory.oom_control
   oom_kill 0

3. Exécutez la commande suivante pour provoquer une mise à mort OOM :

   $ sed -e '' </dev/zero

   Exemple de sortie

   Killed

4. Exécutez la commande suivante pour afficher l'état de sortie de la commande sed:

   $ echo $?

   Exemple de sortie

   137

   Le code 137 indique que le processus du conteneur s'est arrêté avec le code 137, indiquant qu'il a reçu un signal SIGKILL.

5. Exécutez la commande suivante pour vérifier que le compteur de mises à mort OOM de /sys/fs/cgroup/memory/memory.oom_control s'est incrémenté :

   $ grep '^oom_kill ' /sys/fs/cgroup/memory/memory.oom_control
   oom_kill 1

   Si un ou plusieurs processus d'un module sont tués par OOM, lorsque le module se termine par la suite, immédiatement ou non, il aura la phase Failed et la raison OOMKilled. Un module tué par OOM peut être redémarré en fonction de la valeur de restartPolicy. S'il n'est pas redémarré, les contrôleurs tels que le contrôleur de réplication remarqueront l'état d'échec du module et créeront un nouveau module pour remplacer l'ancien.

   Utilisez la commande suivante pour obtenir l'état du pod :

   $ oc get pod test

   Exemple de sortie

   NAME      READY     STATUS      RESTARTS   AGE
   test      0/1       OOMKilled   0          1m

   • Si le module n'a pas redémarré, exécutez la commande suivante pour visualiser le module :

     $ oc get pod test -o yaml

     Exemple de sortie

     ...
     status:
       containerStatuses:
       - name: test
         ready: false
         restartCount: 0
         state:
           terminated:
             exitCode: 137
             reason: OOMKilled
       phase: Failed

   • En cas de redémarrage, exécutez la commande suivante pour afficher le pod :

     $ oc get pod test -o yaml

     Exemple de sortie

     ...
     status:
       containerStatuses:
       - name: test
         ready: true
         restartCount: 1
         lastState:
           terminated:
             exitCode: 137
             reason: OOMKilled
         state:
           running:
       phase: Running