Kubernetes故障排查

排查过程中最怕遇到的，就是“没有报错日志”的故障。某次核心业务集群的基础镜像批量升级后，数百个 Java 微服务 Pod 在重启后瞬间陷入 CrashLoopBackOff，无任何业务日志输出。最终查明，根本原因并非基础镜像本身的业务兼容性问题，而是安全团队通过 Webhook 强推的 Seccomp 自定义严格白名单中，遗漏了新版 glibc (>=2.34) 强依赖的 clone3 系统调用，且错误地配置了阻断动作，导致 JVM 底层线程创建直接崩溃。

防御性编程和安全加固绝对不是在网上抄一段 JSON 配置闭着眼睛全量下发。缺乏灰度压测和系统调用 Profiling 的“一刀切”安全策略，其破坏力甚至远超真实的黑客攻击。

诡异的故障现场

排查过程中，研发反馈新发布的 Pod 全部无法就绪。第一反应是拉取日志：

kubectl logs -f <pod-name> --previous

结果是空的。JVM 连初始化的堆栈都没来得及吐出就暴毙了。查看 Pod 事件：

kubectl describe pod <pod-name>
# 重点信息截取：
# State:          Waiting
# Reason:         CrashLoopBackOff
# Last State:     Terminated
# Reason:         Error
# Exit Code:      132

Exit Code 132，这是一个极其关键的信号。132 = 128 + 4，对应的是 SIGILL（非法指令），但在容器安全上下文里，通常是由于触发了 Seccomp 的 SCMP_ACT_KILL 或 SCMP_ACT_KILL_PROCESS，内核发送了 SIGSYS（Bad system call，信号 31），在某些容器运行时的封装下会以类似异常退出码体现。如果是 SCMP_ACT_ERRNO，退出码通常是 1 并伴随 Operation not permitted。

深入内核层排查

既然应用层没有线索，直接下沉到 Node 节点看内核审计日志。登录故障 Pod 所在的宿主机，执行：

dmesg -T | grep -i seccomp
# 或者查看 audit 日志
tail -n 100 /var/log/audit/audit.log | grep -i seccomp

屏幕上密密麻麻全是类似这样的拦截记录：

type=1326 audit(169xxxxxxx.xxx:xxxx): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=124555 comm="java" exe="/opt/java/openjdk/bin/java" sig=31 arch=c000003e syscall=435 compat=0 ip=0x7f8a9b1c2d49 code=0x80000000

拆解这段内核日志，核心线索浮出水面：

comm="java"：涉事进程是 JVM。
arch=c000003e：代表 x86_64 架构。
syscall=435：查阅 Linux 系统调用表，x86_64 的 435 号是 clone3。
code=0x80000000：对应 Seccomp 动作 SECCOMP_RET_KILL_THREAD。

致命的 ENOSYS 与 EPERM 陷阱

为什么突然会用到 clone3？基础镜像从基于 Debian 10 升级到了 Debian 11/12（或 Ubuntu 22.04），底层的 glibc 版本跨越了 2.34。在旧版本中，glibc 使用 clone (syscall 56) 来创建线程；而在新版本中，默认改用更现代的 clone3 (syscall 435)。

此时，查看安全团队通过 K8S Mutating Webhook 全局注入的 seccompProfile：

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "syscalls": [
    {
      "names": ["clone", "execve", "read", "write", "...(省略约200个常规系统调用)..."],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

这就是典型的低级失误： 配置文件里白名单只放行了 clone，完全漏掉了 clone3 和 rseq。

更致命的是 Seccomp 机制的一个隐藏大坑：优雅降级被破坏。如果内核不支持 clone3，glibc 调用后内核会返回 ENOSYS (Function not implemented)，glibc 捕获到 ENOSYS 后会自动降级使用老的 clone，业务无感。但是！在这个自定义的 Seccomp 配置中，未命中白名单的调用会被直接 SCMP_ACT_ERRNO（返回 EPERM，Operation not permitted）或者 SCMP_ACT_KILL。当 glibc 拿到 EPERM 时，它认为“权限不足”，不会触发降级逻辑，而是直接抛出异常导致进程崩溃。

Falco 报警风暴与监控瘫痪

更有戏剧性的是，集群里其实部署了 Falco 作为运行时 IDS。当我们去查看 Falco 告警时，发现 ES 和 Slack 已经被报警风暴淹没：

{"output":"Unexpected syscall clone3 dropped by seccomp (user=root pod=app-xyz-6d... syscall=clone3)","priority":"Warning","rule":"Seccomp Drop Detected"}

每秒数以万计的并发启动失败，触发了海量的 Falco 审计事件，直接把本地的 journald 队列打满，并引发了宿主机的 CPU 瞬时飙升（Load Average 冲破宿主机核心数），最终导致告警组件触发 Rate Limit 被迫丢弃数据。这正是典型的“告警疲劳”反噬。配置了安全监控，却不在发布前做好基线对齐，真出事时这些监控反倒成了雪上加霜的帮凶。

技术结论与避坑建议

拒绝盲目的一刀切白名单：在 K8S 环境中，推荐直接使用容器运行时的默认配置 RuntimeDefault。Docker/containerd 的默认 Seccomp 配置文件由内核和容器领域的顶尖专家维护，兼顾了安全性与兼容性（例如他们早就处理好了 clone3 返回 ENOSYS 而非 EPERM 的逻辑）。
Profile 必须经过 Audit 阶段：如果要推行极度严格的自定义 Seccomp 或 AppArmor 白名单，必须先在沙盒环境使用 SCMP_ACT_LOG（仅记录不拦截）运行全量回归测试，通过 audit.log 收集完整的系统调用基线，再切换到 SCMP_ACT_ERRNO。
利用 eBPF 工具自动化生成基线：推荐使用 Kubernetes Security Profiles Operator (SPO) 结合 eBPF，在业务正常运行时录制所需的系统调用，自动生成 Seccomp JSON，而不是靠人工拍脑袋写。
关注底层依赖变更：基础镜像升级绝不只是改个 FROM 那么简单，glibc 的更新（如引入 rseq, clone3, statx）会直接改变应用底层的 syscall 足迹。

同类问题排查清单（Seccomp/AppArmor/Falco 拦截排查速查）

进程异常退出且无日志 (Exit Code 132 / 1)
动作：立即执行 dmesg -T | grep -iE 'seccomp|apparmor|audit'。
目标：寻找 sig=31 或 apparmor="DENIED" 的关键日志，定位被拦截的具体资源或系统调用编号。
系统调用编号反查
动作：使用 ausyscall x86_64 翻译系统调用号（如 ausyscall x86_64 435 返回 clone3）。
目标：明确是哪个底层动作触发了安全规则。
确认 Pod 实际生效的安全策略
动作：kubectl get pod -o yaml | grep -A 5 securityContext
目标：检查 seccompProfile 是否被设为了非预期的 Localhost 自定义配置，或者 AppArmor 注解是否被意外注入。
验证 Falco 性能损耗
动作：如果节点系统负载飙升，通过 pidstat -p 1 检查 Falco CPU 占用，并查看 /var/log/falco/ 中的丢包率（drop metrics）。如果是规则过于宽泛导致系统调用捕获量过大，需临时调配 Falco 规则引擎过滤高频无害事件。

标签： Kubernetes故障排查