云原生进阶（01）：Service Mesh——Istio 数据面/控制面、sidecar、流量治理、安全

更新时间：2026-09-01。本文是 cloud/mesh/ 云原生进阶第 01 篇，在 Mesh 索引下。Service Mesh 把服务间通信从应用层剥离到基础设施层，通过 sidecar 代理实现流量管理、安全、可观测性，应用代码不需要修改。

本文要回答的问题

• Service Mesh 是什么？解决了什么问题？
• Istio 架构：数据面和控制面分别做什么？
• sidecar 怎么注入到 Pod？
• 流量治理：流量分割、熔断、超时、重试？
• mTLS 怎么实现服务间安全通信？

一、Service Mesh 是什么？

没有 Service Mesh：
┌───────────────┐
│   应用 A      │
│  ┌─────────┐ │
│  │ 服务发现 │ │  ← 应用代码需要处理服务发现、重试、超时
│  │ 负载均衡 │ │
│  │ 熔断    │ │
│  └─────────┘ │
└──────┬───────┘
       │
┌──────▼───────┐
│   应用 B      │
└──────────────┘

有 Service Mesh（Istio）：
┌──────────────────────┐
│   应用 A             │
│  ┌─────────┐  ┌───┐ │
│  │ 业务代码 │  │P  │ │  ← 业务代码不需要处理网络
│  │ 只关心业务│  │I  │ │     流量由 sidecar 代理处理
│  └─────────┘  │S  │ │
│               │I  │ │
│               │C  │ │
│               │O  │ │
│               │   │ │
│               │高  │ │
│               └───┘ │
└──────────────────────┘

Service Mesh 解决的问题：

• 服务发现和负载均衡（不需要应用代码实现）
• 流量管理（蓝绿、金丝雀、流量分割）
• 熔断、超时、重试、限流
• 安全（mTLS 服务间加密）
• 可观测性（调用链、指标、日志）

二、Istio 架构

Istio 架构：
┌─────────────────────────────────────────────────────┐
│      控制面（Control Plane）— istiod                │
│  ┌──────────────┐  ┌──────────────┐               │
│  │ Pilot        │  │ Citadel      │               │
│  │ (服务发现/流量) │  │ (证书管理)    │              │
│  └──────────────┘  └──────────────┘               │
│  ┌──────────────┐  ┌──────────────┐               │
│  │ Galley       │  │ 配置管理      │              │
│  └──────────────┘  └──────────────┘               │
└─────────────────────────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────┐
│      数据面（Data Plane）— Envoy Proxy              │
│  ┌──────────────┐  ┌──────────────┐               │
│  │ Pod A        │  │ Pod B        │               │
│  │ 业务容器      │  │ 业务容器      │              │
│  │ Envoy sidecar│  │ Envoy sidecar│              │
│  └──────────────┘  └──────────────┘               │
└─────────────────────────────────────────────────────┘

控制面（istiod）：

• Pilot：服务发现，流量管理规则下发
• Citadel：证书签发，mTLS 密钥管理
• Galley：配置验证和管理

数据面（Envoy）：

• 每个 Pod 一个 Envoy sidecar
• 处理所有进出 Pod 的流量
• 实现负载均衡、熔断、重试、指标收集

三、Sidecar 注入

# Istio 自动注入 sidecar
# 给 namespace 打标签
kubectl label namespace default istio-injection=enabled

# 之后在该 namespace 创建 Pod 时，Istio 自动注入 sidecar
# 注入后 Pod 有两个容器：业务容器 + istio-proxy

# 手动注入
istioctl kube-inject -f deployment.yaml | kubectl apply -f -

Sidecar 工作原理：

1. Pod 创建时，mutating webhook 拦截请求
2. Istio 注入 init 容器（设置 iptables 规则）+ sidecar 容器
3. Init 容器在业务容器启动前运行，设置 iptables 规则
4. iptables 规则：所有进出 Pod 的流量转发到 Envoy
5. Envoy 根据控制面下发的配置处理流量

四、流量治理

# 流量分割：可以按百分比切分
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-app
spec:
  hosts:
    - my-app
  http:
    - route:
        - destination:
            host: my-app
            subset: v1
          weight: 90
        - destination:
            host: my-app
            subset: v2
          weight: 10

# 超时和重试
spec:
  http:
    - timeout: 5s  # 请求超时
      retries:
        attempts: 3
        perTryTimeout: 2s
        retryOn: gateway-error,connect-failure
      route:
        - destination:
            host: my-app

# 熔断
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: my-app
spec:
  host: my-app
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 10
        maxRequestsPerConnection: 10
    outlierDetection:
      consecutive5xxErrors: 5   # 连续 5 次 5xx 熔断
      interval: 30s
      baseEjectionTime: 60s     # 熔断持续 60 秒
      maxEjectionPercent: 50    # 最多熔断 50% 的实例

五、mTLS 安全

# 服务间 mTLS 加密通信
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: default
spec:
  mtls:
    mode: STRICT  # 严格模式：所有服务间必须 mTLS 加密

mTLS 模式：

• DISABLE：禁用 mTLS
• PERMISSIVE：兼容模式，接受加密和明文（迁移时用）
• STRICT：严格模式，只接受加密（生产环境推荐）

mTLS 好处：

• 服务间通信加密，防止中间人攻击
• 自动证书轮换，不需要手动管理证书
• 和 Kubernetes ServiceAccount 集成

六、可观测性

# 启用 Istio 指标
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: mesh-default
  namespace: istio-system
spec:
  metrics:
    - providers:
        - name: prometheus

Istio 提供的可观测性：

• 指标：请求数、延迟、错误率（Prometheus + Grafana）
• 调用链：分布式追踪（Jaeger/Zipkin）
• 访问日志：请求日志（Kiali 可视化展示）

七、常见坑对照

坑	现象	对策
sidecar 注入失败	Pod 只有业务容器，没有 istio-proxy	检查 namespace 标签，重启 Pod
请求延迟增加	多了 sidecar 代理，RT 增加	调整 sidecar 资源配置，优化 iptables
mTLS 通信失败	服务间调用报错	先用 PERMISSIVE 模式，确认后再改 STRICT
流量分割不准	灰度比例不对	检查 VirtualService 和 DestinationRule 配置

相关与延伸

下一篇：容器性能与排障——容器 CPU/内存限制生效、kubelet 日志、coredns 问题、集群性能；K8s 核心概念，见 K8s 核心概念。

一句话总结

Service Mesh（Istio）：控制面 istiod 下发配置（Pilot 服务发现、Citadel 证书、Galley 配置），数据面 Envoy sidecar 代理处理所有进出流量；sidecar 通过 iptables 规则拦截流量，应用代码不需要修改；流量治理：VirtualService 配置流量分割、超时、重试，DestinationRule 配置熔断策略；mTLS 在 STRICT 模式下服务间通信强制加密，自动证书管理；可观测性指标（Prometheus）+ 调用链（Jaeger）+ 可视化（Kiali）。