Kubernetes容器生成core文件
1、概述
-
core dump(核心转储)
在绝大多数GNU/Linux系统中,当应用程序发生没有捕获的异常信号ARORT/SEGV时,系统会终止当前进程,并生成core dump文件,它一般在程序执行的主目录下,通常命名为core
或者core.PID
。通常情况下core dump包含了程序运行时的内存,寄存器状态,堆栈指针,内存管理信息等。在实际的开发场景中,这些信息能够对开发人员调试定位问题提供非常大的帮助,所以在特定场合生成并留存core dump是一件必要而有意义的事情。 -
ulimit
ulimit是GNU/Linux的一个命令行工具,用于显示或设置用户可以使用的资源限制。在本例中,我们主要关注其对core文件大小限制的设置或查看。
使用ulimit -c
查看对core文件大小的限制,例如:
# ulimit -c unlimited
unlimited
表示没有限制,这意味着当应用程序异常时,系统能够输出任意大小的core dump文件,如果结果是非零数字,则表示系统只能输出限制大小的core dump文件,如果结果为0,则系统不会输出core dump文件。
设置对core文件大小的限制,如:
# ulimit -c unlimited 不限制 # ulimit -c 1024 限制大小为1024 # ulimit -c 0 限制大小为0,即不输出core dump文件
centos7操作系统默认不输出core dump文件。
# ulimit -c 0
-
docker ulimit
在docker容器中,ulimit
的限制由dockerd
进程控制,用户可以通过参数--default-ulimit
进行配置,默认时,不会限制core文件生成大小,如果用户在dockerd
进程启动时,对core文件生成大小进行了限制,用户依然可以在docker run
的时候通过--ulimit
参数进行修改,docker run
中的--ulimit
参数会优先生效。容器 core dump文件生成不依赖宿主机core文件大小限制,即使宿主机设置了不输出core dump文件,如果dockerd进程不限制容器core文件生成的话,容器照样可以输出core dump文件。 -
kubernetes ulimit
在kubernetes中,容器core文件生成大小的限制依赖dockerd
进程--default-ulimit
参数对core文件生成大小的配置。(本文中以docker作为k8s容器运行时)
注意:即使在 CentOS 7 操作系统上配置了
ulimit -c 0
来限制生成 core dump 文件,容器进程仍然可能会产生 core 文件,可能有以下几种原因:
Docker容器本身的配置: Docker容器的运行时环境可以影响容器内进程的资源限制。即使宿主机上已经限制了 core dump 文件的生成,容器内部的进程也可能具有自己的资源限制,可能会导致 core 文件的生成。要解决这个问题,需要确保 Docker 容器本身的配置也禁止了 core dump 文件的生成。
进程配置: 容器内的应用程序可能会在运行时修改其资源限制,覆盖了默认的 ulimit 设置。检查容器内部的应用程序是否通过编程方式设置了 core dump 行为,如果是,需要修改应用程序的配置以遵守限制。
Linux内核问题: 在某些情况下,特定的 Linux 内核版本可能存在 bug,导致忽略了资源限制,从而生成 core 文件。确保你的操作系统内核是最新版本,并考虑升级或修复内核问题。
其他因素: 如果容器内的应用程序存在问题,例如 bug 或者异常情况,它们可能会导致 core 文件的生成,而无视资源限制。在这种情况下,需要排查应用程序的问题并解决之。
总之,要解决容器内产生 core 文件的问题,需要综合考虑容器运行时、容器内部进程、宿主机的设置以及应用程序的配置。确保所有层面都遵循了禁止生成 core 文件的规则,并排查可能导致异常的情况。如果问题仍然存在,可能需要更详细的调查和分析以确定问题的根本原因。
2、配置dockerd参数,限制docker生成core文件
在centos7安装完docker后,通过systemctl进行管理,修改其参数即修改相应的serivce配置文件。
可以通过systemctl cat docker命令查看配置文件位置及配置文件内容,其中docker配置文件位置为:/usr/lib/systemd/system/docker.service
修改步骤:
打开文件,编辑ExecStart
项,如限制core文件生成大小为0,则在该项后边添加--default-ulimit core=0:0
参数,其他参数保持不变,修改后如下所示:
ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock --default-ulimit core=0:0
- 重新加载
docker.service
配置文件
# systemctl daemon-reload
- 重启docker服务
# systemctl restart docker
- 查看重启后的配置参数
# ps -ef | grep dockerd root 1436 1 17 10:29 ? 00:00:01 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock --default-ulimit core=0:0
3、验证
1)、dockerd限制core文件生成大小为0,docker run
默认启动容器,容器中限制core文件的大小为0。
# docker run -it --name=core-dump-test tomcat bash root@a87b45dcf45b:/usr/local/tomcat# ulimit -c 0
2)、dockerd限制core文件生成大小为0,docker run通过--ulimit修改为不限制,容器中不限制core文件的大小。
# docker run -it --name=core-dump-test-2 --ulimit core=-1 tomcat bash root@c37e89ce47b2:/usr/local/tomcat# ulimit -c unlimited
3)、dockerd限制core文件生成大小为0,kubernetes启动容器,容器限制core文件生成大小为0 。(容器core文件生成大小的限制依赖dockerd
进程)
编写yaml文件core-test.yaml:
apiVersion: v1 kind: Pod metadata: name: core-test spec: nodeSelector: kubernetes.io/hostname: kubetest-2 containers: - name: ubuntu image: ubuntu:12.04 command: ["/bin/sleep","3600"]
创建pod,并进入容器,并验证core文件大小的限制:
# kubectl create -f core-test.yaml pod "core-test" created # kubectl exec -it core-test bash # ulimit -c 0
4)、dockerd不限制core文件生成大小,kubernetes启动容器,容器不限制core文件的大小
修改docker.service
文件,将启动命令修改为如下:
ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock --default-ulimit core=-1
重新启动docker,并验证启动参数是否生效:
# systemctl daemon-reload # systemctl restart docker # ps -ef | grep docker root 10960 1 25 11:40 ? 00:00:01 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock --default-ulimit core=-1
删除刚刚创建的core-test
pod,并重新创建:
# kubectl delete -f core-test.yaml pod "core-test" deleted # kubectl create -f core-test.yaml pod "core-test" created
进入容器并验证core文件大小的限制:
# kubectl exec -it core-test bash # ulimit -c unlimited
5)、dockerd不限制core文件的大小,docker run
默认启动容器,容器中不限制core文件的大小
# docker run -it --name=core-dump-test3 tomcat bash # ulimit -c unlimited
4、设置core dump文件的输出路径
默认情况下,core dump文件生成在应用程序的主路径下边,在kubernetes环境下,一般将业务应用程序作为容器主程序,程序崩溃后容器直接退出,且被回收销毁,所以即使应用程序生成了core文件,一般你不容易拿到core文件。你可能会想,通过目录挂载的方式让core文件直接输出到本机磁盘或者网络存储上,然而一般情况下是不会将应用程序的主目录挂载出来的。所以,为了拿到core文件,我们可能需要修改core cump文件的输出路径,并将该输出路径挂载到本地磁盘或者网络存储,从而获取到相应的core文件。
在主机上执行如下命令(示例中在node1主机上执行):
echo "/tmp/cores/core.%p" > /proc/sys/kernel/core_pattern
以上,将core dump的输出路径修改为/tmp/cores,后续容器中的应用程序core dump文件也将输出到容器的/tmp/cores文件,因为在容器中读取的/proc/sys/kernel/core_pattern文件实质上就是主机的/proc/sys/kernel/core_pattern文件。
5、kubernetes容器中获取core文件
创建core-volume.yaml
文件:
apiVersion: v1 kind: Pod metadata: name: core-volume spec: nodeSelector: kubernetes.io/hostname: kubetest-2 volumes: - name: core-path hostPath: path: /home/core-dump containers: - name: ubuntu image: ubuntu:12.04 command: ["/bin/sleep","3600"] volumeMounts: - mountPath: /tmp/cores name: core-path
创建并进入pod:
# kubectl create -f core-volume.yaml pod "core-volume" created # kubectl exec -it core-volume bash
触发当前shell终端的段错误(会自动退出终端):
# kill -s SIGSEGV $$ command terminated with exit code 139
查看/home/core-dump
目录下是否生成core文件(容器实际运行的主机上查看,本例中为node1)
# ls /home/core-dump core.5
6、总结
在实际的开发场景中,容器生成的core dump文件能够对开发人员调试定位问题提供非常大的帮助,所以在特定场合生成并留存core dump是一件必要而有意义的事情。但是一般生产环境容器是不需要生成core dump文件的,生产环境dokcerd开启core可能会造成服务器节点io负载很高,如果检测到服务器磁盘中容器下生成的core文件占用的磁盘比较大则建议把docker的core给禁用。