3. kubectl debug 简介：用途、基本语法与核心区别
在 Kubernetes 故障排查中，kubectl debug 是 1.20 版本引入的官方调试命令，专为解决“容器内缺少调试工具”和“Pod 无法启动”两大痛点而设计。与传统的 kubectl exec 不同，kubectl debug 允许你通过创建临时容器（Ephemeral Container）或复制 Pod 的方式，在不影响原容器运行状态的前提下，注入完整的调试环境。
3.1 命令用途与适用场景
kubectl debug 的核心价值在于：当目标容器不可达、无 Shell、或缺少必要工具（如 curl、tcpdump、strace）时，仍能进行故障排查。它主要解决以下三类场景：
- 场景一：容器已崩溃或无法启动 —— 通过复制 Pod 并替换镜像，在相同配置下启动一个可交互的调试容器。
- 场景二：容器内无 Shell 或工具链 —— 使用
--image参数注入一个包含完整调试工具集的临时容器。 - 场景三：需要隔离调试，避免影响生产流量 —— 临时容器不会重启原 Pod，调试过程对业务无感。
最佳实践： 在故障域划分中，
kubectl debug 常用于“资源模型排错”的第三步——验证 Pod 内部网络连通性、DNS 解析、存储挂载状态。它让你在“怀疑网络策略”或“怀疑镜像配置”之前，先确认容器内部环境是否正常。
3.2 基本语法与常用参数
kubectl debug 的基本语法结构如下：
kubectl debug (POD | TYPE[[.VERSION].GROUP]/NAME) [--command] [ARG...] [flags]常用参数及其说明：
| 参数 | 类型 | 说明 |
|---|---|---|
--image |
string | 指定调试容器的镜像，默认使用 busybox 或 nicolaka/netshoot |
--target |
string | 指定临时容器附加到的目标容器名称（多容器 Pod 时必用） |
--copy-to |
string | 复制 Pod 并重命名，用于调试无法启动的 Pod |
--replace |
bool | 调试完成后是否删除原 Pod（与 --copy-to 配合使用） |
--share-processes |
bool | 是否与目标容器共享 PID 命名空间（默认 false） |
--command |
bool | 后面跟随的命令作为容器入口点执行，而非默认的 /bin/sh |
典型用法示例：
# 在运行中的 Pod 内启动临时调试容器（注入 netshoot 镜像）
kubectl debug my-pod -n my-namespace --image=nicolaka/netshoot
# 调试无法启动的 Pod（复制并替换镜像为 busybox）
kubectl debug my-pod -n my-namespace --copy-to=my-pod-debug --image=busybox -- /bin/sh
# 多容器 Pod 中指定目标容器
kubectl debug my-pod -n my-namespace --target=app-container --image=nicolaka/netshoot3.3 kubectl debug 与 kubectl exec 的核心区别
两者虽然都用于进入容器执行命令，但在设计理念、适用场景和权限模型上有本质差异。下表从 7 个维度进行对比：
| 对比维度 | kubectl exec | kubectl debug |
|---|---|---|
| 核心机制 | 在已有容器内执行命令 | 创建临时容器或复制 Pod 后执行命令 |
| 容器状态要求 | 容器必须处于 Running 状态 | 支持 CrashLoopBackOff、Init:Error 等非运行状态 |
| 工具依赖 | 依赖容器镜像内置工具 | 可注入任意调试镜像，不依赖原容器 |
| 对原容器影响 | 直接进入进程命名空间，可能影响业务 | 临时容器独立运行，不重启原 Pod |
| 网络命名空间 | 共享原容器的网络栈 | 默认共享，也可通过 --copy-to 独立 |
| 权限要求 | 需要 pods/exec 子资源权限 | 需要 pods/ephemeralcontainers 或 pods/exec 权限 |
| 适用版本 | 所有版本 | Kubernetes 1.20+（Ephemeral Containers 特性门控） |
常见误区： 很多运维人员习惯用
kubectl exec -it 进入容器，但当容器内没有 /bin/bash 或 /bin/sh 时，exec 会直接失败。此时应改用 kubectl debug 并指定 --image 参数，注入一个包含 Shell 的调试容器。
3.4 两种调试模式的架构对比
下图展示了 kubectl exec 与 kubectl debug 在 Pod 内部的工作机制差异：
3.5 在故障域划分中的定位
在“故障域划分”的排错流程中，kubectl debug 通常位于第二层——容器内部域的排查环节。当第一层（集群基础设施域）确认节点和网络正常后，debug 命令帮助你快速验证：
- 容器进程是否存活 —— 通过
--copy-to复制崩溃 Pod 并进入调试。 - 容器内网络连通性 —— 使用 netshoot 镜像测试 DNS、Service 访问、MTU 问题。
- 存储挂载是否正常 —— 检查 Volume 挂载点、文件权限、磁盘空间。
- 环境变量与配置 —— 验证 ConfigMap 和 Secret 是否正确注入。
排错口诀： “先 exec，不行再 debug；容器崩了用 copy-to，缺工具用 netshoot。” 在故障域划分中，debug 命令是连接“容器内部”和“集群外部”两个故障域的关键桥梁。