systemd ユニットやドロップインの編集を伴わない解決策は、 /etc/docker/daemon.json を作成 (または編集) することです 構成ファイルに以下を含めます:
{
"exec-opts": ["native.cgroupdriver=systemd"]
}
保存したら、docker サービスを再起動してください。
sudo systemctl restart docker
このソリューションは、システム全体に適用したい場合にのみ実行可能です。
2 つの構成ファイルがあるため、2 番目の構成ファイルにもエントリを追加する必要があります -- /etc/systemd/system/docker.service.d/docker-thinpool.conf :
--exec-opt native.cgroupdriver=systemd \
追加するだけで、cgroupfs は Docker 独自のコントロール グループ マネージャーです。ただし、大部分の Linux ディストリビューションでは、現在 ssytemd がデフォルトの init システムであり、systemd は Linux コントロール グループと緊密に統合されています。Kubernetes サイトでは、systemd と一緒に cgroupfs を使用することは最適ではないように思われるため、systemd の使用を推奨しています (以下を参照)。 /P>
そのため、cgroup の管理には systemd を使用することをお勧めします。 kubelet はデフォルトで systemd を使用するように設定されています。そのため、Docker を変更して systemd Cgroup ドライバーを使用する方が簡単で優れています
この重複の歴史はこちら https://lwn.net/Articles/676831/
Kubernetes サイトでは、systemd の使用を推奨しています https://kubernetes.io/docs/setup/production-environment/container-runtimes/
<ブロック引用>cgroup ドライバー systemd が Linux ディストリビューションの init システムとして選択されると、init プロセスはルート コントロール グループ (cgroup) を生成および消費し、cgroup マネージャーとして機能します。 Systemd は cgroup と緊密に統合されており、プロセスごとに cgroup を割り当てます。コンテナー ランタイムと kubelet を構成して、cgroupfs を使用することができます。 systemd と一緒に cgroupfs を使用すると、2 つの異なる cgroup マネージャーが存在することになります。
制御グループは、プロセスに割り当てられるリソースを制限するために使用されます。単一の cgroup マネージャーにより、どのリソースが割り当てられているかのビューが簡素化され、デフォルトで、使用可能なリソースと使用中のリソースの一貫したビューが表示されます。マネージャーが 2 人いる場合、それらのリソースのビューは 2 つになります。 kubelet と Docker に cgroupfs を使用するように構成されたノードと、ノードで実行されている残りのプロセスに systemd を使用するように構成されているノードが、リソース不足で不安定になるケースをフィールドで見てきました。