istio sidecar注入失败的常见原因包括命名空间未启用istio-injection=enabled标签、pod模板缺少匹配injector matchlabels的标签、存在sidecar.istio.io/inject: "false"注解、net_admin权限被禁用、injector日志报错、helm部署中webhook未启用或ca证书未被信任。
Go 微服务接入服务网格不是“要不要做”，而是“怎么轻量、可控地做”——Istio 全量部署常带来资源开销和调试复杂度，而纯自研又容易重复造轮子。实际落地时，**用 Go 编写 Sidecar 插件 + Istio 控制平面协同**，是最平衡的选择。
Sidecar 注入失败：Istio 自动注入不生效的常见原因
你执行了 istioctl install 并给命名空间打了 istio-injection=enabled 标签，但 Pod 里始终没有 istio-proxy 容器。
- 检查 Pod 的
spec.template.metadata.labels是否包含与istio-sidecar-injector的matchLabels一致的标签（如app: my-service）；仅 namespace 标签不够，Pod 模板必须显式携带匹配标签 - 确认 Pod 创建时未设置
sidecar.istio.io/inject: "false"或securityContext中禁用了NET_ADMIN权限（iptables 注入依赖该 capability） - 查看 injector 日志：
kubectl logs -n istio-system deploy/istio-sidecar-injector，重点搜failed to inject或no matching policy - 若用 Helm 部署 Istio，确保
values.sidecarInjectorWebhook.enabled=true，且 webhook cert 已被 API server 信任（kubectl get mutatingwebhookconfigurations看clientConfig.caBundle是否非空）
Go 服务如何避免被 Envoy 拦截内部健康检查
你的 Go HTTP 服务自带 /healthz，但 Istio 默认劫持所有端口流量，导致健康探针被转发到上游或超时失败。
- 在 Deployment 的容器 spec 中显式声明
readinessProbe和livenessProbe的httpGet.port，并确保该端口不在traffic.sidecar.istio.io/includeInboundPorts注解中（默认是*） - 更稳妥的做法：为健康端点单独开一个不劫持的端口（如
8081），并在 Pod annotation 中排除它：traffic.sidecar.istio.io/excludeInboundPorts: "8081" - 或者用 Istio 的
SidecarCRD 显式定义 inbound 流量白名单：port: number: 8080 protocol: HTTP，不列健康端口 - 注意：Go 的
http.Server若启用了ReadHeaderTimeout或IdleTimeout，需比 kube-probe 的timeoutSeconds更宽松，否则 Envoy 可能提前断连
VirtualService 路由权重不生效：Go 服务返回 503 的真实原因
你配置了 weight: 90 / weight: 10 的 VirtualService，但实际流量几乎全打到 v1，v2 偶尔 503。
- 先验证
DestinationRule中subsets的labels是否与 v2 Pod 的实际 label 完全一致（大小写、拼写、多余空格都算错）；version:v2和version: v2是两个不同 subset - v2 Pod 必须处于
Ready状态且通过 readiness probe；Istio 只将流量路由到 endpoints 列表中的实例，kubectl get endpoints my-service -o wide查看 v2 是否在列表里 - 检查 v2 服务是否监听了正确端口（如
containerPort: 8080），且 Service 的targetPort与之匹配；Envoy 会按 endpoint IP+port 建连，端口错则直接 503 - Go 服务若用了自定义 HTTP handler 但没处理
Connection: close或复用底层连接，可能触发 Envoy 的连接池异常；建议在 Go 中显式设置http.Transport.MaxIdleConnsPerHost = 100
用 Go 实现轻量级策略插件替代 Istio Mixer（已废弃）
Istio 1.5+ 移除了 Mixer，但你仍需要在 Sidecar 层做请求级限流或 header 注入——不必重写 Envoy，而是用 Go 写一个 sidecar-adjacent 的本地代理。
- 启动一个独立 Go 进程监听
127.0.0.1:8082，接收来自 Envoy 的转发请求（Envoy 的route配置指向该地址） - 在 Go 中解析
X-Request-ID、Authorization等 header，调用本地限流器（如golang.org/x/time/rate）或动态路由逻辑 - 关键点：Go 代理必须透传原始 Host header（
req.Host = r.Header.Get("Host")），否则后端服务无法正确生成绝对 URL - 性能瓶颈通常在 JSON 解析和 goroutine 泄漏；避免在 handler 中做阻塞 IO，用
context.WithTimeout包裹所有下游调用
真正难的不是写路由规则，而是让 Go 服务和 Envoy 在连接生命周期、超时传递、header 处理上达成默契——这些细节不会报错，只会让 1% 的请求慢 3 秒，然后默默失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
