Stupig 2021-11-30T03:43:26.099Z https://plpan.github.io/ plpan Hexo client-go informer 缓存失效问题排查 https://plpan.github.io/client-go-informer-%E7%BC%93%E5%AD%98%E5%A4%B1%E6%95%88%E9%97%AE%E9%A2%98%E6%8E%92%E6%9F%A5/ 2021-11-27T02:36:56.000Z 2021-11-30T03:43:26.099Z 背景

长期以来，弹性云线上服务一直饱受缓存不一致的困扰。

缓存不一致的发生一般伴随着kube-apiserver的升级或重启。且当缓存不一致问题发生时，用户侧能够较为明显的感知，问题严重时会引发线上故障。而常见的故障有：

  • 平台数据不一致：Pod状态一会正常，一会不正常，并且来回跳动
  • 服务管理事件丢失：服务变更时，服务管理未正常工作，如服务树未挂载、流量未接入等等

在问题未定位之前，弹性云制定了诸多问题感知与及时止损策略：

  • 问题感知：
    • 人工：kube-apiserver升级或重启时，人工通知关联方也重启平台服务
    • 智能：配置监控与报警策略，当一段时间内未收到k8s对象的变更事件时，发送告警信息
  • 及时止损：
    • 重启：缓存不一致问题发生时，重启服务，并从kube-apiserver全量拉取最新的数据
    • 自愈：部分场景下，即使服务重启也不能完全恢复，添加自愈策略，主动感知并处理异常情况

问题感知与止损策略并没有真正意义上解决问题，而仅仅是在确定性场景下尝试恢复服务，并且伴随着更多异常场景的发现，策略也需同步调整。

问题定位

感知与止损是一种类似亡羊补牢的修复手段，显然，我们更希望的是一个彻底解决问题的方案。那么，我们先从引起缓存不一致的根因开始排查。

我们选择notifier来排查该问题，notifier是一个集群管理服务的控制器集合，其功能主要包含：

  • 服务树挂载
  • DNS注册
  • LVS摘接流等

选择notifier的原因，在于其功能较为简单：notifier使用了client-go的informer，并对核心资源事件注册处理函数；此外也没有复杂的业务流程来干扰问题排查。

问题复现

我们在线下环境中进行测试，发现kube-apiserver服务重启后，问题能够稳定复现，这给我们排查问题带来了极大的便利。因此问题复现步骤如下：

  • 启动notifier服务
  • 重启kube-apiserver服务

状态分析

当问题发生时，我们首先对服务状态做一些基本检查：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# #服务存活状态
# ps -ef|grep notifier
stupig 1007922 1003335  2 13:41 pts/1    00:00:08 ./notifier -c configs/notifier-test.toml
 
# #服务FD打开状态
# lsof -nP -p 1007922
COMMAND       PID       USER   FD      TYPE             DEVICE SIZE/OFF        NODE NAME
nobody    1007922     stupig   0u       CHR              136,1      0t0           4 /dev/pts/1
nobody    1007922     stupig   1u       CHR              136,1      0t0           4 /dev/pts/1
nobody    1007922     stupig   2u       CHR              136,1      0t0           4 /dev/pts/1
nobody    1007922     stupig   3u      unix 0xffff8810a3132400      0t0  4254094659 socket
nobody    1007922     stupig   4u   a_inode                0,9        0        8548 [eventpoll]
nobody    1007922     stupig   5r      FIFO                0,8      0t0  4253939077 pipe
nobody    1007922     stupig   6w      FIFO                0,8      0t0  4253939077 pipe
nobody    1007922     stupig   8u      IPv4         4254094660      0t0         UDP *:37087
nobody    1007922     stupig   9r       CHR                1,9      0t0        2057 /dev/urandom
nobody    1007922     stupig   10u     IPv4         4253939079      0t0         TCP *:4397 (LISTEN)
nobody    1007922     stupig   11u      REG               8,17 12538653  8604570895 ./logs/notifier.stupig.log.INFO.20211127-134138.1007922
nobody    1007922     stupig   15u     IPv4         4254204931      0t0         TCP 127.0.0.1:43566->127.0.0.1:2479 (ESTABLISHED)   # ETCD
nobody    1007922     stupig   19u      REG                8,5   252384         821 /tmp/notifier.stupig.log.ERROR.20211127-134505.1007922
nobody    1007922     stupig   20u      REG                8,5   252384         822 /tmp/notifier.stupig.log.WARNING.20211127-134505.1007922
nobody    1007922     stupig   21u      REG               8,17   414436  8606917935 ./logs/notifier.stupig.log.WARNING.20211127-134139.1007922
nobody    1007922     stupig   24u      REG               8,17   290725  8606917936 ./logs/notifier.stupig.log.ERROR.20211127-134238.1007922
nobody    1007922     stupig   30u      REG                8,5   252384         823 /tmp/notifier.stupig.log.INFO.20211127-134505.1007922

对比问题发生前的服务状态信息，我们发现一个严重的问题，notifier与kube-apiserver (服务地址：https://localhost:6443) 建立的连接消失了。

因此，notifier与kube-apiserver的数据失去了同步，其后notifier也感知不到业务的变更事件，并最终丧失了对服务的管理能力。

日志分析

现在我们分析notifier的运行日志，重点关注kube-apiserver重启时，notifier打印的日志，其中关键日志信息如下：

1
2
3
4
E1127 14:08:19.728515 1041482 reflector.go:251] notifier/monitor/endpointInformer.go:140: Failed to watch *v1.Endpoints: Get "https://127.0.0.1:6443/api/v1/endpoints?resourceVersion=276025109&timeoutSeconds=395&watch=true": http2: no cached connection was available
E1127 14:08:20.731407 1041482 reflector.go:134] notifier/monitor/endpointInformer.go:140: Failed to list *v1.Endpoints: Get "https://127.0.0.1:6443/api/v1/endpoints?limit=500&resourceVersion=0": http2: no cached connection was available
E1127 14:08:21.733509 1041482 reflector.go:134] notifier/monitor/endpointInformer.go:140: Failed to list *v1.Endpoints: Get "https://127.0.0.1:6443/api/v1/endpoints?limit=500&resourceVersion=0": http2: no cached connection was available
E1127 14:08:22.734679 1041482 reflector.go:134] notifier/monitor/endpointInformer.go:140: Failed to list *v1.Endpoints: Get "https://127.0.0.1:6443/api/v1/endpoints?limit=500&resourceVersion=0": http2: no cached connection was available

上面展示了关键的异常信息 http2: no cached connection was available ，而其关联的操作正是EndpointInformer的ListAndWatch操作。

这里我们已经掌握了关键线索，下一步，我们将结合代码分析定位根因。

代码分析

Informer的工作机制介绍不是本文重点，我们仅关注下面的代码片段：

1
2
3
4
5
6
7
8
9
10
// Run starts a watch and handles watch events. Will restart the watch if it is closed.
// Run will exit when stopCh is closed.
func (r *Reflector) Run(stopCh <-chan struct{}) {
   glog.V(3).Infof("Starting reflector %v (%s) from %s", r.expectedType, r.resyncPeriod, r.name)
   wait.Until(func() {
      if err := r.ListAndWatch(stopCh); err != nil {
         utilruntime.HandleError(err)
      }
   }, r.period, stopCh)
}

Informer的Reflector组件运行在一个独立的goroutine中，并循环调用ListAndWatch接收kube-apiserver的通知事件。

我们结合日志分析可得出结论：当kube-apiserver服务重启后，notifier服务的所有ListAndWatch操作都返回了 http2: no cached connection was available 错误。

因此，我们将关注的重点转移至该错误信息上。

通过代码检索，我们定位了该错误的定位及返回位置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// file: vendor/golang.org/x/net/http2/transport.go:L301
var ErrNoCachedConn = errors.New("http2: no cached connection was available")
 
// file: vendor/golang.org/x/net/http2/client_conn_pool.go:L55~80
func (p *clientConnPool) getClientConn(req *http.Request, addr string, dialOnMiss bool) (*ClientConn, error) {
   if isConnectionCloseRequest(req) && dialOnMiss {
      // It gets its own connection.
      const singleUse = true
      cc, err := p.t.dialClientConn(addr, singleUse)
      if err != nil {
         return nil, err
      }
      return cc, nil
   }
   p.mu.Lock()
   for _, cc := range p.conns[addr] {
      if cc.CanTakeNewRequest() {
         p.mu.Unlock()
         return cc, nil
      }
   }
   if !dialOnMiss {
      p.mu.Unlock()
      return nil, ErrNoCachedConn
   }
   call := p.getStartDialLocked(addr)
   p.mu.Unlock()
   <-call.done
   return call.res, call.err
}

上述代码返回 ErrNoCachedConn 的条件为：

  • 参数dialOnMiss值为false
  • p.conns连接池内没有可用连接

理论上，在发送http请求时，如果连接池为空，则会先建立一个连接，然后发送请求；并且连接池能够自动剔除状态异常的连接。那么本文关注的问题有时如何发生的呢？

现在我们关注 getClientConn 方法的调用链，主要有二：

栈一：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 0  0x0000000000a590b8 in notifier/vendor/golang.org/x/net/http2.(*clientConnPool).getClientConn
    at ./go/src/notifier/vendor/golang.org/x/net/http2/client_conn_pool.go:55
 1  0x0000000000a5aea6 in notifier/vendor/golang.org/x/net/http2.noDialClientConnPool.GetClientConn
    at ./go/src/notifier/vendor/golang.org/x/net/http2/client_conn_pool.go:255
 2  0x0000000000a6c4f9 in notifier/vendor/golang.org/x/net/http2.(*Transport).RoundTripOpt
    at ./go/src/notifier/vendor/golang.org/x/net/http2/transport.go:345
 3  0x0000000000a6bd0e in notifier/vendor/golang.org/x/net/http2.(*Transport).RoundTrip
    at ./go/src/notifier/vendor/golang.org/x/net/http2/transport.go:313
 4  0x0000000000a5b97e in notifier/vendor/golang.org/x/net/http2.noDialH2RoundTripper.RoundTrip
    at ./go/src/notifier/vendor/golang.org/x/net/http2/configure_transport.go:75
 5  0x0000000000828e45 in net/http.(*Transport).roundTrip
    at /usr/local/go1.16.7/src/net/http/transport.go:537
 6  0x00000000008016de in net/http.(*Transport).RoundTrip
    at /usr/local/go1.16.7/src/net/http/roundtrip.go:17
 7  0x00000000016a1ef8 in notifier/vendor/k8s.io/client-go/transport.(*userAgentRoundTripper).RoundTrip
    at ./go/src/notifier/vendor/k8s.io/client-go/transport/round_trippers.go:162
 8  0x00000000007a3aa2 in net/http.send
    at /usr/local/go1.16.7/src/net/http/client.go:251
 9  0x00000000007a324b in net/http.(*Client).send
    at /usr/local/go1.16.7/src/net/http/client.go:175
10  0x00000000007a6ed5 in net/http.(*Client).do
    at /usr/local/go1.16.7/src/net/http/client.go:717
11  0x00000000007a5d9e in net/http.(*Client).Do
    at /usr/local/go1.16.7/src/net/http/client.go:585
12  0x00000000016b9487 in notifier/vendor/k8s.io/client-go/rest.(*Request).request
    at ./go/src/notifier/vendor/k8s.io/client-go/rest/request.go:732
13  0x00000000016b9f2d in notifier/vendor/k8s.io/client-go/rest.(*Request).Do
    at ./go/src/notifier/vendor/k8s.io/client-go/rest/request.go:804
14  0x00000000017093bb in notifier/vendor/k8s.io/client-go/kubernetes/typed/core/v1.(*endpoints).List
    at ./go/src/notifier/vendor/k8s.io/client-go/kubernetes/typed/core/v1/endpoints.go:83
……

栈二：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 0  0x0000000000a590b8 in notifier/vendor/golang.org/x/net/http2.(*clientConnPool).getClientConn
    at ./go/src/notifier/vendor/golang.org/x/net/http2/client_conn_pool.go:55
 1  0x0000000000a5aea6 in notifier/vendor/golang.org/x/net/http2.noDialClientConnPool.GetClientConn
    at ./go/src/notifier/vendor/golang.org/x/net/http2/client_conn_pool.go:255
 2  0x0000000000a6c4f9 in notifier/vendor/golang.org/x/net/http2.(*Transport).RoundTripOpt
    at ./go/src/notifier/vendor/golang.org/x/net/http2/transport.go:345
 3  0x0000000000a6bd0e in notifier/vendor/golang.org/x/net/http2.(*Transport).RoundTrip
    at ./go/src/notifier/vendor/golang.org/x/net/http2/transport.go:313
 4  0x00000000008296ed in net/http.(*Transport).roundTrip
    at /usr/local/go1.16.7/src/net/http/transport.go:590
 5  0x00000000008016de in net/http.(*Transport).RoundTrip
    at /usr/local/go1.16.7/src/net/http/roundtrip.go:17
 6  0x00000000016a1ef8 in notifier/vendor/k8s.io/client-go/transport.(*userAgentRoundTripper).RoundTrip
    at ./go/src/notifier/vendor/k8s.io/client-go/transport/round_trippers.go:162
 7  0x00000000007a3aa2 in net/http.send
    at /usr/local/go1.16.7/src/net/http/client.go:251
 8  0x00000000007a324b in net/http.(*Client).send
    at /usr/local/go1.16.7/src/net/http/client.go:175
 9  0x00000000007a6ed5 in net/http.(*Client).do
    at /usr/local/go1.16.7/src/net/http/client.go:717
10  0x00000000007a5d9e in net/http.(*Client).Do
    at /usr/local/go1.16.7/src/net/http/client.go:585
11  0x00000000016b9487 in notifier/vendor/k8s.io/client-go/rest.(*Request).request
    at ./go/src/notifier/vendor/k8s.io/client-go/rest/request.go:732
12  0x00000000016b9f2d in notifier/vendor/k8s.io/client-go/rest.(*Request).Do
    at ./go/src/notifier/vendor/k8s.io/client-go/rest/request.go:804
13  0x00000000017093bb in notifier/vendor/k8s.io/client-go/kubernetes/typed/core/v1.(*endpoints).List
    at ./go/src/notifier/vendor/k8s.io/client-go/kubernetes/typed/core/v1/endpoints.go:83
……

分别跟踪两个调用栈后，我们可以很快排除栈一的因素：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
// file: net/http/transport.go:L502~620
func (t *Transport) roundTrip(req *Request) (*Response, error) {
   if altRT := t.alternateRoundTripper(req); altRT != nil {               // L537
   if resp, err := altRT.RoundTrip(req); err != ErrSkipAltProtocol {
      return resp, err
   }
   var err error
   req, err = rewindBody(req)
   if err != nil {
      return nil, err
   }
}
 
// file: vendor/golang.org/x/net/http2/configure_transport.go:L74~80
func (rt noDialH2RoundTripper) RoundTrip(req *http.Request) (*http.Response, error) {
   res, err := rt.t.RoundTrip(req)                                        // L75
   if err == ErrNoCachedConn {
      return nil, http.ErrSkipAltProtocol
   }
   return res, err
}
 
// file: vendor/golang.org/x/net/http2/transport.go:L312~314
func (t *Transport) RoundTrip(req *http.Request) (*http.Response, error) {
   return t.RoundTripOpt(req, RoundTripOpt{})                             // L313
}
 
// file: vendor/golang.org/x/net/http2/transport.go:L337~379
func (t *Transport) RoundTripOpt(req *http.Request, opt RoundTripOpt) (*http.Response, error) {
   addr := authorityAddr(req.URL.Scheme, req.URL.Host)
   for retry := 0; ; retry++ {
      cc, err := t.connPool().GetClientConn(req, addr)                    // L345
      if err != nil {
         t.vlogf("http2: Transport failed to get client conn for %s: %v", addr, err)
         return nil, err
      }
   }
}
 
// file: vendor/golang.org/x/net/http2/client_conn_pool.go:L254~256
func (p noDialClientConnPool) GetClientConn(req *http.Request, addr string) (*ClientConn, error) {
   return p.getClientConn(req, addr, noDialOnMiss)                        // L255
}

栈一调用 getClientConn 返回了 ErrNoCachedConn 错误，并在 noDialH2RoundTripper.RoundTrip 函数中被替换为 http.ErrSkipAltProtocol 错误，返回 roundTrip 函数后继续执行余下流程，并进入栈二的流程。

因此我们重点关注栈二的流程：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
// file: net/http/transport.go:L502~620
func (t *Transport) roundTrip(req *Request) (*Response, error) {
   for {
      var resp *Response
      if pconn.alt != nil {
         // HTTP/2 path.
         t.setReqCanceler(cancelKey, nil) // not cancelable with CancelRequest
         resp, err = pconn.alt.RoundTrip(req)                             // L590
      }
      if err == nil {
         resp.Request = origReq
         return resp, nil
      }
 
      // Failed. Clean up and determine whether to retry.
      if http2isNoCachedConnError(err) {
         if t.removeIdleConn(pconn) {
            t.decConnsPerHost(pconn.cacheKey)
         }
      } else if !pconn.shouldRetryRequest(req, err) {
         return nil, err
      }
   }
}
 
// file: vendor/golang.org/x/net/http2/transport.go:L312~314
func (t *Transport) RoundTrip(req *http.Request) (*http.Response, error) {
   return t.RoundTripOpt(req, RoundTripOpt{})                             // L313
}
 
// 内层调用栈同栈一，不再列出

区别于栈一，栈二不再对返回错误做一个转换，而是直接返回了 ErrNoCachedConn 错误，并且 roundTrip 的错误处理流程中也特殊处理了本类错误。如果检测 http2isnoCachedConnError 返回true，则连接池会移除该异常连接。

一切都那么的合乎情理，那么问题是如何发生的呢？这里问题就发生在 http2isnoCachedConnError：

1
2
3
4
5
6
7
8
// file: net/http/h2_bundle.go:L6922~6928
// isNoCachedConnError reports whether err is of type noCachedConnError
// or its equivalent renamed type in net/http2's h2_bundle.go. Both types
// may coexist in the same running program.
func http2isNoCachedConnError(err error) bool {
   _, ok := err.(interface{ IsHTTP2NoCachedConnError() })
   return ok
}

如果 err 对象实现了匿名接口 (仅定义了一个函数 IsHTTP2NoCachedConnError)，那么返回true，否则返回false。

那么，getClientConn 返回的错误类型实现了该接口吗？很显然：没有。

1
2
// file: vendor/golang.org/x/net/http2/transport.go:L301
var ErrNoCachedConn = errors.New("http2: no cached connection was available")

至此，问题发生的原因已基本定位清楚。

解决方案

既然问题是由于 getClientConn 返回的错误类型 ErrNoCachedConn 没有实现 IsHTTP2NoCachedConnError 函数引起，那么其修复策略自然是：修改返回错误类型，并实现该接口函数。

注意，由于该部分代码是我们引用的外部代码库的内容，我们检查最新的 golang.org/x/net 代码发现，问题早在2018年1月份就已被修复。。。具体参见：golang.org/x/net修复方案。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// noCachedConnError is the concrete type of ErrNoCachedConn, which
// needs to be detected by net/http regardless of whether it's its
// bundled version (in h2_bundle.go with a rewritten type name) or
// from a user's x/net/http2. As such, as it has a unique method name
// (IsHTTP2NoCachedConnError) that net/http sniffs for via func
// isNoCachedConnError.
type noCachedConnError struct{}

func (noCachedConnError) IsHTTP2NoCachedConnError() {}
func (noCachedConnError) Error() string             { return "http2: no cached connection was available" }

// isNoCachedConnError reports whether err is of type noCachedConnError
// or its equivalent renamed type in net/http2's h2_bundle.go. Both types
// may coexist in the same running program.
func isNoCachedConnError(err error) bool {
_, ok := err.(interface{ IsHTTP2NoCachedConnError() })
return ok
}

var ErrNoCachedConn error = noCachedConnError{}

而我们线上使用的版本仍然为：1c05540f6。

因此，我们的修复策略变得更为简单，升级vendor中的依赖库版本即可。

目前，线上notifier服务已升级依赖版本，全量上线所有机房。并且也已验证kube-apiserver重启，不会导致notifier服务异常。

]]> <h1 id="背景"><a href="#背景" class="headerlink" title="背景"></a>背景</h1><p>长期以来，弹性云线上服务一直饱受缓存不一致的困扰。</p> <p>缓存不一致的发生一般伴随着kube-apiserver的升级或重启。且当缓 pod terminating 排查之旅(二) https://plpan.github.io/pod-terminating-%E6%8E%92%E6%9F%A5%E4%B9%8B%E6%97%85-%E4%BA%8C/ 2021-06-24T08:39:23.000Z 2021-06-28T02:19:32.413Z 背景

近期，线上报障了多起Pod删除失败的Case，用户的多次删除请求均已失败告终。Pod删除失败的影响主要有二：

  • 面向用户：用户体验下降，且无法对该Pod执行后续的发布流程
  • 面向弹性云：失败率提升，SLA无法达标

并且，随着弹性云Docker版本升级 (1.13 → 18.06) 进度的推进，线上出现Pod删除失败的Case隐隐有增多的趋势。

线上问题无小事！不论是从哪个角度出发，我们都应该给线上环境把把脉，看看是哪个系统出了问题。

问题定位

由于线上出Case的频率并不低，基本每周都会出现，这反而给我们定位问题带来了便利^_^。

排查线上问题的思路一般分如下两个步骤：

  • 定位出现问题的组件
  • 定位组件出现的问题

组件定位

对于弹性云的同学来说，定位问题组件已经有一套标准流程：从上往下，看看问题是由哪个组件引起。【不清楚组件通信流程的同学可以看看容器删除失败排查】

1）第一嫌疑人：kubelet

在kubernetes体系架构下，删除Pod的执行者就是kubelet，作为第一个提审对象，它不冤。

虽然无奈，但是kubelet也早已习惯了，并且在多次经历过社会的毒打之后，练就了一身的甩锅能力：

1
I0624 11:00:26.658872   21280 kubelet.go:1923] skipping pod synchronization - [PLEG is not healthy: pleg was last seen active 3m0.439656895s ago; threshold is 3m0s]

什么意思？死贫道不死道友呗。

PLEG模块不健康？PLEG是kubelet的一个子模块单元，用来统一管理底层容器的运行状态。

kubelet招供：我是好人啊，不能冤枉我，都是docker惹的祸！

2）第二嫌疑人：dockerd

根据kubelet的证词，我们很快提审本案的第二嫌疑人：dockerd。

为自证清白，dockerd三下五除二打出一套军体拳：

1
2
3
4
# docker ps
// 运行正常，dockerd轻舒一口气
# docker ps -a | grep -V NAMES | awk '{print $1}' | xargs -ti docker inspect -f {{.State.Pid}} {}
// 执行到 docker inspect -f {{.State.Pid}} 60f253d59f26 时，命令卡住

该容器恰好属于用户删除失败的Pod。

你们可能没看到当时dockerd的脸色，面如死灰，且一直喃喃自语：难道真是我的锅？

好几分钟后，dockerd才慢慢缓过来，理了理思绪，想好了一套甩锅流程：虽然问题出现在我这，但是你们的证据不足，不能证明是我亲手干的。我手下养着一大帮人，可能是一些小弟自己偷偷干的。

嘿，你还有理了，那好，我继续收集证据，让你死的明明白白。

3）第三嫌疑人：containerd

作为dockerd手下的二当家，我们首先传讯了containerd。这人一看就老实忠厚，它看着dockerd的证词，苦笑了下，吐槽到：跟着大哥这么多年，还是没有得到大哥的信任（所以kubernetes在1.20版本中，将containerd扶上了大哥的位置？哈哈）。

containerd有条不紊的祭出三板斧：

1
2
3
4
5
6
# docker-containerd-ctr -a /var/run/docker/containerd/docker-containerd.sock -n moby c ls
// 运行正常
# docker-containerd-ctr -a /var/run/docker/containerd/docker-containerd.sock -n moby t ls
// 命令卡死，containerd老脸一僵，但是很快恢复正常
# docker-containerd-ctr -a /var/run/docker/containerd/docker-containerd.sock -n moby c ls | grep -v IMAGE | awk '{print $1}' | xargs -ti docker-containerd-ctr -a /var/run/docker/containerd/docker-containerd.sock -n moby t ps {}
// 执行到 docker-containerd-ctr -a /var/run/docker/containerd/docker-containerd.sock -n moby t ps 60f253d59f26e1c573d4ba5f824e73b3a4b1bb1629edace85caba4c620755d4d 时，命令卡住

containerd神色不自然的说：不好意思啊，警官，可能是我家里不争气的孩子惹的祸，这孩子以前也犯过事【docker hang 死排查】。

4）第四嫌疑人：containerd-shim

containerd的话还没说完，待在一旁的儿子containerd-shim跳出来指着containerd叛逆地说：你凭什么说是我？你自己干的那些破事，我都不稀罕说你。

清官难断家务事！案件排查至此，从已知证据，还真不好确认到底是老子，还是儿子犯的罪。

5）第五嫌疑人：runc

万般无奈，我们清楚了本案的最后一个嫌疑人，也是年纪最小的runc。runc只会呀呀自语地说：不是我，不是我！

1
2
# docker-runc --root /var/run/docker/runtime-runc/moby/ list
60f253d59f26e1c573d4ba5f824e73b3a4b1bb1629edace85caba4c620755d4d   0           stopped     /run/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/60f253d59f26e1c573d4ba5f824e73b3a4b1bb1629edace85caba4c620755d4d   2021-05-07T12:43:02.62261156Z    root

从现场收集到的证据表明，这个案件和runc还真没什么关系，案发时，它已经离开了现场，只不过留下了一个烂摊子等着别人来清理。

从众人招供的语录来看，案件嫌疑人初步锁定了containerd与containerd-shim，但是具体是谁，都还不好说。

正当大家一筹莫展之际，一位老刑警从现场提取到了一些新的线索，案件终于有了新的进展。

6）新线索

老刑警领着大家观察它收集到的新线索：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
# sudo docker ps -a | grep PODNAME
60f253d59f26  image      "/dockerinit"  6 weeks ago    Up 6 weeks                        k8s_CNAME_PODNAME_default_013e3b0e-8d17-11eb-8ef7-246e9693e13c_10
6e6fc586dc12  pause:3.1  "/pause"       6 weeks ago    Exited (0) About an hour ago      k8s_POD_PODNAME_default_013e3b0e-8d17-11eb-8ef7-246e9693e13c_1
 
 
# ps -ef|grep 60f253d59f26
root      119820    3608  0 May07 ?        00:11:16 docker-containerd-shim -namespace moby -workdir /docker/docker_rt/containerd/daemon/io.containerd.runtime.v1.linux/moby/60f253d59f26e1c573d4ba5f824e73b3a4b1bb1629edace85caba4c620755d4d -address /var/run/docker/containerd/docker-containerd.sock -containerd-binary /usr/bin/docker-containerd -runtime-root /var/run/docker/runtime-runc
stupig    1629698 1599793  0 11:44 pts/0    00:00:00 grep --color=auto 60f253d59f26
 
 
# ps -ef|grep 119820
root       40825  119820  0 Jun04 ?        00:00:00 [su] <defunct>
76183      40833  119820  0 Jun04 ?        00:00:00 [bash] <defunct>
root      119820    3608  0 May07 ?        00:11:16 docker-containerd-shim -namespace moby -workdir /docker/docker_rt/containerd/daemon/io.containerd.runtime.v1.linux/moby/60f253d59f26e1c573d4ba5f824e73b3a4b1bb1629edace85caba4c620755d4d -address /var/run/docker/containerd/docker-containerd.sock -containerd-binary /usr/bin/docker-containerd -runtime-root /var/run/docker/runtime-runc
root      119886  119820  0 May07 ?        00:04:29 [dockerinit] <defunct>
root      568896  119820  0 Jun07 ?        00:00:00 [su] <defunct>
76183     568898  119820  0 Jun07 ?        00:00:00 [bash] <defunct>
root      695031  119820  0 May08 ?        00:00:00 [su] <defunct>
74647     695037  119820  0 May08 ?        00:00:00 [bash] <defunct>
root      802705  119820  0 Jun09 ?        00:00:00 [su] <defunct>
74647     802709  119820  0 Jun09 ?        00:00:00 [bash] <defunct>
root      865131  119820  0 Jun07 ?        00:00:00 [su] <defunct>
69099     865133  119820  0 Jun07 ?        00:00:00 [bash] <defunct>
root     1073407  119820  0 Jun23 ?        00:00:00 [su] <defunct>
76183    1073428  119820  0 Jun23 ?        00:00:00 [bash] <defunct>
root     1375526  119820  0 Jun22 ?        00:00:00 [su] <defunct>
69099    1375561  119820  0 Jun22 ?        00:00:00 [bash] <defunct>
root     1397568  119820  0 Jun16 ?        00:00:00 [su] <defunct>
69099    1397570  119820  0 Jun16 ?        00:00:00 [bash] <defunct>
root     1483339  119820  0 Jun23 ?        00:00:00 [su] <defunct>
76183    1483341  119820  0 Jun23 ?        00:00:00 [bash] <defunct>
stupig   1631234 1599793  0 11:44 pts/0    00:00:00 grep --color=auto 119820
root     1692888  119820  0 Jun07 ?        00:00:00 [su] <defunct>
76183    1692903  119820  0 Jun07 ?        00:00:00 [bash] <defunct>
root     1882984  119820  0 Jun21 ?        00:00:00 [su] <defunct>
76183    1882985  119820  0 Jun21 ?        00:00:00 [bash] <defunct>
root     1964311  119820  0 Jun07 ?        00:00:00 [su] <defunct>
76183    1964318  119820  0 Jun07 ?        00:00:00 [bash] <defunct>
root     2019760  119820  0 Jun07 ?        00:00:00 [su] <defunct>
76183    2019784  119820  0 Jun07 ?        00:00:00 [bash] <defunct>
root     2122420  119820  0 Jun07 ?        00:00:00 [su] <defunct>
76183    2122434  119820  0 Jun07 ?        00:00:00 [bash] <defunct>
root     2288703  119820  0 Jun09 ?        00:00:00 [su] <defunct>
69099    2288705  119820  0 Jun09 ?        00:00:00 [bash] <defunct>
root     2330164  119820  0 Jun07 ?        00:00:00 [su] <defunct>
76183    2330166  119820  0 Jun07 ?        00:00:00 [bash] <defunct>
root     2406740  119820  0 May27 ?        00:00:00 [su] <defunct>
74647    2406745  119820  0 May27 ?        00:00:00 [bash] <defunct>
root     2421050  119820  0 Jun07 ?        00:00:00 [su] <defunct>
76183    2421069  119820  0 Jun07 ?        00:00:00 [bash] <defunct>
root     2445918  119820  0 Jun22 ?        00:00:00 [su] <defunct>
76183    2445927  119820  0 Jun22 ?        00:00:00 [bash] <defunct>
root     2487600  119820  0 Jun22 ?        00:00:00 [su] <defunct>
76183    2487602  119820  0 Jun22 ?        00:00:00 [bash] <defunct>
root     2897660  119820  0 Jun07 ?        00:00:00 [su] <defunct>
76183    2897662  119820  0 Jun07 ?        00:00:00 [bash] <defunct>

同一个Pod内pause容器依然退出，但是业务容器却没有退出，并且业务容器关联的containerd-shim进程并未执行子进程收割动作，就像是卡住了。

面对这些新证据，containerd-shim毫无征兆地崩溃了，大哭道：为什么总是我？

问题定位

言归正传，我们如何能根据上述现象快速定位问题呢？思路有三：

  1. 拿着现象问谷歌
  2. 带着问题看代码
  3. 深挖现场定问题

1）谷歌大法

当我们拿着问题呈现的现象搜索谷歌时，还真搜到了关联的内容：Exec process may cause shim hang。

该issue中所描述的内容和我们碰到的问题基本一致。问题是由于 reaper.Default 处定义的channel大小太小引起的，调整channel大小可规避该问题。

2）理解代码

尽管本问题可以通过一些手段规避，但是我们还是需要理解代码中出现的问题。

containerd-shim的主要事务是执行runc命令，主要功能是托管真正的容器进程，并暴露一个服务，供外部用户与容器进行交互。

containerd-shim内部处理逻辑如下图所示：

containerd-shim简单架构

GRPC服务：containerd-shim的核心服务，对外暴露众多接口，诸如创建/启动task等，并调用runc执行对应的命令。

此外，containerd-shim内启动了三个协程（包含主协程）共同处理容器内进程退出事件。首先是主协程handleSignals：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
func handleSignals(logger *logrus.Entry, signals chan os.Signal, server *ttrpc.Server, sv *shim.Service) error {
   signals := make(chan os.Signal, 32)
   signal.Notify(signals, unix.SIGTERM, unix.SIGINT, unix.SIGCHLD, unix.SIGPIPE)
   runc.Monitor = reaper.Default
   // set the shim as the subreaper for all orphaned processes created by the container
   if err := system.SetSubreaper(1); err != nil {
      return nil, err
   }
   for {
      select {
      case s := <-signals:
         switch s {
         case unix.SIGCHLD:
            if err := reaper.Reap(); err != nil {
               logger.WithError(err).Error("reap exit status")
            }
         case unix.SIGTERM, unix.SIGINT:
            // shim退出处理
         }
      }
   }
}

containerd-shim调用system.SetSubreaper将自己作为容器内进程的收割者，一般容器内的1号进程也具备收割僵尸进程的能力，因此containerd-shim更多的是收割runc exec进容器内的进程。

当有僵尸进程出现时，就执行收割逻辑：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
func Reap() error {
   now := time.Now()
   exits, err := sys.Reap(false)          // 调用wait系统调用处理僵尸进程
   Default.Lock()
   for c := range Default.subscribers {   // 将退出事件发送给所有订阅者
      for _, e := range exits {
         c <- runc.Exit{
            Timestamp: now,
            Pid:       e.Pid,
            Status:    e.Status,
         }
      }
 
   }
   Default.Unlock()
   return err
}

那么谁又是订阅者呢？shim在初始化时就订阅了一份进程退出事件：

1
2
3
4
5
6
7
8
9
10
11
func NewService(config Config, publisher events.Publisher) (*Service, error) {
   s := &Service{
      processes: make(map[string]proc.Process),
      events:    make(chan interface{}, 128),
      ec:        reaper.Default.Subscribe(),    // 订阅进程退出事件
   }
   go s.processExits()                          // 退出事件处理
   go s.forward(publisher)                      // 退出事件转发
   return s, nil
}

其中退出事件处理逻辑如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
func (s *Service) processExits() {
   for e := range s.ec {
      s.checkProcesses(e)
   }
}
func (s *Service) checkProcesses(e runc.Exit) {
   s.mu.Lock()
   defer s.mu.Unlock()
   for _, p := range s.processes {
      if p.Pid() == e.Pid {
         s.events <- &eventstypes.TaskExit{}
         return
      }
   }
}

只处理s.processes的退出事件，而s.processes关联的都是什么对象呢？主要有二：

1
2
3
4
5
6
7
8
9
10
11
12
// Create a new initial process and container with the underlying OCI runtime
func (s *Service) Create(ctx context.Context, r *shimapi.CreateTaskRequest) (*shimapi.CreateTaskResponse, error) {
   ......
   s.processes[r.ID] = process
   ......
}
// Exec an additional process inside the container
func (s *Service) Exec(ctx context.Context, r *shimapi.ExecProcessRequest) (*ptypes.Empty, error) {
   ......
   s.processes[r.ID] = process
   ......
}

代码就展示这些，其他代码大家感兴趣的自己查阅。

现在，我们再来根据现象查问题。从现象可知，异常容器待收割的僵尸进程较多，肯定超过了32个。当shim在收割众多僵尸进程时，往订阅者信道(大小32)中发送时，出现阻塞，阻塞点：阻塞信号，并且此时持有Default.Lock这一把大锁。

那么只要这时候再有人来申请这把锁，就会形成死锁。

那么究竟谁会来申请这把锁呢？这时候，要是能查看containerd-shim的协程栈就好了。

3）现场分析

确实，containerd-shim启动了一个协程方便用户导出协程栈信息，我们来看看能不能行呢？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
func executeShim() error {
   dump := make(chan os.Signal, 32)
   signal.Notify(dump, syscall.SIGUSR1)
   go func() {
      for range dump {
         dumpStacks(logger)
      }
   }()
}
func dumpStacks(logger *logrus.Entry) {
   var (
      buf       []byte
      stackSize int
   )
   bufferLen := 16384
   for stackSize == len(buf) {
      buf = make([]byte, bufferLen)
      stackSize = runtime.Stack(buf, true)
      bufferLen *= 2
   }
   buf = buf[:stackSize]
   logger.Infof("=== BEGIN goroutine stack dump ===\n%s\n=== END goroutine stack dump ===", buf)
}

一切看起来貌似没什么问题，我们发送SIGUSR1就能获取一份协程栈。

当我们真正去执行时，却发现到处了一个寂寞。根本原因在于：

  • logger.Infof()往os.Stdout输出
  • 由于线上环境docker没有开启debug模式，线上containerd-shim的os.Stdout被赋值为/dev/null
1
2
3
4
5
6
7
COMMAND       PID USER   FD      TYPE             DEVICE SIZE/OFF       NODE NAME
docker-co  119820 root  cwd       DIR               0,18      120  916720892 /run/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/60f253d59f26e1c573d4ba5f824e73b3a4b1bb1629edace85caba4c620755d4d
docker-co  119820 root  rtd       DIR                8,3     4096          2 /
docker-co  119820 root  txt       REG                8,3  4173632     392525 /usr/bin/docker-containerd-shim
docker-co  119820 root    0r      CHR                1,3      0t0       2052 /dev/null
docker-co  119820 root    1w      CHR                1,3      0t0       2052 /dev/null
docker-co  119820 root    2w      CHR                1,3      0t0       2052 /dev/null

问题排查至此，似乎又僵住了！好在，之前看过一丢丢内核问题排查相关知识。虽然线上containerd-shim将协程栈的信息全部导出到了/dev/null中，但是我们还是有一些手段获取。

赶紧找组里的内核大佬帮忙，并很快确定了方案，基于kprobe，在操作系统往/dev/null设备写入协程栈时，拷贝一份内容写到内核日志中。方案实施起来也不复杂：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/kprobes.h>
#include <linux/sched.h>
#include <asm/uaccess.h>
#include <linux/slab.h>
 
static int pid;
module_param(pid, int, 0);
 
static struct kprobe kp = {
    .symbol_name    = "write_null",
};
 
#define SEGMENT 512
 
static int handler_pre(struct kprobe *p, struct pt_regs *regs)
{
    char *wbuf;
    size_t count, place = 0;
 
    if (pid != current->tgid) {
        return 0;
    }
 
    count = (size_t)(regs->dx);
 
    printk(KERN_INFO "%u call write_null count: %lu\n", current->tgid, count);
 
    wbuf = (char *)kmalloc(count + 1, 0);
    if (wbuf == NULL) {
        return 0;
    }
    memset(wbuf, 0x0, count + 1);
 
    if (copy_from_user(wbuf, (void *)regs->si, count)) {
        printk(KERN_ERR "copy_from_user fail\n");
        return 0;
    }
 
    while (place < count) {
        char tmp[SEGMENT + 1];
        memset(tmp, 0x0, SEGMENT + 1);
 
        snprintf(tmp, SEGMENT + 1, "%s", wbuf + place);
        if ((count - place) >= SEGMENT) {
            place += SEGMENT;
        } else {
            place = count;
        }
        printk(KERN_INFO "%s\n", tmp);
    }
 
    if (wbuf) {
        kfree(wbuf);
    }
 
    return 0;
}
 
static int __init kprobe_init(void)
{
    int ret;
    kp.pre_handler = handler_pre;
 
    ret = register_kprobe(&kp);
    if (ret < 0) {
        printk(KERN_INFO "register_kprobe failed, returned %d\n", ret);
        return ret;
    }
    printk(KERN_INFO "Planted kprobe at %p\n", kp.addr);
    return 0;
}
 
static void __exit kprobe_exit(void)
{
    unregister_kprobe(&kp);
    printk(KERN_INFO "kprobe at %p unregistered\n", kp.addr);
}
 
module_init(kprobe_init)
module_exit(kprobe_exit)
MODULE_LICENSE("GPL");

这里着重感谢睿哥提供的kprobe代码。kprobe的相关知识，感兴趣的自己学习下。

我们在线上部署了该kprobe内核模块之后，往containerd-shim发送SIGUSR1顺利获取了协程栈信息。终于补全了问题排查的最后一块拼盘。

补：这里重点感谢飞哥（不愧是老中医）的提醒，其实还有一个非常简单的方法获取协程栈：借助strace跟踪进程的系统调用。

线上containerd-shim的协程栈信息(删减了大量不重要协程栈，并调整了格式)展示如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
time="2021-06-23T16:35:07+08:00" level=info msg="=== BEGIN goroutine stack dump ===
goroutine 22 [running]:
main.dumpStacks(0xc4201c81e0)
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/cmd/containerd-shim/main_unix.go:228 +0x8a
main.executeShim.func1(0xc42012c300, 0xc4201c81e0)
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/cmd/containerd-shim/main_unix.go:148 +0x3d
created by main.executeShim
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/cmd/containerd-shim/main_unix.go:146 +0x5de
 
goroutine 1 [chan send, 83 minutes]:
github.com/containerd/containerd/reaper.Reap(0xc420243be0, 0x1)
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/reaper/reaper.go:44 +0x168
main.handleSignals(0xc4201c81e0, 0xc42012c240, 0xc4201d6090, 0xc4201e4000, 0xc420117ea0, 0x86)
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/cmd/containerd-shim/main_unix.go:197 +0x2a1
main.executeShim(0x2, 0x60)
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/cmd/containerd-shim/main_unix.go:151 +0x616
main.main()
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/cmd/containerd-shim/main_unix.go:96 +0x81
 
goroutine 5 [syscall]:
os/signal.signal_recv(0x6c14c0)
      /usr/local/go/src/runtime/sigqueue.go:139 +0xa6
os/signal.loop()
      /usr/local/go/src/os/signal/signal_unix.go:22 +0x22
created by os/signal.init.0
      /usr/local/go/src/os/signal/signal_unix.go:28 +0x41
 
goroutine 6 [chan receive]:
main.main.func1()
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/cmd/containerd-shim/main_unix.go:81 +0x7b
created by main.main
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/cmd/containerd-shim/main_unix.go:80 +0x46
 
goroutine 7 [select, 92427 minutes, locked to thread]:
runtime.gopark(0x6a70a0, 0x0, 0x696b74, 0x6, 0x18, 0x1)
      /usr/local/go/src/runtime/proc.go:291 +0x11a
runtime.selectgo(0xc420104f50, 0xc42014a180)
      /usr/local/go/src/runtime/select.go:392 +0xe50
runtime.ensureSigM.func1()
      /usr/local/go/src/runtime/signal_unix.go:549 +0x1f4
runtime.goexit()
      /usr/local/go/src/runtime/asm_amd64.s:2361 +0x1
 
goroutine 18 [semacquire, 83 minutes]:
sync.runtime_SemacquireMutex(0xc4201e4004, 0x403200)
      /usr/local/go/src/runtime/sema.go:71 +0x3d
sync.(*Mutex).Lock(0xc4201e4000)
      /usr/local/go/src/sync/mutex.go:134 +0x108
github.com/containerd/containerd/linux/shim.(*Service).checkProcesses(0xc4201e4000, 0xc02cd591b40305ef, 0x13af4280e2630f, 0x7fc440, 0x1c11b, 0x0)
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/linux/shim/service.go:470 +0x45
github.com/containerd/containerd/linux/shim.(*Service).processExits(0xc4201e4000)
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/linux/shim/service.go:465 +0xd0
created by github.com/containerd/containerd/linux/shim.NewService
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/linux/shim/service.go:86 +0x3e9
 
goroutine 19 [syscall, 83 minutes]:
syscall.Syscall6(0xe8, 0x4, 0xc4201189b8, 0x80, 0xffffffffffffffff, 0x0, 0x0, 0xc420118938, 0x45b793, 0xc42047add0)
      /usr/local/go/src/syscall/asm_linux_amd64.s:44 +0x5
github.com/containerd/containerd/vendor/golang.org/x/sys/unix.EpollWait(0x4, 0xc4201189b8, 0x80, 0x80, 0xffffffffffffffff, 0x5, 0x0, 0x0)
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/vendor/golang.org/x/sys/unix/zsyscall_linux_amd64.go:1518 +0x7a
github.com/containerd/containerd/vendor/github.com/containerd/console.(*Epoller).Wait(0xc4201be060, 0xc420117aa8, 0xc420117ab0)
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/vendor/github.com/containerd/console/console_linux.go:110 +0x7a
created by github.com/containerd/containerd/linux/shim.(*Service).initPlatform
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/linux/shim/service_linux.go:109 +0xc6
 
goroutine 20 [chan receive, 83 minutes]:
github.com/containerd/containerd/linux/shim.(*Service).forward(0xc4201e4000, 0x6c0600, 0xc4201d4010)
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/linux/shim/service.go:514 +0x62
created by github.com/containerd/containerd/linux/shim.NewService
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/linux/shim/service.go:90 +0x49b
 
goroutine 21 [IO wait, 92427 minutes]:
internal/poll.runtime_pollWait(0x7f75331fcf00, 0x72, 0x0)
      /usr/local/go/src/runtime/netpoll.go:173 +0x57
internal/poll.(*pollDesc).wait(0xc4201e6118, 0x72, 0xc420010100, 0x0, 0x0)
      /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x9b
internal/poll.(*pollDesc).waitRead(0xc4201e6118, 0xffffffffffffff00, 0x0, 0x0)
      /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x3d
internal/poll.(*FD).Accept(0xc4201e6100, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
      /usr/local/go/src/internal/poll/fd_unix.go:372 +0x1a8
net.(*netFD).accept(0xc4201e6100, 0xc4201d60a0, 0xc4201d6060, 0xc4201563c0)
      /usr/local/go/src/net/fd_unix.go:238 +0x42
net.(*UnixListener).accept(0xc4201d6270, 0x451c70, 0xc42011cea8, 0xc42011ceb0)
      /usr/local/go/src/net/unixsock_posix.go:162 +0x32
net.(*UnixListener).Accept(0xc4201d6270, 0x6a6b10, 0xc4201563c0, 0x6c3840, 0xc420012018)
      /usr/local/go/src/net/unixsock.go:253 +0x49
github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc.(*Server).Serve(0xc4201d6090, 0x6c3440, 0xc4201d6270, 0x0, 0x0)
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc/server.go:69 +0x106
main.serve.func1(0x6c3440, 0xc4201d6270, 0xc4201d6090)
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/cmd/containerd-shim/main_unix.go:176 +0x71
created by main.serve
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/cmd/containerd-shim/main_unix.go:174 +0x1be
 
goroutine 8 [select, 83 minutes]:
github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc.(*serverConn).run(0xc4201563c0, 0x6c3840, 0xc420012018)
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc/server.go:398 +0x3f0
created by github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc.(*Server).Serve
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc/server.go:109 +0x25c
 
goroutine 9 [IO wait, 83 minutes]:
internal/poll.runtime_pollWait(0x7f75331fce30, 0x72, 0xc42011ea48)
      /usr/local/go/src/runtime/netpoll.go:173 +0x57
internal/poll.(*pollDesc).wait(0xc4201a0118, 0x72, 0xffffffffffffff00, 0x6c0a40, 0x7e11b8)
      /usr/local/go/src/internal/poll/fd_poll_runtime.go:85 +0x9b
internal/poll.(*pollDesc).waitRead(0xc4201a0118, 0xc4201ed000, 0x1000, 0x1000)
      /usr/local/go/src/internal/poll/fd_poll_runtime.go:90 +0x3d
internal/poll.(*FD).Read(0xc4201a0100, 0xc4201ed000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
      /usr/local/go/src/internal/poll/fd_unix.go:157 +0x17d
net.(*netFD).Read(0xc4201a0100, 0xc4201ed000, 0x1000, 0x1000, 0xc42011eb30, 0x451430, 0xc420001b00)
      /usr/local/go/src/net/fd_unix.go:202 +0x4f
net.(*conn).Read(0xc42000c050, 0xc4201ed000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
      /usr/local/go/src/net/net.go:176 +0x6a
bufio.(*Reader).Read(0xc42012c480, 0xc4200105a0, 0xa, 0xa, 0x0, 0x2, 0x2)
      /usr/local/go/src/bufio/bufio.go:216 +0x238
io.ReadAtLeast(0x6c02c0, 0xc42012c480, 0xc4200105a0, 0xa, 0xa, 0xa, 0x6c62e0, 0xc42011ef50, 0x0)
      /usr/local/go/src/io/io.go:309 +0x86
io.ReadFull(0x6c02c0, 0xc42012c480, 0xc4200105a0, 0xa, 0xa, 0xc42011eef0, 0x3, 0x3)
      /usr/local/go/src/io/io.go:327 +0x58
github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc.readMessageHeader(0xc4200105a0, 0xa, 0xa, 0x6c02c0, 0xc42012c480, 0xc42011ee70, 0x2, 0x2, 0xc42011eed0)
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc/channel.go:38 +0x60
github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc.(*channel).recv(0xc420010580, 0x6c3800, 0xc4200105c0, 0x0, 0xc420392940, 0x0, 0x0, 0x73, 0x0, 0x0)
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc/channel.go:86 +0x6d
github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc.(*serverConn).run.func1(0xc42014a2a0, 0xc4201563c0, 0xc42014a360, 0xc420010580, 0x6c3800, 0xc4200105c0, 0xc42014a300, 0xc42012c4e0)
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc/server.go:329 +0x1bf
created by github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc.(*serverConn).run
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc/server.go:299 +0x247
 
goroutine 22661144 [chan receive, 83 minutes]:
github.com/containerd/containerd/reaper.(*Monitor).Wait(0x7fb5d0, 0xc42017a580, 0xc420674360, 0x0, 0x0, 0x68c3c0)
    /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/reaper/reaper.go:82 +0x52
github.com/containerd/containerd/vendor/github.com/containerd/go-runc.cmdOutput(0xc42017a580, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0)
    /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/vendor/github.com/containerd/go-runc/runc.go:693 +0x110
github.com/containerd/containerd/vendor/github.com/containerd/go-runc.(*Runc).runOrError(0xc42018b6c0, 0xc42017a580, 0xc4200105c0, 0xc4201d6c30)
    /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/vendor/github.com/containerd/go-runc/runc.go:673 +0x19b
github.com/containerd/containerd/vendor/github.com/containerd/go-runc.(*Runc).Kill(0xc42018b6c0, 0x6c3800, 0xc4200105c0, 0xc420014480, 0x40, 0xf, 0xc42054bbc7, 0xc420393080, 0xc42012d9e0)
    /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/vendor/github.com/containerd/go-runc/runc.go:320 +0x1e2
github.com/containerd/containerd/linux/proc.(*Init).kill(0xc42018c3c0, 0x6c3800, 0xc4200105c0, 0xf, 0x40, 0xc42054bc01)
    /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/linux/proc/init.go:341 +0x78
github.com/containerd/containerd/linux/proc.(*runningState).Kill(0xc4201ca030, 0x6c3800, 0xc4200105c0, 0xf, 0x0, 0x0)
    /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/linux/proc/init_state.go:331 +0xa5
github.com/containerd/containerd/linux/shim.(*Service).Kill(0xc4201e4000, 0x6c3800, 0xc4200105c0, 0xc42000a940, 0x0, 0x0, 0x0)
    /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/linux/shim/service.go:356 +0x271
github.com/containerd/containerd/linux/shim/v1.RegisterShimService.func10(0x6c3800, 0xc4200105c0, 0xc42000a920, 0xc4201ce968, 0x4, 0xc4201be1a0, 0x0)
    /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/linux/shim/v1/shim.pb.go:1670 +0xc5
github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc.(*serviceSet).dispatch(0xc4201ca008, 0x6c3800, 0xc4200105c0, 0xc4204e6570, 0x25, 0xc4201ce968, 0x4, 0xc420226c30, 0x44, 0x44, ...)
    /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc/services.go:71 +0x10e
github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc.(*serviceSet).call(0xc4201ca008, 0x6c3800, 0xc4200105c0, 0xc4204e6570, 0x25, 0xc4201ce968, 0x4, 0xc420226c30, 0x44, 0x44, ...)
    /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc/services.go:44 +0xb5
github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc.(*serverConn).run.func2(0xc4201563c0, 0x6c3800, 0xc4200105c0, 0xace455, 0xc420392900, 0xc42014a2a0, 0xc42014a360,0xc400ace455)
    /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc/server.go:402 +0xaa
created by github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc.(*serverConn).run
    /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc/server.go:401 +0x763
 
goroutine 22661145 [semacquire, 83 minutes]:
sync.runtime_SemacquireMutex(0xc4201e4004, 0x64b800)
      /usr/local/go/src/runtime/sema.go:71 +0x3d
sync.(*Mutex).Lock(0xc4201e4000)
      /usr/local/go/src/sync/mutex.go:134 +0x108
github.com/containerd/containerd/linux/shim.(*Service).State(0xc4201e4000, 0x6c3800, 0xc4200105c0, 0xc420120af0, 0x0, 0x0, 0x0)
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/linux/shim/service.go:271 +0x59
github.com/containerd/containerd/linux/shim/v1.RegisterShimService.func1(0x6c3800, 0xc4200105c0, 0xc42000a980, 0xc4201ce988, 0x5, 0xc4201be080, 0x0)
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/linux/shim/v1/shim.pb.go:1607 +0xc8
github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc.(*serviceSet).dispatch(0xc4201ca008, 0x6c3800, 0xc4200105c0, 0xc4204e65a0, 0x25, 0xc4201ce988, 0x5, 0xc420226c80, 0x42, 0x42, ...)
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc/services.go:71 +0x10e
github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc.(*serviceSet).call(0xc4201ca008, 0x6c3800, 0xc4200105c0, 0xc4204e65a0, 0x25, 0xc4201ce988, 0x5, 0xc420226c80, 0x42, 0x42, ...)
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc/services.go:44 +0xb5
github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc.(*serverConn).run.func2(0xc4201563c0, 0x6c3800, 0xc4200105c0, 0xace457, 0xc420392940, 0xc42014a2a0, 0xc42014a360, 0xc400ace457)
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc/server.go:402 +0xaa
created by github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc.(*serverConn).run
      /tmp/tmp.ma5UpKvnFZ/src/github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc/server.go:401 +0x763
 
=== END goroutine stack dump ===" namespace=moby path="/run/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/60f253d59f26e1c573d4ba5f824e73b3a4b1bb1629edace85caba4c620755d4d" pid=119820

分析以上协程栈可知：

  • goroutine 1：handleSignals确实阻塞在reaper.go:44，导致后续进程无法被收割
  • goroutine 18：checkProcesses阻塞在service.go:470，获取锁失败，但是并非是reaper.Default这把大锁
  • goroutine 22661144：shim.(*Service).Kill阻塞在reaper.go:82

其中，最为异常的是goroutine 22661144，其阻塞点代码如下：

1
2
3
4
5
6
7
8
9
10
func (m *Monitor) Wait(c *exec.Cmd, ec chan runc.Exit) (int, error) {
   for e := range ec {                   // reaper.go:82
      if e.Pid == c.Process.Pid {
         c.Wait()
         m.Unsubscribe(ec)
         return e.Status, nil
      }
   }
   return -1, ErrNoSuchProcess
}

其中ec就是reaper.Default的一个订阅方。

死锁的形成如下：

  • goroutine 22661144：等待着关联进程的退出事件到来，并且持有Service.mu这把锁
  • goroutine 18：等待获取Service.mu这把锁后，再去处理订阅的事件
  • goroutine 1：往所有订阅方发送事件

这三个协程形成了完美的死锁现场。

解决方案

清楚了问题的成因之后，解决问题的方案也很简单，只需调整默认的订阅者信道大小即可。社区优化方案有二：

但是，当我们替换containerd-shim后，影响的也仅是在此之后创建的容器，而之前创建的容器仍然会出现该问题。

这个可以通过添加告警自愈的手段解决：直接杀containerd-shim进程。这样所有的进程都会由init进程完成收割。

]]> <h1 id="背景"><a href="#背景" class="headerlink" title="背景"></a>背景</h1><p>近期，线上报障了多起Pod删除失败的Case，用户的多次删除请求均已失败告终。Pod删除失败的影响主要有二：</p> <ul> <li>面向 docker exec 失败问题排查之旅 https://plpan.github.io/docker-exec-%E5%A4%B1%E8%B4%A5%E9%97%AE%E9%A2%98%E6%8E%92%E6%9F%A5%E4%B9%8B%E6%97%85/ 2021-05-13T11:43:51.000Z 2021-06-27T08:33:36.285Z 锄禾日当午，值班好辛苦；

汗滴禾下土，一查一下午。

问题描述

今天，在值班排查线上问题的过程中，发现系统日志一直在刷docker异常日志：

1
2
3
May 12 09:08:40 HOSTNAME dockerd[4085]: time="2021-05-12T09:08:40.642410594+08:00" level=error msg="stream copy error: reading from a closed fifo"
May 12 09:08:40 HOSTNAME dockerd[4085]: time="2021-05-12T09:08:40.642418571+08:00" level=error msg="stream copy error: reading from a closed fifo"
May 12 09:08:40 HOSTNAME dockerd[4085]: time="2021-05-12T09:08:40.663754355+08:00" level=error msg="Error running exec 110deb1c1b2a2d2671d7368bd02bfc18a968e4712a3c771dedf0b362820e73cb in container: OCI runtime exec failed: exec failed: container_linux.go:348: starting container process caused \"read init-p: connection reset by peer\": unknown"

从系统风险性上来看，异常日志出现的原因需要排查清楚，并摸清是否会对业务产生影响。

下文简单介绍问题排查的流程，以及产生的原因。

问题排查

现在我们唯一掌握的信息，只有系统日志告知dockerd执行exec失败。

在具体的问题分析之前，我们再来回顾一下docker的工作原理与调用链路：

docker调用链路

可见，docker的调用链路非常长，涉及组件也较多。因此，我们的排查路径主要分为如下两步：

  • 确定引起失败的组件
  • 确定组件失败的原因

定位组件

熟悉docker的用户能够一眼定位引起问题的组件。但是，我们还是按照常规的排查流程走一遍：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
// 1. 定位问题容器
# sudo docker ps | grep -v pause | grep -v NAMES | awk '{print $1}' | xargs -ti sudo docker exec {} sleep 1
sudo docker exec aa1e331ec24f sleep 1
OCI runtime exec failed: exec failed: container_linux.go:348: starting container process caused "read init-p: connection reset by peer": unknown


// 2. 排除docker嫌疑
# docker-containerd-ctr -a /var/run/docker/containerd/docker-containerd.sock -n moby t exec --exec-id stupig1 aa1e331ec24f621ab3152ebe94f1e533734164af86c9df0f551eab2b1967ec4e sleep 1
ctr: OCI runtime exec failed: exec failed: container_linux.go:348: starting container process caused "read init-p: connection reset by peer": unknown


// 3. 排除containerd与containerd-shim嫌疑
# docker-runc --root /var/run/docker/runtime-runc/moby/ exec aa1e331ec24f621ab3152ebe94f1e533734164af86c9df0f551eab2b1967ec4e sleep
runtime/cgo: pthread_create failed: Resource temporarily unavailable
SIGABRT: abort
PC=0x6b657e m=0 sigcode=18446744073709551610

goroutine 0 [idle]:
runtime: unknown pc 0x6b657e
stack: frame={sp:0x7ffd30f0d218, fp:0x0} stack=[0x7ffd2ab0e738,0x7ffd30f0d760)
00007ffd30f0d118:  0000000000000002  00007ffd30f7f184
00007ffd30f0d128:  000000000069c31c  00007ffd30f0d1a8
00007ffd30f0d138:  000000000045814e <runtime.callCgoMmap+62>  00007ffd30f0d140
00007ffd30f0d148:  00007ffd30f0d190  0000000000411a88 <runtime.persistentalloc1+456>
00007ffd30f0d158:  0000000000bf6dd0  0000000000000000
00007ffd30f0d168:  0000000000010000  0000000000000008
00007ffd30f0d178:  0000000000bf6dd8  0000000000bf7ca0
00007ffd30f0d188:  00007fdcbb4b7000  00007ffd30f0d1c8
00007ffd30f0d198:  0000000000451205 <runtime.persistentalloc.func1+69>  0000000000000000
00007ffd30f0d1a8:  0000000000000000  0000000000c1c080
00007ffd30f0d1b8:  00007fdcbb4b7000  00007ffd30f0d1e0
00007ffd30f0d1c8:  00007ffd30f0d210  00007ffd30f0d220
00007ffd30f0d1d8:  0000000000000000  00000000000000f1
00007ffd30f0d1e8:  0000000000000011  0000000000000000
00007ffd30f0d1f8:  000000000069c31c  0000000000c1c080
00007ffd30f0d208:  000000000045814e <runtime.callCgoMmap+62>  00007ffd30f0d210
00007ffd30f0d218: <00007ffd30f0d268  fffffffe7fffffff
00007ffd30f0d228:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d238:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d248:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d258:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d268:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d278:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d288:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d298:  ffffffffffffffff  0000000000000000
00007ffd30f0d2a8:  00000000006b68ba  0000000000000020
00007ffd30f0d2b8:  0000000000000000  0000000000000000
00007ffd30f0d2c8:  0000000000000000  0000000000000000
00007ffd30f0d2d8:  0000000000000000  0000000000000000
00007ffd30f0d2e8:  0000000000000000  0000000000000000
00007ffd30f0d2f8:  0000000000000000  0000000000000000
00007ffd30f0d308:  0000000000000000  0000000000000000
runtime: unknown pc 0x6b657e
stack: frame={sp:0x7ffd30f0d218, fp:0x0} stack=[0x7ffd2ab0e738,0x7ffd30f0d760)
00007ffd30f0d118:  0000000000000002  00007ffd30f7f184
00007ffd30f0d128:  000000000069c31c  00007ffd30f0d1a8
00007ffd30f0d138:  000000000045814e <runtime.callCgoMmap+62>  00007ffd30f0d140
00007ffd30f0d148:  00007ffd30f0d190  0000000000411a88 <runtime.persistentalloc1+456>
00007ffd30f0d158:  0000000000bf6dd0  0000000000000000
00007ffd30f0d168:  0000000000010000  0000000000000008
00007ffd30f0d178:  0000000000bf6dd8  0000000000bf7ca0
00007ffd30f0d188:  00007fdcbb4b7000  00007ffd30f0d1c8
00007ffd30f0d198:  0000000000451205 <runtime.persistentalloc.func1+69>  0000000000000000
00007ffd30f0d1a8:  0000000000000000  0000000000c1c080
00007ffd30f0d1b8:  00007fdcbb4b7000  00007ffd30f0d1e0
00007ffd30f0d1c8:  00007ffd30f0d210  00007ffd30f0d220
00007ffd30f0d1d8:  0000000000000000  00000000000000f1
00007ffd30f0d1e8:  0000000000000011  0000000000000000
00007ffd30f0d1f8:  000000000069c31c  0000000000c1c080
00007ffd30f0d208:  000000000045814e <runtime.callCgoMmap+62>  00007ffd30f0d210
00007ffd30f0d218: <00007ffd30f0d268  fffffffe7fffffff
00007ffd30f0d228:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d238:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d248:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d258:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d268:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d278:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d288:  ffffffffffffffff  ffffffffffffffff
00007ffd30f0d298:  ffffffffffffffff  0000000000000000
00007ffd30f0d2a8:  00000000006b68ba  0000000000000020
00007ffd30f0d2b8:  0000000000000000  0000000000000000
00007ffd30f0d2c8:  0000000000000000  0000000000000000
00007ffd30f0d2d8:  0000000000000000  0000000000000000
00007ffd30f0d2e8:  0000000000000000  0000000000000000
00007ffd30f0d2f8:  0000000000000000  0000000000000000
00007ffd30f0d308:  0000000000000000  0000000000000000

goroutine 1 [running]:
runtime.systemstack_switch()
/usr/local/go/src/runtime/asm_amd64.s:363 fp=0xc4200fe788 sp=0xc4200fe780 pc=0x454120
runtime.main()
/usr/local/go/src/runtime/proc.go:128 +0x63 fp=0xc4200fe7e0 sp=0xc4200fe788 pc=0x42bb83
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:2361 +0x1 fp=0xc4200fe7e8 sp=0xc4200fe7e0 pc=0x456c91

rax    0x0
rbx    0xbe2978
rcx    0x6b657e
rdx    0x0
rdi    0x2
rsi    0x7ffd30f0d1a0
rbp    0x8347ce
rsp    0x7ffd30f0d218
r8     0x0
r9     0x6
r10    0x8
r11    0x246
r12    0x2bedc30
r13    0xf1
r14    0x11
r15    0x0
rip    0x6b657e
rflags 0x246
cs     0x33
fs     0x0
gs     0x0
exec failed: container_linux.go:348: starting container process caused "read init-p: connection reset by peer"

由上可知，异常是runc返回的。

定位原因

定位异常组件的同时，runc还给了我们一个惊喜：提供了详细的异常日志。

异常日志表明：runc exec失败的原因是因为 Resource temporarily unavailable，比较典型的资源不足问题。而常见的资源不足类型主要包含（ulimit -a）：

  • 线程数达到限制
  • 文件数达到限制
  • 内存达到限制

因此，我们需要进一步排查业务容器的监控，以定位不足的资源类型。

业务线程数监控指标

上图展示了业务容器的线程数监控。所有容器的线程数都已经达到1w，而弹性云默认限制容器的线程数上限就是1w，设定该上限的原因，也是为了避免单容器线程泄漏而耗尽宿主机的线程资源。

1
2
# cat /sys/fs/cgroup/pids/kubepods/burstable/pod64a6c0e7-830c-11eb-86d6-b8cef604db88/aa1e331ec24f621ab3152ebe94f1e533734164af86c9df0f551eab2b1967ec4e/pids.max
10000

至此，问题的原因已定位清楚，对，就是这么简单。

runc梳理

虽然，我们已经定位了异常日志的成因，但是，对于runc的具体工作机制，一直只有一个模糊的概念。

趁此机会，我们以runc exec为例，梳理runc的工作流程。

  • runc exec首先启动子进程runc init
  • runc init负责初始化容器namespace
    • runc init利用C语言的constructor特性，实现在go代码启动之前，设置容器namespace
    • C代码nsexec执行两次clone，共三个线程：父进程，子进程，孙进程，完成对容器namespace的初始化
    • 父进程与子进程完成初始化任务后退出，此时，孙进程已经在容器namespace内，孙进程开始执行go代码初始化，并等待接收runc exec发送配置
  • runc exec将孙进程添加到容器cgroup
  • runc exec发送配置给孙进程，配置主要包含：exec的具体命令与参数等
  • 孙进程调用system.Execv执行用户命令

注意：

  • 步骤2.c与步骤3是并发执行的
  • runc exec与runc init通信基于socket pair对（init-p和init-c）

runc exec过程中各进程的交互流程，以及namespace与cgroup的初始化参见下图：

runc工作流程

综合我们对runc exec执行流程的梳理，以及runc exec返回的错误信息，我们基本定位到了runc exec返回错误的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
func (p *setnsProcess) start() (err error) {
   defer p.parentPipe.Close()
   err = p.cmd.Start()
   p.childPipe.Close()
   if err != nil {
      return newSystemErrorWithCause(err, "starting setns process")
   }
   if p.bootstrapData != nil {
      if _, err := io.Copy(p.parentPipe, p.bootstrapData); err != nil {       // clone标志位，ns配置
         return newSystemErrorWithCause(err, "copying bootstrap data to pipe")
      }
   }
   if err = p.execSetns(); err != nil {
      return newSystemErrorWithCause(err, "executing setns process")
   }
   if len(p.cgroupPaths) > 0 {
      if err := cgroups.EnterPid(p.cgroupPaths, p.pid()); err != nil {        // 这里将runc init添加到容器cgroup中
         return newSystemErrorWithCausef(err, "adding pid %d to cgroups", p.pid())
      }
   }
   if err := utils.WriteJSON(p.parentPipe, p.config); err != nil {            // 发送配置：命令、环境变量等
      return newSystemErrorWithCause(err, "writing config to pipe")
   }

   ierr := parseSync(p.parentPipe, func(sync *syncT) error {                  // 这里返回 read init-p: connection reset by peer
      switch sync.Type {
      case procReady:
         // This shouldn't happen.
         panic("unexpected procReady in setns")
      case procHooks:
         // This shouldn't happen.
         panic("unexpected procHooks in setns")
      default:
         return newSystemError(fmt.Errorf("invalid JSON payload from child"))
      }
   })
   if ierr != nil {
      p.wait()
      return ierr
   }
   return nil
}

现在，问题的成因与代码分析已全部完成。

Reference

  1. https://www.kernel.org/doc/Documentation/cgroup-v1/pids.txt
  2. https://github.com/opencontainers/runc
]]> <p>锄禾日当午，值班好辛苦；</p> <p>汗滴禾下土，一查一下午。</p> <h3 id="问题描述"><a href="#问题描述" class="headerlink" title="问题描述"></a>问题描述</h3><p>今天，在值班排查线上问题的过程中，发现系统日 删除容器报错 device or resource busy 问题排查之旅 https://plpan.github.io/%E5%88%A0%E9%99%A4%E5%AE%B9%E5%99%A8%E6%8A%A5%E9%94%99-device-or-resource-busy-%E9%97%AE%E9%A2%98%E6%8E%92%E6%9F%A5%E4%B9%8B%E6%97%85/ 2020-10-15T03:59:32.000Z 2020-11-12T14:53:22.099Z 背景

承接上文，近期我们排查弹性云线上几起故障时，故障由多个因素共同引起，列举如下：

  • 弹性云在逐步灰度升级docker版本至 18.06.3-ce
  • 由于历史原因，弹性云启用了docker服务的systemd配置选项 MountFlags=slave
  • 为了避免dockerd重启引起业务容器重建，弹性云启用了 live-restore=true 配置，docker服务发生重启，dockerd与shim进程mnt ns不一致

在以上三个因素合力作用下，线上容器在重建与漂移场景下，出现删除失败的事件。

同样，文章最后也给出了两种解决方案：

  • 长痛：修改代码，忽略错误
  • 短痛：修改配置，一劳永逸

作为优秀的社会主义接班人，我们当然选择短痛了！依据官方提示 MountFlags=slave 与 live-restore=true 不能协同工作，那么我们只需关闭二者之一就能解决问题。

与我们而言，docker提供的 live-restore 能力是一个很关键的特性。docker重启的原因多种多样，既可能是人为调试因素，也可能是机器的非预期行为，当docker重启后，我们并不希望用户的容器也发生重建。似乎关闭 MountFlags=slave 成了我们唯一的选择。

等等，回想一下docker device busy问题解决方案，别人正是为了避免docker挂载泄漏而引起删除容器失败才开启的这个特性。

但是，这个17年的结论真的还具有普适性吗？是与不是，我们亲自验证即可。

对比实验

为了验证在关闭 MountFlags=slave 选项后，docker是否存在挂载点泄漏的问题，我们分别挑选了一台 1.13.1 与 18.06.3-ce 的宿主进行实验。实验步骤正如docker device busy问题解决方案所提示，在验证之前，环境准备如下：

  • 删除docker服务的systemd配置项 MountFlags=slave
  • 挑选启用systemd配置项 PrivateTmp=true 的任意服务，本文以 httpd 为例

下面开始验证：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
////// docker 1.13.1 验证步骤及结果
// 1. 重新加载配置
[stupig@hostname2 ~]$ sudo systemctl daemon-reload
 
// 2. 重启docker
[stupig@hostname2 ~]$ sudo systemctl restart docker
 
// 3. 创建容器
[stupig@hostname2 ~]$ sudo docker run -d nginx
c89c2aeff6e3e6414dfc7f448b4a560b4aac96d69a82ba021b78ee576bf6771c
 
// 4. 重启httpd
[stupig@hostname2 ~]$ sudo systemctl restart httpd
 
// 5. 停止容器
[stupig@hostname2 ~]$ sudo docker stop c89c2aeff6e3e6414dfc7f448b4a560b4aac96d69a82ba021b78ee576bf6771c
c89c2aeff6e3e6414dfc7f448b4a560b4aac96d69a82ba021b78ee576bf6771c
 
// 6. 清理容器
[stupig@hostname2 ~]$ sudo docker rm c89c2aeff6e3e6414dfc7f448b4a560b4aac96d69a82ba021b78ee576bf6771c
Error response from daemon: Driver overlay2 failed to remove root filesystem c89c2aeff6e3e6414dfc7f448b4a560b4aac96d69a82ba021b78ee576bf6771c: remove /home/docker_rt/overlay2/6c77cfb6c0c4b1e809c47af3c5ff6a4732a783cc14ff53270a7709c837c96346/merged: device or resource busy
 
// 7. 定位挂载点
[stupig@hostname2 ~]$ grep -rwn /home/docker_rt/overlay2/6c77cfb6c0c4b1e809c47af3c5ff6a4732a783cc14ff53270a7709c837c96346/merged /proc/*/mountinfo
/proc/19973/mountinfo:40:231 227 0:40 / /home/docker_rt/overlay2/6c77cfb6c0c4b1e809c47af3c5ff6a4732a783cc14ff53270a7709c837c96346/merged rw,relatime shared:119 - overlay overlay rw,lowerdir=XXX,upperdir=XXX,workdir=XXX
/proc/19974/mountinfo:40:231 227 0:40 / /home/docker_rt/overlay2/6c77cfb6c0c4b1e809c47af3c5ff6a4732a783cc14ff53270a7709c837c96346/merged rw,relatime shared:119 - overlay overlay rw,lowerdir=XXX,upperdir=XXX,workdir=XXX
/proc/19975/mountinfo:40:231 227 0:40 / /home/docker_rt/overlay2/6c77cfb6c0c4b1e809c47af3c5ff6a4732a783cc14ff53270a7709c837c96346/merged rw,relatime shared:119 - overlay overlay rw,lowerdir=XXX,upperdir=XXX,workdir=XXX
/proc/19976/mountinfo:40:231 227 0:40 / /home/docker_rt/overlay2/6c77cfb6c0c4b1e809c47af3c5ff6a4732a783cc14ff53270a7709c837c96346/merged rw,relatime shared:119 - overlay overlay rw,lowerdir=XXX,upperdir=XXX,workdir=XXX
/proc/19977/mountinfo:40:231 227 0:40 / /home/docker_rt/overlay2/6c77cfb6c0c4b1e809c47af3c5ff6a4732a783cc14ff53270a7709c837c96346/merged rw,relatime shared:119 - overlay overlay rw,lowerdir=XXX,upperdir=XXX,workdir=XXX
/proc/19978/mountinfo:40:231 227 0:40 / /home/docker_rt/overlay2/6c77cfb6c0c4b1e809c47af3c5ff6a4732a783cc14ff53270a7709c837c96346/merged rw,relatime shared:119 - overlay overlay rw,lowerdir=XXX,upperdir=XXX,workdir=XXX
 
// 8. 定位目标进程
[stupig@hostname2 ~]$ ps -ef|egrep '19973|19974|19975|19976|19977|19978'
root     19973     1  0 15:13 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache   19974 19973  0 15:13 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache   19975 19973  0 15:13 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache   19976 19973  0 15:13 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache   19977 19973  0 15:13 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache   19978 19973  0 15:13 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND

docker 1.13.1 版本的实验结果正如网文所料，容器读写层挂载点出现了泄漏，并且 docker rm 无法清理该容器（注意 docker rm -f 仍然可以清理，原因参考上文）。

弹性云启用docker配置 MountFlags=slave 也是为了避免该问题发生。

那么现在压力转移到 docker 18.06.3-ce 这边来了，新版本是否仍然存在这个问题呢？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
////// docker 18.06.3-ce 验证步骤及结果
[stupig@hostname ~]$ sudo systemctl daemon-reload
 
[stupig@hostname ~]$ sudo systemctl restart docker
 
[stupig@hostname ~]$ sudo docker run -d nginx
718114321d67a817c1498e530b943c2514ed4200f2d0d138880f8c345df7048f
 
[stupig@hostname ~]$ sudo systemctl restart httpd
 
[stupig@hostname ~]$ sudo docker stop 718114321d67a817c1498e530b943c2514ed4200f2d0d138880f8c345df7048f
718114321d67a817c1498e530b943c2514ed4200f2d0d138880f8c345df7048f
 
[stupig@hostname ~]$ sudo docker rm 718114321d67a817c1498e530b943c2514ed4200f2d0d138880f8c345df7048f
718114321d67a817c1498e530b943c2514ed4200f2d0d138880f8c345df7048f

针对docker 18.06.3-ce 的实验非常丝滑顺畅，不存在任何问题。回顾上文知识点，当容器读写层挂载点出现泄漏后，docker 18.06.3-ce 清理容器必定失败，而现在的结果却成功了，说明容器读写层挂载点没有泄漏。

这简直就是黎明的曙光。

蛛丝马迹

上一节对比实验的结果给了我们莫大的鼓励，本节我们探索两个版本的docker的表现差异，以期定位症结所在。

既然核心问题在于挂载点是否被泄漏，那么我们就以挂载点为切入点，深入分析两个版本docker的差异性。我们对比在两个环境下执行完 步骤4 后，不同进程内的挂载详情，结果如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// docker 1.13.1
[stupig@hostname2 ~]$ sudo docker run -d nginx
0fe8d412f99a53229ea0df3ec44c93496e150a39f724ea304adb7f924910d61b
 
[stupig@hostname2 ~]$ sudo docker inspect -f {{.GraphDriver.Data.MergedDir}} 0fe8d412f99a53229ea0df3ec44c93496e150a39f724ea304adb7f924910d61b
/home/docker_rt/overlay2/4e09fa6803feab9d96fe72a44fb83d757c1788812ff60071ac2e62a5cf14cd97/merged
 
// 共享命名空间
[stupig@hostname2 ~]$ grep -rw /home/docker_rt/overlay2/4e09fa6803feab9d96fe72a44fb83d757c1788812ff60071ac2e62a5cf14cd97/merged /proc/$$/mountinfo
223 1143 0:40 / /home/docker_rt/overlay2/4e09fa6803feab9d96fe72a44fb83d757c1788812ff60071ac2e62a5cf14cd97/merged rw,relatime - overlay overlay rw,lowerdir=XXX,upperdir=XXX,workdir=XXX
 
[stupig@hostname2 ~]$ sudo systemctl restart httpd
 
[stupig@hostname2 ps -ef|grep httpd|head -n 1
root     16715     1  2 16:09 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
 
// httpd进程命名空间
[stupig@hostname2 ~]$ grep -rw /home/docker_rt/overlay2/4e09fa6803feab9d96fe72a44fb83d757c1788812ff60071ac2e62a5cf14cd97/merged /proc/16715/mountinfo
257 235 0:40 / /home/docker_rt/overlay2/4e09fa6803feab9d96fe72a44fb83d757c1788812ff60071ac2e62a5cf14cd97/merged rw,relatime shared:123 - overlay overlay rw,lowerdir=XXX,upperdir=XXX,workdir=XXX

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// docker 18.06.3-ce
[stupig@hostname ~]$ sudo docker run -d nginx
ce75d4fdb6df6d13a7bf4270f71b3752ee2d3849df1f64d5d5d19a478ac7db8d
 
[stupig@hostname ~]$ sudo docker inspect -f {{.GraphDriver.Data.MergedDir}} ce75d4fdb6df6d13a7bf4270f71b3752ee2d3849df1f64d5d5d19a478ac7db8d
/home/docker_rt/overlay2/a9823ed6b3c5a752eaa92072ff9d91dbe1467ceece3eedf613bf6ffaa5183b76/merged
 
// 共享命名空间
[stupig@hostname ~]$ grep -rw /home/docker_rt/overlay2/a9823ed6b3c5a752eaa92072ff9d91dbe1467ceece3eedf613bf6ffaa5183b76/merged /proc/$$/mountinfo
218 43 0:105 / /home/docker_rt/overlay2/a9823ed6b3c5a752eaa92072ff9d91dbe1467ceece3eedf613bf6ffaa5183b76/merged rw,relatime shared:109 - overlay overlay rw,lowerdir=XXX,upperdir=XXX,workdir=XXX
 
[stupig@hostname ~]$ sudo systemctl restart httpd
 
[stupig@hostname ~]$ ps -ef|grep httpd|head -n 1
root      63694      1  0 16:14 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
 
// httpd进程命名空间
[stupig@hostname ~]$ grep -rw /home/docker_rt/overlay2/a9823ed6b3c5a752eaa92072ff9d91dbe1467ceece3eedf613bf6ffaa5183b76/merged /proc/63694/mountinfo
435 376 0:105 / /home/docker_rt/overlay2/a9823ed6b3c5a752eaa92072ff9d91dbe1467ceece3eedf613bf6ffaa5183b76/merged rw,relatime shared:122 master:109 - overlay overlay rw,lowerdir=XXX,upperdir=XXX,workdir=XXX

咋一看，好像没啥区别啊！睁大你们的火眼金睛，是否发现差异所在了？

如果细心对比，还是很容易分辨出差异所在的：

  • 共享命名空间中
    • docker 18.06.3-ce 版本创建的挂载点是shared的
    • 而docker 1.13.1 版本创建的挂载点是private的
  • httpd进程命名空间中
    • docker 18.06.3-ce 创建的挂载点仍然是共享的，并且接收共享组109传递的挂载与卸载事件，注意：共享组109正好就是共享命名空间中对应的挂载点
    • 而docker 1.13.1 版本创建的挂载点虽然也是共享的，但是却与共享命名空间中对应的挂载点没有关联关系

可能会有用户不禁要问：怎么分辨挂载点是什么类型？以及不同类型挂载点的传递属性呢？请参阅：mount命名空间说明文档。

问题已然明了，由于两个版本docker所创建的容器读写层挂载点具备不同的属性，导致它们之间的行为差异。

刨根问底

相信大家如果理解了上一节的内容，就已经了解了问题的本质。本节我们继续探索问题的根因。

为什么两个版本的docker行为表现不一致？不外乎两个主要原因：

  1. docker处理逻辑发生变动
  2. 宿主环境不一致，主要指内核

第二个因素很好排除，我们对比了两个测试环境的宿主内核版本，结果是一致的。所以，基本还是因docker代码升级而产生的行为不一致。理论上，我们只需逐个分析docker 1.13.1 与 docker 18.06.3-ce 两个版本间的所有提交记录，就一定能够定位到关键提交信息，大力总是会出现奇迹。

但是，我们还是希望能够从现场中发现有用信息，缩小检索范围。

仍然从挂载点切入，既然两个版本的docker所创建的挂载点在共享命名空间中就已经出现差异，我们顺藤摸瓜，找找容器读写层挂载点链路上是否存在差异：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
// docker 1.13.1
// 本挂载点
[stupig@hostname2 ~]$ grep -rw /home/docker_rt/overlay2/4e09fa6803feab9d96fe72a44fb83d757c1788812ff60071ac2e62a5cf14cd97/merged /proc/$$/mountinfo
223 1143 0:40 / /home/docker_rt/overlay2/4e09fa6803feab9d96fe72a44fb83d757c1788812ff60071ac2e62a5cf14cd97/merged rw,relatime - overlay overlay rw,lowerdir=XXX,upperdir=XXX,workdir=XXX
 
// 定位本挂载点的父挂载点
[stupig@hostname2 ~]$ grep -rw 1143 /proc/$$/mountinfo
1143 44 8:4 /docker_rt/overlay2 /home/docker_rt/overlay2 rw,relatime - xfs /dev/sda4 rw,attr2,inode64,logbsize=256k,sunit=512,swidth=512,prjquota
 
// 继续定位祖父挂载点
[stupig@hostname2 ~]$ grep -rw 44 /proc/$$/mountinfo
44 39 8:4 / /home rw,relatime shared:28 - xfs /dev/sda4 rw,attr2,inode64,logbsize=256k,sunit=512,swidth=512,prjquota
 
// 继续往上
[stupig@hostname2 ~]$ grep -rw 39 /proc/$$/mountinfo
39 1 8:3 / / rw,relatime shared:1 - ext4 /dev/sda3 rw,stripe=64,data=ordered
 
// docker 18.06.3-ce
// 本挂载点
[stupig@hostname ~]$ grep -rw /home/docker_rt/overlay2/a9823ed6b3c5a752eaa92072ff9d91dbe1467ceece3eedf613bf6ffaa5183b76/merged /proc/$$/mountinfo
218 43 0:105 / /home/docker_rt/overlay2/a9823ed6b3c5a752eaa92072ff9d91dbe1467ceece3eedf613bf6ffaa5183b76/merged rw,relatime shared:109 - overlay overlay rw,lowerdir=XXX,upperdir=XXX,workdir=XXX
 
// 定位本挂在点的父挂载点
[stupig@hostname ~]$ grep -rw 43 /proc/$$/mountinfo
43 61 8:17 / /home rw,noatime shared:29 - xfs /dev/sdb1 rw,attr2,nobarrier,inode64,prjquota
 
// 继续定位祖父挂载点
[stupig@hostname ~]$ grep -rw 61 /proc/$$/mountinfo
61 1 8:3 / / rw,relatime shared:1 - ext4 /dev/sda3 rw,data=ordered

两个版本的docker所创建的容器读写层挂载点链路上差异还是非常明显的：

  • 容器读写层挂载点的父级挂载点不同
    • docker 18.06.3-ce 创建的容器读写层挂载点的父级挂载点是 /home/ ，并且是共享的
    • docker 1.13.1 创建的容器读写层挂载点的父级挂载点是 /home/docker_rt/overlay2 ，并且是私有的

这里补充一个背景，弹性云机器在初始化阶段，会将 /home 初始化为xfs文件系统类型，因此所有宿主上 /home 挂载点都具备相同属性。

那么，问题基本就是由 docker 1.13.1 中多出的一层挂载层 /home/docker_rt/overlay2 引起。

如何验证这个猜想呢？现在，其实我们已经具备了检索代码的关键目标，docker 1.13.1 会设置容器镜像层根目录的传递属性。拿着这个先验知识，我们直接查代码，检索过程基本没费什么功夫，直接展示相关代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
// filepath: daemon/graphdriver/overlay2/overlay.go
func init() {
   graphdriver.Register(driverName, Init)
}
 
func Init(home string, options []string, uidMaps, gidMaps []idtools.IDMap) (graphdriver.Driver, error) {
   if err := mount.MakePrivate(home); err != nil {
      return nil, err
   }
 
   supportsDType, err := fsutils.SupportsDType(home)
   if err != nil {
      return nil, err
   }
   if !supportsDType {
      // not a fatal error until v1.16 (#27443)
      logrus.Warn(overlayutils.ErrDTypeNotSupported("overlay2", backingFs))
   }
 
   d := &Driver{
      home:          home,
      uidMaps:       uidMaps,
      gidMaps:       gidMaps,
      ctr:           graphdriver.NewRefCounter(graphdriver.NewFsChecker(graphdriver.FsMagicOverlay)),
      supportsDType: supportsDType,
   }
 
   d.naiveDiff = graphdriver.NewNaiveDiffDriver(d, uidMaps, gidMaps)
 
   if backingFs == "xfs" {
      // Try to enable project quota support over xfs.
      if d.quotaCtl, err = quota.NewControl(home); err == nil {
         projectQuotaSupported = true
      }
   }
 
   return d, nil
}

很明显，问题就出在 mount.MakePrivate 函数调用上。

官方将 GraphDriver 根目录设置为 Private，本意是为了避免容器读写层挂载点泄漏。那为什么在高版本中去掉了这个逻辑呢？显然官方也意识到这么做并不能实现期望的目的，官方也在修复中给出了详细说明。

实际上，不设置 GraphDriver 根目录的传播属性，反而能避免绝大多数挂载点泄漏的问题。。。

结语

现在，我们已经了解了问题的来龙去脉，我们总结下问题的解决方案：

  • 针对 1.13.1 版本docker，存量宿主较多，我们可以忽略 device or resource busy 问题，基本也不会给线上服务带来什么影响
  • 针对 18.06.3-ce 版本docker，存量宿主较少，我们删除docker服务的systemd配置项 MountFlags，通过故障自愈解决docker卡在问题
  • 针对增量宿主，全部删除docker服务的systemd配置项 MountFlags

最后，告诫大家不要迷信网络解决方案，甚至是官方。

]]> <h3 id="背景"><a href="#背景" class="headerlink" title="背景"></a>背景</h3><p>承接<a href="https://plpan.github.io/pod-terminating-%E6%8E%92%E6%9F%A5% pod terminating 排查之旅 https://plpan.github.io/pod-terminating-%E6%8E%92%E6%9F%A5%E4%B9%8B%E6%97%85/ 2020-10-14T10:53:03.000Z 2020-11-12T14:52:44.125Z 背景

近期，弹性云线上集群发生了几起特殊的容器漂移失败事件，其特殊之处在于容器处于Pod Terminating状态，而宿主则处于Ready状态。

宿主状态为Ready说明其能够正常处理Pod事件，但是Pod却卡在了退出阶段，说明此问题并非由kubelet引起，那么docker就是1号犯罪嫌疑人了。

下文将详细介绍问题的排查与分析全过程。

抽丝剥茧

排除kubelet嫌疑

Pod状态如下：

1
2
[stupig@master ~]$ kubectl get pod -owide
pod-976a0-5              0/1     Terminating        0          112m

尽管kubelet的犯罪嫌疑已经很小，但是我们还是需要排查kubelet日志进一步确认。截取kubelet关键日志片段如下：

1
2
3
I1014 10:56:46.492682   34976 kubelet_pods.go:1017] Pod "pod-976a0-5_default(f1e03a3d-0dc7-11eb-b4b1-246e967c4efc)" is terminated, but some containers have not been cleaned up: {ID:{Type:docker ID:41020461ed4d801afa8d10847a16907e65f6e8ca34d1704edf15b0d0e72bf4ef} Name:stupig State:exited CreatedAt:2020-10-14 10:49:57.859913657 +0800 CST StartedAt:2020-10-14 10:49:57.928654495 +0800 CST FinishedAt:2020-10-14 10:50:28.661263065 +0800 CST ExitCode:0 Hash:2101852810 HashWithoutResources:2673273670 RestartCount:0 Reason:Completed Message: Resources:map[CpuQuota:200000 Memory:2147483648 MemorySwap:2147483648]}
E1014 10:56:46.709255   34976 remote_runtime.go:250] RemoveContainer "41020461ed4d801afa8d10847a16907e65f6e8ca34d1704edf15b0d0e72bf4ef" from runtime service failed: rpc error: code = Unknown desc = failed to remove container "41020461ed4d801afa8d10847a16907e65f6e8ca34d1704edf15b0d0e72bf4ef": Error response from daemon: container 41020461ed4d801afa8d10847a16907e65f6e8ca34d1704edf15b0d0e72bf4ef: driver "overlay2" failed to remove root filesystem: unlinkat /home/docker_rt/overlay2/e5dab77be213d9f9cfc0b0b3281dbef9c2878fee3b8e406bc8ab97adc30ae4d5/merged: device or resource busy
E1014 10:56:46.709292   34976 kuberuntime_gc.go:126] Failed to remove container "41020461ed4d801afa8d10847a16907e65f6e8ca34d1704edf15b0d0e72bf4ef": rpc error: code = Unknown desc = failed to remove container "41020461ed4d801afa8d10847a16907e65f6e8ca34d1704edf15b0d0e72bf4ef": Error response from daemon: container 41020461ed4d801afa8d10847a16907e65f6e8ca34d1704edf15b0d0e72bf4ef: driver "overlay2" failed to remove root filesystem: unlinkat /home/docker_rt/overlay2/e5dab77be213d9f9cfc0b0b3281dbef9c2878fee3b8e406bc8ab97adc30ae4d5/merged: device or resource busy

日志显示kubelet处于Pod Terminating状态的原因很清楚：清理容器失败。

kubelet清理容器的命令是 docker rm -f ，其失败的原因在于删除容器目录 xxx/merged 时报错，错误提示为 device or resource busy 。

除此之外，kubelet无法再提供其他关键信息。

登陆宿主，我们验证对应容器的状态：

1
2
3
4
5
[stupig@hostname ~]$ sudo docker ps -a | grep pod-976a0-5
41020461ed4d            Removal In Progress                            k8s_stupig_pod-976a0-5_default_f1e03a3d-0dc7-11eb-b4b1-246e967c4efc_0
f0a75e10b252            Exited (0) 2 minutes ago                       k8s_POD_pod-976a0-5_default_f1e03a3d-0dc7-11eb-b4b1-246e967c4efc_0
[stupig@hostname ~]$ sudo docker rm -f 41020461ed4d
Error response from daemon: container 41020461ed4d801afa8d10847a16907e65f6e8ca34d1704edf15b0d0e72bf4ef: driver "overlay2" failed to remove root filesystem: unlinkat /home/docker_rt/overlay2/e5dab77be213d9f9cfc0b0b3281dbef9c2878fee3b8e406bc8ab97adc30ae4d5/merged: device or resource busy

问题已然清楚，现在我们有两种排查思路：

  • 参考Google上解决 device or resource busy 问题的思路
  • 结合现象分析代码

Google大法

有问题找Google！所以，我们首先咨询了Google，检索结果显示很多人都碰到了类似的问题。

而网络上主流的解决方案：配置docker服务MountFlags为slave，避免docker挂载点信息泄漏到其他mnt命名空间，详细原因请参阅：docker device busy问题解决方案。

这么简单？？？显然不能，检查发现docker服务当前已配置MountFlags为slave。网络银弹再次失去功效。

so，我们还是老老实实结合现场分析代码吧。

docker处理流程

在具体分析docker代码之前，先简单介绍下docker的处理流程，避免作为一只无头苍蝇处处碰壁。

docker处理流程

清楚了docker的处理流程之后，我们再来分析现场。

提审docker

问题发生在docker清理阶段，docker清理容器读写层出错，报错信息为 device or resource busy，说明docker读写层并没有被正确卸载，或者是没有完全卸载。下面的命令可以验证这个结论：

1
2
3
4
5
[stupig@hostname ~]$ grep -rwn '/home/docker_rt/overlay2/e5dab77be213d9f9cfc0b0b3281dbef9c2878fee3b8e406bc8ab97adc30ae4d5/merged' /proc/*/mountinfo
/proc/22283/mountinfo:50:386 542 0:92 / /home/docker_rt/overlay2/e5dab77be213d9f9cfc0b0b3281dbef9c2878fee3b8e406bc8ab97adc30ae4d5/merged rw,relatime - overlay overlay rw,lowerdir=XXX,upperdir=XXX,workdir=XXX
/proc/22407/mountinfo:50:386 542 0:92 / /home/docker_rt/overlay2/e5dab77be213d9f9cfc0b0b3281dbef9c2878fee3b8e406bc8ab97adc30ae4d5/merged rw,relatime - overlay overlay rw,lowerdir=XXX,upperdir=XXX,workdir=XXX
/proc/28454/mountinfo:50:386 542 0:92 / /home/docker_rt/overlay2/e5dab77be213d9f9cfc0b0b3281dbef9c2878fee3b8e406bc8ab97adc30ae4d5/merged rw,relatime - overlay overlay rw,lowerdir=XXX,upperdir=XXX,workdir=XXX
/proc/28530/mountinfo:50:386 542 0:92 / /home/docker_rt/overlay2/e5dab77be213d9f9cfc0b0b3281dbef9c2878fee3b8e406bc8ab97adc30ae4d5/merged rw,relatime - overlay overlay rw,lowerdir=XXX,upperdir=XXX,workdir=XXX

不出所料，容器读写层仍然被以上四个进程所挂载，进而导致docker在清理读写层目录时报错。

随之而来的问题是，为什么docker没有正确卸载容器读写层？我们先展示下 docker stop 中卸载容器读写层挂载的相关部分代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
func (daemon *Daemon) Cleanup(container *container.Container) {
   if err := daemon.conditionalUnmountOnCleanup(container); err != nil {
      if mountid, err := daemon.imageService.GetLayerMountID(container.ID, container.OS); err == nil {
         daemon.cleanupMountsByID(mountid)
      }
   }
}
func (daemon *Daemon) conditionalUnmountOnCleanup(container *container.Container) error {
   return daemon.Unmount(container)
}
func (daemon *Daemon) Unmount(container *container.Container) error {
   if container.RWLayer == nil {
      return errors.New("RWLayer of container " + container.ID + " is unexpectedly nil")
   }
   if err := container.RWLayer.Unmount(); err != nil {
      logrus.Errorf("Error unmounting container %s: %s", container.ID, err)
      return err
   }
 
   return nil
}
func (rl *referencedRWLayer) Unmount() error {
   return rl.layerStore.driver.Put(rl.mountedLayer.mountID)
}
func (d *Driver) Put(id string) error {
   d.locker.Lock(id)
   defer d.locker.Unlock(id)
   dir := d.dir(id)
   mountpoint := path.Join(dir, "merged")
   logger := logrus.WithField("storage-driver", "overlay2")
   if err := unix.Unmount(mountpoint, unix.MNT_DETACH); err != nil {
      logger.Debugf("Failed to unmount %s overlay: %s - %v", id, mountpoint, err)
   }
   if err := unix.Rmdir(mountpoint); err != nil && !os.IsNotExist(err) {
      logger.Debugf("Failed to remove %s overlay: %v", id, err)
   }
   return nil
}

代码处理流程清晰明了，最终docker会发起 SYS_UMOUNT2 系统调用卸载容器读写层。

但是，docker在清理容器读写层时却提示错误，并且容器读写层挂载信息也出现在其他进程中。难不成docker没有执行卸载操作？结合docker日志分析：

1
2
Oct 14 10:50:28 hostname dockerd: time="2020-10-14T10:50:28.769199725+08:00" level=debug msg="Failed to unmount e5dab77be213d9f9cfc0b0b3281dbef9c2878fee3b8e406bc8ab97adc30ae4d5 overlay: /home/docker_rt/overlay2/e5dab77be213d9f9cfc0b0b3281dbef9c2878fee3b8e406bc8ab97adc30ae4d5/merged - invalid argument" storage-driver=overlay2
Oct 14 10:50:28 hostname dockerd: time="2020-10-14T10:50:28.769213547+08:00" level=debug msg="Failed to remove e5dab77be213d9f9cfc0b0b3281dbef9c2878fee3b8e406bc8ab97adc30ae4d5 overlay: device or resource busy" storage-driver=overlay2

日志显示docker在执行卸载容器读写层命令时出错，提示 invalid argument。结合 umount2 文档可知，容器读写层并非是dockerd（docker后台进程）的挂载点？？？

现在，回过头来分析拥有容器读写层挂载信息的进程，我们发现一个惊人的信息：

1
2
3
4
5
[stupig@hostname ~]$ ps -ef|grep -E "22283|22407|28454|28530"
root      22283      1  0 10:48 ?        00:00:00 docker-containerd-shim -namespace moby
root      22407      1  0 10:48 ?        00:00:00 docker-containerd-shim -namespace moby
root      28454      1  0 10:49 ?        00:00:00 docker-containerd-shim -namespace moby
root      28530      1  0 10:49 ?        00:00:00 docker-containerd-shim -namespace moby

容器读写层挂载信息没有出现在dockerd进程命名空间中，却出现在其他容器的托管服务shim进程的命名空间内，推断dockerd进程发生了重启，对比进程启动时间与命名空间详情可以进行验证：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
[stupig@hostname ~]$ ps -eo pid,cmd,lstart|grep dockerd
 34836 /usr/bin/dockerd --storage- Wed Oct 14 10:50:15 2020
 
[stupig@hostname ~]$ sudo ls -la /proc/$(pidof dockerd)/ns
lrwxrwxrwx 1 root root 0 Oct 14 10:50 ipc -> ipc:[4026531839]
lrwxrwxrwx 1 root root 0 Oct 14 10:50 mnt -> mnt:[4026533327]
lrwxrwxrwx 1 root root 0 Oct 14 10:50 net -> net:[4026531968]
lrwxrwxrwx 1 root root 0 Oct 14 10:50 pid -> pid:[4026531836]
lrwxrwxrwx 1 root root 0 Oct 14 10:50 user -> user:[4026531837]
lrwxrwxrwx 1 root root 0 Oct 14 10:50 uts -> uts:[4026531838]
 
[stupig@hostname ~]$ ps -eo pid,cmd,lstart|grep -w containerd|grep -v shim
 34849 docker-containerd --config  Wed Oct 14 10:50:15 2020
 
[stupig@hostname ~]$ sudo ls -la /proc/$(pidof docker-containerd)/ns
lrwxrwxrwx 1 root root 0 Oct 14 10:50 ipc -> ipc:[4026531839]
lrwxrwxrwx 1 root root 0 Oct 14 10:50 mnt -> mnt:[4026533327]
lrwxrwxrwx 1 root root 0 Oct 14 10:50 net -> net:[4026531968]
lrwxrwxrwx 1 root root 0 Oct 14 10:50 pid -> pid:[4026531836]
lrwxrwxrwx 1 root root 0 Oct 14 10:50 user -> user:[4026531837]
lrwxrwxrwx 1 root root 0 Oct 14 10:50 uts -> uts:[4026531838]
 
[stupig@hostname ~]$ ps -eo pid,cmd,lstart|grep -w containerd-shim
 22283 docker-containerd-shim -nam Wed Oct 14 10:48:50 2020
 22407 docker-containerd-shim -nam Wed Oct 14 10:48:55 2020
 28454 docker-containerd-shim -nam Wed Oct 14 10:49:53 2020
 28530 docker-containerd-shim -nam Wed Oct 14 10:49:53 2020
 
[stupig@hostname ~]$ sudo ls -la /proc/28454/ns
lrwxrwxrwx 1 root root 0 Oct 14 10:50 ipc -> ipc:[4026531839]
lrwxrwxrwx 1 root root 0 Oct 14 10:50 mnt -> mnt:[4026533200]
lrwxrwxrwx 1 root root 0 Oct 14 10:50 net -> net:[4026531968]
lrwxrwxrwx 1 root root 0 Oct 14 10:50 pid -> pid:[4026531836]
lrwxrwxrwx 1 root root 0 Oct 14 10:50 user -> user:[4026531837]
lrwxrwxrwx 1 root root 0 Oct 14 10:50 uts -> uts:[4026531838]
 
[stupig@hostname ~]$ sudo ls -la /proc/$$/ns
lrwxrwxrwx 1 stupig stupig 0 Oct 14 21:49 ipc -> ipc:[4026531839]
lrwxrwxrwx 1 stupig stupig 0 Oct 14 21:49 mnt -> mnt:[4026531840]
lrwxrwxrwx 1 stupig stupig 0 Oct 14 21:49 net -> net:[4026531968]
lrwxrwxrwx 1 stupig stupig 0 Oct 14 21:49 pid -> pid:[4026531836]
lrwxrwxrwx 1 stupig stupig 0 Oct 14 21:49 user -> user:[4026531837]
lrwxrwxrwx 1 stupig stupig 0 Oct 14 21:49 uts -> uts:[4026531838]

结果验证了我们推断的正确性。现在再补充下docker组件的进程树模型，用以解释这个现象，模型如下：

1
2
3
4
5
6
7
8
9
10
11
12
                       +-------------+                      
                       |   dockerd   |                      
                       +------|------+                      
                              |                             
                       +------|------+                      
                       | containerd  |                      
                       +---|--|---|--+                      
         +-----------------+  |   +----------------+        
+--------|--------+  +--------|--------+  +--------|--------+
| containerd-shim |  | containerd-shim |  | containerd-shim |
+-----------------+  +-----------------+  +-----------------+

dockerd进程启动时，会自动拉起containerd进程；当用户创建并启动容器时，containerd会启动containerd-shim进程用于托管容器进程，最终由containerd-shim调用runc启动容器进程。runc负责初始化进程命名空间，并exec容器启动命令。

上述模型中shim进程存在的意义是：允许dockerd/containerd升级或重启，同时不影响已运行容器。docker提供了 live-restore 的能力，而我们的集群也的确启用了该配置。

此外，由于我们在systemd的docker配置选项中配置了 MountFlags=slave，参考systemd配置说明，systemd在启动dockerd进程时，会创建一个新的mnt命名空间。

至此，问题已基本定位清楚：

  • systemd在启动dockerd服务时，将dockerd安置在一个新的mnt命名空间中
  • 用户创建并启动容器时，dockerd会在本mnt命名空间内挂载容器读写层目录，并启动shim进程托管容器进程
  • 由于某种原因，dockerd服务发生重启，systemd会将其安置在另一个新的mnt命名空间内
  • 用户删除容器时，容器退出时，dockerd在清理容器读写层挂载时报错，因为挂载并非在当前dockerd的mnt命名空间内

后来，我们在docker issue中也发现了官方给出的说明，MountFlags=slave 与 live-restore 确实不能同时使用。

一波又起

还没当我们沉浸在解决问题的喜悦之中，另一个疑问接踵而来。我们线上集群好多宿主同时配置了 MountFlags=slave 和 live-restore=true，为什么问题直到最近才报出来呢？

当我们分析了几起 Pod Terminating 的涉事宿主后，发现它们的一个通性是docker版本为 18.06.3-ce，而我们当前主流的版本仍然是 1.13.1。

难道是新版本中才引入的问题？我们首先在测试环境中对 1.13.1 版本的docker进行了验证，Pod确实没有被阻塞在 Terminating 状态，这是不是说明低版本docker不存在挂载点泄漏的问题呢？

事实并非如此。当我们再次进行验证时，在删除Pod前记录了测试容器的读写层，之后发送删除Pod指令，Pod顺利退出，但此时，我们登录Pod之前所在宿主，发现docker日志中同样也存在如下日志：

1
2
Oct 14 22:12:43 hostname2 dockerd: time="2020-10-14T22:12:43.730726978+08:00" level=debug msg="Failed to unmount fb41efa2cfcbfbb8d90bd1d8d77d299e17518829faf52af40f7a1552ec8aa165 overlay: /home/docker_rt/overlay2/fb41efa2cfcbfbb8d90bd1d8d77d299e17518829faf52af40f7a1552ec8aa165/merged - invalid argument"

同样存在卸载问题的情况下，高低版本的docker却呈现出了不同的结果，这显然是docker的处理逻辑发生了变更，这里我们对比源码能够很快得出结论：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
// 1.13.1 版本处理逻辑
func (daemon *Daemon) cleanupContainer(container *container.Container, forceRemove, removeVolume bool) (err error) {
   // If force removal is required, delete container from various
   // indexes even if removal failed.
   defer func() {
      if err == nil || forceRemove {
         daemon.nameIndex.Delete(container.ID)
         daemon.linkIndex.delete(container)
         selinuxFreeLxcContexts(container.ProcessLabel)
         daemon.idIndex.Delete(container.ID)
         daemon.containers.Delete(container.ID)
         if e := daemon.removeMountPoints(container, removeVolume); e != nil {
            logrus.Error(e)
         }
         daemon.LogContainerEvent(container, "destroy")
      }
   }()
 
   if err = os.RemoveAll(container.Root); err != nil {
      return fmt.Errorf("Unable to remove filesystem for %v: %v", container.ID, err)
   }
 
   // When container creation fails and `RWLayer` has not been created yet, we
   // do not call `ReleaseRWLayer`
   if container.RWLayer != nil {
      metadata, err := daemon.layerStore.ReleaseRWLayer(container.RWLayer)
      layer.LogReleaseMetadata(metadata)
      if err != nil && err != layer.ErrMountDoesNotExist {
         return fmt.Errorf("Driver %s failed to remove root filesystem %s: %s", daemon.GraphDriverName(), container.ID, err)
      }
   }
 
   return nil
}
 
 
// 18.06.3-ce 版本处理逻辑
func (daemon *Daemon) cleanupContainer(container *container.Container, forceRemove, removeVolume bool) (err error) {
   // When container creation fails and `RWLayer` has not been created yet, we
   // do not call `ReleaseRWLayer`
   if container.RWLayer != nil {
      err := daemon.imageService.ReleaseLayer(container.RWLayer, container.OS)
      if err != nil {
         err = errors.Wrapf(err, "container %s", container.ID)
         container.SetRemovalError(err)
         return err
      }
      container.RWLayer = nil
   }
 
   if err := system.EnsureRemoveAll(container.Root); err != nil {
      e := errors.Wrapf(err, "unable to remove filesystem for %s", container.ID)
      container.SetRemovalError(e)
      return e
   }
 
   linkNames := daemon.linkIndex.delete(container)
   selinuxFreeLxcContexts(container.ProcessLabel)
   daemon.idIndex.Delete(container.ID)
   daemon.containers.Delete(container.ID)
   daemon.containersReplica.Delete(container)
   if e := daemon.removeMountPoints(container, removeVolume); e != nil {
      logrus.Error(e)
   }
   for _, name := range linkNames {
      daemon.releaseName(name)
   }
   container.SetRemoved()
   stateCtr.del(container.ID)
   return nil
}

改动一目了然，官方在清理容器变更中给出了详细的说明。也即在低版本docker中，问题并非不存在，仅仅是被隐藏了，并在高版本中被暴露出来。

问题影响

既然所有版本的docker都存在这个问题，那么其影响是什么呢？

在高版本docker中，其影响是显式的，会引起容器清理失败，进而造成Pod删除失败。

而在低版本docker中，其影响是隐式的，造成挂载点泄漏，进而可能会造成的影响如下：

  • inode被打满：由于挂载点泄漏，容器读写层不会被清理，长时间累计可能会造成inode耗尽问题，但是是小概率事件
  • 容器ID复用：由于挂载点未被卸载，当docker复用了原来已经退出的容器ID时，在挂载容器init层与读写层时会失败。由于docker生成容器ID是随机的，因此也是小概率事件

解决方案

问题已然明确，如何解决问题成了当务之急。思路有二：

  1. 治标：对标 1.13.1 版本的处理逻辑，修改 18.06.3-ce 处理代码
  2. 治本：既然官方也提及 MountFlags=slave 与 live-restore 不能同时使用，那么我们修改两个配置选项之一即可

考虑到 重启docker不重启容器 这样一个强需求的存在，似乎我们唯一的解决方案就是关闭 MountFlags=slave 配置。关闭该配置后，与之而来的疑问如下：

  • 能否解决本问题？
  • 如网络所传，其他systemd托管服务启用PrivateTmp是否会造成挂载点泄漏？

预知后事如何，且听下回分解！

传送门

]]> <h3 id="背景"><a href="#背景" class="headerlink" title="背景"></a>背景</h3><p>近期，弹性云线上集群发生了几起特殊的容器漂移失败事件，其特殊之处在于容器处于Pod Terminating状态，而宿主则处于Ready状态。 一次读 pipe 引发的血案 https://plpan.github.io/%E4%B8%80%E6%AC%A1%E8%AF%BB-pipe-%E5%BC%95%E5%8F%91%E7%9A%84%E8%A1%80%E6%A1%88/ 2020-07-19T10:53:03.000Z 2020-11-12T14:53:08.617Z 背景

背景详见：docker-hang-死排查之旅。总结成一句话：runc非预期写pipe造成一系列组件的阻塞，当我们读pipe以消除阻塞时，发生了一个非预期的现象——宿主上所有的容器都被重建了。

再详细分析问题原因之前，我们先简单回顾下linux pipe的基础知识。

linux pipe

linux pipe（也即管道），相信大家对它都不陌生，是一种典型的进程间通信机制。管道主要分为两类：命名管道与匿名管道。其区别在于：

  • 命名管道：管道以文件形式存储在文件系统之上，系统中的任意两个进程都可以借助命名管道通信
  • 匿名管道：管道不以文件形式存储在文件系统之上，仅存储在进程的文件描述符表中，只有具有血缘关系的进程直接才能借助管道通信，如父子进程、子子进程、祖孙进程等

管道可以被想象成一个固定大小的文件，分为读写两端，阻塞型管道读写有如下特点：

  • 读端：当管道内无数据时，读操作阻塞，直到有数据写入，或者所有写段关闭
  • 写段：当管道已被写满时，写操作阻塞，直到数据被读出

linux pipe默认大小为16内存页[ref.2]，也即65536字节。

这里我有一个小疑惑：写pipe超过65536字节才会被阻塞，我们在宿主上也验证了这个结论，但是docker-hang-死排查之旅写入5378字符时就已被阻塞。欢迎了解的小伙伴解惑。

血案发生

由于runc init非预期往pipe里写入大量数据而引起阻塞，我们消除阻塞的做法很简单，人为读取pipe中的内容。当我们读取完pipe中的内容时，原本一切都应该按照我们的预期发展：收集到runc init非预期写pipe的真正原因；异常容器恢复响应。确实，以上两点都如我们预期的发生了，然而，此时还发生了一个非预期的动作：宿主上所有容器都被重建了。

一个线上事故就此发生。原本其他线上容器运行正常，当我们解决docker hang死问题时，却引起了其他容器的一次重建，这显然是不可接受的。

问题定位

我们的第一嫌犯是docker，怀疑宿主docker服务发生了重启。当我们验证docker服务状态时，排除了docker的嫌疑，因为docker上一次重启时间是好多天前。

既然不是docker，那基本就是kubernetes了。kubernetes组件又分为master端与node端两大类。node端组件仅有kubelet，但是kubelet的嫌疑很小，因为它就是个打工仔，所有事情都是听从master的安排。而master端组件有三：控制器、调度器，与API服务。由于调度器包含驱逐功能，原本调度器嫌疑最大，但是因为我们线上关闭了驱逐功能，因此也基本不可能是调度器搞的鬼；而API服务则是被动的接收变更请求，也能排除嫌疑；那么嫌疑犯只剩下控制器了，控制器为什么要重建宿主上的所有容器呢？

以上是我们的猜测环节，为了验证猜测正确与否，我们必须收集证据。证据何在？基本就埋没在海量的组件日志中。天网恢恢疏而不漏，在控制器日志中，我们掌握了它犯罪的关键证据：

1
/var/log/kubernetes/kube-controller-manager.root.log.INFO.20200712-014245.35913:I0712 03:19:59.590703   35913 controller_utils.go:95] Starting deletion of pod default/kproxy-sf-69466-1

我们在0709发现宿主docker异常，而控制器在0712主动删除了宿主上的容器。证据在手，我们就开始审问控制器，它的交代入下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
// DeletePods will delete all pods from master running on given node,
// and return true if any pods were deleted, or were found pending
// deletion.
func DeletePods(kubeClient clientset.Interface, recorder record.EventRecorder, nodeName, nodeUID string, daemonStore extensionslisters.DaemonSetLister) (bool, error) {
......
for _, pod := range pods.Items {
......
glog.V(2).Infof("Starting deletion of pod %v/%v", pod.Namespace, pod.Name)
if err := kubeClient.CoreV1().Pods(pod.Namespace).Delete(pod.Name, nil); err != nil {
return false, err
}
remaining = true
}
  ......
}

func (nc *Controller) doEvictionPass() {
nc.evictorLock.Lock()
defer nc.evictorLock.Unlock()
for k := range nc.zonePodEvictor {
// Function should return 'false' and a time after which it should be retried, or 'true' if it shouldn't (it succeeded).
nc.zonePodEvictor[k].Try(func(value scheduler.TimedValue) (bool, time.Duration) {
......
remaining, err := nodeutil.DeletePods(nc.kubeClient, nc.recorder, value.Value, nodeUID, nc.daemonSetStore)
......
})
}
}

// Run starts an asynchronous loop that monitors the status of cluster nodes.
func (nc *Controller) Run(stopCh <-chan struct{}) {
  ......
// Managing eviction of nodes:
// When we delete pods off a node, if the node was not empty at the time we then
// queue an eviction watcher. If we hit an error, retry deletion.
go wait.Until(nc.doEvictionPass, scheduler.NodeEvictionPeriod, stopCh)
    ......
}

这个控制器就是node_lifecycle_controller，也即宿主生命周期控制器，该控制器定时 (每100ms) 驱逐宿主上的容器。这个控制器并非不分青红皂白就一通乱杀，不然线上早就乱套了，我们再来看看其判断条件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
// monitorNodeStatus verifies node status are constantly updated by kubelet, and if not,
// post "NodeReady==ConditionUnknown". It also evicts all pods if node is not ready or
// not reachable for a long period of time.
func (nc *Controller) monitorNodeStatus() error {
  ......
  if currentReadyCondition != nil {
// Check eviction timeout against decisionTimestamp
if observedReadyCondition.Status == v1.ConditionFalse {
if decisionTimestamp.After(nc.nodeStatusMap[node.Name].readyTransitionTimestamp.Add(nc.podEvictionTimeout)) {
if nc.evictPods(node) {
glog.V(2).Infof("Node is NotReady. Adding Pods on Node %s to eviction queue: %v is later than %v + %v",
node.Name,
decisionTimestamp,
nc.nodeStatusMap[node.Name].readyTransitionTimestamp,
nc.podEvictionTimeout,
)
}
}
}
if observedReadyCondition.Status == v1.ConditionUnknown {
if decisionTimestamp.After(nc.nodeStatusMap[node.Name].probeTimestamp.Add(nc.podEvictionTimeout)) {
if nc.evictPods(node) {
glog.V(2).Infof("Node is unresponsive. Adding Pods on Node %s to eviction queues: %v is later than %v + %v",
node.Name,
decisionTimestamp,
nc.nodeStatusMap[node.Name].readyTransitionTimestamp,
nc.podEvictionTimeout-gracePeriod,
)
}
}
}
  }
  ......
}

func (nc *Controller) evictPods(node *v1.Node) bool {
nc.evictorLock.Lock()
defer nc.evictorLock.Unlock()
return nc.zonePodEvictor[utilnode.GetZoneKey(node)].Add(node.Name, string(node.UID))
}

可见，控制器驱逐该宿主上的所有Pod的条件有二：

  1. 宿主的状态为NotReady或者Unknown
  2. 宿主状态保持非Ready超过指定时间阈值。该时间阈值由nc.podEvictionTimeout定义，默认为5分钟，我们的线上集群将其定制为2000分钟

在docker-hang-死阻塞-kubelet-初始化流程中，我们提到由于docker hang死，kubelet初始化流程被阻塞，宿主状态为NotReady，命中条件1；我们检查kubelet NotReady的起始时间为2020-07-10 17:58:59，与控制器删除Pod的时间间隔基本为2000分钟，命中条件2。

至此，本问题基本已盖棺定论：由于线上宿主状态非Ready持续时间太长，引起控制器驱逐宿主上所有容器导致。

思考

清楚了其原理之后，大家再来思考一个问题：当宿主状态非Ready时，无法处理控制器发出的驱逐容器的请求，当且仅当宿主状态变成Ready之后，才能开始处理。既然宿主已恢复，是否还有必要立即驱逐其上的所有容器？尤其是针对有状态服务，删除Pod之后，立马又在原宿主创建该Pod。我个人感觉非但没有必要，而且还存在一定风险。

针对控制器的驱逐策略，我们调大了线上的驱逐时间间隔，从原来的2000分钟，调整为3年。

Reference

  1. https://elixir.bootlin.com/linux/v3.10/source/fs/pipe.c#L496
  2. https://elixir.bootlin.com/linux/v3.10/source/include/linux/pipe_fs_i.h#L4
]]> <h3 id="背景"><a href="#背景" class="headerlink" title="背景"></a>背景</h3><p>背景详见：<a href="https://plpan.github.io/docker-hang-%E6%AD%BB%E6%8E%92%E docker hang 死阻塞 kubelet 初始化流程 https://plpan.github.io/docker-hang-%E6%AD%BB%E9%98%BB%E5%A1%9E-kubelet-%E5%88%9D%E5%A7%8B%E5%8C%96%E6%B5%81%E7%A8%8B/ 2020-07-18T08:50:27.000Z 2020-11-12T14:52:25.727Z 背景

最近升级了一版kubelet，修复因kubelet删除Sidecar类型Pod慢导致平台删除集群超时的问题。在灰度redis隔离集群的时候，发现升级kubelet并重启服务后，少量宿主状态变成了NotReady，并且回滚kubelet至之前版本，宿主状态仍然是NotReady。查看宿主状态时提示 ‘container runtime is down’ ，显示容器运行时出了问题。

我们使用的容器运行时是docker。我们就去检查docker的状态，检测结果如下：

  • docker ps 查看所有容器列表，执行正常
  • docker inspect 查看容器详细状态，某一容器执行阻塞

典型的docker hang死行为。我们最近在升级docker版本，存量宿主docker的版本为1.13.1，并且在逐步升级至18.06.3，新宿主的docker版本都是18.06.3。docker hang死问题在1.13.1版本上表现得更彻底，在执行docker ps的时候就已经hang死了；而docker 18.06.3做了一点小小的优化，在执行docker ps时去掉了容器级别的加锁操作。但是很多docker命令在执行前都会申请容器锁，因此一旦某一个容器出现问题，并不会造成docker服务不可响应，受影响的也仅仅是该容器，无法执行操作。

至于为什么以docker ps与docker inspect为指标检查docker状态，因为kubelet就是依赖这两个docker命令获取容器状态。

所以，现在问题有二：

  • docker hang死的根因是什么？
  • docker hang死时，为什么重启kubelet，会导致宿主状态变为NotReady？

docker hang死的排查详见：docker-hang-死排查之旅。现在我们再来分析，当容器异常时，为什么重启kubelet，宿主的状态会从Ready变成NotReady。

宿主状态生成机制

在问题排查之前，我们需要先了解宿主状态的生成机制。

宿主的所有状态都是node.Status的属性，因此我们直接定位kubelet设置node.Status的代码即可。

1
2
3
4
5
6
7
8
9
10
// Run starts the kubelet reacting to config updates
func (kl *Kubelet) Run(updates <-chan kubetypes.PodUpdate) {
  ......
  if kl.kubeClient != nil {
// Start syncing node status immediately, this may set up things the runtime needs to run.
go wait.Until(kl.syncNodeStatus, kl.nodeStatusUpdateFrequency, wait.NeverStop)
go kl.fastStatusUpdateOnce()
}
  ......
}

kubelet在启动时创建了一个goroutine，周期性地向apiserver同步本宿主的状态，同步周期默认是10s。

跟踪调用链路，我们可以看到kubelet针对宿主会设置多个Condition，表明宿主当前所处的状态，比如宿主内存是否告急、线程数是否告急，以及宿主是否就绪。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// defaultNodeStatusFuncs is a factory that generates the default set of
// setNodeStatus funcs
func (kl *Kubelet) defaultNodeStatusFuncs() []func(*v1.Node) error {
   ......
   setters = append(setters,
      nodestatus.OutOfDiskCondition(kl.clock.Now, kl.recordNodeStatusEvent),
      nodestatus.MemoryPressureCondition(kl.clock.Now, kl.evictionManager.IsUnderMemoryPressure, kl.recordNodeStatusEvent),
      nodestatus.DiskPressureCondition(kl.clock.Now, kl.evictionManager.IsUnderDiskPressure, kl.recordNodeStatusEvent),
      nodestatus.PIDPressureCondition(kl.clock.Now, kl.evictionManager.IsUnderPIDPressure, kl.recordNodeStatusEvent),
      nodestatus.ReadyCondition(kl.clock.Now, kl.runtimeState.runtimeErrors, kl.runtimeState.networkErrors, validateHostFunc, kl.containerManager.Status, kl.recordNodeStatusEvent),
      nodestatus.VolumesInUse(kl.volumeManager.ReconcilerStatesHasBeenSynced, kl.volumeManager.GetVolumesInUse),
      // TODO(mtaufen): I decided not to move this setter for now, since all it does is send an event
      // and record state back to the Kubelet runtime object. In the future, I'd like to isolate
      // these side-effects by decoupling the decisions to send events and partial status recording
      // from the Node setters.
      kl.recordNodeSchedulableEvent,
   )
   return setters
}

其中Ready Condition表明宿主是否就绪，kubectl查看宿主状态时，展示的Status信息就是Ready Condition的状态，常见的状态及其含义定义如下：

  • Ready状态：表明宿主状态一切OK，能正常响应Pod事件
  • NotReady状态：表明宿主的kubelet仍在运行，但是此时已经无法处理Pod事件。NotReady绝大多数情况都是由容器运行时异常导致
  • Unknown状态：表明宿主上的kubelet已停止运行

kubelet定义的Ready Condition的判定条件如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
// ReadyCondition returns a Setter that updates the v1.NodeReady condition on the node.
func ReadyCondition(
nowFunc func() time.Time, // typically Kubelet.clock.Now
runtimeErrorsFunc func() []string, // typically Kubelet.runtimeState.runtimeErrors
networkErrorsFunc func() []string, // typically Kubelet.runtimeState.networkErrors
appArmorValidateHostFunc func() error, // typically Kubelet.appArmorValidator.ValidateHost, might be nil depending on whether there was an appArmorValidator
cmStatusFunc func() cm.Status, // typically Kubelet.containerManager.Status
recordEventFunc func(eventType, event string), // typically Kubelet.recordNodeStatusEvent
) Setter {
return func(node *v1.Node) error {
......
rs := append(runtimeErrorsFunc(), networkErrorsFunc()...)
    requiredCapacities := []v1.ResourceName{v1.ResourceCPU, v1.ResourceMemory, v1.ResourcePods}
if utilfeature.DefaultFeatureGate.Enabled(features.LocalStorageCapacityIsolation) {
requiredCapacities = append(requiredCapacities, v1.ResourceEphemeralStorage)
}
missingCapacities := []string{}
for _, resource := range requiredCapacities {
if _, found := node.Status.Capacity[resource]; !found {
missingCapacities = append(missingCapacities, string(resource))
}
}
if len(missingCapacities) > 0 {
rs = append(rs, fmt.Sprintf("Missing node capacity for resources: %s", strings.Join(missingCapacities, ", ")))
}
    if len(rs) > 0 {
newNodeReadyCondition = v1.NodeCondition{
Type:              v1.NodeReady,
Status:            v1.ConditionFalse,
Reason:            "KubeletNotReady",
Message:           strings.Join(rs, ","),
LastHeartbeatTime: currentTime,
}
}
......
}
}

以上代码片段显示，宿主是否Ready取决于很多条件，包含运行时判定、网络判定、基本资源判定等。

宿主状态变化定位

接下来，我们将重点放在运行时判定，分析宿主状态发生变化的原因。运行时判定条件定义如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
func (s *runtimeState) runtimeErrors() []string {
   s.RLock()
   defer s.RUnlock()
   var ret []string
   if !s.lastBaseRuntimeSync.Add(s.baseRuntimeSyncThreshold).After(time.Now()) {  // 1
      ret = append(ret, "container runtime is down")
   }
   if s.internalError != nil {
      ret = append(ret, s.internalError.Error())
   }
   for _, hc := range s.healthChecks {                                            // 2
      if ok, err := hc.fn(); !ok {
         ret = append(ret, fmt.Sprintf("%s is not healthy: %v", hc.name, err))
      }
   }
   return ret
}

当出现如下两种状况之一时，则判定运行时检查不通过：

  1. 当前时间距最近一次运行时同步操作 (lastBaseRuntimeSync) 的时间间隔超过指定阈值（默认30s）
  2. 运行时健康检查未通过

那么，当时宿主的NotReady是由哪种状况引起的呢？结合kubelet日志分析，kubelet每隔5s就输出一条日志：

1
2
3
4
5
......
I0715 10:43:28.049240   16315 kubelet.go:1835] skipping pod synchronization - [container runtime is down]
I0715 10:43:33.049359   16315 kubelet.go:1835] skipping pod synchronization - [container runtime is down]
I0715 10:43:38.049492   16315 kubelet.go:1835] skipping pod synchronization - [container runtime is down]
......

因此，状况1是宿主NotReady的元凶。

我们继续分析为什么kubelet没有按照预期设置lastBaseRuntimeSync。kubelet启动时会创建一个goroutine，并在该goroutine中循环设置lastBaseRuntimeSync，循环如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
func (kl *Kubelet) Run(updates <-chan kubetypes.PodUpdate) {
   ......
   go wait.Until(kl.updateRuntimeUp, 5*time.Second, wait.NeverStop)
   ......
}

func (kl *Kubelet) updateRuntimeUp() {
   kl.updateRuntimeMux.Lock()
   defer kl.updateRuntimeMux.Unlock()
   ......
   kl.oneTimeInitializer.Do(kl.initializeRuntimeDependentModules)
   kl.runtimeState.setRuntimeSync(kl.clock.Now())
}

func (s *runtimeState) setRuntimeSync(t time.Time) {
 s.Lock()
 defer s.Unlock()
 s.lastBaseRuntimeSync = t
}

正常情况下，kubelet每隔5s会将lastBaseRuntimeSync设置为当前时间，而宿主状态异常时，这个时间戳一直未被更新。也即updateRuntimeUp一直被阻塞在设置lastBaseRuntimeSync之前的某一步。因此，我们只需逐个排查updateRuntimeUp内的函数调用即可，具体过程不再展示，最终的函数调用链路如下：

1
initializeRuntimeDependentModules -> kl.cadvisor.Start -> cc.Manager.Start -> self.createContainer -> m.createContainerLocked -> container.NewContainerHandler -> factory.CanHandleAndAccept -> self.client.ContainerInspect

调用链路显示，最后cadvisor执行docker inspect时被hang死，阻塞了kubelet的一个关键初始化流程。

如果容器异常发生在kubelet初始化完毕之后，则不会对宿主的Ready状态造成任何影响，因为oneTimeInitializer是sync.Once类型，也即仅仅会在kubelet启动时执行一次。那时容器异常对kubelet的影响有限，仅仅是不能处理该Pod的任何事件，包含删除、变更等，但是仍然能够处理其他Pod的事件。

这就解释了为什么kubelet重启前宿主状态是Ready，重启后状态是NotReady。

后续

可能有人会问，为什么cadvisor执行docker inspect操作不加超时控制？确实，如果添加了超时控制，重启kubelet不会引起宿主状态变更。个人觉得添加超时控制没有什么问题，不清楚是否有啥坑，待详细挖掘后再来补充。

]]> <h3 id="背景"><a href="#背景" class="headerlink" title="背景"></a>背景</h3><p>最近升级了一版kubelet，修复因kubelet删除Sidecar类型Pod慢导致平台删除集群超时的问题。在灰度redis隔离集群的时候， docker hang 死排查之旅 https://plpan.github.io/docker-hang-%E6%AD%BB%E6%8E%92%E6%9F%A5%E4%B9%8B%E6%97%85/ 2020-07-17T08:20:51.000Z 2020-11-12T14:53:31.389Z 背景

最近，我们在升级kubelet时，发现部分宿主机上docker出现hang死的现象，发现过程详见：docker-hang-死阻塞-kubelet-初始化流程。

现在，我们聚焦在docker上，分析docker hang死问题发生时的现象、形成的原因、问题定位的方法，以及对应的解决办法。本文详细记录了整个过程。

docker hang死

我们对docker hang死并不陌生，因为已经发生了好多起。其发生时的现象也多种多样。以往针对docker 1.13.1版本的排查都发现了一些线索，但是并没有定位到根因，最终绝大多数也是通过重启docker解决。而这一次发生在docker 18.06.3版本的docker hang死行为，经过我们4人小分队接近一周的望闻问切，终于确定了其病因。注意，docker hang死的原因远不止一种，因此本排查方法与结果并不具有普适性。

在开始问题排查之前，我们先整理目前掌握的知识：

  • 特定容器异常，无法响应docker inspect操作

除此之外的信息，我们则一无所知。

当我们排查一个未知的问题时，一般的做法是先找一个切入点，然后顺藤摸瓜，逐步缩小问题排查的圈定范围，并最终在细枝末节上定位问题的所在。而本问题中，docker显然是我们唯一的切入点。

链路跟踪

首先，我们希望对docker运行的全局状况有一个大致的了解，熟悉go语言开发的用户自然能联想到调试神器pprof。我们借助pprof描绘出了docker当时运行的蓝图：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
goroutine profile: total 722373
717594 @ 0x7fe8bc202980 0x7fe8bc202a40 0x7fe8bc2135d8 0x7fe8bc2132ef 0x7fe8bc238c1a 0x7fe8bd56f7fe 0x7fe8bd56f6bd 0x7fe8bcea8719 0x7fe8bcea938b 0x7fe8bcb726ca 0x7fe8bcb72b01 0x7fe8bc71c26b 0x7fe8bcb85f4a 0x7fe8bc4b9896 0x7fe8bc72a438 0x7fe8bcb849e2 0x7fe8bc4bc67e 0x7fe8bc4b88a3 0x7fe8bc230711
#0x7fe8bc2132eesync.runtime_SemacquireMutex+0x3e/usr/local/go/src/runtime/sema.go:71
#0x7fe8bc238c19sync.(*Mutex).Lock+0x109/usr/local/go/src/sync/mutex.go:134
#0x7fe8bd56f7fdgithub.com/docker/docker/daemon.(*Daemon).ContainerInspectCurrent+0x8d/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/daemon/inspect.go:40
#0x7fe8bd56f6bcgithub.com/docker/docker/daemon.(*Daemon).ContainerInspect+0x11c/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/daemon/inspect.go:29
#0x7fe8bcea8718github.com/docker/docker/api/server/router/container.(*containerRouter).getContainersByName+0x118/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/api/server/router/container/inspect.go:15
#0x7fe8bcea938agithub.com/docker/docker/api/server/router/container.(*containerRouter).(github.com/docker/docker/api/server/router/container.getContainersByName)-fm+0x6a/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/api/server/router/container/container.go:39
#0x7fe8bcb726c9github.com/docker/docker/api/server/middleware.ExperimentalMiddleware.WrapHandler.func1+0xd9/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/api/server/middleware/experimental.go:26
#0x7fe8bcb72b00github.com/docker/docker/api/server/middleware.VersionMiddleware.WrapHandler.func1+0x400/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/api/server/middleware/version.go:62
#0x7fe8bc71c26agithub.com/docker/docker/pkg/authorization.(*Middleware).WrapHandler.func1+0x7aa/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/pkg/authorization/middleware.go:59
#0x7fe8bcb85f49github.com/docker/docker/api/server.(*Server).makeHTTPHandler.func1+0x199/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/api/server/server.go:141
#0x7fe8bc4b9895net/http.HandlerFunc.ServeHTTP+0x45/usr/local/go/src/net/http/server.go:1947
#0x7fe8bc72a437github.com/docker/docker/vendor/github.com/gorilla/mux.(*Router).ServeHTTP+0x227/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/vendor/github.com/gorilla/mux/mux.go:103
#0x7fe8bcb849e1github.com/docker/docker/api/server.(*routerSwapper).ServeHTTP+0x71/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/api/server/router_swapper.go:29
#0x7fe8bc4bc67dnet/http.serverHandler.ServeHTTP+0xbd/usr/local/go/src/net/http/server.go:2694
#0x7fe8bc4b88a2net/http.(*conn).serve+0x652/usr/local/go/src/net/http/server.go:1830

4175 @ 0x7fe8bc202980 0x7fe8bc202a40 0x7fe8bc2135d8 0x7fe8bc2132ef 0x7fe8bc238c1a 0x7fe8bcc2eccf 0x7fe8bd597af4 0x7fe8bcea2456 0x7fe8bcea956b 0x7fe8bcb73dff 0x7fe8bcb726ca 0x7fe8bcb72b01 0x7fe8bc71c26b 0x7fe8bcb85f4a 0x7fe8bc4b9896 0x7fe8bc72a438 0x7fe8bcb849e2 0x7fe8bc4bc67e 0x7fe8bc4b88a3 0x7fe8bc230711
#0x7fe8bc2132eesync.runtime_SemacquireMutex+0x3e/usr/local/go/src/runtime/sema.go:71
#0x7fe8bc238c19sync.(*Mutex).Lock+0x109/usr/local/go/src/sync/mutex.go:134
#0x7fe8bcc2eccegithub.com/docker/docker/container.(*State).IsRunning+0x2e/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/container/state.go:240
#0x7fe8bd597af3github.com/docker/docker/daemon.(*Daemon).ContainerStats+0xb3/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/daemon/stats.go:30
#0x7fe8bcea2455github.com/docker/docker/api/server/router/container.(*containerRouter).getContainersStats+0x1e5/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/api/server/router/container/container_routes.go:115
#0x7fe8bcea956agithub.com/docker/docker/api/server/router/container.(*containerRouter).(github.com/docker/docker/api/server/router/container.getContainersStats)-fm+0x6a/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/api/server/router/container/container.go:42
#0x7fe8bcb73dfegithub.com/docker/docker/api/server/router.cancellableHandler.func1+0xce/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/api/server/router/local.go:92
#0x7fe8bcb726c9github.com/docker/docker/api/server/middleware.ExperimentalMiddleware.WrapHandler.func1+0xd9/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/api/server/middleware/experimental.go:26
#0x7fe8bcb72b00github.com/docker/docker/api/server/middleware.VersionMiddleware.WrapHandler.func1+0x400/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/api/server/middleware/version.go:62
#0x7fe8bc71c26agithub.com/docker/docker/pkg/authorization.(*Middleware).WrapHandler.func1+0x7aa/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/pkg/authorization/middleware.go:59
#0x7fe8bcb85f49github.com/docker/docker/api/server.(*Server).makeHTTPHandler.func1+0x199/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/api/server/server.go:141
#0x7fe8bc4b9895net/http.HandlerFunc.ServeHTTP+0x45/usr/local/go/src/net/http/server.go:1947
#0x7fe8bc72a437github.com/docker/docker/vendor/github.com/gorilla/mux.(*Router).ServeHTTP+0x227/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/vendor/github.com/gorilla/mux/mux.go:103
#0x7fe8bcb849e1github.com/docker/docker/api/server.(*routerSwapper).ServeHTTP+0x71/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/api/server/router_swapper.go:29
#0x7fe8bc4bc67dnet/http.serverHandler.ServeHTTP+0xbd/usr/local/go/src/net/http/server.go:2694
#0x7fe8bc4b88a2net/http.(*conn).serve+0x652/usr/local/go/src/net/http/server.go:1830

1 @ 0x7fe8bc202980 0x7fe8bc202a40 0x7fe8bc2135d8 0x7fe8bc2131fb 0x7fe8bc239a3b 0x7fe8bcbb679d 0x7fe8bcc26774 0x7fe8bd570b20 0x7fe8bd56f81c 0x7fe8bd56f6bd 0x7fe8bcea8719 0x7fe8bcea938b 0x7fe8bcb726ca 0x7fe8bcb72b01 0x7fe8bc71c26b 0x7fe8bcb85f4a 0x7fe8bc4b9896 0x7fe8bc72a438 0x7fe8bcb849e2 0x7fe8bc4bc67e 0x7fe8bc4b88a3 0x7fe8bc230711
#0x7fe8bc2131fasync.runtime_Semacquire+0x3a/usr/local/go/src/runtime/sema.go:56
#0x7fe8bc239a3async.(*RWMutex).RLock+0x4a/usr/local/go/src/sync/rwmutex.go:50
#0x7fe8bcbb679cgithub.com/docker/docker/daemon/exec.(*Store).List+0x4c/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/daemon/exec/exec.go:140
#0x7fe8bcc26773github.com/docker/docker/container.(*Container).GetExecIDs+0x33/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/container/container.go:423
#0x7fe8bd570b1fgithub.com/docker/docker/daemon.(*Daemon).getInspectData+0x5cf/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/daemon/inspect.go:178
#0x7fe8bd56f81bgithub.com/docker/docker/daemon.(*Daemon).ContainerInspectCurrent+0xab/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/daemon/inspect.go:42
#0x7fe8bd56f6bcgithub.com/docker/docker/daemon.(*Daemon).ContainerInspect+0x11c/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/daemon/inspect.go:29
#0x7fe8bcea8718github.com/docker/docker/api/server/router/container.(*containerRouter).getContainersByName+0x118/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/api/server/router/container/inspect.go:15
#0x7fe8bcea938agithub.com/docker/docker/api/server/router/container.(*containerRouter).(github.com/docker/docker/api/server/router/container.getContainersByName)-fm+0x6a/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/api/server/router/container/container.go:39
#0x7fe8bcb726c9github.com/docker/docker/api/server/middleware.ExperimentalMiddleware.WrapHandler.func1+0xd9/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/api/server/middleware/experimental.go:26
#0x7fe8bcb72b00github.com/docker/docker/api/server/middleware.VersionMiddleware.WrapHandler.func1+0x400/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/api/server/middleware/version.go:62
#0x7fe8bc71c26agithub.com/docker/docker/pkg/authorization.(*Middleware).WrapHandler.func1+0x7aa/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/pkg/authorization/middleware.go:59
#0x7fe8bcb85f49github.com/docker/docker/api/server.(*Server).makeHTTPHandler.func1+0x199/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/api/server/server.go:141
#0x7fe8bc4b9895net/http.HandlerFunc.ServeHTTP+0x45/usr/local/go/src/net/http/server.go:1947
#0x7fe8bc72a437github.com/docker/docker/vendor/github.com/gorilla/mux.(*Router).ServeHTTP+0x227/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/vendor/github.com/gorilla/mux/mux.go:103
#0x7fe8bcb849e1github.com/docker/docker/api/server.(*routerSwapper).ServeHTTP+0x71/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/api/server/router_swapper.go:29
#0x7fe8bc4bc67dnet/http.serverHandler.ServeHTTP+0xbd/usr/local/go/src/net/http/server.go:2694
#0x7fe8bc4b88a2net/http.(*conn).serve+0x652/usr/local/go/src/net/http/server.go:1830

1 @ 0x7fe8bc202980 0x7fe8bc212946 0x7fe8bc8b6881 0x7fe8bc8b699d 0x7fe8bc8e259b 0x7fe8bc8e1695 0x7fe8bc8c47d5 0x7fe8bd2e0c06 0x7fe8bd2eda96 0x7fe8bc8c42fb 0x7fe8bc8c4613 0x7fe8bd2a6474 0x7fe8bd2e6976 0x7fe8bd3661c5 0x7fe8bd56842f 0x7fe8bcea7bdb 0x7fe8bcea9f6b 0x7fe8bcb726ca 0x7fe8bcb72b01 0x7fe8bc71c26b 0x7fe8bcb85f4a 0x7fe8bc4b9896 0x7fe8bc72a438 0x7fe8bcb849e2 0x7fe8bc4bc67e 0x7fe8bc4b88a3 0x7fe8bc230711
#0x7fe8bc8b6880github.com/docker/docker/vendor/google.golang.org/grpc/transport.(*Stream).waitOnHeader+0x100/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/vendor/google.golang.org/grpc/transport/transport.go:222
#0x7fe8bc8b699cgithub.com/docker/docker/vendor/google.golang.org/grpc/transport.(*Stream).RecvCompress+0x2c/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/vendor/google.golang.org/grpc/transport/transport.go:233
#0x7fe8bc8e259agithub.com/docker/docker/vendor/google.golang.org/grpc.(*csAttempt).recvMsg+0x63a/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/vendor/google.golang.org/grpc/stream.go:515
#0x7fe8bc8e1694github.com/docker/docker/vendor/google.golang.org/grpc.(*clientStream).RecvMsg+0x44/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/vendor/google.golang.org/grpc/stream.go:395
#0x7fe8bc8c47d4github.com/docker/docker/vendor/google.golang.org/grpc.invoke+0x184/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/vendor/google.golang.org/grpc/call.go:83
#0x7fe8bd2e0c05github.com/docker/docker/vendor/github.com/containerd/containerd.namespaceInterceptor.unary+0xf5/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/vendor/github.com/containerd/containerd/grpc.go:35
#0x7fe8bd2eda95github.com/docker/docker/vendor/github.com/containerd/containerd.(namespaceInterceptor).(github.com/docker/docker/vendor/github.com/containerd/containerd.unary)-fm+0xf5/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/vendor/github.com/containerd/containerd/grpc.go:51
#0x7fe8bc8c42fagithub.com/docker/docker/vendor/google.golang.org/grpc.(*ClientConn).Invoke+0x10a/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/vendor/google.golang.org/grpc/call.go:35
#0x7fe8bc8c4612github.com/docker/docker/vendor/google.golang.org/grpc.Invoke+0xc2/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/vendor/google.golang.org/grpc/call.go:60
#0x7fe8bd2a6473github.com/docker/docker/vendor/github.com/containerd/containerd/api/services/tasks/v1.(*tasksClient).Start+0xd3/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/vendor/github.com/containerd/containerd/api/services/tasks/v1/tasks.pb.go:421
#0x7fe8bd2e6975github.com/docker/docker/vendor/github.com/containerd/containerd.(*process).Start+0xf5/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/vendor/github.com/containerd/containerd/process.go:109
#0x7fe8bd3661c4github.com/docker/docker/libcontainerd.(*client).Exec+0x4b4/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/libcontainerd/client_daemon.go:381
#0x7fe8bd56842egithub.com/docker/docker/daemon.(*Daemon).ContainerExecStart+0xb4e/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/daemon/exec.go:251
#0x7fe8bcea7bdagithub.com/docker/docker/api/server/router/container.(*containerRouter).postContainerExecStart+0x34a/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/api/server/router/container/exec.go:125
#0x7fe8bcea9f6agithub.com/docker/docker/api/server/router/container.(*containerRouter).(github.com/docker/docker/api/server/router/container.postContainerExecStart)-fm+0x6a/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/api/server/router/container/container.go:59
#0x7fe8bcb726c9github.com/docker/docker/api/server/middleware.ExperimentalMiddleware.WrapHandler.func1+0xd9/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/api/server/middleware/experimental.go:26
#0x7fe8bcb72b00github.com/docker/docker/api/server/middleware.VersionMiddleware.WrapHandler.func1+0x400/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/api/server/middleware/version.go:62
#0x7fe8bc71c26agithub.com/docker/docker/pkg/authorization.(*Middleware).WrapHandler.func1+0x7aa/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/pkg/authorization/middleware.go:59
#0x7fe8bcb85f49github.com/docker/docker/api/server.(*Server).makeHTTPHandler.func1+0x199/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/api/server/server.go:141
#0x7fe8bc4b9895net/http.HandlerFunc.ServeHTTP+0x45/usr/local/go/src/net/http/server.go:1947
#0x7fe8bc72a437github.com/docker/docker/vendor/github.com/gorilla/mux.(*Router).ServeHTTP+0x227/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/vendor/github.com/gorilla/mux/mux.go:103
#0x7fe8bcb849e1github.com/docker/docker/api/server.(*routerSwapper).ServeHTTP+0x71/root/rpmbuild/BUILD/src/engine/.gopath/src/github.com/docker/docker/api/server/router_swapper.go:29
#0x7fe8bc4bc67dnet/http.serverHandler.ServeHTTP+0xbd/usr/local/go/src/net/http/server.go:2694
#0x7fe8bc4b88a2net/http.(*conn).serve+0x652/usr/local/go/src/net/http/server.go:1830

注意，这是一份精简后的docker协程栈信息。从上面的蓝图，我们可以总结出如下结论：

  • 有 717594 个协程被阻塞在docker inspect
  • 有 4175 个协程被阻塞在docker stats
  • 有 1 个协程被阻塞在获取 docker exec的任务ID
  • 有 1 个协程被阻塞在docker exec的执行过程

从上面的结论，我们基本了解了异常容器hang死的原因：在于该容器执行docker exec (4)后未返回，进而导致获取docker exec的任务ID (3)阻塞，由于(3)获取了容器锁，进而导致了docker inspect (1)与docker stats (2)卡死。所以病因并非是docker inspect，而是docker exec。

要想继续往下挖掘，我们现在有必要补充一下背景知识。kubelet启动容器或者在容器内执行命令的完整调用路径如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
+--------------------------------------------------------------+
|                                                              |
|   +------------+                                             |
|   |            |                                             |
|   |   kubelet  |                                             |
|   |            |                                             |
|   +------|-----+                                             |
|          |                                                   |
|          |                                                   |
|   +------v-----+       +---------------+                     |
|   |            |       |               |                     |
|   |   dockerd  ------->|  containerd   |                     |
|   |            |       |               |                     |
|   +------------+       +-------|-------+                     |
|                                |                             |
|                                |                             |
|                        +-------v-------+     +-----------+   |
|                        |               |     |           |   |
|                        |containerd-shim----->|   runc    |   |
|                        |               |     |           |   |
|                        +---------------+     +-----------+   |
|                                                              |
+--------------------------------------------------------------+

dockerd与containerd可以当做两层nginx代理，containerd-shim是容器的监护人，而runc则是容器启动与命令执行的真正工具人。runc干的事情也非常简单：按照用户指定的配置创建NS，或者进入特定NS，然后执行用户命令。说白了，创建容器就是新建NS，然后在该NS内执行用户指定的命令。

按照上面介绍的背景知识，我们继续往下探索containerd。幸运的是，借助pprof，我们也可以描绘出containerd此时的运行蓝图：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
goroutine profile: total 430
1 @ 0x7f6e55f82740 0x7f6e55f92616 0x7f6e56a8412c 0x7f6e56a83d6d 0x7f6e56a911bf 0x7f6e56ac6e3b 0x7f6e565093de 0x7f6e5650dd3b 0x7f6e5650392b 0x7f6e56b51216 0x7f6e564e5909 0x7f6e563ec76a 0x7f6e563f000a 0x7f6e563f6791 0x7f6e55fb0151
#0x7f6e56a8412bgithub.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc.(*Client).dispatch+0x24b/go/src/github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc/client.go:102
#0x7f6e56a83d6cgithub.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc.(*Client).Call+0x15c/go/src/github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc/client.go:73
#0x7f6e56a911begithub.com/containerd/containerd/linux/shim/v1.(*shimClient).Start+0xbe/go/src/github.com/containerd/containerd/linux/shim/v1/shim.pb.go:1745
#0x7f6e56ac6e3agithub.com/containerd/containerd/linux.(*Process).Start+0x8a/go/src/github.com/containerd/containerd/linux/process.go:125
#0x7f6e565093ddgithub.com/containerd/containerd/services/tasks.(*local).Start+0x14d/go/src/github.com/containerd/containerd/services/tasks/local.go:187
#0x7f6e5650dd3agithub.com/containerd/containerd/services/tasks.(*service).Start+0x6a/go/src/github.com/containerd/containerd/services/tasks/service.go:72
#0x7f6e5650392agithub.com/containerd/containerd/api/services/tasks/v1._Tasks_Start_Handler.func1+0x8a/go/src/github.com/containerd/containerd/api/services/tasks/v1/tasks.pb.go:624
#0x7f6e56b51215github.com/containerd/containerd/vendor/github.com/grpc-ecosystem/go-grpc-prometheus.UnaryServerInterceptor+0xa5/go/src/github.com/containerd/containerd/vendor/github.com/grpc-ecosystem/go-grpc-prometheus/server.go:29
#0x7f6e564e5908github.com/containerd/containerd/api/services/tasks/v1._Tasks_Start_Handler+0x168/go/src/github.com/containerd/containerd/api/services/tasks/v1/tasks.pb.go:626
#0x7f6e563ec769github.com/containerd/containerd/vendor/google.golang.org/grpc.(*Server).processUnaryRPC+0x849/go/src/github.com/containerd/containerd/vendor/google.golang.org/grpc/server.go:920
#0x7f6e563f0009github.com/containerd/containerd/vendor/google.golang.org/grpc.(*Server).handleStream+0x1319/go/src/github.com/containerd/containerd/vendor/google.golang.org/grpc/server.go:1142
#0x7f6e563f6790github.com/containerd/containerd/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1+0xa0/go/src/github.com/containerd/containerd/vendor/google.golang.org/grpc/server.go:637

同样，我们仅保留了关键的协程信息，从上面的协程栈可以看出，containerd阻塞在接收exec返回结果处，附上关键代码佐证：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
func (c *Client) dispatch(ctx context.Context, req *Request, resp *Response) error {
   errs := make(chan error, 1)
   call := &callRequest{
      req:  req,
      resp: resp,
      errs: errs,
   }

   select {
   case c.calls <- call:
   case <-c.done:
      return c.err
   }

   select {        // 此处对应上面协程栈 /go/src/github.com/containerd/containerd/vendor/github.com/stevvooe/ttrpc/client.go:102
   case err := <-errs:
      return filterCloseErr(err)
   case <-c.done:
      return c.err
   }
}

containerd将请求传递至containerd-shim之后，一直在等待containerd-shim的返回。

正常情况下，如果我们能够按照调用链路逐个分析每个组件的协程调用栈信息，我们能够很快的定位问题所在。不幸的是，由于线上docker没有开启debug模式，我们无法收集containerd-shim的pprof信息，并且runc也没有开启pprof。因此单纯依赖协程调用链路定位问题这条路被堵死了。

截至目前，我们已经收集了部分关键信息，同时也将问题排查范围更进一步地缩小在containerd-shim与runc之间。接下来我们换一种思路继续排查。

进程排查

当组件的运行状态无法继续获取时，我们转换一下思维，获取容器的运行状态，也即异常容器此时的进程状态。

既然docker ps执行正常，而docker inspect hang死，首先我们定位异常容器，命令如下：

1
docker ps | grep -v NAME | awk '{print $1}' | while read cid; do echo $cid; docker inspect -f {{.State.Pid}} $cid; done

拿到异常容器的ID之后，我们就能扫描与该容器相关的所有进程：

1
2
3
4
5
UID      PID    PPID  C STIME TTY          TIME CMD
root     11646  6655  0 Jun17 ?        00:01:04 docker-containerd-shim -namespace moby -workdir /home/docker_rt/containerd/daemon/io.containerd.runtime.v1.linux/moby/bbd5e4b5f9c13666dd0ec7ff7afb2c4c2b0ede40a4adf1de43cc31c606f283f5 -address /var/run/docker/containerd/docker-containerd.sock -containerd-binary /usr/bin/docker-containerd -runtime-root /var/run/docker/runtime-runc
root     11680 11646  0 Jun17 ?        00:00:00 /dockerinit
root     15581 11646  0 Jun17 ?        00:00:00 docker-runc --root /var/run/docker/runtime-runc/moby --log /run/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/bbd5e4b5f9c13666dd0ec7ff7afb2c4c2b0ede40a4adf1de43cc31c606f283f5/log.json --log-format json exec --process /tmp/runc-process616674997 --detach --pid-file /run/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/bbd5e4b5f9c13666dd0ec7ff7afb2c4c2b0ede40a4adf1de43cc31c606f283f5/0594c5897a41d401e4d1d7ddd44dacdd316c7e7d53bfdae7f16b0f6b26fcbcda.pid bbd5e4b5f9c13666dd0ec7ff7afb2c4c2b0ede40a4adf1de43cc31c606f283f5
root     15638 15581  0 Jun17 ?        00:00:00 docker-runc init

核心进程列表如上，简单备注下：

  • 6655：containerd进程
  • 11646：异常容器的containerd-shim进程
  • 11680：异常容器的容器启动进程。在容器内查看，因PID NS的隔离，该进程ID是1
  • 15581：在异常容器内执行用户命令的进程，此时还未进入容器内部
  • 15638：在异常容器内执行用户命令时，进入容器NS的进程

这里再补充一个背景知识：当我们启动容器时，首先会创建runc init进程，创建并进入新的容器NS；而当我们在容器内执行命令时，首先也会创建runc init进程，进入容器的NS。只有在进入容器的隔离NS之后，才会执行用户指定的命令。

面对上面的进程列表，我们无法直观地分辨问题究竟由哪个进程引起。因此，我们还需要了解进程当前所处的状态。借助strace，我们逐一展示进程的活动状态：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
// 11646 (container-shim)
Process 11646 attached with 10 threads
[pid 37342] epoll_pwait(5,  <unfinished ...>
[pid 11656] futex(0x818cc0, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid 11655] restart_syscall(<... resuming interrupted call ...> <unfinished ...>
[pid 11654] futex(0x818bd8, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid 11653] futex(0x7fc730, FUTEX_WAKE, 1 <unfinished ...>
[pid 11651] futex(0xc4200b4148, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid 11650] futex(0xc420082948, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid 11649] futex(0xc420082548, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid 11647] restart_syscall(<... resuming interrupted call ...> <unfinished ...>
[pid 11646] futex(0x7fd008, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid 11653] <... futex resumed> )       = 0
[pid 11647] <... restart_syscall resumed> ) = -1 EAGAIN (Resource temporarily unavailable)
[pid 11653] epoll_wait(4,  <unfinished ...>
[pid 11647] pselect6(0, NULL, NULL, NULL, {0, 20000}, 0) = 0 (Timeout)
[pid 11647] futex(0x7fc730, FUTEX_WAIT, 0, {60, 0}


// 11581 (runc exec)
Process 15581 attached with 7 threads
[pid 15619] read(6,  <unfinished ...>
[pid 15592] futex(0xc4200be148, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid 15591] futex(0x7fd6d25f6238, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid 15590] futex(0xc420084d48, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid 15586] futex(0x7fd6d25f6320, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid 15584] restart_syscall(<... resuming interrupted call ...> <unfinished ...>
[pid 15581] futex(0x7fd6d25d9b28, FUTEX_WAIT, 0, NULL


// 11638 (runc init)
Process 15638 attached with 7 threads
[pid 15648] futex(0x7f512cea5320, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid 15647] futex(0x7f512cea5238, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid 15645] futex(0xc4200bc148, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid 15643] futex(0xc420082d48, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid 15642] futex(0xc420082948, FUTEX_WAIT, 0, NULL <unfinished ...>
[pid 15639] restart_syscall(<... resuming interrupted call ...> <unfinished ...>
[pid 15638] write(2, "/usr/local/go/src/runtime/proc.g"..., 33

从关联进程的活动状态，我们可以得出如下结论：

  • runc exec在等待从6号FD读取数据
  • runc init在等待从2号FD写入数据

这些FD究竟对应的是什么文件呢？我们借助lsof可以查看：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
// 11638 (runc init)
COMMAND     PID USER   FD      TYPE             DEVICE SIZE/OFF       NODE NAME
runc:[2:I 15638 root  cwd       DIR               0,41      192 1066743071 /
runc:[2:I 15638 root  rtd       DIR               0,41      192 1066743071 /
runc:[2:I 15638 root  txt       REG                0,4  7644224 1070360467 /memfd:runc_cloned:/proc/self/exe (deleted)
runc:[2:I 15638 root  mem       REG                8,3  2107816    1053962 /usr/lib64/libc-2.17.so
runc:[2:I 15638 root  mem       REG                8,3    19512    1054285 /usr/lib64/libdl-2.17.so
runc:[2:I 15638 root  mem       REG                8,3   266688    1050626 /usr/lib64/libseccomp.so.2.3.1
runc:[2:I 15638 root  mem       REG                8,3   142296    1055698 /usr/lib64/libpthread-2.17.so
runc:[2:I 15638 root  mem       REG                8,3    27168    3024893 /usr/local/gundam/gundam_client/preload/lib64/gundam_preload.so
runc:[2:I 15638 root  mem       REG                8,3   164432    1054515 /usr/lib64/ld-2.17.so
runc:[2:I 15638 root    0r     FIFO                0,8      0t0 1070361745 pipe
runc:[2:I 15638 root    1w     FIFO                0,8      0t0 1070361746 pipe
runc:[2:I 15638 root    2w     FIFO                0,8      0t0 1070361747 pipe
runc:[2:I 15638 root    3u     unix 0xffff881ff8273000      0t0 1070361341 socket
runc:[2:I 15638 root    5u  a_inode                0,9        0       7180 [eventpoll]


// 11581 (runc exec)
COMMAND     PID USER   FD      TYPE             DEVICE SIZE/OFF       NODE NAME
docker-ru 15581 root  cwd       DIR               0,18      120 1066743076 /run/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/bbd5e4b5f9c13666dd0ec7ff7afb2c4c2b0ede40a4adf1de43cc31c606f283f5
docker-ru 15581 root  rtd       DIR                8,3     4096          2 /
docker-ru 15581 root  txt       REG                8,3  7644224     919775 /usr/bin/docker-runc
docker-ru 15581 root  mem       REG                8,3  2107816    1053962 /usr/lib64/libc-2.17.so
docker-ru 15581 root  mem       REG                8,3    19512    1054285 /usr/lib64/libdl-2.17.so
docker-ru 15581 root  mem       REG                8,3   266688    1050626 /usr/lib64/libseccomp.so.2.3.1
docker-ru 15581 root  mem       REG                8,3   142296    1055698 /usr/lib64/libpthread-2.17.so
docker-ru 15581 root  mem       REG                8,3    27168    3024893 /usr/local/gundam/gundam_client/preload/lib64/gundam_preload.so
docker-ru 15581 root  mem       REG                8,3   164432    1054515 /usr/lib64/ld-2.17.so
docker-ru 15581 root    0r     FIFO                0,8      0t0 1070361745 pipe
docker-ru 15581 root    1w     FIFO                0,8      0t0 1070361746 pipe
docker-ru 15581 root    2w     FIFO                0,8      0t0 1070361747 pipe
docker-ru 15581 root    3w      REG               0,18     5456 1066709902 /run/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/bbd5e4b5f9c13666dd0ec7ff7afb2c4c2b0ede40a4adf1de43cc31c606f283f5/log.json
docker-ru 15581 root    4u  a_inode                0,9        0       7180 [eventpoll]
docker-ru 15581 root    6u     unix 0xffff881ff8275400      0t0 1070361342 socket


// 11646 (container-shim)
COMMAND     PID USER   FD      TYPE             DEVICE SIZE/OFF       NODE NAME
docker-co 11646 root  cwd       DIR               0,18      120 1066743076 /run/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/bbd5e4b5f9c13666dd0ec7ff7afb2c4c2b0ede40a4adf1de43cc31c606f283f5
docker-co 11646 root  rtd       DIR                8,3     4096          2 /
docker-co 11646 root  txt       REG                8,3  4173632     919772 /usr/bin/docker-containerd-shim
docker-co 11646 root    0r      CHR                1,3      0t0       2052 /dev/null
docker-co 11646 root    1w      CHR                1,3      0t0       2052 /dev/null
docker-co 11646 root    2w      CHR                1,3      0t0       2052 /dev/null
docker-co 11646 root    3r     FIFO                0,8      0t0 1070361745 pipe
docker-co 11646 root    4u  a_inode                0,9        0       7180 [eventpoll]
docker-co 11646 root    5u  a_inode                0,9        0       7180 [eventpoll]
docker-co 11646 root    6u     unix 0xffff881e8cac2800      0t0 1066743079 @/containerd-shim/moby/bbd5e4b5f9c13666dd0ec7ff7afb2c4c2b0ede40a4adf1de43cc31c606f283f5/shim.sock
docker-co 11646 root    7u     unix 0xffff881e8cac3400      0t0 1066743968 @/containerd-shim/moby/bbd5e4b5f9c13666dd0ec7ff7afb2c4c2b0ede40a4adf1de43cc31c606f283f5/shim.sock
docker-co 11646 root    8r     FIFO                0,8      0t0 1066743970 pipe
docker-co 11646 root    9w     FIFO                0,8      0t0 1070361745 pipe
docker-co 11646 root   10r     FIFO                0,8      0t0 1066743971 pipe
docker-co 11646 root   11u     FIFO               0,18      0t0 1066700778 /run/docker/containerd/bbd5e4b5f9c13666dd0ec7ff7afb2c4c2b0ede40a4adf1de43cc31c606f283f5/init-stdout
docker-co 11646 root   12r     FIFO                0,8      0t0 1066743972 pipe
docker-co 11646 root   13w     FIFO               0,18      0t0 1066700778 /run/docker/containerd/bbd5e4b5f9c13666dd0ec7ff7afb2c4c2b0ede40a4adf1de43cc31c606f283f5/init-stdout
docker-co 11646 root   14u     FIFO               0,18      0t0 1066700778 /run/docker/containerd/bbd5e4b5f9c13666dd0ec7ff7afb2c4c2b0ede40a4adf1de43cc31c606f283f5/init-stdout
docker-co 11646 root   15r     FIFO               0,18      0t0 1066700778 /run/docker/containerd/bbd5e4b5f9c13666dd0ec7ff7afb2c4c2b0ede40a4adf1de43cc31c606f283f5/init-stdout
docker-co 11646 root   16u     FIFO               0,18      0t0 1066700779 /run/docker/containerd/bbd5e4b5f9c13666dd0ec7ff7afb2c4c2b0ede40a4adf1de43cc31c606f283f5/init-stderr
docker-co 11646 root   17w     FIFO               0,18      0t0 1066700779 /run/docker/containerd/bbd5e4b5f9c13666dd0ec7ff7afb2c4c2b0ede40a4adf1de43cc31c606f283f5/init-stderr
docker-co 11646 root   18u     FIFO               0,18      0t0 1066700779 /run/docker/containerd/bbd5e4b5f9c13666dd0ec7ff7afb2c4c2b0ede40a4adf1de43cc31c606f283f5/init-stderr
docker-co 11646 root   19r     FIFO               0,18      0t0 1066700779 /run/docker/containerd/bbd5e4b5f9c13666dd0ec7ff7afb2c4c2b0ede40a4adf1de43cc31c606f283f5/init-stderr
docker-co 11646 root   20r     FIFO                0,8      0t0 1070361746 pipe
docker-co 11646 root   26r     FIFO                0,8      0t0 1070361747 pipe

有心人结合strace与lsof的结果，已经能够自己得出结论。

runc init往2号FD内写数据时阻塞，2号FD对应的类型是pipe类型。而linux pipe有一个默认的数据大小，当写入的数据超过该大小时，同时读端并未读取数据，写端就会被阻塞。

小结一下：containerd-shim启动runc exec去容器内执行用户命令，而runc exec启动runc init进入容器时，由于往2号FD写数据超过限制大小而被阻塞。当最底层的runc init被阻塞时，造成了调用链路上所有进程都被阻塞：

1
runc init → runc exec → containerd-shim exec → containerd exec → dockerd exec

问题定位至此，我们已经了解了docker hang死的原因。但是，现在我们还有如下问题并未解决：

  • 为什么runc init会往2号FD (对应go语言的os.Stderr) 中写入超过linux pipe大小限制的数据？
  • 为什么runc init出现问题只发生在特定容器？

如果常态下runc init就需要往os.Stdout或者os.Stderr中写入很多数据，那么所有容器的创建都应该有问题。所以，我们可以确定是该异常容器出现了什么未知原因，导致runc init非预期往os.Stderr写入了大量数据。而此时runc init往os.Stderr中写入的数据就很有可能揭示非预期的异常。

所以，我们需要获取runc init当前正在写入的数据。由于runc init的2号FD是个匿名pipe，我们无法使用常规文件读取的方式获取pipe内的数据。这里感谢鹤哥趟坑，找到了一种读取匿名pipe内容的方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
# cat /proc/15638/fd/2
runtime/cgo: pthread_create failed: Resource temporarily unavailable
SIGABRT: abort
PC=0x7f512b7365f7 m=0 sigcode=18446744073709551610

goroutine 0 [idle]:
runtime: unknown pc 0x7f512b7365f7
stack: frame={sp:0x7ffe1121a658, fp:0x0} stack=[0x7ffe0ae1bb28,0x7ffe1121ab50)
00007ffe1121a558:  00007ffe1121a6d8  00007ffe1121a6b0
00007ffe1121a568:  0000000000000001  00007f512c527660
00007ffe1121a578:  00007f512c54d560  00007f512c54d208
00007ffe1121a588:  00007f512c333e6f  0000000000000000
00007ffe1121a598:  00007f512c527660  0000000000000005
00007ffe1121a5a8:  0000000000000000  0000000000000001
00007ffe1121a5b8:  00007f512c54d208  00007f512c528000
00007ffe1121a5c8:  00007ffe1121a600  00007f512b704b0c
00007ffe1121a5d8:  00007f512b7110c0  0000000000000000
00007ffe1121a5e8:  00007f512c54d560  00007ffe1121a620
00007ffe1121a5f8:  00007ffe1121a610  000000000f11ed7d
00007ffe1121a608:  00007f512c550153  00000000ffffffff
00007ffe1121a618:  00007f512c550a9b  00007f512b707d00
00007ffe1121a628:  00007f512babc868  00007f512c9e9e5e
00007ffe1121a638:  00007f512d3bb080  00000000000000f1
00007ffe1121a648:  0000000000000011  0000000000000000
00007ffe1121a658: <00007f512b737ce8  0000000000000020
00007ffe1121a668:  0000000000000000  0000000000000000
00007ffe1121a678:  0000000000000000  0000000000000000
00007ffe1121a688:  0000000000000000  0000000000000000
00007ffe1121a698:  0000000000000000  0000000000000000
00007ffe1121a6a8:  0000000000000000  0000000000000000
00007ffe1121a6b8:  0000000000000000  0000000000000000
00007ffe1121a6c8:  0000000000000000  0000000000000000
00007ffe1121a6d8:  0000000000000000  00007f512babc868
00007ffe1121a6e8:  00007f512c9e9e5e  00007f512d3bb080
00007ffe1121a6f8:  00007f512c33f260  00007f512babc1c0
00007ffe1121a708:  00007f512babc1c0  0000000000000001
00007ffe1121a718:  00007f512babc243  00000000000000f1
00007ffe1121a728:  00007f512b7787ec  0000000000000001
00007ffe1121a738:  00007f512babc1c0  000000000000000a
00007ffe1121a748:  00007f512b7e8a4d  000000000000000a
runtime: unknown pc 0x7f512b7365f7
stack: frame={sp:0x7ffe1121a658, fp:0x0} stack=[0x7ffe0ae1bb28,0x7ffe1121ab50)
00007ffe1121a558:  00007ffe1121a6d8  00007ffe1121a6b0
00007ffe1121a568:  0000000000000001  00007f512c527660
00007ffe1121a578:  00007f512c54d560  00007f512c54d208
00007ffe1121a588:  00007f512c333e6f  0000000000000000
00007ffe1121a598:  00007f512c527660  0000000000000005
00007ffe1121a5a8:  0000000000000000  0000000000000001
00007ffe1121a5b8:  00007f512c54d208  00007f512c528000
00007ffe1121a5c8:  00007ffe1121a600  00007f512b704b0c
00007ffe1121a5d8:  00007f512b7110c0  0000000000000000
00007ffe1121a5e8:  00007f512c54d560  00007ffe1121a620
00007ffe1121a5f8:  00007ffe1121a610  000000000f11ed7d
00007ffe1121a608:  00007f512c550153  00000000ffffffff
00007ffe1121a618:  00007f512c550a9b  00007f512b707d00
00007ffe1121a628:  00007f512babc868  00007f512c9e9e5e
00007ffe1121a638:  00007f512d3bb080  00000000000000f1
00007ffe1121a648:  0000000000000011  0000000000000000
00007ffe1121a658: <00007f512b737ce8  0000000000000020
00007ffe1121a668:  0000000000000000  0000000000000000
00007ffe1121a678:  0000000000000000  0000000000000000
00007ffe1121a688:  0000000000000000  0000000000000000
00007ffe1121a698:  0000000000000000  0000000000000000
00007ffe1121a6a8:  0000000000000000  0000000000000000
00007ffe1121a6b8:  0000000000000000  0000000000000000
00007ffe1121a6c8:  0000000000000000  0000000000000000
00007ffe1121a6d8:  0000000000000000  00007f512babc868
00007ffe1121a6e8:  00007f512c9e9e5e  00007f512d3bb080
00007ffe1121a6f8:  00007f512c33f260  00007f512babc1c0
00007ffe1121a708:  00007f512babc1c0  0000000000000001
00007ffe1121a718:  00007f512babc243  00000000000000f1
00007ffe1121a728:  00007f512b7787ec  0000000000000001
00007ffe1121a738:  00007f512babc1c0  000000000000000a
00007ffe1121a748:  00007f512b7e8a4d  000000000000000a

goroutine 1 [running, locked to thread]:
runtime.systemstack_switch()
/usr/local/go/src/runtime/asm_amd64.s:363 fp=0xc4200a3ed0 sp=0xc4200a3ec8 pc=0x7f512c7281d0
runtime.startTheWorld()
/usr/local/go/src/runtime/proc.go:978 +0x2f fp=0xc4200a3ee8 sp=0xc4200a3ed0 pc=0x7f512c70221f
runtime.GOMAXPROCS(0x1, 0xc42013d9a0)
/usr/local/go/src/runtime/debug.go:30 +0xa0 fp=0xc4200a3f10 sp=0xc4200a3ee8 pc=0x7f512c6d9810
main.init.0()
/go/src/github.com/opencontainers/runc/init.go:14 +0x61 fp=0xc4200a3f30 sp=0xc4200a3f10 pc=0x7f512c992801
main.init()
<autogenerated>:1 +0x624 fp=0xc4200a3f88 sp=0xc4200a3f30 pc=0x7f512c9a1014
runtime.main()
/usr/local/go/src/runtime/proc.go:186 +0x1d2 fp=0xc4200a3fe0 sp=0xc4200a3f88 pc=0x7f512c6ff962
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:2361 +0x1 fp=0xc4200a3fe8 sp=0xc4200a3fe0 pc=0x7f512c72ad71

goroutine 6 [syscall]:
os/signal.signal_recv(0x0)
/usr/local/go/src/runtime/sigqueue.go:139 +0xa8
os/signal.loop()
/usr/local/go/src/os/signal/signal_unix.go:22 +0x24
created by os/signal.init.0
/usr/local/go/src/os/signal/signal_unix.go:28 +0x43

rax    0x0
rbx    0x7f512babc868
rcx    0xffffffffffffffff
rdx    0x6
rdi    0x271
rsi    0x271
rbp    0x7f512c9e9e5e
rsp    0x7ffe1121a658
r8     0xa
r9     0x7f512c524740
r10    0x8
r11    0x206
r12    0x7f512d3bb080
r13    0xf1
r14    0x11
r15    0x0
rip    0x7f512b7365f7
rflags 0x206
cs     0x33
fs     0x0
gs     0x0
exec failed: container_linux.go:348: starting container process caused "read init-p: connection reset by peer"

额，runc init因资源不足创建线程失败？？？这种输出显然不是runc的输出，而是go runtime非预期的输出内容。那么资源不足，究竟是什么资源类型资源不足呢？我们在结合 /var/log/message 日志分析：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
Jun 17 03:18:17 host-xx kernel: runc:[2:INIT] invoked oom-killer: gfp_mask=0xd0, order=0, oom_score_adj=997
Jun 17 03:18:17 host-xx kernel: CPU: 14 PID: 12788 Comm: runc:[2:INIT] Tainted: G        W  OE  ------------ T 3.10.0-514.16.1.el7.stable.v1.4.x86_64 #1
Jun 17 03:18:17 host-xx kernel: Hardware name: Inspur SA5212M4/YZMB-00370-107, BIOS 4.1.10 11/14/2016
Jun 17 03:18:17 host-xx kernel: ffff88103841dee0 00000000c4394691 ffff880263e4bcb8 ffffffff8168863d
Jun 17 03:18:17 host-xx kernel: ffff880263e4bd50 ffffffff81683585 ffff88203cc5e300 ffff880ee02b2380
Jun 17 03:18:17 host-xx kernel: 0000000000000001 0000000000000000 0000000000000000 0000000000000046
Jun 17 03:18:17 host-xx kernel: Call Trace:
Jun 17 03:18:17 host-xx kernel: [<ffffffff8168863d>] dump_stack+0x19/0x1b
Jun 17 03:18:17 host-xx kernel: [<ffffffff81683585>] dump_header+0x85/0x27f
Jun 17 03:18:17 host-xx kernel: [<ffffffff81185b06>] ? find_lock_task_mm+0x56/0xc0
Jun 17 03:18:17 host-xx kernel: [<ffffffff81185fbe>] oom_kill_process+0x24e/0x3c0
Jun 17 03:18:17 host-xx kernel: [<ffffffff81093c2e>] ? has_capability_noaudit+0x1e/0x30
Jun 17 03:18:17 host-xx kernel: [<ffffffff811f4d91>] mem_cgroup_oom_synchronize+0x551/0x580
Jun 17 03:18:17 host-xx kernel: [<ffffffff811f41b0>] ? mem_cgroup_charge_common+0xc0/0xc0
Jun 17 03:18:17 host-xx kernel: [<ffffffff81186844>] pagefault_out_of_memory+0x14/0x90
Jun 17 03:18:17 host-xx kernel: [<ffffffff816813fa>] mm_fault_error+0x68/0x12b
Jun 17 03:18:17 host-xx kernel: [<ffffffff81694405>] __do_page_fault+0x395/0x450
Jun 17 03:18:17 host-xx kernel: [<ffffffff816944f5>] do_page_fault+0x35/0x90
Jun 17 03:18:17 host-xx kernel: [<ffffffff81690708>] page_fault+0x28/0x30
Jun 17 03:18:17 host-xx kernel: memory: usage 3145728kB, limit 3145728kB, failcnt 14406932
Jun 17 03:18:17 host-xx kernel: memory+swap: usage 3145728kB, limit 9007199254740988kB, failcnt 0
Jun 17 03:18:17 host-xx kernel: kmem: usage 3143468kB, limit 9007199254740988kB, failcnt 0
Jun 17 03:18:17 host-xx kernel: Memory cgroup stats for /kubepods/burstable/pod6c4333b3-a663-11ea-b39f-6c92bf85beda: cache:0KB rss:0KB rss_huge:0KB mapped_file:0KB swap:0KB inactive_anon:0KB active_anon:0KB inactive_file:0KB active_file:0KB unevictable:0KB
Jun 17 03:18:17 host-xx kernel: Memory cgroup stats for /kubepods/burstable/pod6c4333b3-a663-11ea-b39f-6c92bf85beda/b761e05249245695278b3f409d2d6e5c6a5bff6995ff0cf44d03af4aa9764a30: cache:0KB rss:40KB rss_huge:0KB mapped_file:0KB swap:0KB inactive_anon:0KB active_anon:40KB inactive_file:0KB active_file:0KB unevictable:0KB
Jun 17 03:18:17 host-xx kernel: Memory cgroup stats for /kubepods/burstable/pod6c4333b3-a663-11ea-b39f-6c92bf85beda/1d1750ecc627cc5d60d80c071b2eb4d515ee8880c5b5136883164f08319869b0: cache:0KB rss:0KB rss_huge:0KB mapped_file:0KB swap:0KB inactive_anon:0KB active_anon:0KB inactive_file:0KB active_file:0KB unevictable:0KB
Jun 17 03:18:17 host-xx kernel: Memory cgroup stats for /kubepods/burstable/pod6c4333b3-a663-11ea-b39f-6c92bf85beda/bbd5e4b5f9c13666dd0ec7ff7afb2c4c2b0ede40a4adf1de43cc31c606f283f5: cache:0KB rss:2220KB rss_huge:0KB mapped_file:0KB swap:0KB inactive_anon:0KB active_anon:2140KB inactive_file:0KB active_file:0KB unevictable:0KB
Jun 17 03:18:17 host-xx kernel: Memory cgroup stats for /kubepods/burstable/pod6c4333b3-a663-11ea-b39f-6c92bf85beda/bbd5e4b5f9c13666dd0ec7ff7afb2c4c2b0ede40a4adf1de43cc31c606f283f5/super-agent: cache:0KB rss:0KB rss_huge:0KB mapped_file:0KB swap:0KB inactive_anon:0KB active_anon:0KB inactive_file:0KB active_file:0KB unevictable:0KB
Jun 17 03:18:17 host-xx kernel: [ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name
Jun 17 03:18:17 host-xx kernel: [30598]     0 30598      255        1       4        0          -998 pause
Jun 17 03:18:17 host-xx kernel: [11680]     0 11680   164833     1118      20        0           997 dockerinit
Jun 17 03:18:17 host-xx kernel: [12788]     0 12788   150184     1146      23        0           997 runc:[2:INIT]
Jun 17 03:18:17 host-xx kernel: oom-kill:,cpuset=bbd5e4b5f9c13666dd0ec7ff7afb2c4c2b0ede40a4adf1de43cc31c606f283f5,mems_allowed=0-1,oom_memcg=/kubepods/burstable/pod6c4333b3-a663-11ea-b39f-6c92bf85beda,task_memcg=/kubepods/burstable/pod6c4333b3-a663-11ea-b39f-6c92bf85beda/bbd5e4b5f9c13666dd0ec7ff7afb2c4c2b0ede40a4adf1de43cc31c606f283f5,task=runc:[2:INIT],pid=12800,uid=0
Jun 17 03:18:17 host-xx kernel: Memory cgroup out of memory: Kill process 12800 (runc:[2:INIT]) score 997 or sacrifice child
Jun 17 03:18:17 host-xx kernel: Killed process 12788 (runc:[2:INIT]) total-vm:600736kB, anon-rss:3296kB, file-rss:276kB, shmem-rss:1012kB

/var/log/message 记录了该容器在大约1个月前大量的OOM日志信息，该时间与异常的runc init进程启动时间基本匹配。

小结runc init阻塞的原因：在一个非常关键的时间节点，runc init由于内存资源不足，创建线程失败，触发go runtime的非预期输出，进而造成runc init阻塞在写pipe操作。

定位至此，问题的全貌已经基本描述清楚。但是我们还有一个疑问，既然runc init在往pipe中写数据，难道没有其它进程来读取pipe中的内容吗？

大家还记得上面lsof执行的结果吗？有心人一定发现了该pipe的读端是谁了，对，就是containerd-shim，对应的pipe的inode编号为1070361747。那么，为什么containerd-shim没有来读pipe里面的内容呢？我们结合代码来分析：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
func (e *execProcess) start(ctx context.Context) (err error) {
   ......
   if err := e.parent.runtime.Exec(ctx, e.parent.id, e.spec, opts); err != nil {   // 执行runc init
      close(e.waitBlock)
      return e.parent.runtimeError(err, "OCI runtime exec failed")
   }
   ......
   else if !e.stdio.IsNull() {
      fifoCtx, cancel := context.WithTimeout(ctx, 15*time.Second)
      defer cancel()

      if err := copyPipes(fifoCtx, e.io, e.stdio.Stdin, e.stdio.Stdout, e.stdio.Stderr, &e.wg, &copyWaitGroup); err != nil {   // 读pipe
         return errors.Wrap(err, "failed to start io pipe copy")
      }
   }
   ......
}


func (r *Runc) Exec(context context.Context, id string, spec specs.Process, opts *ExecOpts) error {
   ......
   cmd := r.command(context, append(args, id)...)
   if opts != nil && opts.IO != nil {
      opts.Set(cmd)
   }
   ......
   ec, err := Monitor.Start(cmd)
   ......
   status, err := Monitor.Wait(cmd, ec)
   ......
}

额，containerd-shim的设计是，等待runc init执行完成之后，再来读取pipe中的内容。但是此时的runc init由于非预期的写入数据量比较大，被阻塞在了写pipe操作处。。。完美的死锁。

终于，本次docker hang死问题的核心脉络都已理清。接下来我们再来聊聊解决方案。

解决方案

当了解了docker hang死的成因之后，我们可以针对性的提出如下解决办法。

最直观的办法

既然docker exec可能会引起docker hang死，那么我们禁用系统中所有的docker exec操作即可。最典型的是kubelet的probe，当前我们默认给所有Pod添加了ReadinessProbe，并且是以exec的形式进入容器内执行命令。我们调整kubelet的探测行为，修改为tcp或者http probe即可。

这里组件虽然改动不大，但是涉及业务容器的改造成本太大了，如何迁移存量集群是个大问题。

最根本的办法

既然当前containerd-shim读pipe需要等待runc exec执行完毕，如果我们将读pipe的操作提前至runc exec命令执行之前，理论上也可以避免死锁。

同样。这种方案的升级成本太高了，升级containerd-shim时需要重启存量的所有容器，这个方案基本不可能通过评审。

最简单的办法

既然runc init阻塞在写pipe，我们主动读取pipe内的内容，也能让runc init顺利退出。

在将本解决方案自动化的过程中，如何能够识别如docker hang死是由于写pipe导致的，是一个小小的挑战。但是相对于以上两种解决方案，我认为还是值得一试，毕竟其影响微乎其微。

后续

其实我们在读pipe的时候还引起了一个另外的问题，详见：一次读-pipe-引发的血案。

另外，docker hang死的原因远非这一种，本次排查的结果也并非适用于所有场景。希望各位看官能够根据自己的现场排查问题。

本次docker hang死的排查之旅已然告终。

本次排查由四人小分队 @飞哥 @鹤哥 @博哥 @我 一起排查长达数天的结论，欢迎大家一键三连，以表支持。

以上排查如果有误，也欢迎指正。

]]> <h3 id="背景"><a href="#背景" class="headerlink" title="背景"></a>背景</h3><p>最近，我们在升级kubelet时，发现部分宿主机上docker出现hang死的现象，发现过程详见：<a href="https://plpa netns leak 排查之旅 https://plpan.github.io/netns-leak-%E6%8E%92%E6%9F%A5%E4%B9%8B%E6%97%85/ 2020-05-15T02:19:24.000Z 2020-11-12T01:23:48.060Z 揭开面纱

周一，接到RD反馈线上容器网络访问存在异常，具体线上描述如下：

  • 上游服务driver-api所有容器访问下游服务duse-api某一容器TCP【telnet测试】连接不通，访问其余下游容器均正常
  • 上游服务容器测试下游容器IP连通性【ping测试】正常

从以上两点现象可以得出一个结论：

  • 容器的网络设备存在，IP地址连通，但是容器服务进程未启动，端口未启动
  • 但是，当我们和业务RD确认之后，发现业务容器状态正常，业务进程也正运行着。嗯，问题不简单。

此外，同事这边排查还有一个结论：

  • arp反向解析duse-api特殊容器IP时，不返回MAC地址信息
  • 当telnet失败后，立即执行arp，会返回MAC地址信息

当我们拿着arp解析的MAC地址与容器当前的MAC地址作比较时，发现MAC地址不一致。唔，基本上确定问题所在了，net ns泄漏了。执行如下命令验证：

1
sudo ip netns ls | while read ns; do sudo ip netns exec $ns ip addr; done | grep inet | grep -v 127 | awk '{print $2}' | sort | uniq -c

确实发现该容器对应的IP出现了两次，该容器IP对应了两个网络命名空间，也即该容器的网络命名空间出现了泄漏。

误入迷障

当确定了问题所在之后，我们立马调转排查方向，重新投入到net ns泄漏的排查事业当中。

既然net ns出现了泄漏，我们只需要排查被泄露的net ns的成因即可。在具体定位之前，首先补充一个背景：

  • ip netns 命令默认扫描 /var/run/netns 目录，从该目录下的文件读取net ns的信息
  • 默认情况下，kubelet调用docker创建容器时，docker会将net ns文件隐藏，如果不做特殊处理，我们执行 ip netns 命令将看不到任何数据
  • 当前弹性云为了方便排查问题，做了一个特殊处理，将容器的网络命名空间mount到 /var/run/netns 目录 【注意，这里有个大坑】

有了弹性云当前的特殊处理，我们就可以知道所有net ns的创建时间，也即 /var/run/netns 目录下对应文件的创建时间。

我们查看该泄漏ns文件的创建时间为2020-04-17 11:34:07，排查范围进一步缩小，只需从该时间点附近排查即可。

接下来，我们分析了该附近时间段，容器究竟遭遇了什么：

  • 2020-04-17 11:33:26 用户执行发布更新操作
  • 2020-04-17 11:34:24 平台显示容器已启动
  • 2020-04-17 11:34:28 平台显示容器启动脚本执行失败
  • 2020-04-17 11:36:22 用户重新部署该容器
  • 2020-04-17 11:36:31 平台显示容器已删除成功

既然是容器网络命名空间泄漏，则说明再删除容器的时候，没有执行ns的清理操作。【注：这里由于基础知识不足，导致问题排查绕了地球一圈】

我们梳理kubelet在该时间段对该容器的清理日志，核心相关日志展示如下：

1
2
3
4
5
I0417 11:36:30.974674   37736 kubelet_pods.go:1180] Killing unwanted pod "duse-api-xxxxx-0"
I0417 11:36:30.976803   37736 plugins.go:391] Calling network plugin cni to tear down pod "duse-api-xxxxx-0_default"
I0417 11:36:30.983499   37736 kubelet_pods.go:1780] Orphaned pod "4ae28778-805c-11ea-a54c-b4055d1e6372" found, removing pod cgroups
I0417 11:36:30.986360   37736 pod_container_manager_linux.go:167] Attempt to kill process with pid: 48892
I0417 11:36:30.986382   37736 pod_container_manager_linux.go:174] successfully killed all unwanted processes.

简单描述流程：

  • I0417 11:36:30.974674 根据删除容器执行，执行杀死Pod操作
  • I0417 11:36:30.976803 调用cni插件清理网络命名空间
  • I0417 11:36:30.983499 常驻协程检测到Pod已终止运行，开始执行清理操作，包括清理目录、cgroup
  • I0417 11:36:30.986360 清理cgroup时杀死容器中还未退出的进程
  • I0417 11:36:30.986382 显示所有容器进程都已被杀死

这里提示一点：正常情况下，容器退出时，容器内所有进程都已退出。而上面之所以出现清理cgroup时需要杀死容器内未退出进程，是由于常驻协程的检测机制导致的，常驻协程判定Pod已终止运行的条件是：

1
2
3
4
5
6
7
8
9
10
11
12
// podIsTerminated returns true if pod is in the terminated state ("Failed" or "Succeeded").
func (kl *Kubelet) podIsTerminated(pod *v1.Pod) bool {
   // Check the cached pod status which was set after the last sync.
   status, ok := kl.statusManager.GetPodStatus(pod.UID)
   if !ok {
      // If there is no cached status, use the status from the
      // apiserver. This is useful if kubelet has recently been
      // restarted.
      status = pod.Status
   }
   return status.Phase == v1.PodFailed || status.Phase == v1.PodSucceeded || (pod.DeletionTimestamp != nil && notRunning(status.ContainerStatuses))
}

这个容器命中了第三个或条件：容器已被标记删除，并且所有业务容器都不在运行中（业务容器启动失败，根本就没运行起来过），但是Pod的sandbox容器可能仍然处于运行状态。

仅依据上面的kubelet日志，难以发现问题所在。我们接着又分析了cni插件的日志，截取cni在删除该Pod容器网络时的日志如下：

1
2
3
4
5
[pid:98497] 2020/04/17 11:36:30.990707 main.go:89: ===== start cni process =====
[pid:98497] 2020/04/17 11:36:30.990761 main.go:90: os env: [CNI_COMMAND=DEL CNI_CONTAINERID=c2ef79f7596b6b558f0c01c0715bac46714eefd1e9966625a09414c7218e1013 CNI_NETNS=/proc/48892/ns/net CNI_ARGS=IgnoreUnknown=1;K8S_POD_NAMESPACE=default;K8S_POD_NAME=duse-api-xxxxx-0;K8S_POD_INFRA_CONTAINER_ID=c2ef79f7596b6b558f0c01c0715bac46714eefd1e9966625a09414c7218e1013 CNI_IFNAME=eth0 CNI_PATH=/home/user/cloud/cni-plugins/bin LANG=en_US.UTF-8 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin KUBE_LOGTOSTDERR=--logtostderr=false KUBE_LOG_LEVEL=--v=3 KUBE_ALLOW_PRIV=--allow-privileged=true KUBE_MASTER=--master=https://10.xxx.xxx.xxx:6443 KUBELET_ADDRESS=--address=0.0.0.0 KUBELET_HOSTNAME=--hostname_override=10.xxx.xxx.xxx KUBELET_POD_INFRA_CONTAINER= KUBELET_ARGS=--network-plugin=cni --cni-bin-dir=/home/user/cloud/cni-plugins/bin --cni-conf-dir=/home/user/cloud/cni-plugins/conf --kubeconfig=/etc/kubernetes/kubeconfig/kubelet.kubeconfig --cert-dir=/etc/kubernetes/ssl --log-dir=/var/log/kubernetes --stderrthreshold=3 --allowed-unsafe-sysctls=net.*,kernel.shm*,kernel.msg*,kernel.sem,fs.mqueue.* --pod-infra-container-image=registry.keji.com/k8s/pause:3.0 --eviction-hard=  --image-gc-high-threshold=75 --image-gc-low-threshold=65 --feature-gates=KubeletPluginsWatcher=false --restart-count-limit=5 --last-upgrade-time=2019-07-01]
[pid:98497] 2020/04/17 11:36:30.990771 main.go:91: stdin : {"cniVersion":"0.3.0","logDir":"/home/user/cloud/cni-plugins/acllogs","name":"cloudcni","type":"aclCni"}
[pid:98497] 2020/04/17 11:36:30.990790 main.go:181: failed to Statfs "/proc/48892/ns/net": no such file or directory
[pid:98497] 2020/04/17 11:36:30.990814 main.go:94: ===== end cni process =====

其中，main.go:181行的错误日志一下就抓住了我们的眼球，结合代码分析下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
func cmdDel(args *skel.CmdArgs) error {
    n, _, err := loadConf(args.StdinData)
    if err != nil {
        return err
    }
 
    netns, err := ns.GetNS(args.Netns)
    if err != nil {
        log.Println(err)     //// Line 181
        return fmt.Errorf("failed to open netns %q: %v", netns, err)
    }
    defer netns.Close()
    ...
}

可以看到，cni在调用该插件清理容器网络命名空间时，由于181行的错误，导致cni插件提前退出，并没有执行后面的清理操作。唔，终于找到你，小虫子。

这里，我们先简单总结下问题排查至此，得出的阶段性结论：

  • 由于容器启动失败，在删除Pod时，常驻协程定时清理非运行状态Pod的cgroup，杀死了Pod的sandbox容器
  • 当删除容器命令触发的cni清理操作执行时，发现sandbox的pause进程已退出，定位不到容器的网络命名空间，因此退出cni的清理操作
  • 最终容器网络命名空间泄漏

既然，明确了问题所在，我们就赶紧来定制修复方案吧，甚至于，我们很快就给出了一版修复：

  • 保证在Pod的所有容器退出之前，不会执行cgroup清理操作

这样就保证了删除容器命令触发的清理操作能够按照顺序执行：

  • 杀死所有业务容器
  • 执行cni插件清理工作
  • 杀死sandbox容器
  • 执行cgroup清理工作

我们风风火火的修复了内部版本之后，还验证了社区新版本代码中这块逻辑仍旧保持原样，就想着给社区送温暖（事实证明是妄想）。我们就去开源版本搭建的集群中，复现这个问题。然后噩梦就来了。。。

相同的Pod配置文件，我们在弹性云内部版本几乎能够百分百复现net ns泄漏的问题，而在开源社区版本中，从未出现过一次net ns泄漏。难不成，搞不好，莫不是说，不是我们定位的这个原因？

拨云现月

这个结论对我们来说，不是一个好消息。费力不小，不说南辕北辙，但是确实还未发现问题的根因。

为了进一步缩小问题排查范围，我们找内核组同学请教了一个基础知识：

  • 在删除net ns时，如果该ns内仍有网络设备，系统自动先删除网络设备，然后再删除ns

掌握了这个基础知识，我们再来排查。既然原生k8s集群不存在net ns泄漏问题，那问题一定由我们定制的某个模块引起。由于net ns泄漏发生在node上，当前弹性云在node节点上部署的模块包含：

  • kubelet
  • cni plugins
  • other tools

由于kubelet已经被排除嫌疑，那么罪魁祸首基本就是cni插件了。对比原生集群与弹性云线上集群的cni插件，发现一个极有可能会造成net ns泄漏的点：

  • 定制的cni插件为了排查问题的方便，将容器的网络命名空间文件绑定挂载到了 /var/run/netns 目录下 【参考上面的大坑】

我们赶紧着手验证元凶是否就是它。修改cni插件代码，删除绑定挂载操作，然后在测试环境验证。验证结果符合预期，net ns不在泄漏。至此，真相终于大白于天下了。

亡羊补牢

当初为net ns做一个绑定挂载，其目的就是为了方便我们排查问题，使得 ip netns 命令能够访问当前宿主上所有Pod的网络命名空间。

但其实一个简单的软链操作就能够实现这个目标。Pod退出时，如果这个软链文件未被清理，也不会引起net ns的泄漏，同时 ls -la /var/run/netns 命令可以清晰的看到哪些net ns仍有效，哪些已无效。

事后诸葛

为什么绑定挂载能够导致net ns泄漏呢？这是由linux 网络命名空间特性决定的：

  • 只要该命名空间中仍有一个进程存活，或者存在绑定挂载的情况（可能还存在其他情况），该ns就不会被回收
  • 而一旦所有进程都已退出，并且也无特殊状况，linux将自动回收该ns

最后，这个问题本身并不复杂，之所以问题存在如此之久，排查如此曲折，主要暴露了我们的基础知识有所欠缺。

好好学习，天天向上，方是王道！

]]> <h3 id="揭开面纱"><a href="#揭开面纱" class="headerlink" title="揭开面纱"></a>揭开面纱</h3><p>周一，接到RD反馈线上容器网络访问存在异常，具体线上描述如下：</p> <ul> <li>上游服务driver-api所有容 go sync.pool https://plpan.github.io/go-sync-pool/ 2019-04-14T07:26:29.000Z 2020-11-12T01:23:48.060Z 众所周知，Go实现了自动垃圾回收，这就意味着：当我们在申请内存时，不必关心如何以及何时释放内存，这些都是由Go语言内部实现的。注：我们关心的是堆内存，因为栈内存会随着函数调用的返回自动释放。

自动垃圾回收极大地降低了我们写程序时的心智负担，但是，这是否就意味着我们能够随心所欲的申请大量内存呢？理论上当然可以，但实际写代码时强烈不推荐这种做法，因为大量的临时堆内存会给GC线程的造成负担。

此时，小明同学就问：有没有办法能缓解海量临时对象的分配问题呢？

当然是有的，内存复用就是一个典型方案，而内存池就是该方案的一个实例，Go语言官方提供一种内存池的实现方案——sync.Pool。

首先我们来看sync.Pool的使用方式：

1
2
3
4
5
6
7
8
9
10
11
func main() {
pool := sync.Pool{
New: func() interface{} {
return "Hello"
},
}
old := pool.Get()
pool.Put(old.(string) + " World")
new := pool.Get()
fmt.Println(new) // Hello World
}

借助上面这段简单代码，我们验证了sync.Pool的内存复用。那么sync.Pool又是如何实现内存复用的呢？让我们来深入Go源码看一看。

sync.Pool的源码位于$GOROOT/src/sync/pool.go，其结构体定义如下：

1
2
3
4
5
6
7
8
9
10
11
type Pool struct {
noCopy noCopy

local     unsafe.Pointer // local fixed-size per-P pool, actual type is [P]poolLocal
localSize uintptr        // size of the local array

// New optionally specifies a function to generate
// a value when Get would otherwise return nil.
// It may not be changed concurrently with calls to Get.
New func() interface{}
}
  • noCopy字段：go vet静态扫描代码时提示对象拷贝，不影响编译和运行
  • local：对象池数组，实际上是[P]poolLocal，而poolLocal则为每个P的本地内存池，P的本地内存池有两个对象：
    • private interface{}：一个私有坑位
    • shared []interface{}：一组公有坑位
  • localSize：local数组的大小，一般等于P的数量（在调用GOMAXPROCS时会出现短暂不一致）
  • New：当对象池为空时，就调用New方法创建一个临时对象

这里需要注意的是：sync.Pool内存池并非P结构体的一个字段，而是sync.Pool自己维护了一个数组，取P的id作为数组下标来获取内存池对象。

了解了sync.Pool的数据结构之后，我们再来看其操作原理，sync.Pool的操作有两个：Get和Put，因为Put简单，我们先来看Put:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// Put adds x to the pool.
func (p *Pool) Put(x interface{}) {
if x == nil {
return
}
l := p.pin()
if l.private == nil {
l.private = x
x = nil
}
runtime_procUnpin()
if x != nil {
l.Lock()
l.shared = append(l.shared, x)
l.Unlock()
}
}

p.pin用于获取P的对象池，Put优先将内存对象存储到内存池私有坑位，如果私有坑位已经被占，则将其存储到公有坑位

注意：如果内存对象被存储至公有坑位，则需要加锁。

接着我们再来看Get操作：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
func (p *Pool) Get() interface{} {
l := p.pin()
x := l.private
l.private = nil
runtime_procUnpin()
if x == nil {
l.Lock()
last := len(l.shared) - 1
if last >= 0 {
x = l.shared[last]
l.shared = l.shared[:last]
}
l.Unlock()
if x == nil {
x = p.getSlow()
}
}
if x == nil && p.New != nil {
x = p.New()
}
return x
}
  • 如果本P的私有坑位有对象，则直接返回
  • 如果本P私有坑位没有对象，则从本P的公有坑位中获取一个对象返回
  • 如果本P的公有坑位也没有对象，则依次遍历其他P的公有坑位，取走一个对象返回
  • 如果所有P的公有坑位都没有对象，并且定义New函数，则调用New函数创建一个对象
  • 否则返回nil

注意：每当遍历一个P的公有坑位时，都需要加锁，因此最多加锁N次，最少0次，其中N为P的数目

了解了以上原理，我们就能够开开心心的使用sync.Pool了。此时，小明同学又问了，我明明已经使用了sync.Pool了，为什么GC压力还非常大？

这就涉及到sync.Pool本身的内存回收了：sync.Pool缓存临时对象并非是永久保存，它保活的时间作用域其实也非常短：我们发现sync/pool.go中还定义了poolCleanup函数用于内存池的清理，我们再看其调用时机：

1
2
3
func init() {
runtime_registerPoolCleanup(poolCleanup)
}

runtime_xxx函数都可以对应到$GOROOT/src/runtime包下的xxx函数，我们找到对应的函数定义：

1
2
3
4
5
6
7
8
9
10
11
//go:linkname sync_runtime_registerPoolCleanup sync.runtime_registerPoolCleanup
func sync_runtime_registerPoolCleanup(f func()) {
poolcleanup = f
}
func clearpools() {
   // clear sync.Pools
   if poolcleanup != nil {
      poolcleanup()
   }
  ......
}

因此，我们只需要定位clearpools的调用时机即可：

1
2
3
4
5
6
7
8
9
10
11
// gcStart transitions the GC from _GCoff to _GCmark (if
// !mode.stwMark) or _GCmarktermination (if mode.stwMark) by
// performing sweep termination and GC initialization.
//
// This may return without performing this transition in some cases,
// such as when called on a system stack or with locks held.
func gcStart(mode gcMode, trigger gcTrigger) {
    ......
    clearpools()
   ......
}

我们发现每当GC开始时，都会清理sync.Pool内存对象池，这就意味着sync.Pool缓存的临时对象都活不过一个GC周期。如果我们的程序在疯狂分配临时对象，这就会加速GC的执行频率，而GC开始时又会释放sync.Pool内存池，这简直就是一个死循环。

所以小明啊，最佳的实践是什么呢？当然是优化代码逻辑咯，尽量减少内存分配次数。具体的代码优化可以借助pprof实现。

]]> <p>众所周知，Go实现了自动垃圾回收，这就意味着：当我们在申请内存时，不必关心如何以及何时释放内存，这些都是由Go语言内部实现的。注：我们关心的是堆内存，因为栈内存会随着函数调用的返回自动释放。</p> <p>自动垃圾回收极大地降低了我们写程序时的心智负担，但是，这是否就意味着