K8s常用排障调试工具 入侵排查 kubectl debug 命令详解

kubectl debug是 Kubernetes 中一个强大的调试工具，允许开发者和运维人员对运行中的 Pod 进行故障排查和诊断，而无需修改或重启原有 Pod。

kubectl debug的核心思想是创建一个临时的调试容器，将其附加到目标 Pod 的命名空间中，提供安全的调试环境。这种方式避免了传统调试方法的局限性。

为什么需要 kubectl debug？

在它出现之前，排查 Pod 问题的常见方法有很大局限：

1. kubectl exec：只能使用目标容器内已有的、通常非常精简的命令集（可能没有 ping, curl, ps, netstat等工具）。
2. 修改 Pod 镜像：将基础镜像改为包含调试工具的版本并重新部署。这改变了现场，并且可能重启服务，影响业务。
3. 在节点上使用 docker exec/crictl exec：这需要登录节点，并且有节点权限，不安全且不方便。

kubectl debug完美地解决了这些问题。

使用语法

kubectl debug <TARGET_POD_NAME> -c <DEBUG_CONTAINER_NAME> --image=<DEBUG_IMAGE> --target=<TARGET_CONTAINER_NAME> -- <COMMAND>

主要使用模式

1. 临时调试容器模式（最常用）

这是最常见的用法。当你的应用 Pod（例如，使用 nginx镜像）无法正常工作，你需要网络诊断工具时

# 在一个名为 "app-nginx" 的 Pod 中创建一个名为 "debugger" 的临时容器，使用流行的 nicolaka/netshoot 镜像
[root@master ~]# kubectl get pod 
NAME        READY   STATUS    RESTARTS   AGE
app-nginx   1/1     Running   0          26s[root@master ~]# kubectl debug app-nginx -c debugger --image=nicolaka/netshoot --target=nginx -it -- /bin/sh 
Targeting container "nginx". If you don't see processes from this container it may be because the container runtime doesn't support this feature.
--profile=legacy is deprecated and will be removed in the future. It is recommended to explicitly specify a profile, for example "--profile=general".
If you don't see a command prompt, try pressing enter.
~ # ps 
PID   USER     TIME  COMMAND1 root      0:00 nginx: master process nginx -g daemon off;29 101       0:00 nginx: worker process30 101       0:00 nginx: worker process58 root      0:00 /bin/sh64 root      0:00 ps--profile=legacy:这个参数已经被标记为"弃用"，在未来的版本中会被移除
原因：legacy配置文件被认为安全性不足因为权限太高，Kubernetes 团队希望用户使用更安全的配置建议：明确指定一个安全配置文件，比如使用 --profile=general

# 如果只想创建一个交互式的 Shell 并直接附加到它
[root@master ~]# kubectl debug app-nginx --profile=general -c debugger-1 --image=nicolaka/netshoot --target=nginx -it -- /bin/bash

参数解释：

• -c debugger-1：指定新创建的调试容器的名称。
• --image=nicolaka/netshoot：指定调试容器使用的镜像。netshoot是一个包含大量网络诊断工具（如 tcpdump, netstat, curl, iproute2等）的著名镜像。其他常用镜像有 busybox， alpine。
• --target=nginx：**（关键选项）**指定要将调试容器的命名空间共享给哪个目标容器。这使调试容器可以看到目标容器的网络、进程等命名空间。如果 Pod 中有多个容器，必须指定此参数。
• -it：保持标准输入打开并分配一个伪终端，以便进行交互式操作。
• --profile=general获取一个中等权限，日常调试通用配置。

进入容器可以执行：
# 检查网络连接（因为共享了网络命名空间）
nginx-deployment-54c98b4f84-dxqrw:~# netstat -lntp
nginx-deployment-54c98b4f84-dxqrw:~# curl -v http://localhost:80
* Host localhost:80 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:80...
* Connected to localhost (::1) port 80# 抓包
# tcpdump -i any -w capture.pcap# 检查 DNS
# nslookup kubernetes.default.svc.cluster.local# 查看进程（因为通过 --target 共享了进程命名空间）
# ps aux

场景 2：复制一个 Pod 并进行调试（例如，修改启动命令或镜像）

当 Pod 因配置错误（如启动命令错误、崩溃循环）而无法正常启动时，你可以复制它的配置并创建一个新的、可调试的副本。

# 更常见的用法：在复制的 Pod 中，将第一个容器的启动命令改为 /bin/sleep 3600，并直接运行
[root@master ~]# kubectl debug app-nginx --copy-to=app-nginx-debug --container=nginx -- /bin/sleep 3600
[root@master ~]# kubectl get pod 
NAME                READY   STATUS    RESTARTS   AGE
app-nginx           1/1     Running   0          14m
app-nginx-debug     1/1     Running   0          20s

参数解释：

• --copy-to=app-nginx-debug：创建一个名为 app-nginx-debug的新 Pod，它是原 Pod 的副本。
• --container=nginx：指定要修改哪个容器的启动命令。
• 命令末尾的 /bin/sleep 3600：替换原容器的启动命令。这样 Pod 就不会崩溃，而是保持运行，允许你 kubectl exec进去排查。

之后，你可以：

# 连接到新 Pod 进行诊断
[root@master ~]# kubectl exec -it app-nginx-debug -- /bin/sh# 检查文件系统、环境变量，并尝试手动运行原始启动命令来查看错误信息。

---

场景 3：在节点上创建调试 Pod（用于节点级故障排查）

这个功能允许你创建一个具有节点权限的 Pod，用于排查节点本身的问题（如文件系统、内核问题）。

# 在名为 node-1 的节点上创建一个调试 Pod
[root@master ~]# kubectl debug node/node-1 -it --image=nicolaka/netshoot

特点：

• 创建的 Pod 会运行在宿主机的命名空间中（hostNetwork: true, hostPID: true, hostIPC: true）。
• 它通常会将宿主机的根文件系统挂载到 Pod 内的 /host目录。
• **警告：**此 Pod 具有很高的节点权限，请谨慎使用。

进入后，你可以像登录到节点上一样操作：

node-1  ~  chroot /host ps aux
node-1  ~  chroot /host netstat -tulpn
node-1  ~  chroot /host ls -la /var/log/
node-1  ~  chroot /host ls  /var/log/pods

在入侵排查中的具体应用

# 1. 静默调查可疑 Pod（不惊动攻击者）
# kubectl debug suspicious-pod --image=nicolaka/netshoot --target=malicious-container# 在调试容器中秘密调查：
# - 监控网络连接：ss -tunap
# - 抓取恶意流量：tcpdump -i any -w capture.pcap
# - 分析进程树：pstree -p# 2. 分析已停止的恶意 Pod
# kubectl debug stopped-malicious-pod --copy-to=forensics-pod --container=app -- /bin/sleep 3600# 检查文件系统痕迹
# kubectl exec -it forensics-pod -c app -- /bin/sh
find / -name "*.sh" -o -name "*.py" -o -name "*.elf"  # 查找脚本和二进制文件
cat /etc/passwd /etc/shadow  # 检查用户账户

kubectl debug是你的“手术刀”：

1. 排查可疑 Pod：发现一个未知 Pod suspicious-pod正在挖矿。
   • 不要直接 exec进去，这可能会惊动攻击者或触发其自毁机制。
   • 使用 kubectl debug创建一个共享其网络和进程命名空间的调试容器。
   • 在调试容器中，使用 tcpdump抓取恶意流量，使用 nsenter或 ps观察其进程树和父进程，从而分析攻击链。
2. 分析崩溃的恶意 Pod：一个挖矿 Pod 因为资源不足总是崩溃循环。
   • 使用 --copy-to功能复制该 Pod，并将命令改为 sleep，使其稳定运行。
   • 然后 exec进去，检查它的文件系统（查看 /tmp是否有恶意脚本）、环境变量和启动命令，了解其攻击载荷。
3. 排查被入侵的节点：怀疑某个工作节点被攻陷。
   • 使用 kubectl debug node/...来检查节点的进程、文件系统和日志，而无需直接 SSH 登录（如果 SSH 密钥已泄露或已被攻击者修改）。

最佳实践建议：

• 在你的集群中预先拉取常用的调试镜像（如 nicolaka/netshoot, busybox），以加快调试速度。
• 明确区分 --target（共享命名空间）和 --copy-to（复制Pod）的使用场景。
• 在生产环境中使用节点调试功能时要格外小心。

掌握 kubectl debug能极大提升你对 Kubernetes 的故障排查和安全事件响应能力。