如何定位问题Pod

2026-01-22 22:22:00
丁国栋
原创 23
摘要:如何通过节点的事件找到问题Pod的位置。

确定问题Pod的命名空间和Pod名称

kubernetes集群中的一个节点报告:

Events:
  Type     Reason                 Age   From       Message
  ----     ------                 ----  ----       -------
  Warning  OomGuardKillContainer  21m   oom-guard  {"hostname":"10.8.0.4","timestamp":"2026-01-22T06:30:18.054248091Z","oomcgroup":"/sys/fs/cgroup/memory/kubepods/burstable/pod24cfd002-f295-4ef5-8607-c9aeadc63f1e/4cd1c76c3a4f6955fc18a8b2bcc98fb5f86213e7cfb9be7126607155d045e1ce","selected":"/sys/fs/cgroup/memory/kubepods/burstable/pod24cfd002-f295-4ef5-8607-c9aeadc63f1e/4cd1c76c3a4f6955fc18a8b2bcc98fb5f86213e7cfb9be7126607155d045e1ce","threshold":263066747,"usage":264224768,"killed":"2795169(s6-svscan) 2795875(s6-supervise) 2795876(s6-supervise) 2795976(apachectl) 2795977(cron) ","stats":"cache 74108928|rss 153587712|rss_huge 0|shmem 73830400|mapped_file 74207232|dirty 135168|writeback 0|swap 0|pgpgin 4767246|pgpgout 4711332|pgfault 7927392|pgmajfault 0|inactive_anon 73801728|active_anon 153550848|inactive_file 0|active_file 0|unevictable 0|hierarchical_memory_limit 268435456|hierarchical_memsw_limit 9223372036854771712|total_cache 74108928|total_rss 153587712|total_rss_huge 0|total_shmem 73830400|total_mapped_file 74207232|total_dirty 135168|total_writeback 0|total_swap 0|total_pgpgin 4767246|total_pgpgout 4711332|total_pgfault 7927392|total_pgmajfault 0|total_inactive_anon 73801728|total_active_anon 153550848|total_inactive_file 0|total_active_file 0|total_unevictable 0|","policy":"Container"}

思路:从事件中的 oomcgroup 路径可以确定出 Pod 的 UID,然后通过 kubectl 命令查找对应的 Pod 名称和命名空间。

步骤解析

1. 从事件中提取 Pod UID

事件中的 cgroup 路径包含 Pod UID:

/sys/fs/cgroup/memory/kubepods/burstable/pod24cfd002-f295-4ef5-8607-c9aeadc63f1e/...

Pod UID 是:24cfd002-f295-4ef5-8607-c9aeadc63f1e

2. 通过 kubectl 查找 Pod

使用以下任一命令查找对应的 Pod:

方法一:通过 Pod UID 直接过滤

kubectl get pods --all-namespaces -o json | \
  jq -r '.items[] | select(.metadata.uid=="24cfd002-f295-4ef5-8607-c9aeadc63f1e") | "Namespace: \(.metadata.namespace) Pod: \(.metadata.name)"'

方法二:列出所有 Pod 并过滤 UID

kubectl get pods --all-namespaces -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,UID:.metadata.uid | \
  grep 24cfd002-f295-4ef5-8607-c9aeadc63f1e

方法三:如果知道 Pod 在特定节点名称可以直接过滤以提高性能

kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=<node-name> -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,UID:.metadata.uid |grep 24cfd002-f295-4ef5-8607-c9aeadc63f1e

4. 如果只有节点访问权限

在出问题的节点上执行:

# 查看 cgroup 对应的容器
sudo crictl ps -o json | grep "24cfd002-f295-4ef5-8607-c9aeadc63f1e"

问题分析

从事件信息可以看出:

  • Pod 内存限制:hierarchical_memory_limit 显示为 256MiB (268435456 bytes)
  • 实际使用:usage 为 264224768 bytes (~252MiB),已接近限制
  • 被 OOM Guard 杀死的进程主要是 s6 和 apache 相关进程
  • 这是一个使用了 s6-overlay 和 Apache 的容器

找到 Pod 后,建议:

  1. 检查 Pod 的内存请求和限制配置
  2. 考虑适当增加内存限制
  3. 检查应用是否存在内存泄漏
  4. 查看 Pod 的日志做进一步分析
发表评论
博客分类