问题现象

K8S集群中有一个节点的docker stats命令查看不到资源使用：

[root@node1 ~]# docker stats
CONTAINER ID        NAME                     CPU %           MEM USAGE / LIMIT     MEM %       NET I/O           
1c9bec808f61        k8s_busybox_xxx         --              --                    --           --           
86f38791af8f        k8s_kube-controller-manager_xxx   --              --                  --   --
60d98fe39332        k8s_kube-scheduler_xxx            --              --           --     --
a81320ad61e8        k8s_calico-kube-controllers_xxx   --              --                   --      --
4cf98fb540ba        k8s_calico-node_xxx               --              --                 --      --
9747e7ce0032        k8s_kube-proxy_xxx                --              --         --     --
...

原因分析

先看docker日志，存在大量如下异常：

time="xxx" level=error msg="collecting stats for xxx：no metrics reveived"

根据错误信息未找到相关问题，继续看这个命令的结果是从哪里读取的，根据资料[1]可知，该数据是从cgroup fs中计算得到。

随机找一个容器id，进入cgroup中看看相关指标文件是否正常：

[root@node1 ~]# cat /sys/fs/cgroup/cpu,cpuacct/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podxxx/docker-xxx.scope/cpuacct.usage
32068181

[root@node1 ~]# cat /sys/fs/cgroup/memory/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-podxxx/docker-xxx.scope/memory.limit_in_bytes
9223372036854771712

看起来没啥问题，查docker相关issue，未找到相关问题。

查containerd服务，发现一直在打印如下异常：

/sys/fs/cgroup/cpuacct/kubepods.slice/besteffort.slice/podxxx/xxx/cpuacct.stat is expected to have 4 fields

根据上面的错误信息，再次查看相关cgroup，看内容不像是4个字段：

[root@node1 ~]# cat /sys/fs/cgroup/cpuacct/kubepods.slice/kubepods-besteffort.slice/podxxx/xxx/cpuacct.stat
user 32
system 89
sched_delay 0

找一个正常节点，查看相关cgroup：

[root@node1 ~]# cat /sys/fs/cgroup/cpuacct/kubepods.slice/kubepods-burstable.slice/podxxx/xxx/cpuacct.stat
user 1568
system 6436

对比发现，问题环境里多了一个sched_delay字段，该字段表示由于调度延迟而导致的 CPU 时间延迟。查看到相关资料[2]，此问题源自https://github.com/containerd/cgroups。 当尝试从文件/sys/fs/cgroup/cpuacct/cpuacct.stat检索字段时，会报告该错误。这个限制是不合理的，已在containerd/cgroups@5fe29ea中修复。

查看修改记录，containerd/cgroups的解决版本如下：

 v3.0.3  v3.0.2 v3.0.1 v3.0.0 v1.1.0

对应的containerd版本是从v1.7.0开始升级cgroup版本到v1.0.0，解决了该问题。

为什么只有一个节点存在该问题？

根据修复记录的说明，某些系统内核才会触发该问题。查看正常节点和异常节点的内核版本，发现异常节点的内核版本是4.14.0，而正常节点的内核版本是5.x。

解决方案

1.升级containerd到v1.7.0及以上版本；

2.升级操作系统内核版本；

参考资料

1.https://cloud.tencent.com/developer/article/1096453

2.https://github.com/milvus-io/milvus/issues/22982

3.https://github.com/containerd/cgroups/pull/23