TKE集群设置容器coredump持久化

原创

聂伟星

发布于 2023-11-24 10:56:40

4110

发布于 2023-11-24 10:56:40

业务跑在容器上，当业务进程发生异常退出时候，业务日志无法定位到具体原因，需要结合coredump文件进一步分析，下面我们来介绍下如何在tke上持久化容器的coredump文件。现在业务在tke部署容器，通常有2种方式，一直是部署在普通cvm节点，一种是超级节点上，下面我们分别说明下在这2种节点的pod如何持久化coredump文件。

1. coredump内核参数说明

首先我们说明下如何开启coredump，这里是直接设置容器所在宿主机的内核参数开启，在节点执行这个命令，设置core文件的存放路径。

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

参数说明：

%h：主机名（在 Pod 内主机名即 Pod 的名称），推荐。
%e：程序文件名，推荐。
%p：进程 ID，可选。
%t：coredump 的时间，可选。

最终会在pod所在节点/tmp/cores目录下生成文件

/tmp/cores/core.xxxxxx

当然也可以通过其他方式来设置内核参数，临时给节点开启coredump，这种如果机器重启，内核参数就会失效

sysctl -w kernel.core_pattern="/tmp/cores/core.%h.%e.%p.%t"

如果要永久生效，可以执行下面命令设置

echo 'kernel.core_pattern=/tmp/cores/cores.%h.%e.%p.%t' >>/etc/sysctl.conf
sysctl -p

2. 普通cvm节点pod持久化coredump

如果pod是运行在普通cvm上，首先参考第一步在节点设置内核参数，开启coredump，然后将容器的core文件存放目录持久化挂载，避免pod重建，core文件就没有了。下面我们来配置下，这里我们用的cbs磁盘持久化，但是实际生产中，不建议用cbs，一般core文件比较大，容易将cbs磁盘打满，并且pod数量多，每个pod都要挂载cbs，成本比较高，，建议挂载到cfs或者cos这种外部存储中，将数据卷换成cfs或者cos类型pvc即可。

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    k8s-app: centos
    qcloud-app: centos
  name: centos
  namespace: weixnie
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      k8s-app: centos
      qcloud-app: centos
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        k8s-app: centos
        qcloud-app: centos
    spec:
      containers:
      - args:
        - 70d
        command:
        - sleep
        image: centos:7
        imagePullPolicy: IfNotPresent
        name: centos
        resources: {}
        securityContext:
          privileged: false
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /tmp/cores
          name: vol
      dnsPolicy: ClusterFirst
      imagePullSecrets:
      - name: qcloudregistrykey
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
      volumes:
      - name: vol
        persistentVolumeClaim:
          claimName: cbs-test

这里我们通过centos7镜像启动pod来进行测试，我们登陆容器，执行sleep 100命令然后，再执行ctrl + \ 命令触发coredump，看看是否会生成对应的core文件

销毁重建pod后，历史的core文件还是可以查看的

3. 超级节点pod持久化coredump

为了满足业务快速的扩缩容，现在很多业务会在tke集群加入超级节点，pod调度到超级节点上，超级节点其实底层是不存在物理资源的，只是k8s里的一个node资源对象，只有pod调度到了超级节点，这个时候才会买机器然后运行容器，也就是超级节点是无法登陆的，那超级节点的pod如何开启coredump呢？

其实超级节点的pod具有强隔离性，每个pod会申请一台独立的机器，运行容器，也就是说，每个pod其实也是有自己的宿主机的，这里我们只需要在宿主机设置内核参数开启coredump即可，但是超级节点pod的宿主机我们是无法登陆的，不过eks提供了通过注解方式来设置宿主机内核参数，参考文档/document/product/457/44173#.E8.AE.BE.E7.BD.AE.E5.AE.BF.E4.B8.BB.E6.9C.BA.E5.86.85.E6.A0.B8.E5.8F.82.E6.95.B0

可以在workload的yaml加上这个配置

spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      k8s-app: centos
      qcloud-app: centos
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
    type: RollingUpdate
  template:
    metadata:
      annotations:
        eks.tke.cloud.tencent.com/host-sysctls: '[{"name": "kernel.core_pattern","value": "/tmp/cores/core.%h.%e.%p.%t"}]'

和普通cvm节点一样，我们将容器的core文件存放目录持久化挂载，我这里用cbs挂载测试，但是实际生产建议用cfs或者cos。

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    k8s-app: centos
    qcloud-app: centos
  name: centos
  namespace: weixnie
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      k8s-app: centos
      qcloud-app: centos
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
    type: RollingUpdate
  template:
    metadata:
      annotations:
        eks.tke.cloud.tencent.com/host-sysctls: '[{"name": "kernel.core_pattern","value":
          "/tmp/cores/core.%h.%e.%p.%t"}]'
      creationTimestamp: null
      labels:
        k8s-app: centos
        qcloud-app: centos
    spec:
      containers:
      - command:
        - tail
        - -f
        - /etc/hosts
        image: centos:7
        imagePullPolicy: Always
        name: centos
        resources:
          limits:
            cpu: 250m
            memory: 256Mi
          requests:
            cpu: 250m
            memory: 256Mi
        securityContext:
          privileged: true
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /tmp/cores
          name: vol
      dnsPolicy: ClusterFirst
      imagePullSecrets:
      - name: qcloudregistrykey
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
      volumes:
      - name: vol
        persistentVolumeClaim:
          claimName: test

pod启动后，我们登陆容器测试下

能正常生成core文件，重建下pod，之前的core文件还是可以正常查看

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

容器服务

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

容器服务

登录后参与评论

0 条评论

热度