Chapitre 6. Travailler avec des conteneurs
6.1. Comprendre les conteneurs
Les unités de base des applications OpenShift Container Platform sont appelées containers. Les technologies de conteneurs Linux sont des mécanismes légers permettant d'isoler les processus en cours d'exécution afin qu'ils ne puissent interagir qu'avec les ressources qui leur sont attribuées.
De nombreuses instances d'applications peuvent être exécutées dans des conteneurs sur un seul hôte, sans visibilité sur les processus, les fichiers, le réseau, etc. des autres. En règle générale, chaque conteneur fournit un seul service (souvent appelé "micro-service"), tel qu'un serveur web ou une base de données, bien que les conteneurs puissent être utilisés pour des charges de travail arbitraires.
Le noyau Linux intègre depuis des années des fonctionnalités pour les technologies de conteneurs. OpenShift Container Platform et Kubernetes ajoutent la possibilité d'orchestrer des conteneurs sur des installations multi-hôtes.
6.1.1. A propos des conteneurs et de la mémoire du noyau RHEL
En raison du comportement de Red Hat Enterprise Linux (RHEL), un conteneur sur un nœud avec une utilisation élevée du CPU peut sembler consommer plus de mémoire que prévu. La consommation de mémoire plus élevée peut être causée par kmem_cache dans le noyau RHEL. Le noyau RHEL crée un site kmem_cache pour chaque cgroup. Pour plus de performances, le site kmem_cache contient un site cpu_cache et un cache de nœud pour tous les nœuds NUMA. Ces caches consomment tous de la mémoire du noyau.
La quantité de mémoire stockée dans ces caches est proportionnelle au nombre de CPU que le système utilise. Par conséquent, un nombre plus élevé de CPU se traduit par une plus grande quantité de mémoire du noyau conservée dans ces caches. Des quantités plus importantes de mémoire du noyau dans ces caches peuvent amener les conteneurs OpenShift Container Platform à dépasser les limites de mémoire configurées, ce qui entraîne la destruction du conteneur.
Pour éviter de perdre des conteneurs en raison de problèmes de mémoire du noyau, assurez-vous que les conteneurs demandent suffisamment de mémoire. Vous pouvez utiliser la formule suivante pour estimer la quantité de mémoire consommée par la commande kmem_cache, où nproc est le nombre d'unités de traitement disponibles indiqué par la commande nproc. La limite inférieure des demandes de conteneurs doit correspondre à cette valeur plus les besoins en mémoire des conteneurs :
$(nproc) X 1/2 MiB
6.1.2. À propos du moteur de conteneurs et de l'exécution des conteneurs
Un container engine est un logiciel qui traite les demandes des utilisateurs, y compris les options de la ligne de commande et les extractions d'images. Le moteur de conteneurs utilise un container runtime, également appelé lower-level container runtime, pour exécuter et gérer les composants nécessaires au déploiement et au fonctionnement des conteneurs. Vous n'aurez probablement pas besoin d'interagir avec le moteur de conteneur ou le runtime de conteneur.
La documentation d'OpenShift Container Platform utilise le terme container runtime pour se référer à l'exécution de conteneur de niveau inférieur. D'autres documentations peuvent faire référence au moteur de conteneurs en tant que runtime de conteneurs.
OpenShift Container Platform utilise CRI-O comme moteur de conteneur et runC ou crun comme runtime de conteneur. L'exécution de conteneur par défaut est runC. Les deux moteurs d'exécution de conteneurs respectent les spécifications de l'Open Container Initiative (OCI ) en matière de moteurs d'exécution.
CRI-O est une implémentation de moteur de conteneur natif de Kubernetes qui s'intègre étroitement avec le système d'exploitation pour fournir une expérience Kubernetes efficace et optimisée. Le moteur de conteneurs CRI-O s'exécute en tant que service systemd sur chaque nœud de cluster OpenShift Container Platform.
runC, développé par Docker et maintenu par l'Open Container Project, est un runtime de conteneur léger et portable écrit en Go. crun, développé par Red Hat, est un runtime de conteneur rapide et à faible mémoire entièrement écrit en C. Depuis OpenShift Container Platform 4.12, vous pouvez choisir entre les deux.
la prise en charge de l'exécution des conteneurs 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 de les utiliser 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.
crun présente plusieurs améliorations par rapport à runC, notamment
- Binaire de petite taille
- Traitement plus rapide
- Une empreinte mémoire plus faible
runC présente certains avantages par rapport à crun, notamment
- Le système d'exécution de conteneurs OCI le plus populaire.
- Une plus grande ancienneté dans la production.
- Durée d'exécution du conteneur par défaut de CRI-O.
Vous pouvez passer d'un conteneur à l'autre si nécessaire.
Pour plus d'informations sur la définition de la durée d'exécution du conteneur à utiliser, voir Création d'un CR ContainerRuntimeConfig pour modifier les paramètres CRI-O.
