【云原生与DevOps】07-Istio服务网格落地:从试点到全量的踩坑记录 专栏云原生 DevOps难度专家标签Istio服务网格Service Mesh微服务流量治理前言我们团队花了6个月把Istio从试点推到全量踩了很多坑。本文按时间线记录整个过程重点在踩坑和解决方案。一、为什么选 Istio业务痛点微服务数量超过50个服务间调用追踪困难灰度发布需要业务代码配合耦合严重不同语言的服务超时重试策略不统一二、安装# 使用 istioctl 安装推荐可控性强istioctlinstall--setprofileproduction# 开启自动注入kubectl label namespace production istio-injectionenabled# 验证kubectl get pod-nistio-system istioctl analyze-nproduction三、坑记录坑1注入后DNS解析变慢原因Envoy sidecar 拦截了 DNS 请求增加了延迟。解决关闭 DNS 代理或升级到 Istio 1.14DNS 代理性能已优化# 临时禁用DNS代理kubectl annotate pod mypodtraffic.sidecar.istio.io/excludeOutboundPorts53坑2数据库连接被 Istio 断开原因Istio 默认对长连接有10分钟超时。解决配置 DestinationRule 的 connectionPoolapiVersion:networking.istio.io/v1alpha3kind:DestinationRulemetadata:name:mysql-dbspec:host:mysql.production.svc.cluster.localtrafficPolicy:connectionPool:tcp:maxConnections:100connectTimeout:30stcpKeepalive:time:7200sinterval:75s坑3灰度发布权重配置不生效原因VirtualService 和 Service 的 selector 不匹配。解决确保 Pod 的versionlabel 与 DestinationRule 的 subset 一致。四、流量治理配置示例# 金丝雀发布5%流量到新版本apiVersion:networking.istio.io/v1alpha3kind:VirtualServicemetadata:name:myappspec:hosts:-myapphttp:-route:-destination:host:myappsubset:v2weight:5-destination:host:myappsubset:v1weight:95结语Istio非常强大但学习曲线很陡。建议先从单个非核心服务试点充分理解原理后再推广。不要一上来就全量推否则出问题很难排查。