telepresence 连不上集群或 intercept 失败，主因是 k8s 上下文配置错误、serviceaccount 权限不足、端口/dns 冲突及拦截规则不匹配；需逐项验证 kubectl 连通性、rbac、go 绑定地址、host 头、dns 代理与 intercept 参数。
Telepresence 连不上集群时 telepresence connect 卡住或报错
常见现象是命令长时间无响应，或报错类似 Failed to connect to cluster: context deadline exceeded。本质是 Telepresence 无法访问 K8s API Server 或本地 kubeconfig 配置有误。
- 先确认
kubectl get ns能正常返回，否则 Telepresence 必然失败——它底层完全依赖kubectl的认证与连接能力 - 检查当前 context 是否指向目标集群：
kubectl config current-context；若用的是kubectx切换过，确保没残留 alias 或 shell 函数干扰 - Telepresence v2 默认走
root用户的~/.kube/config，如果你用sudo telepresence connect，它会读/root/.kube/config，而你的kubectl可能配在普通用户下，导致“能 kubectl 但连不上 Telepresence” - 某些企业集群禁用了
ServiceAccount的impersonate权限，Telepresence v2 启动代理时需要该权限，报错里若含user "system:serviceaccount:default:telepresence"和impersonate，就得让集群管理员加 RBAC
Go 服务启动后被 Telepresence 强制注入 sidecar 导致 panic
Telepresence 默认启用 --mount 并注入 traffic-manager sidecar，而 Go 程序若监听 localhost:8080、又没设 SO_REUSEPORT，就可能和 sidecar 抢端口，或者因 DNS 解析行为突变（如 127.0.0.11 不可用）直接 panic。
- 本地 Go 服务改用
0.0.0.0:8080启动，避免绑定 localhost 后被 sidecar 拦截或冲突 - 禁用自动挂载：启动时加
--mount=false，这样不注入 sidecar，只做流量劫持，对 Go 进程零侵入 - 如果必须用
--mount=true（比如要调试 DNS 或 TLS 流量），务必在 Go 代码里显式设置http.Server.Addr = ":8080"，不要依赖localhost；同时检查os.Getenv("TELEPRESENCE_ROOT")是否存在，可据此判断是否在 Telepresence 环境中做适配 - Go 的
net/http默认使用系统 DNS，Telepresence 修改了/etc/resolv.conf，若服务内硬编码了127.0.0.11（旧版 CoreDNS 地址），会解析失败——应统一用域名访问其他服务，让 Telepresence 自动转发
telepresence intercept 后请求 503 或超时
这不是 Go 代码问题，而是拦截规则没匹配上流量路径。Telepresence 不会自动转发所有请求，它靠 HTTP Host / path 或 gRPC service name 匹配，匹配失败就回退到集群原服务，而原服务可能没启动或健康检查失败，于是返回 503。
- 拦截前先确认目标服务在集群中是
Running且Ready：kubectl get pod -n <ns> -l app=<your-app></your-app></ns> - 拦截命令必须指定完整 service 名和 namespace：
telepresence intercept <service-name> --namespace <ns> --port 8080:8080</ns></service-name>；漏掉--namespace就会去 default 下找，大概率找不到 - Go 服务若用 Gin/Echo 等框架，HTTP Host 头默认是
localhost，但集群 Service 的 Host 往往是myapp.default.svc.cluster.local，Telepresence 默认按 Host 匹配，所以得加--host <service-name>.<ns>.svc.cluster.local</ns></service-name>显式指定 - 本地启动 Go 服务后，用
curl -H "Host: myapp.default.svc.cluster.local" http://localhost:8080/health测试，而不是直接curl http://localhost:8080，否则流量根本进不了 intercept
本地 Go 服务调用其他 K8s 服务时 DNS 解析失败
这是最隐蔽的问题：你本地 Go 进程能跑、能接请求，但一调用 redis.default.svc.cluster.local 就超时。Telepresence 的 DNS 劫持只对 intercept 中声明的服务生效，其他服务默认走宿主机 DNS，而宿主机显然解析不了 .svc.cluster.local。
- 运行
telepresence status，确认输出里有DNS: active；没有的话说明 DNS 代理没起来，需重连或检查/etc/resolv.conf是否被覆盖 - Go 程序里别用
net.LookupIP手动解析，直接用http.Client发请求，让 Go 底层走 cgo resolver 或 Go 自带 resolver（需开启GODEBUG=netdns=cgo）配合 Telepresence 的 DNS 代理 - 如果必须手动解析，用
net.DefaultResolver.LookupHost(context.Background(), "redis.default.svc.cluster.local")，它会尊重系统 DNS 配置；避免用net.LookupHost（走纯 Go resolver，绕过系统配置） - 某些 Linux 发行版（如 Ubuntu 22.04）用 systemd-resolved，会把
/etc/resolv.conf指向127.0.0.53，Telepresence 无法接管这个地址——此时需临时改用nameserver 127.0.0.11，或在 Telepresence 启动前执行sudo systemd-resolve --set-dns=127.0.0.11 --interface=lo
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
