K8s Pod突然重启，日志清空，原因何在？

Question

在K8s集群中，Pod突然重启且日志清空是一个常见问题。主要原因包括：1) Pod的健康检查失败（如Liveness Probe或Readiness Probe异常），导致K8s主动重启Pod；2) 容器内应用崩溃或退出，触发RestartPolicy；3) 节点资源不足（CPU、内存等），被K8s的Eviction机制驱逐；4) 配置变更或滚动更新，强制重启Pod；5) Pod所在节点故障或维护，Pod迁移至其他节点。 日志清空通常是因为容器重启后，之前的日志文件被销毁，或者日志存储未持久化。解决方法：检查Pod的事件日志（`kubectl describe pod `）、节点状态和系统日志，分析探针配置是否合理，优化资源请求与限制，使用外部日志收集工具（如EFK栈）持久化日志数据，避免因Pod重启导致日志丢失。

Answer 1

1. 问题概述

在Kubernetes集群中，Pod突然重启且日志清空是一个常见问题。这种情况可能对故障排查带来困难，因此需要深入分析其原因和解决方案。

主要问题表现：

• Pod频繁重启。
• 容器内日志文件丢失或被销毁。

以下是可能导致该问题的常见原因：

2. 原因分析

根据实际经验，Pod突然重启且日志清空的主要原因可以归类为以下几项：

1. 健康检查失败：Liveness Probe或Readiness Probe配置不合理，导致K8s判定Pod不健康并主动重启。
2. 应用崩溃或退出：容器内应用异常退出，触发RestartPolicy中的策略（如Always、OnFailure等）。
3. 节点资源不足：CPU或内存资源耗尽，K8s通过Eviction机制驱逐Pod。
4. 配置变更或滚动更新：Deployment或StatefulSet的配置发生变更，触发滚动更新。
5. 节点故障或维护：Pod所在的节点出现故障或进行维护操作，Pod迁移至其他节点。

同时，日志清空的原因主要包括：

• 容器重启后，之前的日志文件被销毁。
• 日志存储未持久化，数据无法保留。

3. 解决方案

针对上述问题，可以通过以下步骤逐步排查并解决问题：

步骤	操作	目标
1	使用`kubectl describe pod `命令查看Pod事件日志。	定位Pod重启的具体原因。
2	检查节点状态和系统日志（如dmesg或journalctl）。	确认是否因节点资源不足导致Pod被驱逐。
3	分析探针配置是否合理（如初始延迟、超时时间等）。	避免因探针误判导致Pod重启。
4	优化资源请求与限制（Requests和Limits）。	减少因资源不足引发的问题。

4. 日志持久化策略

为了防止Pod重启导致日志丢失，可以采用以下方法：

# 使用EFK栈进行日志收集
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
spec:
  selector:
    matchLabels:
      name: fluentd
  template:
    metadata:
      labels:
        name: fluentd
    spec:
      containers:
      - name: fluentd
        image: fluent/fluentd:v1.14-debian-1
        volumeMounts:
        - name: varlog
          mountPath: /var/log
      volumes:
      - name: varlog
        hostPath:
          path: /var/log

通过部署Fluentd等日志收集工具，将日志数据发送到Elasticsearch中存储，并通过Kibana进行可视化。

5. 流程图示例

以下是Pod重启及日志丢失问题的排查流程图：

graph TD;
    A[Pod重启] --> B{检查事件日志};
    B --健康检查失败--> C[调整Liveness/Readiness Probe];
    B --资源不足--> D[优化Requests/Limits];
    B --应用异常退出--> E[修复应用逻辑];
    B --配置变更--> F[确认滚动更新];
    B --节点故障--> G[检查节点状态];
    H[日志丢失] --> I{日志持久化？};
    I --未持久化--> J[部署EFK栈];