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

背景

在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项目的根路径下执行：