Eine Lösung, die keine Bearbeitung von systemd-Units oder Drop-Ins beinhaltet, wäre das Erstellen (oder Bearbeiten) von /etc/docker/daemon.json Konfigurationsdatei und folgendes einzuschließen:
{
"exec-opts": ["native.cgroupdriver=systemd"]
}
Starten Sie nach dem Speichern Ihren Docker-Dienst neu.
sudo systemctl restart docker
Diese Lösung ist natürlich nur praktikabel, wenn Sie dies systemweit anwenden möchten.
Da ich zwei Konfigurationsdateien habe, muss ich auch den Eintrag in der zweiten Konfigurationsdatei hinzufügen - /etc/systemd/system/docker.service.d/docker-thinpool.conf :
--exec-opt native.cgroupdriver=systemd \
Nur um hinzuzufügen, cgroupfs ist Dockers eigener Kontrollgruppenmanager. Für die meisten Linux-Distributionen ist ssytemd jedoch jetzt das Standard-Init-System und systemd hat eine enge Integration mit Linux-Kontrollgruppen und auf der Kubernetes-Site empfehlen sie die Verwendung von systemd (siehe unten), da die Verwendung von cgroupfs zusammen mit systemd nicht optimal zu sein scheint /P>
Daher ist es besser, systemd als für die Cgroup-Verwaltung zu verwenden. kubelet ist standardmäßig so konfiguriert, dass es systemd verwendet. Daher ist es einfacher und besser, Docker so zu ändern, dass der systemd Cgroup-Treiber verwendet wird
Eine Geschichte dieser Überschneidung finden Sie hier https://lwn.net/Articles/676831/
Auf der Kubernetes-Site empfehlen sie die Verwendung von systemd https://kubernetes.io/docs/setup/production-environment/container-runtimes/
Cgroup-Treiber Wenn systemd als Init-System für eine Linux-Distribution gewählt wird, generiert und verbraucht der Init-Prozess eine Root-Kontrollgruppe (cgroup) und fungiert als Cgroup-Manager. Systemd hat eine enge Integration mit Cgroups und weist Cgroups pro Prozess zu. Es ist möglich, Ihre Containerlaufzeit und das Kubelet für usecgroupfs zu konfigurieren. Die Verwendung von cgroupfs zusammen mit systemd bedeutet, dass es dann zwei verschiedene Cgroup-Manager gibt.
Kontrollgruppen werden verwendet, um Ressourcen einzuschränken, die Prozessen zugeordnet sind. Ein einzelner Cgroup-Manager vereinfacht die Ansicht der zugewiesenen Ressourcen und bietet standardmäßig eine konsistentere Ansicht der verfügbaren und verwendeten Ressourcen. Wenn wir zwei Manager haben, haben wir am Ende zwei Ansichten dieser Ressourcen. Wir haben Fälle in der Praxis gesehen, in denen Knoten, die so konfiguriert sind, dass sie cgroupfs für Kubelet und Docker und systemd für den Rest der auf dem Knoten ausgeführten Prozesse verwenden, unter Ressourcendruck instabil werden.