服务网格Istio基础介绍

Istio介绍

Istio是一个开源的服务网格(Service Mesh)产品，专为微服务架构设计，用于透明地管理服务间的通信、安全、监控和流量策略。Istio通过Sidecar拦截并控制服务间的所有流量，将复杂的微服务治理(如流量管理、安全策略)从业务代码中剥离，并下沉到基础设施层，使开发者更专注于业务逻辑，以提升开发效率。

Istio几乎无需更改任何代码就可以实现如下功能:

  • 双向TLS加密
  • HTTP、gRPC、WebSocket和TCP流量的自动负载均衡
  • 错误重试、故障转移和故障注入等
  • 访问控制、限流、认证、鉴权等
  • 可观测性指标、链路追踪、日志等
  • 集群内入口和出口的流量管理

Istio平台架构

Istio从逻辑上分为数据平面和控制平面：

  • 控制平面：Control Plane负责管理和配置数据平面的流量策略，由管理员创建的Istio资源会解析成相关的配置下发到数据平面
  • 数据平面：Data Plane负责拦截并处理所有入站(Inbound)和出站(0utbound)流量，用来执行由控制平面下发的策略比如路由、负载均衡、重试、熔断、TLS加密等，同时数据平面还可以收集流量指标、日志和追踪数据，并发送给监控系统。

数据平面在Istio 1.22版本后，分为了Sidecar和Ambient两种模式：

  • Sidecar模式：此模式会为集群中启动的每个Pod都部署一个Envoy代理，或者为在虚拟机上运行的服务并行运行一个Envoy代理
  • Ambient模式：此模式在每个节点上启动一个四层代理，也可以为每个命名空间启动一个Envoy代理实现七层功能代理

两种模式对比：

在生产环境还是推荐使用Sidecar模式。

Istio Sidecar架构

Istio控制平面组件介绍

在 Kubernetes 环境中，Istio 的控制平面正是以 Pod 的形式 运行在 istio-system 命名空间下的（通常是一个名为 istiod 的 Deployment）。

早期的 Istio（1.5 之前）将控制平面拆分成了多个独立的微服务 Pod。为了降低维护复杂度和资源消耗，现代 Istio 将这些功能整合进了一个统一的单体二进制程序 —— istiod 。

Istiod为Istio的控制平面，提供服务发现、配置、证书管理、加密通信和认证。早期的Istio控制平台并没有Istiod这个容器，而是由Mixer(新版本已废弃)、Pilot、Citadel共同组成，后来为了化Istio的架构，将其合并为Istiod，所以对于新版本的Istio(v1.5+)，部署后仅能看到Istiod一类Pod。

🧭 Pilot（服务发现与流量管理）：

  • 监听 Kubernetes 的 Service、Endpoints 以及 Istio 的路由规则（如 VirtualService）。
  • 将高层路由策略转化为 Envoy 能理解的配置，通过 xDS 协议 动态下发给各个数据平面代理。
  • 主要用于监听APIServer，动态获取集群中Service和Endpoints信息，并将配置的路由规则、负载均衡策略转换为Envoy可理解的配置并下发至各个Sidecar中

🔐 Citadel（安全与身份凭证）：

  • 充当内置的证书颁发机构（CA）。
  • 负责签发、轮换密钥与证书，为每个 Pod 分配 SPIFFE 身份标识，实现数据平面的双向 mTLS 加密通信。
  • 主要用于提供强大的服务与服务之间的最终用户身份验证可用于升级服务网格中未加密的流量，实现双向TLS加密

📋 Galley（配置验证与分发）：

  • 监听用户提交的 Istio 自定义资源（CRD），负责语法的合法性校验与统一格式化。
  • 负责配置管理的组件，用于验证配置信息的格式和正确性。Galley使用网格配置协议(Mesh Configuration Protocol)和其它组件进行配置的交互。

💉 Sidecar Injector（自动注入控制器）：

  • 充当 Kubernetes 的准入控制器（Webhook）。
  • 当检测到带有特定标签的 Pod 创建时，自动在 Pod 中注入 istio-init（配置 iptables）和 istio-proxy（Envoy 容器）。

Istio数据平面组件介绍

Istio的数据平面使用的是Envoy，Envoy是用C++开发的高性能代理，用于调解服务网格中所有服务的所有入站和出站流量。Envoy代理是唯一一个与数据平面流量交互的Istio组件，并以Sidecar的方式注入到网格中的每一个Pod中。

主要提供以下功能：

  • 动态服务发现
  • 负载均衡
  • HTTP/2 & gRPC代理
  • 熔断器
  • 监控检查
  • 基于百分比流量拆分的灰度发布
  • 故障注入
  • 丰富的度量指标

Istio核心资源介绍

DestinationRule资源

DestinationRule（简称 DR）是 Istio 流量管理中的核心 CRD 之一， DestinationRule（DR） 的作用就是 “到达目的地之后的策略控制”（负责定义流量到达目标服务后，具体如何负载均衡、如何分组、连接池大小、异常实例驱逐以及是否开启 TLS 加密）。

使用场景：

  • 版本划分：根据pod的标签划分同一个服务的不同版本
  • 负载均衡策略：支持配置各种负载均衡算法(例如：轮询，随机，最少请求/连接)
  • 熔断器：支持配置最大连接数、熔断等

配置示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews-dr
  namespace: prod
spec:
  # 作用的目标服务：FQDN 全限定域名、短域名或 Service 名
  host: reviews.prod.svc.cluster.local

  # 全局流量策略（对当前 host 下所有没有覆盖策略的 subset 生效）
  trafficPolicy:
    # 1. 负载均衡策略
    loadBalancer:
      simple: ROUND_ROBIN

    # 2. 连接池管理（限流/保护）
    connectionPool:
      tcp:
        maxConnections: 1024
        connectTimeout: 30ms
      http:
        http1MaxPendingRequests: 100
        maxRequestsPerConnection: 10

    # 3. 熔断与异常检测（剔除不健康的 Pod）
    outlierDetection:
      consecutive5xxErrors: 3          # 连续出现 3 次 5xx 错误
      interval: 10s                    # 每 10 秒检测一次
      baseEjectionTime: 30s            # 首次驱逐 30 秒
      maxEjectionPercent: 50           # 最多驱逐 50% 的实例，防止雪崩

    # 4. 安全认证（网格内自动 mTLS）
    tls:
      mode: ISTIO_MUTUAL

  # 5. 子集划分（版本隔离）
  subsets:
  - name: v1
    labels:
      version: v1
    # 可以在 subset 级别覆盖全局的 trafficPolicy
    trafficPolicy:
      loadBalancer:
        simple: LEAST_REQUEST

  - name: v2
    labels:
      version: v2

  - name: v3
    labels:
      version: v3

VirtualService资源

VirtualService（虚拟服务，简称 VS） 是 Istio 流量管理中最核心、最频繁打交道的 CRD（自定义资源）。

如果把 DestinationRule（DR） 比作“到达目的地后的治理与约束（怎么分发、并发限制、熔断）”，那么 VirtualService（VS） 就是流量由谁接待、走哪条路线的“总导航调度器”。它定义了请求如何从客户端或网关被拦截、匹配、重写，并精准路由到具体的后端服务或版本子集（Subset）。

使用场景：

  • 灰度发布：支持基于比例的流量分配
  • A/B测试：支持基于请求头、URL、权重等条件的流量分配
  • 重试：支持错误重试、故障注入、链接超时等策略

配置示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: order-service-vs
  namespace: prod
spec:
  # 1. 作用的主机名（域名或 K8s 内部短/长域名）
  hosts:
  - "order.example.com"
  - "order-service.prod.svc.cluster.local"

  # 2. 绑定的入口：mesh 代表网格内互访，结合 IngressGateway 可以同时处理内外流量
  gateways:
  - istio-system/public-gateway # 外部 Ingress 流量
  - mesh                        # 网格内部服务间调用的流量

  # 3. HTTP 路由规则（自上而下匹配，首条命中即终止）
  http:
  # 规则 A：内部测试人员优先路由到 beta 版本
  - name: internal-beta-route
    match:
    - headers:
        x-user-role:
          exact: beta-tester
      uri:
        prefix: /orders
    route:
    - destination:
        host: order-service.prod.svc.cluster.local
        subset: v2 # 依赖 DestinationRule 中定义的 subset
        port:
          number: 8080

  # 规则 B：正常生产流量，执行路径重写、超时、重试与金丝雀分流
  - name: production-canary-route
    match:
    - uri:
        prefix: /api/v1/orders
    # 路径重写：后端收到的路径变为 /orders
    rewrite:
      uri: /orders
    # 超时保护
    timeout: 3s
    # 失败重试策略
    retries:
      attempts: 3
      perTryTimeout: 1s
      retryOn: "5xx,connect-failure,refused-stream"
    # 按权重分流
    route:
    - destination:
        host: order-service.prod.svc.cluster.local
        subset: v1
        port:
          number: 8080
      weight: 90
    - destination:
        host: order-service.prod.svc.cluster.local
        subset: v2
        port:
          number: 8080
      weight: 10
  # 规则 C：默认兜底规则
  - name: default-fallback
    route:
    - destination:
        host: order-service.prod.svc.cluster.local
        subset: v1
        port:
          number: 8080

Gateway资源

Gateway（网关资源） 是 Istio 流量管理中专门负责网络边缘流量准入的 CRD（自定义资源）。

在 Istio 的流量管理模型中，Gateway、VirtualService 和 DestinationRule 组成了最经典的三部曲：

  • Gateway：负责“开门与安检”（只管在网关边缘监听哪些端口、协议、域名，以及配置 TLS 证书终止与透传）。
  • VirtualService：负责“寻路与导流”（请求进门后，按 URI 路径、Header、权重分配到哪个服务）。
  • DestinationRule：负责“到达后的治理”（请求到达目标服务后，做版本子集划分、负载均衡、连接池与熔断）。

核心设计哲学（关注点分离）：Kubernetes 原生的 Ingress 资源将“端口监听、域名、TLS 证书”与“后端路由规则（路径映射）”杂糅在单个资源中；而 Istio 将这两层解耦——Gateway 专注 L4-L6 的边缘端口与安全，VirtualService 专注 L7 的应用路由。这使得运维人员管理网关和开发人员管理业务路由可以完全权限隔离。

应用场景：

  • 端口监听：可以根据协议指定对外暴露的端口
  • TLS：可以添加域名证书提供https访问
  • 域名：可以根据域名进行路由分发
  • 出口管控：可以将出口流量固定从EgressGateway的服务中代理出去

配置示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: corporate-gateway
  namespace: istio-system  # 建议与网关 Pod 在同一命名空间
spec:
  # 1. 标签选择器：将配置下发给具体的 Ingress Gateway Pod
  selector:
    istio: ingressgateway

  # 2. 监听器服务器列表
  servers:
  # 场景 A：80 端口捕获所有 HTTP 流量，强制 301 重定向到 HTTPS
  - port:
      number: 80
      name: http-redirect
      protocol: HTTP
    hosts:
    - "*.example.com"
    - "example.com"
    tls:
      httpsRedirect: true

  # 场景 B：443 端口启用 TLS 终止（基于域名加载各自证书）
  - port:
      number: 443
      name: https-main
      protocol: HTTPS
    hosts:
    - "api.example.com"
    - "shop.example.com"
    tls:
      mode: SIMPLE
      # 证书 Secret 存放在 istio-system 命名空间
      credentialName: example-wildcard-tls

  # 场景 D：纯四层 TCP 端口透传（例如暴露集群内自建的 MySQL 或 Redis）
  - port:
      number: 3306
      name: tcp-mysql
      protocol: TCP
    hosts:
    - "*" # 四层协议通常没有 Host 头部概念，配 "*" 即可