断点不命中主因是路径映射错误，需严格匹配localroot（本地项目路径）与remoteroot（容器内绝对路径），并确保进程监听0.0.0.0、端口透传正确、源码与运行代码一致。
直接在 Kubernetes 集群里用 VSCode 打断点调试，不是“连上容器就行”，而是要让本地调试器能真正触达 Pod 里运行的进程，并准确映射源码位置。核心前提是：调试端口得通、进程得在监听、路径得对得上。
为什么断点不命中？重点查 localRoot 和 remoteRoot 映射
这是最常被忽略的环节。VSCode 的 attach 模式靠路径映射来定位源码行，一旦容器内代码路径（如 /app/main.go）和你本地打开的项目路径（如 /Users/me/my-project/main.go）不一致，断点就永远不触发。
- Node.js / Python / Go 等语言的调试配置中，
localRoot指你本地 VSCode 打开的工程根目录；remoteRoot是容器内应用实际运行时的绝对路径 - 如果 Pod 内应用是用
CMD ["node", "src/index.js"]启动，且工作目录是/app，那remoteRoot就得设成/app，不能写成/或留空 - 某些场景下（比如你本地直接编辑的是编译前源码，而容器里跑的是构建后产物），必须显式设置这两项；但若你本地打开的就是原始项目、容器也挂载了相同结构的代码（如用
volumeMounts绑定源码），则通常可省略——此时 VSCode 会按文件哈希或相对路径自动匹配 - 开启
"trace": true查看调试器日志，里面会明确打印 “Breakpoint set at … but no matching file found” 这类提示
kubectl port-forward 是最轻量可靠的端口透传方式
它不依赖额外组件，只要 kubectl 能访问集群，就能把 Pod 里的调试端口暴露到本地 localhost。适合单服务调试、CI/CD 测试环境联调等场景。
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
- 先确认 Pod 内进程已启用调试：Node.js 加
--inspect=0.0.0.0:9229，Go 用dlv exec --headless --listen=:40000，Python 用debugpy监听0.0.0.0:5678 - 确保容器 YAML 中声明了对应
containerPort，否则 kubelet 可能拦截连接 - 执行命令：
kubectl port-forward pod/my-app-5c7b9d4f8-xyz12 9229:9229（注意顺序：本地端口在前，Pod 端口在后） - VSCode 的
launch.json必须用"request": "attach"，"port"填本地转发端口（如 9229），"address"填"localhost" - 别在后台长期挂着
port-forward进程——它不自动重连，Pod 重启后会断，需手动重启命令
用 telepresence 调试需要跨 Service 调用的 Pod
当你调试的服务要主动调用集群内其他 Service（比如访问 redis.default.svc.cluster.local），仅靠 port-forward 不够，因为本地网络看不到集群 DNS 和内部服务地址。
-
telepresence connect会注入一个本地代理，把你的机器“接入”集群网络，所有*.svc.cluster.local域名、ClusterIP、NodePort 都可直连 - 它不替换容器，也不改 Deployment，只在本地建立隧道，适合开发阶段快速验证服务间交互逻辑
- 启动后，你可以像调试本地进程一样用 VSCode attach 到
localhost:40000，同时代码里调用其他 Service 的请求也会走真实集群链路 - 注意权限：首次运行可能提示安装
sudo权限的 network driver，Mac 上还需允许“完全磁盘访问” - 退出时务必运行
telepresence quit，否则本地 DNS 解析可能持续污染
VSCode 2026 的 container-debug 特性仍需谨慎对待
虽然 VSCode 2026 宣称支持“零配置 DevContainer 热插拔”和“eBPF 进程跟踪”，但它对 Kubernetes 的原生支持仍处于实验阶段，尤其在多命名空间、非 containerd 运行时（如 CRI-O）、或启用了 seccomp/AppArmor 的 Pod 中容易失败。
- 其
devContainer.json的ms-vscode.container-debugfeature 本质还是依赖dlv或vsdbg-lite注入，不是真免调试器 - 文档中提到的“跨容器断点联动”需服务间传递 OpenTelemetry traceID，且所有服务都得用兼容 SDK，生产环境未必满足
- 如果你用的是 Kind / Minikube 等本地集群，它可能表现良好；但对接 EKS / AKS / GKE 时，建议优先回归
kubectl port-forward+ 手动launch.json方案，稳定性更高
路径映射错一位、容器没监听 0.0.0.0、port-forward 端口写反、忘记删掉生产镜像里的 dlv ——这些细节比选哪个工具更决定成败。调试器不会替你读 Pod 日志，先 kubectl logs 确认进程起来了，再动手配 VSCode。
