### 背景

- 目前[機器學習平臺](http://ml.intra.xiaojukeji.com/axe#/)後端採用k8s架構進行GPU和CPU資源的排程和容器編排。k8s的核心能力是容器編排，容器服務的穩定執行直接關係到整體平臺的穩定性。
- 春節值班期間，[機器學習平臺](http://ml.intra.xiaojukeji.com/axe#/)實驗環境-[隔離環境](http://ml.intra.xiaojukeji.com/axe#/k8sinstancemgr/) vgpu資源出現比較多的使用者容器異常退出問題。此問題導致Pod中的使用者容器發生重建，一些使用者在容器執行時環境的資料會丟失，由於平臺具有暫存使用者異常容器現場的能力，值班同學可以透過恢復使用者異常容器現場來恢復使用者的資料。
- 使用者容器異常退出，雖然可以透過運維工具來恢復使用者的資料進行問題降級處理，但是頻繁無故的使用者容器異常退出，環境重啟問題，極大的影響了使用者使用 [機器學習平臺](http://ml.intra.xiaojukeji.com/axe#/)實驗環境-[隔離環境](http://ml.intra.xiaojukeji.com/axe#/k8sinstancemgr/) vgpu資源的體驗和值班同學處理類似問題的時效性。

### 問題記錄-之看現象

- 【看現場】

- 版本資訊

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

- 表格中記錄了2020-01-14到2020-02-04期間一部分使用者容器的kvm環境、docker、containerd、容器錯誤碼的資訊。
    ![avatar](http://img-hxy021.didistatic.com/static/way/do1_FTyiJpyGBkle6Rf9QCsv)

- 開始部分同學是懷疑cuda版本相容性問題，導致使用者容器異常退出，想透過升級cuda版本檢視此問題是否收斂，但是cuda-10.0上也有類似現場，此懷疑不攻自破。

- 是否是由於使用者容器OOM，導致異常退出，透過dmesg也沒有查到任何異常日誌。OOM論也被否定了。

- 相同版本的kernel、docker版本，物理GPU節點為出現使用者容器重啟，只有在kvm vgpu上出現，也讓人摸不著頭腦。

- 檢視docker的日誌，當使用者容器異常退出時，就只有正常容器退出 clean up的資訊，無其他異常日誌。PS:其實此處才是澄清137問題的關鍵。

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

- 【找同盟】

- 為何出現exitCode=137？
    - [Container exits with non-zero exit code 137](https://success.docker.com/article/what-causes-a-container-to-exit-with-code-137) 介紹了kill -9 (128 + 9) 觸發的exitCode=137原因是容器stop時沒有處理SIGTERM訊號，進行容器優雅的退出。但是其本質還是使用者容器異常退出了，不是正常stop操作。容器沒有OOM，cpu、memory的監控利用率都沒有超標，dmesg和messages日誌中都沒有異常資訊，一度開始懷疑人生。
  - 類似社群137問題
    - [Random task failures with "non-zero exit (137)" since 18.09.1](https://github.com/moby/moby/issues/38768) 這個issue中作者從docker 18.09.0 升級到 18.09.1 (或者18.09.2)版本都會遇到137問題，也懷疑是OOM問題，但是實際應用沒有出現OOM相關的日誌現場。其中[lwimmer](https://github.com/lwimmer)把docker升級到18.09.3後未出現137問題，[Ghostbaby](https://github.com/Ghostbaby)使用者把contianerd升級到1.2.5後也未出現137問題。Maintainer [thaJeztah](https://github.com/thaJeztah)提了containerd 和runc 在18.09.2和18.09.3版本中差異。[containerd/containerd@9754871...e6b3f56](https://github.com/containerd/containerd/compare/9754871865f7fe2f4e74d43e2fc7ccd237edcbce...e6b3f5632f50dbc4e9cb6288d911bf4f5e95b18e) [opencontainers/runc@09c8266...6635b4f](https://github.com/opencontainers/runc/compare/09c8266bf2fcf9519a651b04ae54c967b9ab86ec...6635b4f0c6af3810594d2770f662f34ddc15b40d) 結果就是升級沒有出現137的問題了。

### 問題排查-之得細品

- 【升級否】

- 組內討論了一波是否直接升級到docker 18.09.2之後的版本來解決137容器重啟的問題。但是社群使用者的環境畢竟和[機器學習平臺](http://ml.intra.xiaojukeji.com/axe#/)還是有差異，存在一些不確定性，在沒有詳細版本測試情況下，全量升級docker的版本，勢必對使用者環境穩定性有影響。而且物理GPU節點上部署同樣的docker版本，並未出現此問題。保守起見，灰度了一部分節點，升級docker版本，確認是否會出現137問題。
  - 事實升級了docker版本還是會出現137問題。同時並行著再灰度一些containerd的版本。PS:升級了contianerd版本的節點未出現容器137問題。
    ![avatar](http://img-hxy021.didistatic.com/static/way/do1_nPCtexi3bNwpHXBRJZ7s)

- 【抓現場】

- 從 Random task failures with "non-zero exit (137)" since 18.09.1  issue中發現了auditctl這個訊號抓取的工具，可以澄清到底是哪個程式給容器傳送了kill -9 訊號。

```
    # 配置捕獲SIGKILL
    auditctl -a always,exit -F arch=b64 -S kill,tkill,tgkill -F a1=0x9 -F key=trace_kill_9
    ```

- 發現抓取到的現場確實是/usr/bin/nvidia-container-runtime把使用者容器systemd程式kill了。因為GPU節點docker runtime都是使用nvidia-container-runtime。但是還是無法確認為什麼被kill -9了。

```
    time->Wed Feb 19 16:00:07 2020
    type=PROCTITLE msg=audit(1582099207.232:3369619): proctitle=6E76696469612D636F6E7461696E65722D72756E74696D65002D2D726F6F74002F7661722F72756E2F646F636B65722F72756E74696D652D6E76696469612F6D6F6279002D2D6C6F672D666F726D6174006A736F6E0064656C657465002D2D666F72636500313862326665373233363936333538666230363331376334323761
    type=OBJ_PID msg=audit(1582099207.232:3369619): opid=18848 oauid=-1 ouid=0 oses=-1 ocomm="systemd"
    type=SYSCALL msg=audit(1582099207.232:3369619): arch=c000003e syscall=62 success=yes exit=0 a0=49a0 a1=9 a2=0 a3=0 items=0 ppid=14134 pid=23413 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="nvidia-containe" exe="/usr/bin/nvidia-container-runtime" key="trace_kill_9"
    ```

- 一方面為了抓取更多的docker日誌，灰度一部分節點，開啟docker debug日誌開關。

- 一方面為了確認是否有程式coredump的問題，把一些節點的coredump配置也開啟，抓取問題現場。

- 同時review docker的程式碼，發現容器建立執行的一個簡單基本流程是dockerd -> containerd -> containerd-shim -> nvidia-container-runtime -> entrypoint。containerd-shim託管了容器的執行時狀態，當contianerd-shim 異常退出時，會呼叫[exitHandler](https://github.com/containerd/containerd/blob/v1.2.2/runtime/v1/shim/client/client.go#L79) 中進行[cleanupAfterDeadShim](https://github.com/containerd/containerd/blob/v1.2.2/runtime/v1/linux/runtime.go#L354)操作觸發kill -9。

- 為了確認containerd-shim程式是異常退出，增加kill -15訊號捕獲。

```
    # 配置捕獲SIGTERM
    auditctl -a always,exit -F arch=b64 -S kill,tkill,tgkill -F a1=0xF -F key=trace_kill_15
    ```

- 抓取到trace訊號 -9 和-15，證明containerd-shim程式確實異常退出，具體還是需要確認是什麼原因導致。

```
    time->Thu Feb 20 22:47:19 2020
    type=PROCTITLE msg=audit(1582210039.403:2649702): proctitle=6E76696469612D636F6E7461696E65722D72756E74696D65002D2D726F6F74002F7661722F72756E2F646F636B65722F72756E74696D652D6E76696469612F6D6F6279002D2D6C6F672D666F726D6174006A736F6E0064656C657465002D2D666F72636500666631613337626130303962396262396562303466633861643763
    type=OBJ_PID msg=audit(1582210039.403:2649702): opid=2858 oauid=-1 ouid=0 oses=-1 ocomm="systemd"
    type=SYSCALL msg=audit(1582210039.403:2649702): arch=c000003e syscall=62 success=yes exit=0 a0=b2a a1=9 a2=0 a3=0 items=0 ppid=24502 pid=6558 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="nvidia-containe" exe="/usr/bin/nvidia-container-runtime" key="trace_kill_9"
    
    time->Thu Feb 20 22:47:26 2020
    type=PROCTITLE msg=audit(1582210046.181:2649752): proctitle="/usr/lib/systemd/systemd-udevd"
    type=OBJ_PID msg=audit(1582210046.181:2649752): opid=6686 oauid=-1 ouid=0 oses=-1 ocomm="systemd-udevd"
    type=SYSCALL msg=audit(1582210046.181:2649752): arch=c000003e syscall=62 success=yes exit=0 a0=1a1e a1=f a2=8 a3=bb8 items=0 ppid=1 pid=16425 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="systemd-udevd" exe="/usr/lib/systemd/systemd-udevd" key="trace_kill_15"
    
    time->Thu Feb 20 22:47:42 2020
    type=PROCTITLE msg=audit(1582210062.620:2649753): proctitle="/usr/sbin/init"
    type=OBJ_PID msg=audit(1582210062.620:2649753): opid=7283 oauid=-1 ouid=0 oses=-1 ocomm="sshd"
    type=SYSCALL msg=audit(1582210062.620:2649753): arch=c000003e syscall=62 success=yes exit=0 a0=bf a1=f a2=0 a3=ffffffc0 items=0 ppid=6661 pid=6683 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="systemd" exe="/usr/lib/systemd/systemd" key="trace_kill_15"
    ```

- 【起死回生】

- containerd-shim 異常退出現場，看到在執行docker exec命令時，發生了panic: runtime error: invalid memory address or nil pointer dereference，顯示程式碼訪問空指標，contaienrd-shim程式異常退出，觸發cleanupAfterDeadShim，導致使用者容器異常退出。

```
    Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.374422177+08:00" level=debug msg="Calling POST /v1.39/containers/de42a6372c1d996efc475d294afc42f430beaad3ff443a86f124754a70a1b517/exec"
    Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.374608247+08:00" level=debug msg="form data: {\"AttachStderr\":true,\"AttachStdin\":true,\"AttachStdout\":true,\"Cmd\":[\"ip\",\"a\"],\"Detach\":false,\"DetachKeys\":\"\",\"Env\":null,\"Privileged\":false,\"Tty\":false,\"User\":\"\",\"WorkingDir\":\"\"}"
    Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.376137747+08:00" level=debug msg="Calling POST /v1.39/exec/0f80962a9b908b89ea5af2f20f361e9dc10cfee6986cdc29d59e040e863427ef/start"
    Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.376236749+08:00" level=debug msg="form data: {\"Detach\":false,\"Tty\":false}"
    Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.376409211+08:00" level=debug msg="starting exec command 0f80962a9b908b89ea5af2f20f361e9dc10cfee6986cdc29d59e040e863427ef in container de42a6372c1d996efc475d294afc42f430beaad3ff443a86f124754a70a1b517"
    Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.377794937+08:00" level=debug msg="attach: stdin: begin"
    Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.377888031+08:00" level=debug msg="attach: stdout: begin"
    Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.377945302+08:00" level=debug msg="attach: stderr: begin"
    Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.378383214+08:00" level=debug msg="Closing buffered stdin pipe"
    Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.378459556+08:00" level=debug msg="attach: stdin: end"
    Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.521401882+08:00" level=debug msg="event published" ns=moby topic="/tasks/exec-started" type=containerd.events.TaskExecStarted
    Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.522615348+08:00" level=debug msg=event module=libcontainerd namespace=moby topic=/tasks/exec-started
    Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.742957161+08:00" level=debug msg="event published" ns=moby topic="/tasks/exit" type=containerd.events.TaskExit
    Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.744535201+08:00" level=debug msg=event module=libcontainerd namespace=moby topic=/tasks/exit
    Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.745009232+08:00" level=debug msg="attach: stderr: end"
    Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.745069071+08:00" level=debug msg="attach: stdout: end"
    Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.745086517+08:00" level=debug msg="attach done"
    Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.749102092+08:00" level=debug msg="Calling GET /v1.39/exec/0f80962a9b908b89ea5af2f20f361e9dc10cfee6986cdc29d59e040e863427ef/json"
    Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.793241263+08:00" level=debug msg="Calling GET /v1.38/containers/json?all=1&filters=%7B%22label%22%3A%7B%22io.kubernetes.docker.type%3Dpodsandbox%22%3Atrue%7D%7D&limit=0"
    Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.803366670+08:00" level=debug msg="Calling GET /v1.38/containers/json?all=1&filters=%7B%22label%22%3A%7B%22io.kubernetes.docker.type%3Dcontainer%22%3Atrue%7D%7D&limit=0"
    Feb 25 22:07:13 gpu-ser-xyz systemd: Removed slice User Slice of root.
    Feb 25 22:07:13 gpu-ser-xyz dockerd: panic: runtime error: invalid memory address or nil pointer dereference
    Feb 25 22:07:13 gpu-ser-xyz dockerd: [signal SIGSEGV: segmentation violation code=0x1 addr=0x78 pc=0x5ff488]
    Feb 25 22:07:13 gpu-ser-xyz dockerd: goroutine 5 [running]:
    Feb 25 22:07:13 gpu-ser-xyz dockerd: github.com/containerd/containerd/runtime/v1/linux/proc.(*execProcess).pidv(...)
    Feb 25 22:07:13 gpu-ser-xyz dockerd: /go/src/github.com/containerd/containerd/runtime/v1/linux/proc/exec.go:76
    Feb 25 22:07:13 gpu-ser-xyz dockerd: github.com/containerd/containerd/runtime/v1/linux/proc.(*execStoppedState).Pid(0x8d8cf0, 0xffffffffffffffff)
    Feb 25 22:07:13 gpu-ser-xyz dockerd: /go/src/github.com/containerd/containerd/runtime/v1/linux/proc/exec_state.go:175 +0x8
    Feb 25 22:07:13 gpu-ser-xyz dockerd: github.com/containerd/containerd/runtime/v1/linux/proc.(*execProcess).Pid(0xc4201e0000, 0x55ec)
    Feb 25 22:07:13 gpu-ser-xyz dockerd: /go/src/github.com/containerd/containerd/runtime/v1/linux/proc/exec.go:72 +0x34
    Feb 25 22:07:13 gpu-ser-xyz dockerd: github.com/containerd/containerd/runtime/v1/shim.(*Service).checkProcesses(0xc42000e0c0, 0xbf8d68647291f929, 0xbec8633ef91e, 0x8bc720, 0x4308, 0x0)
    Feb 25 22:07:13 gpu-ser-xyz dockerd: /go/src/github.com/containerd/containerd/runtime/v1/shim/service.go:514 +0xde
    Feb 25 22:07:13 gpu-ser-xyz dockerd: github.com/containerd/containerd/runtime/v1/shim.(*Service).processExits(0xc42000e0c0)
    Feb 25 22:07:13 gpu-ser-xyz dockerd: /go/src/github.com/containerd/containerd/runtime/v1/shim/service.go:492 +0xd0
    Feb 25 22:07:13 gpu-ser-xyz dockerd: created by github.com/containerd/containerd/runtime/v1/shim.NewService
    Feb 25 22:07:13 gpu-ser-xyz dockerd: /go/src/github.com/containerd/containerd/runtime/v1/shim/service.go:91 +0x3e9
    Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.874199295+08:00" level=info msg="shim reaped" id=de42a6372c1d996efc475d294afc42f430beaad3ff443a86f124754a70a1b517
    Feb 25 22:07:13 gpu-ser-xyz dockerd: time="2020-02-25T22:07:13.874266470+08:00" level=warning msg="cleaning up after killed shim" id=de42a6372c1d996efc475d294afc42f430beaad3ff443a86f124754a70a1b517 namespace=moby
    ```

### 問題分析-之論本質

- 【從程式碼中來到程式碼中去】

- 為什麼在開啟docker debug日誌節點能抓到現場，線上其他vgpu上為什麼沒有出現SIGSEGV這個panic的問題。

- containerd-shim出現panic時，因為containerd啟動containerd-shim程式時，stdout/stderr都沒有重定向到os的stdout/stderr上，所以在messages中沒有找到任何panic資訊。只有debug日誌開啟時，

containerd-shim設定了重定向

，才會有panic的日誌輸出。

```
      if debug {
      cmd.Stdout = os.Stdout
      cmd.Stderr = os.Stderr
      }
      ```

- 為什麼containerd-shim出現panic時，dmesg和/var/log/message中都沒有相關segment fault的日誌。

- c/c++程式遇到segment fault都會在messages有類似的日誌。
      segfault at 0 ip 00000000004005c7 sp 00007ffce36494f0 error 6 in main。因為containerd-shim是go程式，go的runtime catch到了SIGSEGV。當containerd-shim SIGSEGV 觸發panic時，go runtime會呼叫runtime.crash，dieFromSignal(_SIGABRT) 實際 raise的是SIGABRT訊號，所以dmesg和/var/log/message同時由於docker啟動的時候，沒有配置GOTRACEBACK=crash環境變數，預設是 GOTRACEBACK=single，ulimited -c 是0，也不會生成coredump檔案。

- 為什麼容器中會有頻繁的exec操作

- 平臺kubelet使用內網sdn介面獲取ip，沒有使用cni外掛的方式，當每秒執行PLEG，檢查Pod狀態，透過docker exec -i ip a 獲取Pod IP。
    - 頻繁的exec操作，增加了containerd-shim觸發exec bug機率。

- 問題本質是[exec.go程式碼](https://github.com/containerd/containerd/blob/v1.2.2/runtime/v1/linux/proc/exec.go#L76) 訪問了空指標。

```
    Feb 25 22:07:13 gpu-ser-xyz dockerd: panic: runtime error: invalid memory address or nil pointer dereference
    Feb 25 22:07:13 gpu-ser-xyz dockerd: [signal SIGSEGV: segmentation violation code=0x1 addr=0x78 pc=0x5ff488]
    Feb 25 22:07:13 gpu-ser-xyz dockerd: goroutine 5 [running]:
    Feb 25 22:07:13 gpu-ser-xyz dockerd: github.com/containerd/containerd/runtime/v1/linux/proc.(*execProcess).pidv(...)
    Feb 25 22:07:13 gpu-ser-xyz dockerd: /go/src/github.com/containerd/containerd/runtime/v1/linux/proc/exec.go:76
    ```

- 【從社群來到社群去】

- containerd社群相關的issue，在1.2.2版本上抓到了和我們類似的現場，pid原來是int型別修改成safePid，加鎖執行緒安全了。[[signal SIGSEGV: segmentation violation code=0x1 addr=0x78 pc=0x5ff488\]](https://github.com/containerd/containerd/issues/2969)
  - [Fix exec race condition](https://github.com/containerd/containerd/pull/2970) pr中已經解決2969此問題，1.2.3版本上合入了這個commit：[5730c5003980f2b8c6d18188b56188230353ba81](https://github.com/containerd/containerd/commit/5730c5003980f2b8c6d18188b56188230353ba81)
  - 同時也能解釋通升級到containerd 1.2.3之後的版本，容器未出現137問題

### 解決方案

- 【降運維】
  - 在137問題根本原因未澄清前，為了減少使用者容器異常退出帶來的運維工作量。修改了kubelet 容器異常重啟的策略，透過使用者容器的標籤資訊，將平臺實驗環境vgpu的容器發生異常退出時，不在是容器重建，修改成容器重啟。
  - 修改平臺Daemonset hostNetwork=true的方式，不在使用sdn網路，減少exec操作。
- 【開處方】
  - 問題本質原因是containerd execde bug，後續增量環境containerd升級至1.2.4版本。
  - 去除kubelet sdn網路exec獲取容器IP的方式。
  - 使用平臺自研的sdn cni網路外掛，目前正在研發中。

### 參考文件

- [Container exits with non-zero exit code 137](https://success.docker.com/article/what-causes-a-container-to-exit-with-code-137)
- [STOPSIGNAL--與訊號轉發](https://github.com/zhangguanzhang/docker-need-to-know/blob/master/2.docker-image/dockerfile/stopsignal.md)
- [Random task failures with "non-zero exit (137)" since 18.09.1](https://github.com/moby/moby/issues/38768)
- [[signal SIGSEGV: segmentation violation code=0x1 addr=0x78 pc=0x5ff488]](https://github.com/containerd/containerd/issues/2969)
### 作者：童超【 滴滴出行資深軟體開發工程師】

- [	現在註冊滴滴雲，得8888元立減紅包](https://app.didiyun.com/#/auth/signup?channel=14816)
- [7月特惠，1C2G1M雲伺服器 9.9元/月限時搶](https://www.didiyun.com/?channel=14816)
- [滴滴雲使者專屬特惠，包年雲伺服器低至68元/年](https://www.didiyun.com/envoy/e-index.html?channel=14816)
- [輸入大師碼【7886】，GPU全線產品9折優惠](https://www.didiyun.com/production/gpu.html?channel=14816)

【docker-ce】k8s叢集docker容器異常重啟問題分析

相關文章