XuHuaian,s Blog

Appearance

Istio笔记 ​

1. 流量管理相关（Traffic Management） ​

1.1 VirtualService ​

  • 用途
    VirtualService 主要用来定义“请求路由策略（Routing）”与“流量转发细节”。它能够指定请求在微服务间的转发规则，比如根据 URL 路径、HTTP Header、版本标签（version 等）等进行路由。
  • 使用场景
    • 根据请求特征（Header、Host、Path 等）把流量转发给不同版本或后端。
    • 灰度发布（Canary）、蓝绿部署（Blue/Green），控制不同版本之间流量的分配比例。
    • 对特定流量进行熔断、重试、故障注入等。

1.2 DestinationRule ​

  • 用途
    DestinationRule 指定“目标服务”的具体策略以及与之关联的子集（Subsets），包括负载均衡、连接池配置、熔断策略（circuit breaker）等。简单理解就是：VirtualService 负责告诉请求“去哪儿（到哪个子集或后端）”，而 DestinationRule 负责告诉与目标服务相关的流量如何处理，比如要不要熔断、负载均衡策略是什么等。
  • 使用场景
    • 为后端服务定义负载均衡模式（如 round robin、least request 等）。
    • 配置连接池与熔断策略，控制异常时的重试、超时处理。
    • 为目标服务的不同版本（subsets）设定不同的路由或策略。

1.3 Gateway ​

Gateway

  • 用途
    Gateway 用于定义进出流量的网关配置，类似于 Kubernetes 的 Ingress，但它更灵活、功能更强。Gateway 主要分为两类：
    • Ingress Gateway: 接收外部流量进入网格。
    • Egress Gateway: 将网格内的流量导向外部服务。
  • 使用场景
    • 在边界网关层配置 TLS 终止、域名绑定、负载均衡等。
    • 与 VirtualService 结合起来使用：Gateway 定义入口（或出口），VirtualService 定义具体转发规则，实现对网格中服务的精确暴露。

1.4 ServiceEntry ​

  • 用途
    ServiceEntry 的作用是把“外部服务”纳入服务网格管理或将未在 Kubernetes Service 中声明的内部服务添加到网格中。Istio 默认只知道集群内部的服务，如果要让 Istio 了解某个外部地址（例如调用外部 API），需要通过 ServiceEntry 来“登记”。
  • 使用场景
    • 当一个微服务需要访问外部 API（如第三方 SaaS、公共 API），通过 ServiceEntry 把这个外部服务的域名/IP 告诉 Istio，使其能够统一进行流量管控。
    • 如果需要把不在 Kubernetes Service 之列的服务纳入网格做统一管理，也可通过 ServiceEntry 来实现。

1.5 Sidecar ​

  • 用途
    Sidecar 资源用来细化对单个或一组工作负载的 Envoy 代理配置。它可以理解为在“全局流量规则”之上，再做一层更加颗粒度的配置，包括哪些命名空间可见、哪些流量要纳入代理，或者对某个特定工作负载如何裁剪 Envoy 配置等。
  • 使用场景
    • 优化大型网格中 Envoy 配置规模，比如限制 Envoy 只关注自身需要的服务，而不是监听整个集群。
    • 在多命名空间或多租户环境下，对不同服务做精细化流量可见性管理。

1.6 EnvoyFilter ​

  • 用途
    EnvoyFilter 能让你直接对 Envoy 的底层配置进行修改，比如插入自定义的过滤器、修改 http filter chain 等。通常仅在需要高阶或非常定制化的功能时才会使用。
  • 使用场景
    • 添加自定义的 Envoy filter，用于请求或响应的自定义处理。
    • 做一些 Istio 自带 API 无法直接配置的底层功能扩展。

2. 安全相关（Security） ​

2.1 AuthorizationPolicy ​

  • 用途
    AuthorizationPolicy 用于配置基于身份或请求属性的访问控制策略（即 RBAC/ABAC）。它规定了哪些主体（Principal，如用户、服务账号、请求来源）可以对哪些目标资源（比如 HTTP 路径、方法等）进行访问。
  • 使用场景
    • 配置服务间或用户到服务的访问权限控制策略。
    • 结合 JWT、mTLS 等身份认证，按照请求属性（HTTP Header、来源 IP、JWT Claims 等）进行细粒度授权。

2.2 PeerAuthentication ​

  • 用途
    PeerAuthentication 用来定义工作负载之间的安全通信方式（mTLS 策略），包括是否强制加密传输、是否使用双向 TLS 等。
  • 使用场景
    • 为集群中的服务强制开启 mTLS 加密。
    • 在部分场景下允许明文通信或者混合模式（PERMISSIVE）进行过渡。

2.3 RequestAuthentication ​

  • 用途
    RequestAuthentication 主要用于配置 JWT 验证等身份认证策略，用来识别请求的合法身份。例如指定 JWT Issuer、Audiences 等，以及如何在请求头中传递 token。
  • 使用场景
    • 对外部来的请求进行 JWT 验证。
    • 与 AuthorizationPolicy 结合，实现身份认证 + 授权控制。

3. 可观测性（Observability）和其他 ​

3.1 Telemetry ​

  • 用途
    Telemetry 资源（在 Istio 1.5+ 引入，之后版本继续迭代）允许用户自定义可观测性相关设置，例如如何收集指标、日志和跟踪信息，是对早期 Mixer 模型的替代和演进。
  • 使用场景
    • 配置是否采集 HTTP/GRPC 访问日志、指标的采样率等。
    • 为特定命名空间或特定服务定制度量指标（Prometheus Metrics）、访问日志（Access Logs）以及调用链跟踪（Tracing）等。

3.2 WorkloadEntry / WorkloadGroup ​

  • 用途
    用于把“虚拟机工作负载”或者“不在 Kubernetes 上”的工作负载纳入 Istio 的网格管理。
    • WorkloadEntry：为单个实例定义入口，如 IP、端口等。
    • WorkloadGroup：为一组工作负载定义通用配置，然后可用 WorkloadEntry 引用该配置。
  • 使用场景
    • 在混合环境（容器 + 虚拟机）的场景下，需要让虚拟机上的应用也能接入 Istio Service Mesh。
    • 将非 K8s 的工作负载通过该方式注册，实现与 K8s 工作负载统一治理。

4. 如何理解与使用这些 CRD ​

  1. 分层理解
    • Gateway + VirtualService：定义流量“怎么进来”和“怎么路由”。
    • DestinationRule：对目标服务配置负载均衡、熔断、子集版本等策略。
    • ServiceEntry：把外部服务或未注册的内部服务纳入网格。
    • Sidecar、EnvoyFilter：更细粒度或更底层的配置控制。
  2. 安全策略
    • PeerAuthentication：配置工作负载间加密传输（mTLS）。
    • RequestAuthentication：配置 JWT 等身份验证方式。
    • AuthorizationPolicy：基于身份或属性进行授权策略。
  3. 可观测性
    • Telemetry：自定义指标、日志和追踪方式。
  4. 混合环境
    • WorkloadEntry / WorkloadGroup：把非 K8s 负载或虚拟机接入到网格。
  5. 组合使用
    • 大多数场景需要多个 CRD 协同工作。例如，对外暴露服务时，常见组合是 Gateway + VirtualService；同时要配置服务间调用的安全策略，则需要 PeerAuthentication + AuthorizationPolicy。
  6. 环境区别
    • 流量管理的 CRD（如 VirtualService、DestinationRule）是核心和常用的。
    • 安全相关 CRD 如 PeerAuthentication、AuthorizationPolicy 等，在需零信任（Zero-Trust）或分级访问控制场景下才会大量用到。
    • EnvoyFilter 一般是最后的定制选项，只有在其他高层 CRD 难以满足需求时才会修改 EnvoyFilter。

本文作者：许怀安
创作时间：2025-04-08
版权声明：本博客所有文章除特别声明外，均采用BY-NC-SA许可协议。转载请禀明出处！

许怀安 | MIT License

Copyright © 2020-2025