【Pod Terminating原因追踪系列之一】containerd中被漏掉的runc错误信息

前一段时间发现有一些containerd集群出现了Pod卡在Terminating的问题，经过一系列的排查发现是containerd对底层异常处理的问题。最后虽然通过一个短小的PR修复了这个bug，但是找到bug的过程和对问题的反思还是值得和大家分享的。

本文中会借由排查bug的过程来分析kubelet删除Pod的调用链，这样不仅仅可以了解containerd的bug，还可以借此了解更多Pod删除不掉的原因。在文章的最后会对问题进行反思，来探讨OCI出现的问题。

一个删除不掉的Pod

可能大家都会遇到这种问题，就是集群中有那么几个Pod无论如何也删除不掉，看起来和下图一样。当然可有很多可能导致Pod卡在Terminating的原因，比如mount目录被占用、dockerd卡死了或镜像中有“i”属性的文件。因为节点上复杂的组件（docker、containerd、cri、runc）和过长的调用链，导致很难瞬间定位出现问题的位置。所以一般遇到此类问题都会通过日志、Pod的信息和容器的状态来逐步缩小排查范围。

当然首先看下集群的信息，发现没有使用docker而直接用的cri和containerd。直接使用containerd照比使用docker会有更短的调用链和更强的鲁棒性，照比使用docker应该更稳定才对（比如经常出现的docker和containerd数据不一致的问题在这里就不会出现）。接下来当然是查看kubelet日志，如下（只保留了核心部分），从这条日志中可以发现貌似是kubelet调用cri接口，最终调用runc去删除容器时报错导致删除失败。

$ journalctl -u kubelet
Feb 01 11:37:27 VM_74_45_centos kubelet[687]: E0201 11:37:27.241794     687 pod_workers.go:190] Error syncing pod 18c3d965-38cc-11ea-9c1d-6e3e7be2a462 ("advertise-api-bql7q_prod(18c3d965-38cc-11ea-9c1d-6e3e7be2a462)"), skipping: error killing pod: [failed to "KillContainer" for "memcache" with KillContainerError: "rpc error: code = Unknown desc = failed to kill container \"55d04f7c957e81fcf487b0dd71a4e50fe138165303cf6e96053751fd6770172c\": unknown error after kill: runc did not terminate sucessfully: container \"55d04f7c957e81fcf487b0dd71a4e50fe138165303cf6e96053751fd6770172c\" does not exist\n: unknown"

接下来我们打算分析下容器当前的状态，简单介绍下，containerd中用container来表示容器、用task来表示容器的运行状态，创建一个容器相当于创建container，而把容器运行起来相当于创建一个task并把task状态置为Running。当然停掉容器就相当于把task的状态设置为Stopped。通过ctr命令看下containerd中container和task的状态，容器55d04f对应的container和task都还在、task状态是STOPPED。接下来查看containerd日志，我们节选了一小部分，发现了如下现象，第一条日志是stop容器55d04f时做umount失败，接下来都是kill容器55d04f时发现container不存在。

error="failed to handle container TaskExit event: failed to stop container: failed rootfs umount: failed to unmount target /run/containerd/io.containerd.runtime.v1.linux/k8s.io/55d04f.../rootfs: device or resource b