专栏首页腾讯云原生团队【Pod Terminating原因追踪系列之二】exec连接未关闭导致的事件阻塞

【Pod Terminating原因追踪系列之二】exec连接未关闭导致的事件阻塞

岳家瑞,腾讯云后台开发工程师,日常负责K8s生态和运行时相关工作,包括K8s插件开发和运行时问题排查。

前一阵有客户docker18.06.3集群中出现Pod卡在terminating状态的问题,经过排查发现是containerd和dockerd之间事件流阻塞,导致后续事件得不到处理造成的。

定位问题的过程极其艰难,其中不乏大量工具的使用和大量的源码阅读。本文将梳理排查此问题的过程,并总结完整的dockerd和contaienrd之间事件传递流程,一步一步找到问题产生的原因,特写本文记录分享,希望大家在有类似问题发生时,能够迅速定位、解决。

对于本文中提到的问题,在docker19中已经得到解决,但docker18无法直接升级到docker19,因此本文在结尾参考docker19给出了一种简单的解决方案。

删除不掉Pod

相信大家在解决现网问题时,经常会遇到Pod卡在terminating不动的情况,产生这种情况的原因有很多,比如【Pod Terminating原因追踪系列】之 containerd 中被漏掉的 runc 错误信息中提到的containerd没有正确处理错误信息,当然更常见的比如umount失败、dockerd卡死等等。

遇到此类问题时,通常通过kubelet或dockerd日志、容器和Pod状态、堆栈信息等手段来排查问题。本问题也不例外,首先登录到Pod所在节点,使用以下两条指令查看容器状态:

#查看容器状态,看到容器状态为updocker ps | grep <container-id>#查看task状态,显示task的状态为STOPPEDdocker-container-ctr --namespace moby --address var/run/docker/containerd/docker-containerd.sock task ls | grep <container-id>

可以看到在dockerd中容器状态为up,但在containerd中task状态为STOPPED,两者信息产生了不一致,也就是说由于某种原因containerd中的状态信息没有同步到dockerd中,为了探究为什么两者状态产生了不一致,首先需要了解从dockerd到containerd的整体调用链:

当启动dockerd时,会通过NewClient方法创建一个client,该client维护一条到containerd的gRPC连接,同时起一个协程processEventStream订阅(subscribe)来自containerd的task事件,当某个容器的状态发生变化产生了事件,containerd会返回事件到client的eventQ队列中,并通过ProcessEvent方法进行处理,processEventStream协程在除优雅退出以外永远不会退出(但在有些情况下还是会退出,在后续会推出一篇文章,恰好是这种情况,敬请期待~)。

当容器进程退出时,containerd会通过上述gRPC连接返回一个exit的task事件给client,client接收到来自containerd的exit事件之后由ProcessEvent调用DeleteTask接口删除对应task,至此完成了一个容器的删除。

由于containerd一直处于STOPPED状态,因此通过上面的调用链猜测会不会是task exit事件因为某种原因而阻塞掉了?产生的结果就是在containerd侧由于发送了exit事件而进入STOPPED状态,但由于没有调用DeleteTask接口,因此本task还存在。

模拟task exit事件

通过发送task exit事件给一个卡住的Pod,来模拟容器结束的情况:

/tasks/exit {"container_id":"23bd0b1118238852e9dec069f8a89c80e212c3d039ba030cfd33eb751fdac5a7","id":"23bd0b1118238852e9dec069f8a89c80e212c3d039ba030cfd33eb751fdac5a7","pid":17415,"exit_status":127,"exited_at":"2020-07-17T12:38:01.970418Z"}

我们可以手动将上述事件publish到containerd中,但是需要注意的一点的是,在publish之前需要将上述内容进行一下编码(参考containerd/cmd/containerd-shim/main_unix.go Publish方法)。得到的结果如下图,可以看到事件成功的被publish,也被dockerd捕获到,但容器的状态仍然没有变化。

#将file文件中的事件发送到containerddocker-containerd --address var/run/docker/containerd/docker-containerd.sock publish --namespace moby --topic /tasks/exit < ~/file

当我们查看docker堆栈日志(向dockerd进程发送SIGUSR1信号),发现有大量的Goroutine卡在append方法,每次publish新的exit事件都会增加一个append方法的堆栈信息:

通过查看append方法的源码发现,append方法负责将收到的containerd事件放入eventQ,并执行回调函数,对收到的不同类型事件进行处理:

func (q *queue) append(id string, f func()) {    q.Lock()    defer q.Unlock()    if q.fns == nil {        q.fns = make(map[string]chan struct{})    }    done := make(chan struct{})    fn, ok := q.fns[id]    q.fns[id] = done    go func() {        if ok {            <-fn        }        f()        close(done)        q.Lock()        if q.fns[id] == done {            delete(q.fns, id)        }        q.Unlock()    }()}

形参中的id为container的id,因此对于同一个container它的事件是串行处理的,只有前一个事件处理结束才会处理下一个事件,且没有超时机制。

因此只要eventQ中有一个事件发生了阻塞,那么在它后面所有的事件都会被阻塞住。这也就解释了为什么每次publish新的对于同一个container的exit事件,都会在堆栈中增加一条append的堆栈信息,因为它们都被之前的一个事件阻塞住了。

深入源码定位问题原因

为了找到阻塞的原因,我们找到阻塞的第一个exit事件append的堆栈信息再详细的看一下:

通过堆栈可以发现代码卡在了docker/daemon/monitor.go文件的123行(省略了不重要的代码):

func (daemon *Daemon) ProcessEvent(id string, e libcontainerd.EventType, ei libcontainerd.EventInfo) error {    ......    case libcontainerd.EventExit:        ......        if execConfig := c.ExecCommands.Get(ei.ProcessID); execConfig != nil {            ......123行        execConfig.StreamConfig.Wait()            if err := execConfig.CloseStreams(); err != nil {                logrus.Errorf("failed to cleanup exec %s streams: %s", c.ID, err)            }            ......        } else {            ......        }    ......    return nil}

可以看到收到的事件为exit事件,并在第123行streamConfig在等待一个wg,这里的streamconfig为一个内存队列,负责收集来自containerd的输出返回给客户端,具体是如何处理io的在后面会细讲,这里先顺藤摸瓜查一下wg在什么时候add的:

func (c *Config) CopyToPipe(iop *cio.DirectIO) {    copyFunc := func(w io.Writer, r io.ReadCloser) {        c.Add(1)        go func() {            if _, err := pools.Copy(w, r); err != nil {                logrus.Errorf("stream copy error: %v", err)            }            r.Close()            c.Done()        }()    }    if iop.Stdout != nil {        copyFunc(c.Stdout(), iop.Stdout)    }    if iop.Stderr != nil {        copyFunc(c.Stderr(), iop.Stderr)    }    .....}

CopyToPipe是用来将containerd返回的输出copy到streamconfig的方法,可以看到当来自containerd的io流不为空,则会对wg add1,并开启协程进行copy,copy结束后才会done,因此一旦阻塞在copy,则对exit事件的处理会一直等待copy结束。我们再回到docker堆栈中进行查找,发现确实有一个IO wait,并阻塞在polls.Copy函数上:

至此造成dockerd和containerd状态不一致的原因已经找到了!我们来梳理一下。

首先通过查看dockerd和containerd状态,发现两者状态不一致。由于containerd处于STOPPED状态因此判断在containerd发送task exit事件时可能发生阻塞,因此我们构造了task exit事件并publish到containerd,并查看docker堆栈发现有大量阻塞在append的堆栈信息,证实了我们的猜想。

最后我们通过分析代码和堆栈信息,最终定位在ProcessEvent由于pools.Copy的阻塞,也会被阻塞,直到copy结束,而事件又是串行处理的,因此只要有一个事件处理被阻塞,那么后面所有的事件都会被阻塞,最终表现出的现象就是dockerd和containerd状态不一致。

找出罪魁祸首

我们已经知道了阻塞的原因,但是究竟是什么操作阻塞了事件的处理?其实很简单,此exit事件是由exec退出产生的,我们通过查看堆栈信息,发现在堆栈有为数不多的ContainerExecStart方法,说明有exec正在执行,推测是客户行为:

ContainerExecStart方法中第二个参数为exec的id值,因此可以使用gdb查找对应地址内容,查看其参数中的execId和terminating Pod中的容器的exexId(docker inspect可以查看execId,每个exec操作对应一个execId)是否一致,结果发现execId相同!因此可以断定是由于exec退出,产生的exit事件阻塞了ProcessEvent的处理逻辑,通过阅读源码总结出exec的处理逻辑:

那么为什么exec的exit会导致Write阻塞呢?我们需要梳理一下exec的io处理流程看看究竟Write到了哪里。下图为io流的处理过程:

首先在exec开始时会将socket的输出流attach到一个内存队列,并启动了⼀个goroutine用来把内存队列中的内容输出到socket中,除了内存队列外还有一个FIFO队列,通过CopyToPipe开启协程copy到内存队列。FIFO队列用来接收containerd-shim的输出,之后由内存队列写入socket,以response的方式返回给客户端。但我们的问题还没有解决,还是不清楚为什么Write会阻塞住。不过可以通过gdb来定位到Write函数打开的fd,查看一下socket的状态:

n, err := syscall.Write(fd.Sysfd, p[nn:max])type FD struct {    // Lock sysfd and serialize access to Read and Write methods.    fdmu fdMutex    // System file descriptor. Immutable until Close.    Sysfd int    ......}

Write为系统调用,其参数中第一位即打开的fd号,但需要注意,Sysfd并非FD结构体的第一个参数,因此需要加上偏移量16字节(fdMutex占16字节)

发现该fd为一个socket连接,使用ss查看一下socket的另一端是谁:

发现该fd为来自kubelet的一个socket连接,且没有被关闭,因此可以判断Write阻塞的原因正是客户端exec退出以后,该socket没有正常的关闭,使Write不断地向socket中写数据,直到写满阻塞造成的。

通过询问客户是否使用过exec,发现客户自己写了一个客户端并通过kubelet exec来访问Pod,与上述排查结果相符,因此反馈客户可以排查下客户端代码,是否正确关闭了exec的socket连接。

修复与反思

其实docker的这个事件处理逻辑设计并不优雅,客户端的行为不应该影响到服务端的处理,更不应该造成服务端的阻塞,因此本打算提交pr修复此问题,发现在docker19中已经修复了此问题,而docker18的集群无法直接升级到docker19,因为docker会持久化数据到硬盘上,而docker19不支持docker18的持久化数据。

虽然不能直接升级到docker19,不过我们可以参考docker19的实现,在docker19中通过添加事件处理超时的逻辑避免事件一直阻塞,在docker18中同样可以添加一个超时的逻辑!

对exit事件添加超时处理:

#/docker/daemon/monitor.goctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)execConfig.StreamConfig.WaitWithTimeout(ctx)cancel()
#/docker/container/stream/streams.gofunc (c *Config) WaitWithTimeout(ctx context.Context) {    done := make(chan struct{}, 1)    go func() {        c.Wait()        close(done)    }()    select {    case <-done:    case <-ctx.Done():        if c.dio != nil {            c.dio.Cancel()            c.dio.Wait()            c.dio.Close()        }    }}

这里添加了一个2s超时时间,超时则优雅关闭来自containerd的事件流。

至此一个棘手的Pod terminating问题已经解决,后续也将推出小版本修复此问题,虽然修复起来比较简单,但问题分析的过程却无比艰辛,希望本篇文章能够对大家今后的问题定位打开思路,谢谢观看~

文章分享自微信公众号:
腾讯云原生

本文参与 腾讯云自媒体分享计划 ,欢迎热爱写作的你一起参与!

如有侵权,请联系 cloudcommunity@tencent.com 删除。
登录 后参与评论
0 条评论

相关文章

  • 【Pod Terminating原因追踪系列之三】让docker事件处理罢工的cancel状态码

    岳家瑞,腾讯云后台开发工程师,日常负责K8s生态和运行时相关工作,包括K8s插件开发和运行时问题排查。

    腾讯云原生
  • 开工必备!50+篇超实用云原生技术干货合集

    kai 开 gong 工 da 大 ji 吉 新年新气象,更要1G棒 2020年没写完的代码,现在还有思路吗? 2021年开始使用云原生技术了吗? 一开工就遇...

    腾讯云原生
  • 转发有礼 | 50篇+云原生系列干货文章汇总,请查收!

    云原生技术干货文章合集,来咯~ 2020 年,要说咱们技术圈子里什么最火? 云原生肯定是那 NO.1 截止目前,我们不难看出,K8s 容器、服务网格、...

    腾讯云原生
  • 腾讯云【燎原社】3天搞定企业云原生改造?这份攻略请查收!

    众所周知,云原生技术改变了软件开发和交付的方式,让应用程序开发更容易、部署更快捷、运行更可靠,以容器、微服务以及动态编排为代表的云原生技术蓬勃发展,成为赋能业务...

    腾讯云原生
  • 中秋福利 | 15个系列100+篇超实用云原生原创干货合集(内含腾讯彩蛋)

    还有2天,就要迎来中秋小长假啦 这个中秋节你打算怎么过? 小云选择把这篇干货全部拿下! 云原生技术干货文章合集,来咯~ 2021 年,要说咱们技术圈子里什...

    腾讯云原生
  • 光速从0到1掌握Prometheus和Grafana,腾讯云专家5万字精华教程免费送

    黄雷,腾讯云高级工程师,曾负责构建腾讯云云监控新一代多维业务监控系统,擅长大规模分布式监控系统设计,对 golang 后台项目架构设计有较深理解,后加入TKE...

    腾讯云原生
  • 24位腾讯云专家精彩演讲,4万字《腾讯云技术实践精选集 2021》发布!(附合集下载)

    随着创新技术的发展,数字经济也迎来了新的风口。新风口下,企业该如何进行云原生改造,实现成本优化?如何对基础架构和数据库技术进行创新,化解可用性、可靠性、高并发、...

    腾讯云原生
  • qGPU 容器产品全量上线,重磅发布 GPU 在离线混部功能

    徐蓓,腾讯云容器技术专家,腾讯云异构计算容器负责人,多年云计算一线架构设计与研发经验,长期深耕 Kubernetes、在离线混部与 GPU 容器化领域,Kube...

    腾讯云原生
  • 大规模服务网格性能优化 | Aeraki xDS 按需加载

    钟华,腾讯云专家工程师,Istio project member、contributor,专注于容器和服务网格,在容器化和服务网格生产落地方面具有丰富经验,目...

    腾讯云原生
  • 新部署的服务 go_cpu 占满如何处理?

    作者:周易建,腾讯云云监控高级工程师 排查结果展示 [点击查看大图] 故障现象 新部署的服务,没有任何请求。但 Pod 上的 CPU 一直是占满状态,但...

    腾讯云监控团队
  • Kubernetes 实践:勿让 Docker Volume 引发 Terminating Pod

    问卷链接(https://www.wjx.cn/jq/97146486.aspx)

    CNCF
  • TKE 用户故事 | 作业帮 Kubernetes 原生调度器优化实践

    吕亚霖,2019年加入作业帮,作业帮架构研发负责人,在作业帮期间主导了云原生架构演进、推动实施容器化改造、服务治理、GO微服务框架、DevOps的落地实践。 ...

    腾讯云原生
  • k8s 实践经验(五)pod 详解(1)

    容器中的程序要运行,肯定会占用一定的资源,比如CPU和内存等,如果不对某个容器的资源做限制,那么它就可能吃掉大量的资源,导致其他的容器无法运行。针对这种情况,k...

    看、未来
  • K8S 滚动更新如何优雅停止 Pod

    优雅停止(Graceful shutdown) 这个说法来自于操作系统,我们执行关机之后都得 OS 先完成一些清理操作,而与之相对的就是硬中止(Hard shu...

    YP小站
  • Kubernetes之Pod生命周期

    简括:首先kubectl向 API 接口发送指令,随后kube-api 会调度到我们的kubelet,这个调度过程是由我们的etcd完成的存储,随后kubele...

    用户4877748
  • TKE上关于postStart 和preStop使用

    Kubernetes 支持 postStart 和 preStop 事件。 当一个容器启动后,Kubernetes 将立即发送 postStart 事件;在容器...

    聂伟星
  • 如何利用termination GracePeriodSeconds 优雅地关闭你的服务

    当涉及到分布式系统,处理故障是关键。Kubernetes通过利用可以监视系统状态并重新启动已停止执行的服务的控制器(controllers)来解决这个问题。另一...

    kubernetes中文社区
  • App Store 年度游戏:英雄联盟手游的云函数语音红包实践

    2021 年末,Apple 公布了 App Store Awards 获奖名单。《英雄联盟手游》凭借精致细腻的视觉效果和丰富刺激的故事情节,被评选为 App S...

    腾讯云原生
  • 聊聊 Kubernetes Pod or Namespace 卡在 Terminating 状态的场景

    一句话,本质是API Server虽然标记了对象的删除,但是作为实际清理的控制器kubelet, 并不能关停Pod或相关资源, 因而没能通知API Server...

    冬夜先生

扫码关注云+社区

领取腾讯云代金券