Kubernetes DaemonSet Pod无明确原因批量重启的排查方案问询

我在Kubernetes集群中通过DaemonSet部署了一个应用，预期每个节点运行一个实例，该Pod包含业务容器与代理辅助容器两个容器。在稳定性测试过程中，发现集群所有节点上的该应用Pod几乎同时重启，尝试定位这类全集群重启的潜在原因。

已完成的排查项 #

• 未发现驱逐相关问题
• 集群节点无重启或重启记录
• 暂未发现触发资源限制的迹象，但无法100%确认，且未在日志中找到相关信息
• syslog、kubectl events及其他日志均未发现异常
• 看到大量垃圾回收（GC）尝试释放空间失败的日志，但据了解GC不应影响运行中的容器

目前已将kubectl日志级别调至最高，但仅观测到来自API的DELETE调用，不清楚触发该调用的原因。

应用YAML文件 #

apiVersion: apps/v1
kind: DaemonSet 
metadata:
  name: test-app
  labels:
    app: test-app
spec:
  selector:
    matchLabels:
      app: test-app
  template:
    metadata:
        labels:
          app: test-app
    spec:
      containers:
        - name: test-app
          image: test-app:0.0.1 
          imagePullPolicy: IfNotPresent
          resources:
            requests:
              ephemeral-storage: "100Mi"
              memory: "1Gi"
            limits:
              ephemeral-storage: "100Mi"
              memory: "1Gi"
          ports:
            - containerPort: 12345
              hostPort: 12345
          volumeMounts:
            - name: log-volume
              mountPath: /var/log/
        - image: proxy:0.0.1
          imagePullPolicy: IfNotPresent
          name: proxy
          resources:
            requests:
              cpu: 10m
              memory: 10m
      volumes:
        - name: log-volume
          hostPath:
            path: /var/log/

kubelet中观测到的DELETE日志 #

kubelet 284030  I0522 17:09:07.287913  284030 config.go:293] "Setting pods for source" source="api"
kubelet 284030  I0522 17:09:07.301398  284030 kubelet.go:2405] "SyncLoop DELETE" source="api" pods=["default/test-app-abcde"]
kubelet 284030  I0522 17:09:07.303019  284030 pod_workers.go:856] "Pod is marked for graceful deletion, begin teardown" pod="default/test-app-abcde" podUID="123456-12345-123456-12345" updateType="update"

进一步调试方法 #

1. 追踪API Server侧DELETE请求来源 #

• 启用API Server审计日志（若未开启），配置审计策略记录所有Pod相关DELETE操作，通过审计日志查看请求发起的客户端、用户、IP等信息，确认是控制器自动触发、人工操作还是第三方组件执行
• 排查全命名空间事件：kubectl get events --all-namespaces --sort-by='.metadata.creationTimestamp'，重点关注kube-system下DaemonSet控制器、调度器的异常事件
• 检查DaemonSet本身的事件与状态：kubectl describe daemonset test-app，查看是否存在模板变更、滚动更新触发的记录（比如是否有人修改了spec.template导致全量重建）

2. 验证资源限制与存储异常 #

• 通过监控工具（如Prometheus+Grafana）或kubectl top node查看Pod重启时刻的节点内存、存储、CPU使用率，确认是否存在瞬时资源耗尽的情况
• 检查节点临时存储状态：执行df -h查看容器运行时存储目录（如/var/lib/docker），GC释放空间失败可能是存储压力的信号，极端情况下kubelet可能触发异常处理逻辑
• 获取容器退出码：kubectl get pod <pod-name> -o jsonpath='{.status.containerStatuses[*].lastTerminationState.terminated.exitCode}'，退出码137对应OOM，0为正常退出，其他码可对应容器自身崩溃原因

3. 排查容器运行时与kubelet异常 #

• 查看容器运行时日志：journalctl -u containerd（或cri-o对应服务），检查重启时刻是否有容器崩溃、运行时故障的记录
• 过滤kubelet特定时间段日志：journalctl -u kubelet --since="17:08" --until="17:10"，除DELETE日志外，重点关注Pod sandbox销毁、健康检查失败、镜像拉取异常等信息
• 检查DaemonSet更新策略：当前YAML未配置updateStrategy，默认是RollingUpdate，确认是否有maxUnavailable参数修改，或节点亲和性/容忍度变更导致Pod重新调度

4. 检查集群核心组件一致性 #

• 查看API Server、Controller Manager、Scheduler的日志，确认重启时刻是否有组件重启或集群状态异常
• 验证etcd健康状态：etcdctl endpoint health，查看etcd日志是否存在数据不一致、写入失败的情况（DaemonSet状态存储在etcd中，异常可能导致控制器误触发删除）
• 排查第三方工具操作：检查是否有CI/CD脚本、配置管理工具在重启时刻执行了Pod删除或DaemonSet更新操作

内容的提问来源于stack exchange，提问作者user25198921