Une solution qui n'implique pas l'édition d'unités systemd ou de drop-ins serait de créer (ou d'éditer) le /etc/docker/daemon.json fichier de configuration et d'inclure les éléments suivants :
{
"exec-opts": ["native.cgroupdriver=systemd"]
}
Après l'avoir enregistré, redémarrez votre service docker.
sudo systemctl restart docker
Cette solution n'est évidemment réalisable que si vous souhaitez l'appliquer à l'ensemble du système.
Comme j'ai deux fichiers de configuration, je dois également ajouter l'entrée dans le deuxième fichier de configuration -- /etc/systemd/system/docker.service.d/docker-thinpool.conf :
--exec-opt native.cgroupdriver=systemd \
Juste pour ajouter, cgroupfs est le propre gestionnaire de groupe de contrôle de dockers. Cependant, pour la majorité des distributions Linux, sytemd est maintenant le système d'initialisation par défaut et systemd a une intégration étroite avec les groupes de contrôle Linux et sur le site Kubernetes, ils recommandent d'utiliser systemd (voir ci-dessous) car l'utilisation de cgroupfs avec systemd ne semble pas optimale /P>
Il est donc préférable d'utiliser systemd que pour la gestion des groupes de contrôle. kubelet est configuré par défaut pour utiliser systemd. Il est donc plus facile et préférable de changer Docker pour utiliser le pilote systemd Cgroup
Un historique de ce chevauchement est ici https://lwn.net/Articles/676831/
Sur le site Kubernetes, ils recommandent d'utiliser systemd https://kubernetes.io/docs/setup/production-environment/container-runtimes/
Pilotes de groupe de contrôle Lorsque systemd est choisi comme système d'initialisation pour une distribution Linux, le processus d'initialisation génère et utilise un groupe de contrôle racine (groupe de contrôle) et agit comme un gestionnaire de groupe de contrôle. Systemd a une intégration étroite avec les cgroups et allouera des cgroups par processus. Il est possible de configurer votre environnement d'exécution de conteneur et le kubelet pour utiliser cgroupfs. L'utilisation de cgroupfs avec systemd signifie qu'il y aura alors deux gestionnaires de groupe de contrôle différents.
Les groupes de contrôle sont utilisés pour limiter les ressources allouées aux processus. Un gestionnaire de groupe de contrôle unique simplifiera la vue des ressources allouées et aura par défaut une vue plus cohérente des ressources disponibles et en cours d'utilisation. Lorsque nous avons deux gestionnaires, nous nous retrouvons avec deux visions de ces ressources. Nous avons vu des cas sur le terrain où des nœuds configurés pour utiliser cgroupfs pour le kubelet et Docker, et systemd pour le reste des processus exécutés sur le nœud deviennent instables sous la pression des ressources.