illegalCreed

中文

English

中文

English

Appearance

入门：服务网格、Sidecar 与三大能力 ​

基于 Istio 1.22（含 Ambient GA）· 核于 2026-08

速查 ​

  • 定义：Istio 是 CNCF 开源的服务网格平台，通过 Sidecar 代理（Envoy）把「流量管理、安全（mTLS）、可观测性」从应用代码剥离下沉到基础设施，让微服务专注业务。
  • 服务网格（Service Mesh）：处理服务间通信的基础设施层。核心模式是 Sidecar——每个服务旁部署一个代理（Envoy），所有进出流量经 Sidecar，治理逻辑（路由/熔断/mTLS/指标）由 Sidecar 统一执行，应用无感知。开发者写的是「纯业务」，治理与业务解耦。
  • Sidecar 模式：业务容器 + Envoy Sidecar 容器同处一个 Pod（共享网络命名空间），Sidecar 用 iptables 拦截所有进出 Pod 的流量，按控制面下发的规则做路由/加密/采集。应用零改造。
  • 数据面 vs 控制面：数据面 = 一堆 Envoy Sidecar（执行流量拦截、路由、加密、指标采集）；控制面 = istiod（统一管理，把用户配置的 CRD 翻译成 Envoy 配置下发）。数据面做事，控制面下指令。
  • 三大能力：①流量管理（VirtualService 路由、DestinationRule 熔断/负载均衡、金丝雀/AB/镜像）；②安全（自动 mTLS 双向认证、AuthorizationPolicy 授权、JWT 校验）；③可观测性（Prometheus 指标、Jaeger 追踪、Kiali 拓扑图，无需业务埋点）。
  • Envoy：Istio 数据面用的代理（Lyft 开源，C++），高性能 L7 代理，支持 HTTP/gRPC/TCP，是 Sidecar 的实现。xDS 协议从控制面动态接收配置。
  • istiod：控制面组件（Istio 1.5+ 合并了 pilot/citadel/galley 为单进程），职责是服务发现、配置转换（CRD→Envoy）、证书签发（CA）。
  • 声明式 CRD：Istio 用 Kubernetes CRD 扩展配置——VirtualService（路由规则）、DestinationRule（目标策略）、Gateway（入口网关）、ServiceEntry（外部服务）、AuthorizationPolicy（授权）、RequestAuthentication（JWT）等。
  • Ambient 模式 GA（1.22+）：Istio 的新架构，去 Sidecar——用节点级 ztunnel（L4 mTLS）+ 按需 waypoint（L7 流量管理）替代每 Pod 一个 Envoy，大幅降低资源开销（不必每 Pod 跑一个 Envoy）。Sidecar 模式仍支持，两种共存。
  • vs Spring Cloud：Spring Cloud 是 SDK 内嵌（治理逻辑在应用内的 Java 库，绑 Java）；Istio 是 Sidecar 外挂（治理在基础设施，语言无关）。后者更解耦、多语言友好。
  • vs Linkerd：Istio（Envoy/C++，功能全，重型）/ Linkerd（自研 Rust 代理，轻量，功能少）。Istio 功能与生态占优，Linkerd 性能与简易性占优。
  • 进阶顺序：流量管理 → 安全与 Ambient 模式 → 参考。

一、服务网格：从 SDK 内嵌到 Sidecar 外挂 ​

传统微服务治理（如 Spring Cloud、Dubbo）把治理逻辑（熔断/限流/负载均衡/追踪）做成 SDK 内嵌进应用——应用依赖一堆 Java 库，治理与业务耦合。这带来痛点：①语言绑定（Spring Cloud 只能 Java，多语言项目要每语言重写一套）；②升级困难（SDK 升级要改业务代码重新部署）；③治理逻辑占用业务代码心智。

服务网格（Service Mesh）的解法是 Sidecar 外挂：把治理逻辑从应用剥离，下沉到一个独立代理（Sidecar），与业务容器同处一个 Pod，拦截所有流量：

   Pod
   ┌─────────────────────────────┐
   │  业务容器（纯业务，无治理库）  │
   │         ↕                    │
   │  Envoy Sidecar（治理逻辑）   │  ← 路由/熔断/mTLS/指标都在这里
   │         ↕                    │
   │  iptables 拦截所有进出流量    │
   └─────────────────────────────┘
  • 应用零改造：业务代码只管发请求，Sidecar 拦截后做治理（路由到正确实例、熔断故障实例、加密流量、采集指标）。
  • 语言无关：Sidecar 是独立进程，Java/Go/Python/Node 服务都一样接入，治理统一。
  • 升级独立：Sidecar 升级（Istio 版本）不必改业务代码，滚动重启 Sidecar 即可。
  • 代价：每个 Pod 多一个 Sidecar 容器，资源开销与一跳代理延迟。

一句话：服务网格把治理从应用 SDK 剥离到 Sidecar，让微服务专注业务，Istio 是其主流实现。

二、数据面与控制面 ​

Istio 采用经典的数据面/控制面分离架构：

              ┌─────────── 控制面 ───────────┐
              │           istiod              │  ← 单进程，含 pilot+citadel+galley
              │  - 服务发现（监听 K8s Service）│
              │  - 配置转换（CRD -> Envoy）    │
              │  - 证书签发（CA，签 mTLS 证书）│
              └───────────────┬───────────────┘
                              │ xDS（下发配置）/ SDS（下发证书）
            ┌─────────────────┼─────────────────┐
            ▼                 ▼                 ▼
        Envoy Sidecar    Envoy Sidecar    Envoy Sidecar
        (Pod A)          (Pod B)          (Pod C)
            │                 │                 │
        ┌───┴───┐         ┌───┴───┐         ┌───┴───┐
        │ 业务A  │         │ 业务B  │         │ 业务C  │
        └───────┘         └───────┘         └───────┘
              数据面（一堆 Envoy，执行流量拦截）
  • 数据面（Data Plane）：一堆 Envoy Sidecar，每个 Pod 一个。职责：拦截进出 Pod 的流量，按控制面下发的规则做路由/负载均衡/熔断/mTLS 加密/指标采集。Envoy 是真正「做事」的。
  • 控制面（Control Plane）：istiod（单进程，1.5+ 合并了原来的 pilot/citadel/galley）。职责：①服务发现（监听 K8s Service/Endpoint）；②配置转换（把用户的 CRD 如 VirtualService 翻译成 Envoy 能理解的配置，通过 xDS 协议下发）；③证书签发（作为 CA 给每个服务签 mTLS 证书，通过 SDS 下发）。控制面不接触业务流量，只下指令。
  • xDS 协议：Envoy 与控制面通信的协议（LDS/RDS/CDS/EDS），动态接收路由、集群、监听器配置。这让 Envoy 配置可热更新（改 VirtualService 秒级生效，不必重启 Envoy）。

三、三大核心能力 ​

Istio 的价值集中在三大能力，全部通过 Sidecar 实现，应用零改造：

能力做什么关键 CRD
流量管理精细控制服务间流量（路由、负载均衡、熔断、重试、金丝雀、AB、镜像）VirtualService、DestinationRule、Gateway
安全服务间 mTLS 双向认证 + 授权 + JWT 校验，零信任PeerAuthentication、AuthorizationPolicy、RequestAuthentication
可观测性自动采集指标（Prometheus）、分布式追踪（Jaeger）、拓扑图（Kiali）（开箱即用，无需 CRD）
  • 流量管理是 Istio 最常用的能力——用 VirtualService 定义「请求该怎么路由」（如 90% 到 v1，10% 到 v2 做金丝雀），DestinationRule 定义「目标实例的策略」（负载均衡算法、熔断阈值、连接池）。这两者配合实现精细流量控制。
  • 安全默认开启 mTLS（服务间双向证书认证，防窃听与伪造），叠加 AuthorizationPolicy 做细粒度授权（服务 A 能否调服务 B 的某接口）。
  • 可观测性完全开箱——Sidecar 自动采集每次请求的指标（QPS/延迟/错误率）发 Prometheus，自动注入追踪 header 发 Jaeger，Kiali 据此画出服务拓扑图。业务无需埋点。

四、Ambient 模式 GA：去 Sidecar 的新架构 ​

Sidecar 模式的痛点是每 Pod 一个 Envoy 的资源开销——一个集群几千 Pod 就要跑几千个 Envoy，内存与 CPU 开销可观。Istio 1.22（2024）把 Ambient 模式 GA（正式可用），用两层替代每 Pod Sidecar：

   节点级 ztunnel（L4 mTLS）         ← 每节点一个，只做 L4 流量加密（mTLS）
       ↑ 只需 L4 的服务用这层（轻量）

   按需 waypoint（L7 流量管理）      ← 按命名空间/服务按需部署，做 L7 路由/熔断等
       ↑ 需要 L7 治理（如金丝雀）的服务才挂 waypoint
  • ztunnel：每个节点一个（DaemonSet），用 Rust 写的轻量 L4 代理，只做 mTLS 加密与基本 L4 路由。所有节点的流量默认经 ztunnel 加密，享受 mTLS 但无 Sidecar 开销。
  • waypoint：按需部署的 Envoy（L7），需要 L7 流量管理（VirtualService 金丝雀/AB/熔断）的命名空间或服务才挂 waypoint。不需要 L7 治理的服务只用 ztunnel（最轻）。
  • 分层按需：L4 加密人人有（ztunnel），L7 治理按需加（waypoint）。比「每 Pod 一个全功能 Envoy」省资源。
  • Sidecar 与 Ambient 共存：1.22+ 两种模式都支持，可逐命名空间迁移。Ambient 是未来方向。

五、Istio vs Spring Cloud vs Linkerd ​

维度IstioSpring CloudLinkerd
模式Sidecar 外挂SDK 内嵌Sidecar 外挂
语言语言无关仅 Java语言无关
代理Envoy（C++）应用内 Java 库自研 Rust 代理
功能全（流量/安全/观测）全（但绑 Java）较少（轻量）
复杂度高中（SDK 升级难）低
性能中（Envoy 开销）高（无 Sidecar）高（Rust 轻量）
生态CNCF 主流Java 生态CNCF
  • vs Spring Cloud：Istio 把治理从 SDK 剥离到 Sidecar，多语言友好、升级独立；Spring Cloud 治理在应用内（Java 库），性能好但绑 Java、SDK 升级要改业务。趋势是 Istio（基础设施层）替代部分 Spring Cloud 治理能力。
  • vs Linkerd：Istio 用 Envoy（功能全但重），Linkerd 用 Rust 轻量代理（功能少但性能好、易用）。重度流量治理选 Istio，追求极简与性能选 Linkerd。

下一步 ​

理解了服务网格与 Istio 架构后，下一步深入流量管理——VirtualService 路由、DestinationRule 熔断/负载均衡、Gateway 入口、金丝雀/AB/镜像实战，以及安全与 Ambient 模式——mTLS、AuthorizationPolicy、Ambient 详解、与 Linkerd 对比。