K8s 日志查看与调试的实战技巧

概述

在 Kubernetes（K8s）的日常运维中，应用一旦出现异常，日志就是我们最可靠的“黑匣子”。然而，K8s 的分布式架构使得日志散落在各个节点和容器中，新手往往在排查问题时感到无从下手。本文将带你系统掌握 K8s 中的日志查看方法与进阶调试技巧，帮你快速定位问题，告别“盲人摸象”式的排错。

什么是 K8s 中的日志

在 K8s 中，日志主要分为两大类：

1. 应用日志（Application Logs）：容器内应用输出到标准输出（stdout）和标准错误（stderr）的文本。这是排查业务逻辑错误的核心依据。
2. 系统日志（System Logs）：由 K8s 系统组件（如 kubelet、kube-proxy、containerd）生成的日志，以及节点的内核日志。这类日志主要用于排查节点级故障、网络策略异常或容器运行时问题。

为什么需要掌握日志调试技巧

面对复杂的微服务架构，仅凭监控面板上的告警往往只能看到“结果”，而日志能提供完整的“过程”：

1. 精准定位根因：通过错误堆栈（Stack Trace）和异常类型，直接定位到代码出问题的具体行数。
2. 还原事件时间线：结合系统日志和应用日志，可以清晰地看到“CPU 飙升 → OOM 被杀 → 容器重启 → 数据库连接失败”的完整故障链路。
3. 排查隐蔽问题：当容器因 CrashLoopBackOff 不断重启时，常规命令可能抓不到日志，必须借助高级调试技巧才能捕获崩溃瞬间的现场。

核心日志查看命令

掌握以下 kubectl 命令，可以覆盖 80% 的日常日志排查需求：

1. 查看常规日志：kubectl logs <pod-name> 获取容器当前的标准输出。
2. 实时追踪日志：kubectl logs <pod-name> -f 类似 Linux 的 tail -f，用于观察请求处理时的实时反馈。
3. 查看崩溃前的日志（核心）：kubectl logs <pod-name> --previous。当容器陷入无限重启时，当前日志可能是空的，加上 --previous 参数可以查看上一次崩溃前留下的最后遗言。
4. 多容器 Pod 指定日志：kubectl logs <pod-name> -c <container-name>。在 Sidecar 架构中，必须指定具体的容器名称才能看到对应日志。

原理解析：进阶调试与临时容器

当遇到极端情况（例如容器镜像是 Distroless 无发行版镜像，或者容器一启动就崩溃导致 kubectl exec 无法进入）时，我们需要使用 K8s 的**临时容器（Ephemeral Containers）**功能：

通过 kubectl debug 命令，K8s 可以在不重启目标 Pod 的情况下，动态注入一个包含丰富调试工具（如 bash、curl、tcpdump）的临时容器。

• 调试运行中的 Pod：kubectl debug -it <pod-name> --image=busybox --target=<pod-name>。这会注入一个与目标容器共享网络、进程命名空间的调试容器，方便你抓包或查看内存状态。
• 调试故障节点：kubectl debug node/<node-name> -it --image=ubuntu。当节点网络断开或 kubelet 宕机时，此命令会在该节点上启动一个特权 Pod，并将节点的根文件系统挂载到 /host 路径下，让你能直接查看 /host/var/log/kubelet.log 等底层系统日志。

最佳实践

1. 结构化日志输出：强烈建议应用输出 JSON 格式的日志。结合 jq 等工具，可以轻松过滤出特定 TraceID 的请求，或在海量日志中精准提取 Error 级别的信息。
2. 结合 Describe 看 Events：日志不是万能的。如果 kubectl logs 没有任何输出，说明容器根本没启动成功。此时必须立刻执行 kubectl describe pod <pod-name>，查看底部的 Events 字段，排查是否是镜像拉取失败、资源不足（OOMKilled）或探针配置错误。
3. 日志级别动态调整：对于复杂的线上问题，可以通过环境变量或配置中心动态将应用的日志级别调整为 DEBUG，获取更详细的上下文信息，问题解决后再调回 INFO。

常见问题

1. 日志量过大导致磁盘爆满：应用疯狂打印 DEBUG 日志，撑爆了节点磁盘。解决办法是在 K8s 层面配置容器日志轮转（Log Rotation），限制单文件大小和总大小。
2. 多行日志被截断：Java 等语言的异常堆栈包含大量换行符，在 K8s 中可能被拆分成多条日志。解决办法是使用支持多行合并的日志采集插件（如 Fluentd/Filebeat 的 multiline 配置）。
3. 网络不通但日志无报错：应用日志显示正常，但请求就是超时。解决办法是使用 netshoot 等网络诊断镜像，通过 kubectl debug 注入到 Pod 中，使用 tcpdump 或 curl 排查 Service 到 Pod 的网络连通性。

总结

日志排查是 K8s 运维的基本功。从基础的 kubectl logs 到高级的 kubectl debug，再到结合 describe 和系统日志的综合分析，构建了一套完整的排障坐标系。在实际生产中，建议将日志查看与 ELK/Loki 等日志聚合平台结合使用，让故障排查从“单点突击”升级为“全局掌控”。