Chapitre 11. Optimisation de l'utilisation de l'unité centrale avec l'encapsulation de l'espace de noms de montage
Vous pouvez optimiser l'utilisation du CPU dans les clusters OpenShift Container Platform en utilisant l'encapsulation mount namespace pour fournir un espace de noms privé pour les processus kubelet et CRI-O. Cela réduit les ressources CPU du cluster utilisées par systemd sans différence de fonctionnalité.
L'encapsulation de l'espace de noms de montage 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 d'un point de vue 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.
11.1. Encapsulation des espaces de noms des montages
Les espaces de noms de montage sont utilisés pour isoler les points de montage afin que les processus dans différents espaces de noms ne puissent pas voir les fichiers des autres. L'encapsulation est le processus qui consiste à déplacer les espaces de noms de montage Kubernetes vers un autre emplacement où ils ne seront pas constamment analysés par le système d'exploitation hôte.
Le système d'exploitation hôte utilise systemd pour analyser en permanence tous les espaces de noms de montage : à la fois les montages Linux standard et les nombreux montages que Kubernetes utilise pour fonctionner. L'implémentation actuelle de kubelet et de CRI-O utilise l'espace de noms de premier niveau pour tous les points de montage de l'exécution du conteneur et de kubelet. Cependant, l'encapsulation de ces points de montage spécifiques aux conteneurs dans un espace de noms privé réduit la charge de travail de systemd sans différence de fonctionnalité. L'utilisation d'un espace de noms de montage distinct pour CRI-O et kubelet permet d'encapsuler les montages spécifiques aux conteneurs à partir de toute interaction avec systemd ou d'autres systèmes d'exploitation hôtes.
Cette capacité à réaliser potentiellement une optimisation majeure du CPU est désormais disponible pour tous les administrateurs d'OpenShift Container Platform. L'encapsulation peut également améliorer la sécurité en stockant les points de montage spécifiques à Kubernetes dans un emplacement à l'abri de l'inspection par des utilisateurs non privilégiés.
Les diagrammes suivants illustrent une installation Kubernetes avant et après l'encapsulation. Les deux scénarios montrent des exemples de conteneurs dont les paramètres de propagation des montages sont bidirectionnels, host-to-container et none.
Ici, nous voyons systemd, les processus du système d'exploitation hôte, kubelet et le runtime du conteneur partager un seul espace de noms de montage.
- systemd, les processus du système d'exploitation hôte, kubelet et le runtime du conteneur ont tous accès à tous les points de montage et en ont la visibilité.
-
Le conteneur 1, configuré avec la propagation bidirectionnelle des montages, peut accéder aux montages de systemd et de l'hôte, aux montages de kubelet et de CRI-O. Un montage provenant du conteneur 1, tel que
/run/a, est visible par systemd, les processus du système d'exploitation hôte, kubelet, le runtime du conteneur et d'autres conteneurs configurés avec une propagation de montage hôte à conteneur ou bidirectionnelle (comme dans le conteneur 2). -
Le conteneur 2, configuré avec la propagation des montages d'hôte à conteneur, peut accéder aux montages de systemd et d'hôte, ainsi qu'aux montages de kubelet et de CRI-O. Un montage provenant du conteneur 2, tel que
/run/b, n'est visible pour aucun autre contexte. -
Le conteneur 3, configuré sans propagation des montages, n'a aucune visibilité sur les points de montage externes. Un montage provenant du conteneur 3, tel que
/run/c, n'est visible pour aucun autre contexte.
Le diagramme suivant illustre l'état du système après l'encapsulation.
- Le processus principal de systemd n'est plus consacré à l'analyse inutile des points de montage spécifiques à Kubernetes. Il ne surveille que les points de montage spécifiques au système et les points de montage de l'hôte.
- Les processus du système d'exploitation hôte ne peuvent accéder qu'aux points de montage de systemd et de l'hôte.
- L'utilisation d'un espace de noms de montage distinct pour CRI-O et kubelet sépare complètement tous les montages spécifiques aux conteneurs de toute interaction avec systemd ou tout autre système d'exploitation hôte.
-
Le comportement du conteneur 1 est inchangé, sauf qu'un montage qu'il crée, tel que
/run/a, n'est plus visible par systemd ou les processus du système d'exploitation de l'hôte. Il est toujours visible pour kubelet, CRI-O et d'autres conteneurs avec une propagation de montage hôte à conteneur ou bidirectionnelle configurée (comme le conteneur 2). - Le comportement des conteneurs 2 et 3 reste inchangé.
