Wang Xigang 360 Cloud Computing
Déclaration d'héroïne
Cgroups v1 a été présenté dans un article précédent " Parler de Cgroups ". Cgroups fournit une base pour la virtualisation des conteneurs. Avec le développement continu de la technologie des conteneurs, la gestion des contrôleurs dans Cgroups v1 est devenue plus compliquée. L'émergence de Cgroups v2 simplifie la hiérarchie et devient une fonctionnalité officielle du noyau 4.5.0. Cet article présentera Cgroups v2 à partir de son arrière-plan et des changements spécifiques par rapport à la v1.
PS: une technologie de première ligne riche, un large éventail de formes, le tout en " 3 60 cloud computing " point de préoccupation Oh!
1
Contexte
J'ai écrit un article avant pour présenter cgroup v1, mais comme le k8 actuel utilise cephfs pour le stockage de données, lors d'une utilisation multi-locataire, IO doit être restreint. À l'heure actuelle, cgroup v1 n'a pas de coopération entre memcg et blkio, donc la limitation du buffer io n'a pas été réalisée. Et l'implémentation de cgroup v1 dans le noyau a été chaotique, la raison principale étant que, pour offrir de la flexibilité, cgroup permet aux processus d'appartenir à différents groupes dans plusieurs hiérarchies. Mais en fait, la hiérarchie multiple n'est pas très utile, car le contrôleur (contrôleur) ne peut appartenir qu'à une seule hiérarchie. Donc, en utilisation réelle, il y a généralement un contrôleur par hiérarchie.
Ce type de multi-hiérarchie n'est pas très utile sauf pour augmenter la complexité du code et la difficulté de compréhension. D'une part, le suivi du processus de tous les contrôleurs devient compliqué; d'autre part, il est également difficile pour chaque contrôleur de travailler ensemble (car les contrôleurs peuvent appartenir à une hiérarchie différente, donc à partir de 3.16, le noyau a commencé à bouger à une seule hiérarchie (hiérarchie unifiée) La limite du buffer io.
2
Changements dans Cgroups v2
En raison des divers problèmes de Cgroups v1, Cgroups v2 a changé l'approche multi-hiérarchie en une hiérarchie unifiée et a monté tous les contrôleurs sur une hiérarchie unifiée.
Le noyau actuel ne supprime pas la version Cgroups v1, permettant à la fois Cgroups v1 et v2 de coexister. Mais le même contrôleur ne peut pas être monté sur ces deux versions différentes de Cgroup en même temps.
Voici cinq améliorations apportées à Cgroups v2:
Tous les contrôleurs de Cgroups v2 seront montés sous une hiérarchie unifiée. Il n'y a rien de tel que de permettre à différents contrôleurs d'être montés sur une hiérarchie différente dans la v1.
Proess ne peut être lié qu'au répertoire racine ("/") du groupe de contrôle et aux nœuds feuilles dans l'arborescence du répertoire du groupe de contrôle
Spécifiez quels contrôleurs peuvent être utilisés via cgroup.controllers et cgroup.subtree_control
Le fichier de tâches dans la version v1 et le fichier cgroup.clone_children dans le contrôleur cpuset ont été supprimés
Lorsque le groupe de contrôle est vide, le mécanisme de notification est amélioré, via la notification du fichier cgroup.events
3
hiérarchie unifiée
Bien que Cgroups v1 permette de monter différents contrôleurs sur différentes hiérarchies, il est très flexible, mais en fait cette méthode n'est pas nécessaire pour les utilisateurs. Par conséquent, dans la version Cgroups v2, tous les contrôleurs sont montés dans une hiérarchie.
Vous pouvez utiliser la commande suivante pour monter Cgroups v2 sur le système de fichiers, et tous les contrôleurs disponibles seront montés automatiquement.
mount -t cgroup2 aucun $ MOUNT_POINT
Un contrôleur ne peut pas être utilisé dans Cgroups v1 et v2 en même temps. Si vous voulez utiliser un contrôleur qui a été utilisé par Cgroups v1 dans Cgroups v2, vous devez d'abord le démonter de Cgroups v1.
Il convient de noter que lorsque le système démarre, systemd utilise par défaut Cgroups v1 et monte le contrôleur disponible sur / sys / fs / cgroup. Si vous souhaitez désactiver Cgroups v1 au démarrage du système, vous pouvez modifier les paramètres du noyau dans le fichier / etc / default / grub et ajouter GRUB_CMDLINE_LINUX_DEFAULT = "cgroup_no_v1 = all". (tout signifie pour fermer tous les contrôleurs. Si vous voulez fermer le contrôleur spécifié, remplacez tout par le nom du contrôleur dont vous avez besoin, séparé par des virgules). De cette façon, vous pouvez utiliser le contrôleur de votre choix dans Cgroups v2.
4
contrôleurs
Actuellement, cgroup v2 prend en charge les contrôleurs suivants:
io （depuis Linux 4.5）
mémoire (depuis Linux 4.5)
pids （depuis Linux 4.5）
perf_event (depuis Linux 4.11)
rdma (depuis Linux 4.11)
cpu (depuis Linux 4.15)
5
contrôle de sous-arborescence
Chaque groupe de contrôle sous la hiérarchie contiendra les deux fichiers suivants:
cgroup.controllers
Il s'agit d'un fichier en lecture seule. Contient tous les contrôleurs disponibles sous le Cgroup.
cgroup.subtree_control
Ce fichier contient les contrôleurs qui ont été activés sous le Cgroup. Et les contrôleurs contenus dans cgroup.subtree_control sont un sous-ensemble des contrôleurs dans le fichier cgroup.controllers.
Le format du contenu du fichier cgroup.subtree_control est le suivant: Les espaces sont utilisés entre les contrôleurs, avec "+" devant pour l'activation et "-" pour la désactivation. Par exemple, l'exemple suivant:
echo '+ pids -memory'> x / y / cgroup.subtree_control
La structure organisationnelle spécifique de Cgroups v2 est illustrée dans la figure suivante:
6
règle "aucun processus interne"
Contrairement à Cgroups v1, Cgroups v2 ne peut lier les processus qu'aux nœuds feuilles. Par conséquent, le processus ne peut être lié à aucun sous-groupe pour lequel le contrôleur est activé.
7
fichier cgroup.events
Dans l'implémentation de Cgroups v2, le mécanisme d'obtention de notifications lors de la vidange du groupe est également optimisé.
Cgroups v1 utilisait release_agent et notify_on_release pour être supprimés dans la v2. Au lieu de cela, le fichier cgroup.events est utilisé. Il s'agit d'un fichier en lecture seule avec une paire clé-valeur par ligne, séparée par des espaces entre la clé et la valeur.
Actuellement, une seule clé de ce fichier est remplie et la valeur correspondante est 0. 0 signifie qu'il n'y a aucun processus dans le groupe de contrôle et 1 signifie que le groupe de contrôle contient un processus.
8
fichier cgroup.stat
Chaque groupe sous la hiérarchie Cgroups v2 contiendra un fichier en lecture seule cgroup.stat. Son contenu se présente également sous forme de valeur-clé. Actuellement, ce fichier contient les deux clés suivantes:
nr_descendants
Indique le nombre de sous-groupes survivants dans le groupe de contrôle
nr_dying_descendants
Indique le nombre de groupes de contrôle qui sont morts dans le groupe de contrôle
9
Limite du nombre de Cgroups descendants
La hiérarchie Cgroups v2 contient également deux fichiers restreints pour l'affichage et la définition du nombre de Cgroups descendants sous les Cgroups:
cgroup.max.depth (depuis Linux 4.14)
Ce fichier définit la profondeur maximale des sous-groupes. 0 signifie que le groupe de contrôle ne peut pas être créé. Si vous essayez de créer un groupe de contrôle, une erreur EAGAIN sera signalée; max signifie qu'il n'y a pas de limite et la valeur par défaut est max.
cgroup.max.descendants (depuis Linux 4.14)
Le nombre maximum de répertoires de groupes de contrôle actifs qui peuvent être créés actuellement. La valeur par défaut "max" signifie aucune limite. Si la limite est dépassée, revenez à EAGAIN.
Articles Liés
http://man7.org/linux/man-pages/man7/cgroups.7.html
https://facebookmicrosites.github.io/cgroup2/docs/create-cgroups.html
https://events.static.linuxfound.org/sites/events/files/slides/cgroup_and_namespaces.pdf
https://lwn.net/Articles/679786/
https://www.lijiaocn.com/%E6%8A%80%E5%B7%A7/2019/01/28/linux-tool-cgroup-detail.html