背景

在2018年底，vivo AI 研究院为了解决统一的高性能训练环境、大规模的分布式训练、计算资源的高效利用调度等痛点，着手建设AI计算平台。白驹过隙，将近两年时间过去了，平台的建设和落地取得了很大的进展，成为了vivo AI领域的核心基础平台。平台现在已经有超过500多个用户，来自人工智能、影像、互联网等多个部门。平台的容器集群有1000多台服务器，拥有50000多CPU核，1000多张GPU卡，GPU算力将近100 PFLOPS。每天运行1000多个的算法训练任务，部署了100多个的模型推理服务和AI应用。这些训练任务和应用都是以容器的方式运行。平台从当初服务深度学习训练为主，到现在演进成包含VTraining、VServing、VContainer三大模块，对外提供模型训练、模型推理和容器化的能力。

计算平台的底座是VContainer，是基于Kubernetes构建的容器平台，对上提供了容器运行、资源调度等能力。Kubernetes是平台最基础最重要的组件，其稳定性对平台至关重要。本文是vivo AI计算平台技术演进系列文章之一，着重分享了平台在Kubernetes上遇到的疑难杂症和解决方法。

疑难杂症一：kmem accounting问题

平台的GPU机器在运行算法训练的时候，经常会出现机器Crash重启或者卡死的现象。CPU机器也会偶现此问题。通过排查，发现是臭名昭著的kmem accounting问题。这个问题在网上有很多资料，比如腾讯云的文章《Cgroup泄漏–潜藏在你的集群中》和PingCap的文章《诊断修复 TiDB Operator 在 K8s 测试中遇到的 Linux 内核问题》。这些资料提供了现象、根因的说明以及具体的修复方法，对我们修复问题提供很大的帮助，但现存的资料有以下问题：

某些细节的信息有误。比如PingCap文章提到docker 18.09.1版本的runc已经将问题修复，但实际并没有。
缺乏严谨的验证修复是否成功的方法。比如如何验证某个版本的runc修复了该问题。
缺乏针对GPU机器的修复说明。
该问题还会导致容器的内存指标虚高的问题。

本文针对上面的问题进行补充，希望给大家解决此问题带来帮助。

kubelet的编译选项

有些资料提到kubelet版本是v1.14及以上的，可以用编译选项BUILDTAGS=“nokmem"来关闭kmem accounting的特性。实际验证这个编译选项是无效的，正确的编译选项是GOFLAGS=”-tags=nokmem"。完整的编译命令是在k8s项目的根路径下执行：

./build/run.sh make kubelet KUBE_BUILD_PLATFORMS=linux/amd64 BUILDTAGS="nokmem"

验证修复的方法

首先，可以用命令 docker run -d --name test --kernel-memory 100M nginx:1.14.2 验证runc是否关闭了kmem accounting。如果该命令执行成功，容器成功创建，说明kmem accounting特性还是开启的。如果命令失败，出现以下错误消息：

# docker run -d --name test --kernel-memory 100M nginx:1.14.2
001f2ed0176941715d717b87a331fa05ab2bb2a9ab7107f3f66322ce9d6471a5
docker: Error response from daemon: OCI runtime create failed: container_linux.go:345: starting container process caused "process_linux.go:430: container init caused \"process_linux.go:396: setting cgroup config for procHooks process caused \\\"kernel memory accounting disabled in this runc build\\\"\"": unknown.

则说明kmem accounting特性已经被关闭了。

确认runc的kmem accounting关闭后，下一步是确认kubelet的kmem accounting是否关闭。重启机器后执行命令：

# find /sys/fs/cgroup/memory/kubepods/ -name memory.kmem.slabinfo | xargs cat > /tmp/mem.txt
# cat /tmp/mem.txt

如果mem.txt的内容是空，说明kubelet的kmem accounting也成功关闭。该机器的kmem问题已修复。

GPU机器的特殊处理

我们将重新编译的kubelet和runc部署到CPU机器，通过上述验证方法，证明kmem问题已经修复了。但是同样部署到GPU机器后，却发现kmem问题还存在。经过排查后，我们找到了原因。GPU机器上，docker的runtime会设置为nvidia-container-runtime：

# cat /etc/docker/daemon.json
{
    "runtimes": {
        "nvidia": {
            "path": "/usr/bin/nvidia-container-runtime",
            "runtimeArgs": []
        }
    }
}

即docker会调用nvidia-container-runtime，而不是runc。我们使用了nvidia-container-runtime v2.0.0.3，该版本是基于runc改动，添加了一个pre-start hook，用于容器启动前在容器内挂载GPU驱动、nvidia库和GPU设备，其原理如下图所示：

注意nvidia-container-runtime本身充当了runc，机器上的runc二进制不会被调用。因此为了修复GPU机器上的kmem问题，我们需要关闭nvidia-container-runtime的kmem accounting特性。

接下来我们又遇到一个问题，在官方仓库中找不到v2.0.0.3的对应分支或者tags。经过一番研究，我们发现nvidia-container-runtime对runc的改动是PR Add patch updated for v1.0.0-rc8的内容。我们自己从runc的1.0.0-rc8 tag拉出分支，做了一样的改动后，通过命令make BUILDTAGS="seccomp nokmem"编译出关闭了kmem的nvidia-container-runtime。将新的二进制部署到GPU机器，可以通过上述的验证。

如果大家使用的是nvidia-container-runtime v3.0以上版本，则不会遇到这个问题。因为3.0做了重构，nvidia-container-runtime不再基于runc，是一个独立的实现，会调用runc。因此只需要runc关闭kmem即可。

容器内存指标虚高的问题

我们注意到平台的calico容器使用了很多的内存，下面所示的一个calico-node的Pod使用了4.8G内存。

# kubectl top pod -n kube-system |grep calico-node         
calico-node-2cdkw                               921m         4841Mi

一开始我们怀疑calico有内存泄露的问题，社区上也有相关的issue： Large RAM consumption。但接着发现内存泄露问题在我们使用的v3.6.5版本已经修复，calico相关的进程实际使用的内存也不多。进一步排查后发现是kmem导致了这个问题。

k8s或者监控组件cadvisor，会使用容器内/sys/fs/cgroup/memory/memory.usage_in_bytes文件的值，作为容器的内存使用值。这个值是包含了/sys/fs/cgroup/memory/memory.kmem.usage_in_bytes的值。
存在kmem问题的节点上，memory.kmem.usage_in_bytes的值很大，从而导致memory.usage_in_bytes的值特别大：

# kubectl exec -it calico-node-zng2w -n kube-system sh
/ # cat /sys/fs/cgroup/memory/memory.usage_in_bytes
17915895808
/ # cat  /sys/fs/cgroup/memory/memory.kmem.usage_in_bytes
17763127296

在正常的节点上，memory.kmem.usage_in_bytes的值为0，memory.usage_in_bytes的值是正常的：

# kubectl exec -it  calico-node-q9vz4 -n kube-system sh
/ #  cat /sys/fs/cgroup/memory/memory.usage_in_bytes
151412736
/ # cat  /sys/fs/cgroup/memory/memory.kmem.usage_in_bytes
0

由此可见，kmem的问题除了会影响机器的稳定性，还会影响容器的内存指标。如果Pod配置了limit会导致Pod频繁被OOM Kill。

疑难杂症二：CPU Manager导致容器的GPU设备缺失

CPU Manager是k8s的一个特性，可以在kubelet上开启。开启后满足需求的Pod（QoS为Guaranteed, 且cpu request为正整数）会跑在固定的CPU核上并且独占CPU核，这能有效提升容器内应用的性能。这个特性在官方文章Feature Highlight: CPU Manager有详细说明。我们在GPU机器启动了该特性后，发现GPU容器无法访问GPU设备，执行nvidia-smi命令会有错误消息“Failed to initialize NVML: Unknown Error”。社区中有相关issue：Updating cpu-manager-policy=static causes NVML unknown error。

根因分析

CPU Manager特性是在kubelet的CPU Manager模块实现的。该模块通过docker的–cpuset-cpus参数，可以限制容器使用指定的CPU核。它会维护一个数据结构，记录哪些Pod独占用了哪些CPU核。非独占核的Pod会共享没被独占的CPU核，如下图所示：

当新的Pod创建时，如果不满足独占核需求，cpuset-cpus将设置为Share-Pool里的CPU核。如果满足独占核需求，则会从Share-Pool的Assignable里面分出CPU核给新的Pod，Share-Pool发生变化后也要更新非独占核Pod的cpuset-cpus。CPU Manager模块会定时刷新Pod的cpuset-cpus参数。

文章上一节提到，GPU容器是通过nvidia设置pre-start hook，在容器创建后启动前将GPU设备挂载到容器内，但这个设备信息没有同步给docker。因此CPU Manager调用docker API更新容器cpuset-cpus参数时，GPU设备的挂载会失效，导致了上述的问题。

修复方法

修复该问题需要修改kubelet的CPU Manager模块的代码。对于独占核的Pod，不再定时去更新Pod的cpuset-cpus参数。这样规避了更新导致设备失效的问题。这个修复要求使用GPU的Pod必须独占核。具体的代码改动可以参见社区此说明。

疑难杂症三：容器内僵尸进程

按照容器的最佳实践，容器里应该只运行一个应用进程。有些业务场景由于特殊需求会在容器内启动多个子进程，比如一机多卡的算法训练。当子进程出现异常时，父进程没正确处理和回收，导致子进程变成僵尸进程。如下面的情况：

root     111457      1  0 Jul03 ?        00:06:41 containerd-shim -namespace moby -workdir /data/docker/containerd/daemon/io.containe
root     111476 111457  0 Jul03 ?        00:00:00  \_ [bash]
root     114254 111476 99 Jul03 ?        213558-11:24:03  |   \_ python /data/glusterfs_workspaces/11121083/MAFNDeep/main.py 
root       1202 114254  0 Jul03 ?        00:00:00  |       \_ [python] <defunct>
root       1204 114254  0 Jul03 ?        00:00:00  |       \_ [python] <defunct>
root       1205 114254  0 Jul03 ?        00:00:00  |       \_ [python] <defunct>
root       1206 114254  0 Jul03 ?        00:00:00  |       \_ [python] <defunct>

这会导致删除Pod后，Pod在k8s中一直处于Terminating状态，主机上也无法通过docker命令删除对应的容器。我们可以通过 kubectl delete pod ${podName} --force --grace-period=0命令从k8s中删除这个Pod。在节点上通过 pkill -9 ${containerID} 命令将容器的shim进程强制杀掉。但是僵尸进程会一直存在于系统中，最后只有重启系统才能解决。在Linux中1号进程有处理和回收僵尸进程的职责。在容器内一般的应用进程作为1号进程并没有这个功能。为了解决这个问题，我们需要在容器内有一个正确发挥作用的1号进程。

社区的tini项目是专门为容器设计的init进程，可以通过将tini设置为entrypoint让它成为1号进程。这需要在镜像内安装tini和设置entrypoint。平台上用户可以使用自己打包的镜像，这涉及太多镜像的改造。我们发现了一种改造成本更小的方案。k8s启动的Pod在主机上除了业务容器还会有pause容器。pause容器中的pause进程实际上也有回收僵尸进程的功能。因此通过给Pod设置shareProcessNamespace: true，pause容器和业务容器共享PID命名空间后，容器内的一号进程就是pause进程，这就解决了僵尸进程的问题。关于pause容器和进程的更多信息，可以参见The Almighty Pause Container。

疑难杂症四：CIDRNotAvailable问题

在k8s集群规模变大后，我们发现Controller Manager的日志有很多CIDRNotAvailable相关的错误，k8s的event里也有很多相关事件：

# kubectl get event
LAST SEEN   TYPE      REASON             OBJECT                                MESSAGE
4m21s       Normal    CIDRNotAvailable   node/10.193.131.130                   Node 10.193.131.130 status is now: CIDRNotAvailable
4m34s       Normal    CIDRNotAvailable   node/10.193.131.135                   Node 10.193.131.135 status is now: CIDRNotAvailable

我们对此进行了排查和验证，最终确定该错误只会影响使用了host-local模式来分配容器IP的集群。平台的集群网络使用了calico-ipam模式，不受影响。

当容器IP分配使用host local模式，容器网络会划分成多个子网，每个节点分配一个子网，调度到节点上的容器的IP从这个子网分配。通过Controller Manager的参数node-cidr-mask-size可以指定子网的大小。Controller Manager会根据这个参数分配子网给节点。node的spec.podCIDR字段就是节点分配到的子网的信息：

# kubectl get node 10.196.2.1 -o yaml
apiVersion: v1
kind: Node
  name: 10.196.2.1
spec:
  podCIDR: 10.227.228.0/24

node-cidr-mask-size参数默认值是24，即主机上的子网是24位，比如10.42.0.0/24。整个容器网络是16位的子网，如10.42.0.0/16，这个网络可以划分成256个24位的子网，集群中有256个节点可以分配到子网。超过了256个后，新的节点划分不到子网，就会出现这个错误。使用host local模式的集群，调度到新节点的容器因为分配不到IP，状态会一直处于ContainerCreating。平台使用calico-ipam模式，不依赖podCIDR字段，因此不受影响。

疑难杂症五：cadvisor CPU利用率过高

平台通过使用cadvisor来采集容器指标。我们发现有时候某些节点上的容器指标缺失。经过排查，发现是节点的cadvisor卡住了，这时cadvisor的CPU利用率很高。社区有相关issue：High CPU usage with low number of containers。Github的文章Debugging network stalls on Kubernetes详细剖析了根因，此文问题排查的技巧和思路绝佳，强烈推荐大家阅读。Github遇到服务出现偶现的网络延迟，和我们的现象不一样。但是导致问题的根因是一样的。

直接原因是cadvisor在读取/sys/fs/cgroup/memory/memory.stat文件时，耗费了较多时间。这是因为当容器退出时，应用的内存已经释放了，但是内核用于缓存如inode等数据的内存还未释放。如果每次主动释放这些内存，会有较大的性能开销，因此内核采用了延迟释放的策略，只有当内存不够的时候，才释放这些内存，然后才会删除对应的cgroup。这种策略导致系统中存在很多僵尸cgroup，这些cgroup的进程已退出但是因为内核使用内存未释放，所以一直未被清理，还会包含在memory.stat中。当这些内存被回收和cgroup被清理时，读取memory.stat的耗时就会变长。这个问题在4.19以上的内核已经优化了。

相关文章：

《Kube-batch在vivo AI计算平台的应用》
《从VETH到Kubernetes网络通信剖析》

作者介绍:

吴梓洋，曾就职于Oracle, Rancher等公司，目前是vivo AI研究院计算平台组的资深工程师，也是kube-batch, tf-operator等项目的contributor，关注K8s、容器等云原生技术。

创作场景

vivo AI 计算平台的 K8s 填坑指南