Istio

📅 2026-04-03 ✏️ 2026-04-03 CS INFRA

1 · Istio#

S - 什么场景：微服务上了 K8s，服务间通信需要治理（路由、灰度、熔断、mTLS、可观测性），即需要 Service Mesh

C - 什么冲突：Service Mesh 是理念，落地需要具体实现。自研成本极高（数据平面代理 + 控制平面 + xDS 协议 + 证书管理 + CRD 体系），且要和 K8s 生态深度集成

Q - 什么问题：用什么方案来落地 Service Mesh？

A - 回答问题：Istio — 最主流的 Service Mesh 实现。控制平面 Istiod + 数据平面 Envoy Sidecar，通过 CRD 声明式管理流量、安全和可观测性

1.1 · 核心架构

详见 Service Mesh 架构

Istiod (控制平面)                    Envoy Sidecar (数据平面)
├── Pilot: 服务发现 + xDS 下发        ├── 流量劫持 (iptables)
├── Citadel: 证书签发 + mTLS          ├── 路由/负载均衡/重试/熔断
└── Galley: 配置校验                  └── 遥测数据上报

1.2 · 流量管理（Istio 最核心的能力）#

S: 服务跑起来了，K8s Service 提供了基本的四层负载均衡 C: K8s Service 只能做简单的轮询转发，无法按 header/权重/版本做七层路由，灰度发布、金丝雀、流量镜像都做不了 Q: 如何实现精细化的七层流量控制？ A: VirtualService + DestinationRule 两个 CRD 配合完成

1.2.1 · VirtualService — 流量怎么走（路由规则）#

定义请求到达某个 host 后如何路由：

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews            # 目标服务
  http:
    - match:
        - headers:
            end-user:
              exact: test-user   # 匹配条件：header
      route:
        - destination:
            host: reviews
            subset: v2           # 测试用户 → v2
    - route:
        - destination:
            host: reviews
            subset: v1
          weight: 90             # 90% → v1
        - destination:
            host: reviews
            subset: v2
          weight: 10             # 10% → v2（金丝雀）

核心能力：

路由匹配：按 URI、header、query param、端口
流量分割：按权重百分比（金丝雀发布）
重试：retries.attempts + retryOn
超时：timeout: 3s
故障注入：fault.delay / fault.abort（混沌测试）
流量镜像：mirror 把流量复制到另一个版本（不影响响应）

1.2.2 · DestinationRule — 流量到了之后怎么处理（目标策略）#

定义到达目标服务后的行为：

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100      # 连接池
      http:
        h2UpgradePolicy: UPGRADE
    outlierDetection:            # 熔断
      consecutive5xxErrors: 5
      interval: 10s
      baseEjectionTime: 30s
  subsets:                       # 定义版本子集
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

核心能力：

subsets：按 Pod label 划分版本子集（VirtualService 引用）
负载均衡：ROUND_ROBIN / LEAST_CONN / RANDOM / PASSTHROUGH
连接池：限制最大连接数、每连接最大请求数
熔断（outlierDetection）：连续错误达阈值 → 驱逐异常实例

1.2.3 · Gateway — 南北向流量入口#

替代 K8s Ingress，管理集群外部流量的入口：

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: my-gateway
spec:
  selector:
    istio: ingressgateway       # 绑定到 IngressGateway Pod
  servers:
    - port:
        number: 443
        name: https
        protocol: HTTPS
      tls:
        mode: SIMPLE
        credentialName: my-cert  # K8s Secret 中的 TLS 证书
      hosts:
        - "api.example.com"

Gateway 定义入口 + TLS，VirtualService 绑定 Gateway 定义路由 → 完整的外部流量管理。

1.2.4 · ServiceEntry — 纳管外部服务#

把集群外部的服务（如外部 API、数据库）注册到 Istio 的服务发现中，使其也能享受路由、重试、熔断等治理能力。

1.3 · 安全

S: 服务间通信在网络上是明文的 C: 微服务数量多、变化快，传统的网络防火墙/ACL 无法跟上节奏 Q: 如何在零信任环境下保障服务间通信安全？ A: mTLS（传输加密）+ PeerAuthentication（认证）+ AuthorizationPolicy（授权）

mTLS 自动化：Istiod 为每个 Pod 签发 SPIFFE 证书，Sidecar 自动完成双向 TLS，业务无感知
PeerAuthentication：控制 mTLS 模式（STRICT / PERMISSIVE / DISABLE），可按 namespace 或 workload 粒度
AuthorizationPolicy：基于身份（ServiceAccount）的访问控制，声明谁能访问谁

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-frontend
  namespace: default
spec:
  selector:
    matchLabels:
      app: backend
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/default/sa/frontend"]
      to:
        - operation:
            methods: ["GET", "POST"]

1.4 · 可观测性

Envoy Sidecar 自动采集所有流量的遥测数据，业务代码零改动：

维度	机制	典型工具
Metrics	Envoy 暴露请求量/延迟/错误率等指标	Prometheus + Grafana
Tracing	Envoy 注入 trace header，上报 span	Jaeger / Zipkin
Logging	Envoy access log	ELK / Loki
拓扑	基于流量数据生成服务调用关系图	Kiali

注意：分布式追踪需要业务代码传播 trace header（如 x-request-id、x-b3-traceid），Istio 不会自动跨进程传播。

1.5 · 实际使用：灰度发布流程

1. 部署 v2 Deployment（少量副本）
2. DestinationRule 定义 subset v1 和 v2
3. VirtualService 设置 weight: 95/5（5% 金丝雀）
4. 观察 Kiali/Grafana 指标
5. 逐步调整 weight: 50/50 → 0/100
6. 下线 v1 Deployment

1.6 · Sidecar 模式的代价#

延迟增加：每次请求多经过两跳 Envoy（~1-3ms）
资源消耗：每个 Pod 多一个 Envoy 容器（~50MB 内存）
调试复杂度：网络问题排查链路变长
Ambient Mesh：Istio 新方向，用 ztunnel（每节点共享代理）替代 Sidecar，减少资源开销