专栏： 云原生 & DevOps
难度： 专家
标签： Istio 服务网格 Service Mesh 微服务 流量治理

前言

我们团队花了6个月把Istio从试点推到全量，踩了很多坑。本文按时间线记录整个过程，重点在踩坑和解决方案。

一、为什么选 Istio

业务痛点：

• 微服务数量超过50个，服务间调用追踪困难
• 灰度发布需要业务代码配合，耦合严重
• 不同语言的服务，超时重试策略不统一

二、安装

# 使用 istioctl 安装（推荐，可控性强）
istioctl install --set profile=production

# 开启自动注入
kubectl label namespace production istio-injection=enabled

# 验证
kubectl get pod -n istio-system
istioctl analyze -n production

三、坑记录

坑1：注入后DNS解析变慢

原因： Envoy sidecar 拦截了 DNS 请求，增加了延迟。
解决： 关闭 DNS 代理或升级到 Istio 1.14+（DNS 代理性能已优化）

# 临时：禁用DNS代理
kubectl annotate pod mypod "traffic.sidecar.istio.io/excludeOutboundPorts=53"

坑2：数据库连接被 Istio 断开

原因： Istio 默认对长连接有10分钟超时。
解决： 配置 DestinationRule 的 connectionPool

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: mysql-db
spec:
  host: mysql.production.svc.cluster.local
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
        connectTimeout: 30s
        tcpKeepalive:
          time: 7200s
          interval: 75s

坑3：灰度发布权重配置不生效

原因： VirtualService 和 Service 的 selector 不匹配。
解决： 确保 Pod 的 version label 与 DestinationRule 的 subset 一致。

四、流量治理配置示例

# 金丝雀发布：5%流量到新版本
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: myapp
spec:
  hosts:
  - myapp
  http:
  - route:
    - destination:
        host: myapp
        subset: v2
      weight: 5
    - destination:
        host: myapp
        subset: v1
      weight: 95

结语： Istio非常强大，但学习曲线很陡。建议先从单个非核心服务试点，充分理解原理后再推广。不要一上来就全量推，否则出问题很难排查。