Istio 不是“引入”而是“接管”，因为它不依赖 SDK 或代码侵入，而是通过 Sidecar（Envoy）劫持所有进出流量，并由 VirtualService、DestinationRule 等 CRD 声明治理规则；Golang 服务只需部署在启用 istio-injection 的命名空间、监听 0.0.0.0、使用 Service 名调用，即可被透明接管。
为什么 Istio 不是“引入”而是“接管”服务流量
在 Golang 微服务里加个 istio 包？不行。Istio 本身不提供 SDK，也不侵入应用代码。它通过 Sidecar（默认是 envoy）劫持进出容器的所有网络流量，再靠 VirtualService、DestinationRule 这类 Kubernetes CRD 声明规则。所以所谓“引入”，本质是让服务部署进 Istio 管理的命名空间，并确保 Pod 注入了 Sidecar。
常见错误现象：curl http://orders:8080 在本地能通，进集群后 503；或 grpc.Dial("orders:8080") 直连成功，但用 Istio 流量策略做金丝雀时完全不生效——大概率是没走 Sidecar，或没启用 mTLS 导致 Envoy 拒绝转发。
- 确认命名空间已启用自动注入：
kubectl label namespace default istio-injection=enabled - Golang 服务不要硬编码
localhost:8080或127.0.0.1:8080，Sidecar 只拦截 outbound 到集群 DNS 名（如orders.default.svc.cluster.local）的请求 - 若用 HTTP 客户端，避免设置
http.Transport.Proxy，否则可能绕过 Envoy
如何让 Golang 服务适配 Istio 的健康检查与超时模型
Istio 默认依赖 Kubernetes 的 readinessProbe 和 livenessProbe，但 Envoy 会额外对上游服务做主动健康检查（Outlier Detection），如果 Golang 服务的 HTTP handler 返回慢、或未正确响应 /healthz，Envoy 可能将实例从负载均衡池中踢出，导致 503。
典型表现：istioctl proxy-status 显示某 Pod 的 STATUS 是 NOT HEALTHY；istioctl proxy-config endpoints deploy/orders 中对应 endpoint 状态为 UNHEALTHY。
立即学习“go语言免费学习笔记（深入）”；
- 确保
readinessProbe路径（如/healthz）返回 200 且耗时 - 在
DestinationRule中显式配置outlierDetection，避免默认激进策略误剔节点：outlierDetection: consecutive5xxErrors: 10 interval: 30s baseEjectionTime: 30s
- Golang HTTP server 启动时别忽略
http.Server.ReadTimeout和WriteTimeout，Istio 默认全局超时是 15s，若你的 handler 长期阻塞，Envoy 会在 15s 后断连并重试，引发雪崩
怎样用 VirtualService 实现 Golang 微服务的灰度发布
想把 5% 流量切到 v2 版本的 orders 服务？不能改 Golang 代码里的 URL，得靠 VirtualService 把请求按 header、path 或权重分发到不同 subset。
关键点：subset 必须在 DestinationRule 中先定义，且 label 必须和 Pod 的 metadata.labels 完全一致（比如 version: v2），否则流量永远走不到目标实例。
- 先写
DestinationRule定义 subsets：apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: orders-dr spec: host: orders.default.svc.cluster.local subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 - 再写
VirtualService按权重路由：apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: orders-vs spec: hosts: - orders.default.svc.cluster.local http: - route: - destination: host: orders.default.svc.cluster.local subset: v1 weight: 95 - destination: host: orders.default.svc.cluster.local subset: v2 weight: 5 - 验证是否生效：
istioctl proxy-config routes deploy/orders -o json | jq '.virtualHosts[].routes[].route.cluster'，应看到带orders.default.svc.cluster.local|v1和|v2的 cluster 条目
为什么 Golang gRPC 服务必须开启 TLS 才能走 Istio mTLS
Istio 默认启用 STRICT mTLS，但 gRPC over plaintext（即 grpc.Dial("orders:8080", grpc.WithInsecure())）会被 Envoy 拒绝，报错 connection closed before server preface received 或 transport: authentication handshake failed。
这不是证书问题，而是协议协商失败：Envoy 要求所有内部通信走 TLS，而 gRPC 客户端若未配置 TLS，根本连不上 Envoy 的 8080 端口（它只监听 HTTPS/mTLS）。
- 服务端无需改 Golang 代码，只要 Pod 注入 Sidecar，Envoy 就自动处理 TLS 终止和 mTLS 加密
- 客户端必须用
grpc.WithTransportCredentials(credentials.NewTLS(&tls.Config{}))，哪怕空 config 也行（Istio 提供证书给 Envoy，客户端只需声明支持 TLS） - 检查
DestinationRule是否设置了trafficPolicy.tls.mode: ISTIO_MUTUAL（这是 STRICT mTLS 的等效写法） - 临时调试可降级为 PERMISSIVE：
istioctl authn policy set default --mode PERMISSIVE，但上线前务必切回 STRICT
最常被忽略的是：Golang 服务日志里一切正常，HTTP 接口也通，唯独 gRPC 调不通——八成是客户端没开 TLS，而不是服务没部署好。
