关于服务网格实战的几点记录
这次项目需要引入服务网格，从评估到落地，花了不少时间。
中间踩过的坑，有些还挺典型。
为什么需要 Service Mesh
微服务架构下，有几个问题变得复杂：
服务间通信：HTTP 调用、重试、超时这些逻辑分散在每个服务里
安全问题：服务间的 mTLS 加密，证书管理复杂
可观测性：分布式追踪、监控告警需要统一的方案
流量管理：灰度发布、故障注入、金丝雀发布
Service Mesh 在服务网格层统一解决这些问题，业务代码无需改动。
Istio 部署
准备工作
# 确保集群版本兼容
kubectl version --short
# 安装 istioctl
curl -L https://istio.io/downloadIstio | sh -
# 验证安装
istioctl version
安装 Istio
# 安装 Istio
istioctl install --set profile=demo -y
# 等待安装完成
kubectl get pod -n istio-system
安装完成后，istio-system 命名空间下会有多个 Pod：
- istiod：控制平面
- istio-proxy：数据平面代理
- istio-ingressgateway：入口网关
自动注入 Sidecar
给需要注入 Sidecar 的命名空间打标签：
kubectl label namespace default istio-injection=enabled
之后在这个命名空间创建的 Pod 会自动注入 Sidecar 代理。
流量管理实战
金丝雀发布
新版本只让部分用户访问，逐步扩大比例。
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: myservice
spec:
hosts:
- myservice
http:
- match:
- headers:
x-canary:
exact: "true"
route:
- destination:
host: myservice
subset: v2
weight: 100
- route:
- destination:
host: myservice
subset: v1
weight: 100
给 1% 的用户加上 x-canary: true 的 Header，就能访问新版本。
故障注入
测试服务的容错能力，主动注入故障。
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: myservice
spec:
hosts:
- myservice
http:
- fault:
delay:
percentage:
value: 10
fixedDelay: 5s
route:
- destination:
host: myservice
subset: v1
10% 的请求会有 5 秒延迟。
超时和重试
apiVersion: networking.iaas.io/v1alpha3
kind: DestinationRule
metadata:
name: myservice
spec:
host: myservice
trafficPolicy:
connectionPool:
tcp:
maxConnections: 100
loadBalancer:
simple: ROUND_ROBIN
outlierDetection:
consecutive5xxErrors: 5
interval: 30s
baseEjectionTime: 30s
timeout: 10s
安全配置
mTLS 启用
Istio 默认启用了 mTLS，但需要配置证书。
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
spec:
mtls:
mode: STRICT
STRICT 模式下，服务间必须通过 mTLS 通信。
可观测性
分布式追踪
Istio 会自动收集追踪数据，配合 Jaeger 或 Zipkin。
# 配置 Jaeger
apiVersion: v1
kind: Service
metadata:
name: tracing
namespace: istio-system
spec:
ports:
- port: 9411
protocol: TCP
监控指标
Prometheus 会自动从 Istio 收集指标：
# Prometheus 配置
scrape_configs:
- job_name: 'istio-mesh'
kubernetes_sd_configs:
- role: pod
namespaces:
names:
- istio-system
踩过的坑
坑一：资源消耗
每个 Pod 都有一个 Sidecar，资源消耗明显增加。
# 查看代理资源使用
kubectl top pod -n <namespace> -c istio-proxy
解决：
- 调整 Sidecar 的资源限制
- 对延迟敏感的服务 bypass Proxy
坑二：性能延迟
虽然 Istio 性能在不断提升，但仍然有一定延迟。
解决：使用 Permissive 模式降低延迟，或对关键路径 bypass
坑三：配置复杂
Istio 的配置确实复杂，VirtualService、DestinationRule、ServiceEntry 等概念多。
解决：
- 先用简单的配置，逐步增加复杂度
- 建立配置模板，复用经验
写在最后
Service Mesh 这东西，解决了微服务的很多问题，但也不是万能的。
适合用的场景：
- 微服务数量多（>10 个）
- 服务间通信复杂
- 对安全、可观测性要求高
- 团队有 Kubernetes 和 Istio 经验
不适合用的场景：
- 服务数量少
- 团队规模小
- 对延迟极其敏感
选型之前先评估清楚，Service Mesh 的成本和价值是否匹配。
这次 Istio 部署花了半个月，中间经历过配置错误、资源浪费等问题。但部署完成后，服务间通信、故障注入这些功能确实很有用。
版权声明: 本文首发于 指尖魔法屋-关于服务网格实战的几点记录（https://blog.thinkmoon.cn/post/54-service-mesh-practice-istio-traffic-management/） 转载或引用必须申明原指尖魔法屋来源及源地址！
评论
使用 GitHub 账号登录后即可留言，支持 Markdown。