這是因為kubelet的cgroup和docker的不一致所導致的，“kubelet cgroup驅動為systemd，而docker的為cgroupfs”，有兩種決解決方式，
方式一：修改docker的cgroup為systemd
修改docker服務的配置文件，“/etc/docker/daemon.json ”文件，添加如下
"exec-opts": ["native.cgroupdriver=systemd"]
重啟dokcer服務：
sudo systemctl daemon-reload
sudo systemctl restart docker
修改后查看docker的cgroup
$ docker info |grep "Cgroup Driver"
Cgroup Driver: systemd #表明已經更新為了systemd
重啟kuberlet:
systemctl restart kubelet
方式二：修改kubelet的cgroup為cgroupfs (不推薦)
修改Kubelet的配置文件：/var/lib/kubelet/config.yaml
cgroupDriver: cgroupfs
重啟kuberlet:
systemctl restart kubelet
修改完成后，此時可以可以在目標node上，再次查看kubelet的事件，看看是否報錯，或通過docker ps 、crictl ps工具查看目標容器是否被創建。
雖然解決了上面的問題，但是我們不禁產生一些疑問，什么是cgroup？systemd和cfgroupfs兩種cgroup有什么區別？
cgroup 驅動
在 Linux 上，控制組（CGroup）用於限制分配給進程的資源。
kubelet 和底層容器運行時都需要對接控制組來強制執行 為 Pod 和容器管理資源 並為諸如 CPU、內存這類資源設置請求和限制。若要對接控制組，kubelet 和容器運行時需要使用一個 cgroup 驅動。 關鍵的一點是 kubelet 和容器運行時需使用相同的 cgroup 驅動並且采用相同的配置。
可用的 cgroup 驅動有兩個：
cgroupfs 驅動
cgroupfs 驅動是 kubelet 中默認的 cgroup 驅動。當使用 cgroupfs 驅動時， kubelet 和容器運行時將直接對接 cgroup 文件系統來配置 cgroup。
當 systemd 是初始化系統時， 不 推薦使用 cgroupfs 驅動，因為 systemd 期望系統上只有一個 cgroup 管理器。 此外，如果你使用 cgroup v2， 則應用 systemd cgroup 驅動取代 cgroupfs。
systemd cgroup 驅動
當某個 Linux 系統發行版使用 systemd 作為其初始化系統時，初始化進程會生成並使用一個 root 控制組（cgroup），並充當 cgroup 管理器。
systemd 與 cgroup 集成緊密，並將為每個 systemd 單元分配一個 cgroup。 因此，如果你 systemd 用作初始化系統，同時使用 cgroupfs 驅動，則系統中會存在兩個不同的 cgroup 管理器。
同時存在兩個 cgroup 管理器將造成系統中針對可用的資源和使用中的資源出現兩個視圖。某些情況下， 將 kubelet 和容器運行時配置為使用 cgroupfs、但為剩余的進程使用 systemd 的那些節點將在資源壓力增大時變得不穩定。
當 systemd 是選定的初始化系統時，緩解這個不穩定問題的方法是針對 kubelet 和容器運行時將 systemd 用作 cgroup 驅動。
要將 systemd 設置為 cgroup 驅動，需編輯 KubeletConfiguration 的 cgroupDriver 選項，並將其設置為 systemd。例如：
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
...
cgroupDriver: systemd
如果你將 systemd 配置為 kubelet 的 cgroup 驅動，你也必須將 systemd 配置為容器運行時的 cgroup 驅動。 參閱容器運行時文檔，了解指示說明。例如：