通过Core Dump文件定位容器问题

应用场景

Core Dump是Linux操作系统在程序突然异常终止或者崩溃时将当时的内存状态记录下来，保存在一个文件中。通过Core Dump文件可以分析查找问题原因。

容器一般将业务应用程序作为容器主程序，程序崩溃后容器直接退出，且被回收销毁，因此容器Core Dump需要将Core文件持久化存储在主机或云存储上。本文将介绍容器Core Dump的方法。

约束与限制

容器Core Dump持久化存储至OBS（并行文件系统或对象桶）时，由于CCE挂载OBS时默认挂载参数中带有umask=0的设置，这导致Core Dump文件虽然生成但由于umask原因Core Dump信息无法写入到Core文件中。您可通过设置OBS的挂载参数umask=0077，将Core Dump文件正常存储到OBS中。设置umask的方法请参见设置挂载参数。

开启节点Core Dump

登录节点，执行如下命令开启Core Dump，设置core文件的存放路径及格式。

echo "/tmp/cores/core.%h.%e.%p.%t" > /proc/sys/kernel/core_pattern

其中%h、%e、%p、%t均表示占位符，说明如下：

• %h：主机名（在 Pod 内即为 Pod 的名称），建议配置。
• %e：程序文件名，建议配置。
• %p：进程 ID，可选。
• %t：coredump 的时间，可选。

即通过以上命令开启Core Dump后，生成的core文件的命名格式为“core.{主机名}.{程序文件名}.{进程ID}.{时间}”。

您也可以在创建节点时候通过设置安装前或安装后脚本自动执行该命令。

EulerOS 2.3 Systemd有一个社区bug影响容器Core Dump，如需使用Core Dump需执行如下操作。

1. 在节点的/usr/lib/systemd/system/docker.service文件中，将LimitCORE的值修改为infinity。
2. 重启Docker。
3. 业务容器重新部署。

容器Core Dump持久化

apiVersion: v1
kind: Pod
metadata:
  name: coredump
spec:
  volumes:
  - name: coredump-path
    hostPath:
      path: /home/coredump
  containers:
  - name: ubuntu
    image: ubuntu:12.04
    command: ["/bin/sleep","3600"]
    volumeMounts:
    - mountPath: /tmp/cores
      name: coredump-path

使用kubectl创建Pod。

kubectl create -f pod.yaml

配置验证

Pod创建后，进入到容器内，触发当前shell终端的段错误。

$ kubectl get pod
NAME                          READY   STATUS    RESTARTS   AGE
coredump                      1/1     Running   0          56s
$ kubectl exec -it coredump -- /bin/bash
root@coredump:/# kill -s SIGSEGV $$
command terminated with exit code 139

登录节点，在/home/coredump路径下查看core文件是否生成，如下示例表示已经生成了core文件。

# ls /home/coredump
core.coredump.bash.18.1650438992