3. kubectl debug 简介：起源、作用与核心差异

在 Kubernetes 故障诊断体系中，kubectl debug 是专为“不可变基础设施”设计的交互式诊断命令。它解决了传统 kubectl exec 在容器镜像精简、只读根文件系统、缺少调试工具等场景下的根本性局限。本节从起源、作用、与 kubectl exec 的对比三个维度，建立对 kubectl debug 的完整认知。

3.1 命令起源：从“容器内执行”到“临时诊断容器”

Kubernetes 社区在 v1.18（2020 年）引入 kubectl debug 作为 alpha 特性，v1.23 进入 beta，v1.27 正式 GA。其诞生背景直接对应生产环境中的三类痛点：

• 镜像精简化：Distroless、Scratch 等基础镜像不包含 shell、ping、tcpdump、curl 等调试工具，kubectl exec 无法启动交互式进程。
• 只读文件系统：安全容器或 Pod 安全策略禁止写入 /tmp、/proc 等路径，kubectl exec 安装临时工具失败。
• 故障现场保护：kubectl exec 直接在目标容器内运行进程，可能污染环境变量、修改内核参数或触发 OOM，干扰故障根因分析。

3.2 核心作用：三大诊断能力

kubectl debug 提供三种互补的调试模式，覆盖不同故障场景：

3.3 与 kubectl exec 的本质区别

以下对比表从 7 个关键维度说明 kubectl debug 与 kubectl exec 的差异，帮助你在故障诊断中做出正确选择：

3.4 架构资源冲突诊断中的定位

在后续章节的故障域划分中，kubectl debug 将作为“无侵入探针”出现在以下诊断环节：

• 端口冲突：通过调试容器执行 ss -tlnp 或 netstat，确认目标 Pod 内实际监听的端口与 Service/Ingress 配置是否一致。
• 存储卷挂载冲突：挂载目标 Pod 的 /var/lib/kubelet/pods/<pod-uid>/volumes，检查 CSI 驱动返回的设备路径与 Pod 内挂载点是否匹配。
• 资源配额超限：在调试容器内读取 /sys/fs/cgroup 中的 CPU/内存限制值，与 Pod 的 resource limits 声明进行比对。
• 网络策略拦截：使用 nicolaka/netshoot 镜像执行 curl、dig、traceroute，验证 egress/ingress 规则是否生效。

3.5 快速上手：一条命令的完整生命周期

以下示例演示 kubectl debug 在诊断“Pod 内端口监听异常”时的典型用法：

# 1. 为运行中的 Pod 附加临时诊断容器
kubectl debug my-app-7d4f8b9c6-x2k3l \
  -it \
  --image=nicolaka/netshoot \
  --target=my-app-container

# 2. 在诊断容器内执行网络诊断
/ # ss -tlnp
State    Recv-Q   Send-Q     Local Address:Port     Peer Address:Port   Process
LISTEN   0        128              0.0.0.0:8080          0.0.0.0:*       users:(("java",pid=1,fd=29))
LISTEN   0        128                 [::]:8080             [::]:*       users:(("java",pid=1,fd=30))

# 3. 确认端口冲突：Service 声明 8080，但 Pod 内实际监听 8080 → 一致
# 若发现监听 9090 而非 8080，则属于“容器端口声明与实际监听端口不匹配”的架构资源冲突

# 4. 退出诊断容器，自动清理
/ # exit