【docker-ce】k8s集群docker容器异常重启问题分析

背景

• 目前机器学习平台后端采用k8s架构进行GPU和CPU资源的调度和容器编排。k8s的核心能力是容器编排，容器服务的稳定运行直接关系到整体平台的稳定性。
• 春节值班期间，机器学习平台实验环境-隔离环境 vgpu资源出现比较多的用户容器异常退出问题。此问题导致Pod中的用户容器发生重建，一些用户在容器运行时环境的数据会丢失，由于平台具有暂存用户异常容器现场的能力，值班同学可以通过恢复用户异常容器现场来恢复用户的数据。
• 用户容器异常退出，虽然可以通过运维工具来恢复用户的数据进行问题降级处理，但是频繁无故的用户容器异常退出，环境重启问题，极大的影响了用户使用 机器学习平台实验环境-隔离环境 vgpu资源的体验和值班同学处理类似问题的时效性。

问题记录-之看现象

• 【看现场】
  
  • 版本信息

root@gpu-ser-xyz:~$ kubelet --version
Kubernetes v1.14-mlpe-20200225
root@gpu-ser-xyz:~$ docker version
Client:
Version:           18.09.2
API version:       1.39
Go version:        go1.10.6
Git commit:        6247962
Built:             Sun Feb 10 04:13:27 2019
OS/Arch:           linux/amd64
Experimental:      false
Server: Docker Engine - Community
Engine:
Version:          18.09.2
API version:      1.39 (minimum version 1.12)
Go version:       go1.10.6
Git commit:       6247962
Built:            Sun Feb 10 03:47:25 2019
OS/Arch:          linux/amd64
Experimental:     false
root@gpu-ser-xyz:~$ ctr --address /var/run/docker/containerd/containerd.sock version
Client:
Version:  1.2.2
Revision: 9754871865f7fe2f4e74d43e2fc7ccd237edcbce
Server:
Version:  1.2.2
Revision: 9754871865f7fe2f4e74d43e2fc7ccd237edcbce
root@gpu-ser-xyz:~$ containerd -v
containerd github.com/containerd/containerd 1.2.2 9754871865f7fe2f4e74d43e2fc7ccd237edcbce
root@gpu-ser-xyz:~$ runc -v
runc version 1.0.0-rc6+dev
commit: 09c8266bf2fcf9519a651b04ae54c967b9ab86ec
spec: 1.0.1-dev
root@gpu-ser-xyz:~$ nvidia-container-runtime -v
runc version 1.0.0-rc6+dev
commit: 6635b4f0c6af3810594d2770f662f34ddc15b40d-dirty
spec: 1.0.1-dev

• • 表格中记录了2020-01-14到2020-02-04期间一部分用户容器的kvm环境、docker、containerd、容器错误码的信息。
    

• 开始部分同学是怀疑cuda版本兼容性问题，导致用户容器异常退出，想通过升级cuda版本查看此问题是否收敛，但是cuda-10.0上也有类似现场，此怀疑不攻自破。
• 是否是由于用户容器OOM，导致异常退出，通过dmesg也没有查到任何异常日志。OOM论也被否定了。
• 相同版本的kernel、docker版本，物理GPU节点为出现用户容器重启，只有在kvm vgpu上出现，也让人摸不着头脑。
• 查看docker的日志，当用户容器异常退出时，就只有正常容器退出 clean up的信息，无其他异常日志。PS:其实此处才是澄清137问题的关键。

Feb 19 16:00:07 gpu-ser-xyz dockerd: time="2020-02-19T16:00:07.204930762+08:00" level=info msg="shim reaped" id=18b2fe723696358fb06317c427ab72777f430f074c8473612fad0fc99cbcb226
Feb 19 16:00:07 gpu-ser-xyz dockerd: time="2020-02-19T16:00:07.205071630+08:00" level=warning msg="cleaning up after killed shim" id=18b2fe723696358fb06317c427ab72777f430f074c8473612fad0fc99cbcb226 namespace=moby
Feb 19 16:00:08 gpu-ser-xyz dockerd: time="2020-02-19T16:00:08.305641212+08:00" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete"

• 【找同盟】
  
  • 为何出现exitCode=137？
    
    • Container exits with non-zero exit code 137 介绍了kill -9 (128 + 9) 触发的exitCode=137原因是容器stop时没有处理SIGTERM信号，进行容器优雅的退出。但是其本质还是用户容器异常退出了，不是正常stop操作。容器没有OOM，cpu、memory的监控利用率都没有超标，dmesg和messages日志中都没有异常信息，一度开始怀疑人生。
  • 类似社区137问题
    
    • Random task failures with "non-zero exit (137)" since 18.09.1 这个issue中作者从docker 18.09.0 升级到 18.09.1 (或者18.09.2)版本都会遇到137问题，也怀疑是OOM问题，但是实际应用没有出现OOM相关的日志现场。其中