Chapitre 3. Déployer les charges de travail des conteneurs sandboxés d'OpenShift

OpenShift sandboxed containers permet aux utilisateurs d'exécuter des charges de travail sur leurs clusters OpenShift Container Platform à l'intérieur d'un runtime sandboxed (Kata). Chaque pod est représenté par une machine virtuelle (VM). Chaque VM s'exécute dans un processus QEMU et héberge un processus kata-agent qui agit en tant que superviseur pour gérer les charges de travail des conteneurs et les processus s'exécutant dans ces conteneurs. Deux processus supplémentaires ajoutent des frais généraux :

Chaque VM est configurée avec une quantité de mémoire par défaut. La mémoire supplémentaire est connectée à chaud à la VM pour les conteneurs qui demandent explicitement de la mémoire.

Un conteneur fonctionnant sans ressource mémoire consomme de la mémoire libre jusqu'à ce que la mémoire totale utilisée par la VM atteigne l'allocation par défaut. L'invité et ses tampons d'E/S consomment également de la mémoire.

Si un conteneur se voit attribuer une quantité spécifique de mémoire, cette mémoire est connectée à chaud à la VM avant le démarrage du conteneur.

Lorsqu'une limite de mémoire est spécifiée, la charge de travail est interrompue si elle consomme plus de mémoire que la limite. Si aucune limite de mémoire n'est spécifiée, le noyau s'exécutant sur la VM peut manquer de mémoire. Si le noyau manque de mémoire, il peut mettre fin à d'autres processus sur la VM.

Les tampons de fichiers apparaissent et sont pris en compte à plusieurs endroits :

L'overhead pod décrit la quantité de ressources système utilisée par un pod sur un nœud. Vous pouvez obtenir le pod overhead actuel pour le runtime Kata en utilisant oc describe runtimeclass kata comme indiqué ci-dessous.

oc describe runtimeclass kata

$ oc describe runtimeclass kata

kind: RuntimeClass
apiVersion: node.k8s.io/v1
metadata:
  name: kata
overhead:
  podFixed:
    memory: "500Mi"
    cpu: "500m"

kind: RuntimeClass
apiVersion: node.k8s.io/v1
metadata:
  name: kata
overhead:
  podFixed:
    memory: "500Mi"
    cpu: "500m"

Vous pouvez modifier l'overhead du pod en changeant le champ spec.overhead pour un RuntimeClass. Par exemple, si la configuration que vous exécutez pour vos conteneurs consomme plus de 350Mi de mémoire pour le processus QEMU et les données du noyau invité, vous pouvez modifier l'overhead RuntimeClass pour l'adapter à vos besoins.

Lors de l'exécution de tout type d'E/S du système de fichiers dans l'invité, des tampons de fichiers sont alloués dans le noyau de l'invité. Les tampons de fichiers sont également mappés dans le processus QEMU sur l'hôte, ainsi que dans le processus virtiofsd.

Par exemple, si vous utilisez 300Mi de cache de tampon de fichier dans l'invité, QEMU et virtiofsd semblent utiliser 300Mi de mémoire supplémentaire. Cependant, la même mémoire est utilisée dans les trois cas. En d'autres termes, l'utilisation totale de la mémoire n'est que de 300Mi, mappée à trois endroits différents. Ce fait est correctement pris en compte dans le rapport sur l'utilisation de la mémoire.

Avant d'exécuter des conteneurs OpenShift sandboxed, vous pouvez vérifier si les nœuds de votre cluster sont éligibles pour exécuter des conteneurs Kata. Certains nœuds du cluster peuvent ne pas être conformes aux exigences minimales des conteneurs sandboxed. La raison la plus courante de l'inéligibilité d'un nœud est l'absence de support de virtualisation sur le nœud. Si vous tentez d'exécuter des charges de travail en bac à sable sur des nœuds non éligibles, vous rencontrerez des erreurs. Vous pouvez utiliser l'opérateur NFD (Node Feature Discovery) et une ressource NodeFeatureDiscovery pour vérifier automatiquement l'éligibilité des nœuds.

La procédure suivante applique l'étiquette feature.node.kubernetes.io/runtime.kata=true à tous les nœuds éligibles et configure la ressource KataConfig pour vérifier l'éligibilité des nœuds.