Linkerd可零代码接入Go应用，关键在Kubernetes配置：需先验证控制平面就绪（linkerd check），再通过命名空间注解或手动注入启用sidecar；须显式声明容器端口、避免健康探针被proxy拦截、使用标准DNS服务名并注意HTTP客户端兼容性。
Go 应用本身不需要改一行代码就能接入 Linkerd，关键在 Kubernetes 部署配置是否正确 —— 错误常出在注入没生效、端口不一致、或健康探针干扰 proxy 启动。
确认 Linkerd 控制平面已就绪
Linkerd sidecar 注入依赖控制平面正常运行，不是“装完 CLI 就算完”。必须先验证 control plane 是否 ready：
- 运行
linkerd check，所有项（尤其是control-plane-version和linkerd-identity）都应显示 ✅；若报linkerd-controller: no running pods，说明linkerd install | kubectl apply -f -没成功或被 RBAC 拦截 -
linkerd check --proxy会检查数据平面能力，但仅在已有注入的 Pod 上才有意义，别提前跑 - 常见坑：集群启用了 PodSecurityPolicy 或 PSP 替代方案（如 PodSecurity Admission），导致 linkerd-proxy 容器因非 root 用户或 seccomp 策略被拒绝启动
让 Go 应用 Pod 自动注入 linkerd-proxy
注入不是靠改 Go 代码，而是靠 Kubernetes 资源上的注解或命名空间级开关。两种方式选其一即可，推荐后者用于生产环境：
- 命名空间自动注入：
kubectl annotate namespace default linkerd.io/inject=enabled，之后该 namespace 下所有新创建的 Pod（含 Deployment 触发的）都会注入 - 手动注入（调试用）：
kubectl get deploy go-app -o yaml | linkerd inject - | kubectl apply -f -，适合快速验证，但不适用于 CI/CD 流水线 - 必须确保你的 Go 应用容器监听的端口（如
8080）在 Deployment 的containers[].ports[].containerPort中显式声明，否则 linkerd-proxy 无法识别流量方向，可能导致 503 或连接拒绝
验证注入是否真正生效
光看 kubectl get pods 显示两个容器不等于 sidecar 正常工作。要确认三件事：
- Pod 状态为
Running且READY是2/2（不是1/2）；若长期卡在1/2，大概率是 linkerd-proxy 初始化失败，查kubectl logs <pod-name> -c linkerd-proxy</pod-name> - 执行
kubectl get pod <pod-name> -o jsonpath='{.metadata.annotations.linkerd\.io/created-by}'</pod-name>，输出应类似stable-2.12.4，说明注入器确实参与了创建 - 进容器抓包验证：
kubectl exec -it <pod-name> -c go-app -- sh -c "apk add -U tcpdump && tcpdump -i lo port 4143"</pod-name>（4143 是 linkerd-proxy 的 inbound 端口），有流量进出才代表代理链路通
Go 应用需注意的兼容性细节
Linkerd 默认透明接管所有 outbound 流量，但某些 Go 行为会绕过它，导致指标缺失或 mTLS 失效：
- 避免硬编码
http://service-name:port，改用 DNS 名称（如http://backend.default.svc.cluster.local:8080），否则请求可能走 hostNetwork 或 bypass proxy - HTTP 客户端不要设置
Transport.Proxy = http.ProxyFromEnvironment，Linkerd 不依赖系统代理变量；更不要手动配置http.Transport.DialContext去连 localhost:4140（outbound proxy 端口），这会破坏重试和指标采集 - 健康探针（
livenessProbe/readinessProbe）若指向/healthz且 Go 服务未做特殊处理，linkerd-proxy 会拦截并返回 404（因路径未配置路由），建议 probe 使用exec方式或明确暴露一个不被 proxy 拦截的端口
最易被忽略的是：Linkerd 的超时和重试策略默认作用于 HTTP 状态码，如果你的 Go 服务返回了 2xx 以外的业务错误码（比如 422），而你又依赖 Linkerd 的重试预算，那这些请求不会被重试 —— 这需要你在服务端统一用 5xx 标识可重试失败，或在 Linkerd 的 route config 中显式定义重试条件。
