VSCode的Port Forwarding只是单向端口映射，不支持双向代理；要实现本地代码被集群内服务调用，需用telepresence或VSCode 2026内置Debug Proxy，且本地服务必须监听0.0.0.0、端口匹配、环境变量显式注入。
VSCode 里 port-forward 不是双向代理，只是单向端口映射
很多人误以为右键 Pod → Forward Port 就实现了“双向代理”，其实它只是执行 kubectl port-forward，本质是把远程 Pod 的某个端口（比如 8080）在本地监听并转发——仅支持从本地发起连接到 Pod，**不支持从集群内服务反向调用你本地代码**。真正的双向代理需要服务流量重定向能力，不是端口映射能解决的。
要实现“本地代码被集群内其他服务调用”，必须用 Bridge-to-Kubernetes 替代方案
Bridge to Kubernetes 已于 2025 年 4 月 30 日正式退役，但它的核心能力已被开源替代方案继承：目前唯一稳定可用的是 ksync + telepresence 组合，或直接使用 VSCode 2026 内置的 devcontainer.json 中声明式调试代理（Debug Proxy）。
-
telepresence是当前最接近原 Bridge 行为的工具：它会替换集群中目标 Pod 的容器镜像为一个轻量 sidecar，并将该 Pod 的所有入站流量劫持、转发到你本地运行的服务进程 - 启用前提：集群需允许
mutatingwebhookconfiguration，且你有cluster-admin权限部署 operator - VSCode 2026 中，若已安装
ms-vscode.container-debug-proxyfeature，且集群运行了vscode-debug-proxy-operatorv2.1+，则调试启动时自动注入 DebugProxyInstance，该实例默认启用 mTLS 双向通信通道，可被集群内其他服务通过 ClusterIP 直接调用
本地服务暴露给集群的关键配置点
即使用了 telepresence 或 Debug Proxy，仍需注意三个硬性约束：
- 本地服务必须监听
0.0.0.0:<port>，不能只绑127.0.0.1；否则代理无法中转请求 - Pod 的 Service 必须定义明确的
targetPort和port，且与本地服务监听端口一致；否则 telepresence 无法正确路由 - 若本地服务依赖环境变量（如
DATABASE_URL），需在telepresence --env-file .env或devcontainer.json的env字段中显式注入，Kubernetes 原生环境变量不会自动透传
调试时流量路径容易被忽略的环节
真正决定“是否算双向”的，是请求来源和响应路径是否闭环。常见断点失效场景：
- 你在本地启动了服务，也成功运行了
telepresence connect，但集群内其他 Pod 调用失败 → 检查目标 Service 的selector是否仍匹配原 Pod 标签；telepresence 会临时修改标签，需确认 Service selector 是否宽泛到覆盖 injected sidecar - 本地断点命中，但日志里看不到上游调用方 IP → 默认情况下 telepresence 剥离了原始 source IP；如需保留，启动时加
--preserve-host参数（仅限 v2.10+） - VSCode 启动调试后，
DebugProxyInstance状态为Running，但集群内调用超时 → 查看kubectl logs -n vscode-system <proxy-pod-name>，重点找connection refused或no route to host，大概率是本地服务未启动或端口未就绪
双向代理不是开个端口就行的事，它要求本地服务具备生产级可访问性、集群网络策略允许回流、以及代理组件在控制平面和数据平面都完成注册。最容易卡住的地方，永远是本地服务启动时机早于代理建立完成。
