k8s查不到logs该怎么处理

为什么用 kubectl logs 查不到K8s日志？生产环境排查指南

在 Kubernetes 中查看 Pod 日志是日常运维的高频操作，但遇到 kubectl logs 查不到日志时，新手容易手忙脚乱。本文结合生产环境常见问题，手把手教你排查和解决日志查看失败的问题。

---

1. 先看Pod状态：Pod都没起来，哪来的日志？

检查命令：

kubectl get pods -n <命名空间>
kubectl describe pod <Pod名> -n <命名空间>

常见问题：

• Pod卡在Pending状态：可能是资源不足（CPU/内存）、节点污点未容忍、存储卷挂载失败。
• Pod不断重启（CrashLoopBackOff）：应用启动失败，此时即使有日志也可能被轮转覆盖。
• Pod状态Completed：一次性任务执行结束，需检查是否配置了日志持久化。

解决思路：

• 通过 kubectl describe 查看 Events 字段的错误提示（如镜像拉取失败、端口冲突）。
• 修复应用问题或调整资源配置，确保Pod进入 Running 状态。

---

2. 权限不足：你确定有权限看日志？

场景：

• 生产环境通常启用 RBAC（角色权限控制），普通用户可能无权查看日志。
• 使用 ServiceAccount 的服务（如CI/CD流水线）未绑定日志权限。

检查权限：

# 检查当前用户是否有权限查看日志
kubectl auth can-i get pods --subresource=logs

解决方案：

# 创建一个Role绑定日志权限
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-logs-reader
rules:
- apiGroups: [""]
  resources: ["pods/log"]
  verbs: ["get", "list"]
---
# 将Role绑定到用户或ServiceAccount
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-logs
subjects:
- kind: User
  name: "your-user"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-logs-reader
  apiGroup: rbac.authorization.k8s.io

---

3. 容器选择错误：Pod里有多个容器

现象：

• 当Pod包含多个容器时，必须指定容器名，否则默认选第一个容器。

正确命令：

kubectl logs <Pod名> -c <容器名> -n <命名空间>

偷懒技巧：

# 查看Pod内所有容器的日志
kubectl logs <Pod名> --all-containers=true

---

4. 日志被“吃掉”了：应用的日志去哪了？

常见问题：

• 应用未输出到stdout：K8s默认采集标准输出日志，若日志写入文件（如 /app/logs/error.log），则 kubectl logs 查不到。
• 日志缓冲区未刷新：某些语言（如Java）的日志框架存在缓冲区，需配置立即刷新。

解决方案：

• 方案1：修改应用配置，将日志输出到标准输出。
• 方案2：挂载日志文件到共享存储，用边车（Sidecar）容器转发日志。
• 方案3：改用日志采集工具（如Fluentd、Filebeat）直接抓取文件日志。

---

5. 节点级问题：kubelet或磁盘炸了

排查步骤：

1. 检查kubelet状态：

   # 登录节点执行
   systemctl status kubelet
   journalctl -u kubelet -n 100 | grep error
   

2. 检查磁盘空间：

   df -h /var/lib/docker  # 默认容器日志存储路径
   

   • 如果磁盘满了，K8s会自动清理旧日志，但可能误删当前日志。

3. 检查kubelet日志配置：

   # 检查kubelet参数
   ps aux | grep kubelet | grep -- --container-log-max-size
   

   • 参数示例：--container-log-max-size=10Mi（单日志文件最大10MB）

---

6. 冷门问题：你可能想不到的坑

• 日志驱动不匹配：Docker默认用 json-file 驱动，若改为 journald，需通过 journalctl 查询。
• 容器瞬间崩溃：日志未生成时直接退出，需结合 kubectl events 和 describe 排查。
• API Server故障：集群控制平面异常，所有 kubectl 命令均失效，需优先恢复集群。

---

总结：日志查看的通用排查流程

1. 确认Pod状态 → kubectl get pods
2. 检查权限 → kubectl auth can-i
3. 查看容器名 → kubectl describe pod
4. 检查应用日志输出 → 进入容器确认
5. 排查节点问题 → kubelet、磁盘、网络
6. 终极方案 → 登录节点直接查看日志文件（/var/log/pods/...）

---

实战技巧：

• 长期日志保留：使用 Loki 或 EFK 栈集中采集日志。
• 日志轮转：配置 kubectl logs --previous 查看上一次崩溃的容器日志。
• 日志调试：临时启动 Busybox Sidecar 挂载日志目录，实时 tail -f 观察。

掌握这些技巧后，99%的日志查看问题都能迎刃而解！