无法通过kubectl debug调试Kubernetes Pod中的Sidecar容器

开发者阿泽

2026-7-1

问题：调试Kubernetes Pod中崩溃循环的Sidecar容器

我有一个包含两个容器的Kubernetes Pod，其中Sidecar容器陷入崩溃循环。尝试用kubectl debug命令调试，但在调试Pod内无法识别并访问该Sidecar容器。

Pod清单片段

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  # 主应用容器
  - name: nginx-container
    image: nginx:latest
    ports:
      - containerPort: 80
    volumeMounts:
      - name: logs
        mountPath: /var/log/nginx
  # Sidecar容器
  - name: sidecar-container
    image: busybox
    command: ["/bin/sh"]
    args: ["-c", "tail -f /var/log/access.log"]
    volumeMounts:
      - name: logs
        mountPath: /var/log/nginx
  volumes:
    - name: logs
      emptyDir: {}

Sidecar容器日志

能获取到Sidecar的日志，但希望通过调试Pod深入排查：

kubectl logs nginx-pod  -c sidecar-container
tail: can't open '/var/log/access.log': No such file or directory
tail: no files

我故意给Sidecar容器设置了错误路径模拟故障，目的是测试kubectl debug的调试能力。

调试命令及输出

使用以下命令创建调试Pod：

kubectl debug nginx-pod -it --image=busybox:1.28 --share-processes --copy-to=debug-pod

命令输出：

kubectl debug nginx-pod -it --image=busybox:1.28 --share-processes --copy-to=debug-pod
Defaulting debug container name to debugger-qnnf7.
If you don't see a command prompt, try pressing enter.
/ #

Pod状态

k get po               
NAME        READY   STATUS             RESTARTS      AGE
debug-pod   2/3     CrashLoopBackOff   1 (12s ago)   15s
nginx-pod   1/2     CrashLoopBackOff   3 (27s ago)   80s

当前调试进展

能在调试Pod中找到主容器并访问其文件：

/ # 
/ # ps
PID   USER     TIME  COMMAND
    1 65535     0:00 /pause
    7 root      0:00 nginx: master process nginx -g daemon off;
   35 101       0:00 nginx: worker process
   36 101       0:00 nginx: worker process
   37 101       0:00 nginx: worker process
   38 101       0:00 nginx: worker process
   39 101       0:00 nginx: worker process
   40 101       0:00 nginx: worker process
   41 101       0:00 nginx: worker process
   42 101       0:00 nginx: worker process
   49 root      0:00 sh
   61 root      0:00 ps
/ # 
/ # cd proc/7/root/
(unreachable)/ # ls
bin                   docker-entrypoint.d   home                  mnt                   root                  srv                   usr
boot                  docker-entrypoint.sh  lib                   opt                   run                   sys                   var
dev                   etc                   media                 proc                  sbin                  tmp
(unreachable)/ # cat etc/hostname 
debug-pod
(unreachable)/ # cd var/log/nginx/
(unreachable)/var/log/nginx # ls
access.log  error.log
(unreachable)/var/log/nginx # 
(unreachable)/var/log/nginx #

但找不到Sidecar容器，求有效调试该Sidecar的方法，以及是否能在调试Pod中访问Sidecar的文件？

解决方案

1. 为什么看不到Sidecar容器进程？

因为Sidecar容器启动后立即崩溃退出，--share-processes只能共享当前运行中的容器进程，已退出的容器进程不会保留在Pod的进程命名空间里，所以ps命令看不到它。

2. 调试崩溃Sidecar的实用方法

方法一：修改Sidecar启动命令，阻止其退出

直接修改原Pod的Sidecar容器配置，将启动命令改为不会立即退出的形式，比如：

command: ["/bin/sh"]
args: ["-c", "sleep 3600"]

重新创建Pod后，再用kubectl debug连接，就能看到Sidecar的进程并访问它的文件系统。

方法二：用`kubectl debug`直接替换故障Sidecar

使用--target参数指定Sidecar容器，在原Pod中启动一个交互式调试容器，共享Sidecar的命名空间：

kubectl debug nginx-pod -it --image=busybox:1.28 --target=sidecar-container

这个命令会基于Sidecar的镜像和配置启动调试容器，即使原Sidecar崩溃，也能直接查看它的文件结构和运行环境。

方法三：查看Pod事件定位崩溃原因

先检查Pod的事件日志，确认Sidecar崩溃的具体触发条件：

kubectl describe pod nginx-pod

在Events区块会看到容器启动失败的详细原因，结合日志能快速定位问题。

方法四：通过共享卷检查文件状态

Sidecar和主容器共享了logs这个emptyDir卷，可以直接在调试Pod中挂载该卷，检查文件是否存在：
如果调试Pod未挂载该卷，重新创建时指定挂载：

kubectl debug nginx-pod -it --image=busybox:1.28 --share-processes --copy-to=debug-pod --volume-mount=name=logs,mount-path=/tmp/logs

然后查看/tmp/logs目录，确认是否存在access.log文件。

3. 能否访问Sidecar的文件？

如果Sidecar已经退出，无法通过进程命名空间直接访问它的文件系统，但可以通过以下方式间接查看：

拉取Sidecar使用的镜像（如docker pull busybox），本地查看镜像内的文件结构。
若Sidecar挂载了共享卷，通过卷查看它写入的文件（比如上述的logs卷）。
使用kubectl debug --target=sidecar-container启动的调试容器，会继承Sidecar的文件系统和配置，可直接查看相关文件。

内容的提问来源于stack exchange，提问作者Anvesh Muppeda

无法通过kubectl debug调试Kubernetes Pod中的Sidecar容器

Pod清单片段 #

Sidecar容器日志 #

调试命令及输出 #

Pod状态 #

当前调试进展 #

解决方案 #