cgroup driver：
cgroup是通过一系列的文件来管控所有的资源分配的，包括创建了一个cgroup，同时将一个cgroup和这个进程进行关联，也就是将进程号echo到那个procs文件里面，同时修改cpu的quota来限制其使用的资源，这一整套都是cgroup的文件系统，cgroup本身可以有不同的driver。
SyStemd 驱动:（整个操作系统是使用了systemd cgroup driver，当使用kubernetes的时候，要将两者统一，如果其他进程是使用systemd拉起来的，systemd拉起来的那些进程就由systemd这套系统去管控的，docker拉起的进程是由cgroupfs这套系统去管控的，这就会出现同一套资源被两套系统网外分，当系统压力大的时候就会引发不必要的问题，所以kubernetes在启动的时候会做一些检查，在启动kubelet的时候，去判断docker使用了哪一个cgroup driver，如果docker本身不是使用systemd，那么它就会默认报错不启动）
当操作系统使用systemd作为init system时，初始化进程生成一个根cgroup目录结构并作为cgroup管理器。
systemd与cgroup紧密结合，并且为每个systemd unit分配cgroup。，
cgroupfs 驱动:
docker默认用cgroupfs作为cgroup驱动。
存在问题∶
因此，在systemd作为init system的系统中，默认并存着两套groupdriver。
这会似的系统中docker和kubelet管理的 进程被cgroupfs驱动管，而systemd拉起的服务由systemd驱动管，让cgroup管理混乱且容易在资源紧张时引发问题。
因此kubelet会默认--cgroup-driver=systemd，若运行时cgroup不一致时，kubelet会报错
所以在搭建kubrnetes集群的时候，你往往需要去修改docker本身的cgroup driver，那么kubelet才能够启动起来。
systemd 和 cgroupfs 这两种驱动有什么区别呢？
1.systemd cgroup driver 是 systemd 本身提供了一个 cgroup 的管理方式，使用systemd 做 cgroup 驱动的话，所有的 cgroup 操作都必须通过 systemd 的接口来完成，不能手动更改 cgroup 的文件
2.cgroupfs 驱动就比较直接，比如说要限制内存是多少、要用 CPU share 为多少？直接把 pid 写入对应的一个 cgroup 文件，然后把对应需要限制的资源也写入相应的 memory cgroup 文件和 CPU 的 cgroup 文件就可以了
所以可以看出来 systemd 更加安全，因为不能手动去更改 cgroup 文件，当然我们也推荐使用 systemd 驱动来管理 cgroup。
