【云原生网络】Istio基础篇

文章目录

😊点此到文末惊喜↩︎

概述

基础知识

背景知识
- 服务网格（Service Mesh）：独立于应用程序的基础设施层，通过在服务间引入 "代理"来拦截和处理所有网络通信，实现对服务间交互的透明控制
- 微服务架构的挑战
  - 微服务架构带来了服务间通信复杂性、流量管理、安全性和可观测性等方面的挑战。
  - Kubernetes 虽然解决了分布式应用的部署和调度问题，但无法直接处理服务间的通信复杂性
Istio简介
- 定义：是一个开源服务网格平台，通过在应用层和网络层之间插入一个代理层（Sidecar），从而增强对服务间通信的透明控制
- 核心作用：
  - 网络层的全权代理：Istio 通过在每个 Pod 中注入 Sidecar 代理（Envoy），从而将所有请求通过 Sidecar 代理，从而统一管理服务间的通信逻辑
  - 业务代码无侵入：Sidecar 作为独立进程运行，只负责处理网络层的逻辑，而业务代码专注于业务逻辑实现
Istio的功能
- 流量管理
  - 智能路由：基于请求内容（如 Header、URI）、权重、版本等条件进行流量分发，支持 A/B 测试、金丝雀发布、蓝绿部署。
  - 弹性容错：通过断路器、超时、重试机制应对服务故障，防止级联失败。
  - 负载均衡：支持多种负载均衡策略（轮询、随机、最少请求数），并根据服务健康状态动态调整。
  - 安全增强
    - 双向 TLS（mTLS）：自动为服务间通信加密，无需修改应用代码，支持证书自动分发和轮换。
    - 细粒度访问控制：基于身份（服务账户）和属性（如 IP、端口）定义访问策略，实现零信任网络。
    - 身份与认证：为每个服务分配唯一身份，基于 JWT 进行身份验证。
  - 可观测性
    - 分布式追踪：自动收集请求链路数据（如请求耗时、调用关系），支持 Jaeger、Zipkin 等追踪系统。
    - 指标监控：收集服务间通信的关键指标（QPS、错误率、延迟），与 Prometheus、Grafana 集成。
    - 日志聚合：集中记录服务间请求信息，辅助故障排查。
Istio架构
- 控制平面（Control Plane）
  - 基于配置及其对服务的视图，进行动态地编程代理服务器，并根据规则或环境的变化对其进行更新。
  - 主要包括了Pilot、Mixer、Citadel和Galley共4个组件，主要功能是通过配置和管理Sidecar代理来进行流量控制，并配置Mixer去执行策略和收集遥测数据（Telemetry）
- 数据平面（Data Plane）
  - 服务之间的通信
  - 由一组和业务服务成对出现的Sidecar代理（Envoy）构成，主要功能是接管服务的进出流量，传递并控制服务和Mixer组件的所有网络通信
Pod的内部工作流程
- 容器对象
  - istio-init容器：负责初始化Pod的iptables规则，用于重定向网络流量到Envoy代理。只有当istio-init容器成功完成后，Pod中的其他容器才会启动
  - Istio'的sidecar容器：Istio注入到Pod中的辅助代理容器，通常是一个Envoy实例，负责处理Pod的入站和出站流量
  - App container: 这是Pod中的应用程序容器，运行实际的业务逻辑
- 网络流量处理
  - Inbound/Outbound traffic：出站和入站流量被iptables规则重定向到Envoy代理，Envoy代理根据配置决定如何处理这些流量
  - DNS queries: 应用容器发出的DNS查询被iptables规则重定向到DNS代理，DNS代理负责解析DNS查询并将结果返回给应用容器
- 控制平面处理
  - istiod: istiod是Istio的控制平面组件，负责管理和分发配置信息。它通过xDS API与Pilot代理通信，提供服务发现、路由规则、安全策略等配置信息。
  - Pilot agent: Pilot代理是sidecar的一部分，它与istiod保持持续连接，接收配置更新，并将这些更新应用到Envoy代理。Pilot代理还负责启动Envoy代理作为一个进程，并可选地运行本地DNS代理服务器，以保持与从istiod接收到的最新网格状态同步
- 组件交互
  - istio-init容器设置iptables规则: istio-init容器在启动时设置Pod的iptables规则，这些规则用于重定向网络流量和DNS查询到Envoy代理和DNS代理。
  - Pilot代理与istiod通信: Pilot代理通过xDS API与istiod通信，接收配置更新，并将这些更新应用到Envoy代理。
  - Envoy代理处理网络流量: Envoy代理根据配置处理入站和出站流量，包括路由、负载均衡、安全策略等。
  - DNS代理处理DNS查询: DNS代理解析应用容器发出的DNS查询，并将结果返回给应用容器。

技术架构

概述

Istio的组成
- 数据平面：由一组在Pod中部署为辅助容器sidecar的网络代理Envoy组成，负责服务间所有网络流量的实际控制(Traffic Management)
  - Istio-init容器：负责初始化Pod的网络配置，包括设置iptables规则，以确保流量通过Envoy代理。
  - Pilot-agent：负责启动和管理Envoy代理，包括配置文件的生成和证书的获取。
  - Envoy代理：部署在每个Pod中，作为sidecar容器运行。它负责处理服务之间的网络通信，包括负载均衡、服务发现、流量管理、安全和可观测性等功能。
- 控制平面：Istiod是Istio的控制平面组件，它负责管理服务网格中的配置和证书，主要包括
  - Pilot：负责将服务发现信息转换为Envoy可以理解的配置，并通过xDS API分发给Envoy代理。
  - Citadel：负责生成和分发证书，以确保服务之间的安全通信。
  - Galley：负责配置管理，从Kubernetes API服务器获取配置并进行验证和转换。
数据平面
- 成对部署：Istio通过K8s的自动注入机制将Sidecar（基于Envoy实现的辅助容器）和业务容器部署在同一个 pod中，确保代理与应用生命周期同步
- 流量劫持：初始化容器 istio-init 通过配置Pod的iptables 规则，将出入站流量透明重定向到Envoy Sidecar代理进行处理，从而实现服务的流量控制
数据平面流量处理路径
- 使用Istio的流量转发路径
  - 源业务容器发送请求到目标业务容器。
  - 源Pod的iptables规则拦截请求，并将其重定向到源Sidecar的15001端口。
  - 源Sidecar接收到请求后，执行一系列流量策略，包括路由决策、负载均衡、重试和超时处理。
  - 源Sidecar将处理后的请求转发给目标Sidecar。
  - 目标Sidecar接收到请求后，执行另一系列流量策略，包括身份验证、速率限制和指标采集等
  - 目标Pod的iptables规则将请求重定向到目标业务容器的15006端口。
  - 请求最终被交付给目标Pod的目标业务容器。
- 原始流量转发路径：源容器 → 目标容器
作用
- 透明化：通过 Sidecar 代理模式将业务间的通信和实际的业务逻辑解耦，从而实现对业务代码无侵入的网络流量处理
- 动态化：通过控制平面可以实时对流量控制策略进行动态注入更新
- 安全性：Pod 级零信任网络，即默认情况下不信任网格内的任何服务
控制片面的作用
- 传统微服务治理：
  - 核心挑战：服务发现、负载均衡、熔断、限流等流量治理需求
  - 解决方法：通常将这些功能以 SDK 形式嵌入业务代码，但SDK 与业务代码深度绑定，且多语言的SDK维护困难
- 服务网格Service Mesh治理：
  - 核心思想：通过 Sidecar 代理（如 Envoy）将流量治理功能从业务代码中解耦，即服务与服务间的流量治理转变为Proxy与Proxy之间的流量治理。从而实现对业务代码的零侵入，开发人员可以更加关注业务逻辑

数据平面核心组件

网络代理Envoy

概述
- 定义：Envoy是基于C++开发的一个开源、高性能的网络服务代理，作为Istio的数据平面核心组件，负责处理和转发微服务间的所有网络流量，并执行控制平面下发的策略
核心功能
- 代理能力完善
  - 多代理支持：同时支持边缘代理（接收外部流量，如面向用户的 API 网关）和服务间代理（处理微服务之间的内部通信）。
  - 高性能：基于 C++ 实现，采用异步非阻塞架构，支持高并发、低延迟，能高效处理百万级别的并发连接。
- 基于服务发现的动态配置
  - 服务发现：原生支持与主流服务发现工具（如 Consul、etcd、Kubernetes Service、AWS CloudMap 等）集成，自动发现服务实例的上下线，动态更新可用节点列表。
  - 动态配置：通过一套标准化的发现服务 API（xDS协议族，包括 LDS、RDS、CDS、EDS 等）实现动态配置，无需重启即可更新路由、集群、监听器等规则，适配动态变化的云原生环境。
- 流量管理
  - 负载均衡：提供丰富的负载均衡算法，包括加权轮询、最小请求数、随机、一致性哈希、熔断（Circuit Breaking）、健康检查（主动 / 被动）、异常值检测（Outlier Detection）等，提升服务可用性。
  - 精细化路由：支持基于路径、主机名、请求头、查询参数等条件的路由规则，可实现 A/B 测试、金丝雀发布等场景。
  - 流量控制：支持请求重试、超时控制、限流、流量镜像（Shadowing）等，优化服务稳定性和资源利用率。
- 可观测能力
  - 详细日志：支持访问日志、错误日志等，可自定义格式（如 JSON），便于日志收集和分析。
  - 丰富指标：暴露 Prometheus 兼容的指标（如请求量、延迟、错误率、连接数等），支持实时监控服务状态。
  - 分布式追踪：原生集成 OpenTelemetry、Jaeger、Zipkin 等追踪系统，自动为请求添加追踪上下文，实现跨服务调用链可视化。
- 安全通信保障
  - TLS 全链路加密：支持双向 TLS（mTLS），可作为 TLS 终止点（边缘代理）或转发点（服务间代理），确保服务间通信的机密性和完整性。
  - 身份认证与授权：可集成外部认证服务（如 OAuth2），并通过配置实现细粒度的流量访问控制。
- 可拓展性
  - 协议适配：原生支持 HTTP/1.1、HTTP/2、gRPC、TCP 等协议，可在不同协议间进行转换（如 HTTP/1.1 转 gRPC）。
  - 过滤器链机制：通过模块化的过滤器链（Filter Chain）扩展功能，支持自定义逻辑（如请求修改、鉴权、日志增强等），无需修改 Envoy 核心代码。
基础架构
- 跨进程架构：以独立进程形式与每个应用服务并行运行，形成透明通信网格。应用仅需与本地 Envoy 通信，无需感知网络拓扑。
- 事件驱动模型：采用异步 I/O（基于 Libevent）处理并发连接，实现高吞吐量与低延迟
- 分层过滤器链：L3/L4 过滤器：处理原始 TCP/UDP 流量（如连接代理、TLS 终止
- 动态配置：通过 xDS API（如 EDS、CDS、RDS）实时更新路由、集群等配置，无需重启
- 边车模式（Sidecar）：在服务网格（如 Istio）中作为代理容器与业务容器共存，拦截所有进出流量
Envoy网络及线程模型（原理）
- 启动监听：Envoy在启动时会创建与工作线程绑定的Listener（监听器），监听器会向libevent注册Read回调函数onSocketEvent，然后进入阻塞运行状态，直到进程退出
- 新连接处理
  - 内核调用：当新连接到达时，内核网络协议栈会调用注册的回调函数，并创建新连接的Socket
  - 监听过滤：通过ConnectionHandler调用监听过滤器，获取真实访问目标地址
  - 连接创建：根据目标地址匹配到相应的业务监听器后，创建Connection连接对象。
- 连接对象管理
  - 注册回调：创建的Connection对象会再次向libevent注册Read/Write回调函数onFileEvent。
  - L4层处理：Connection对象作为L4层过滤管理器，处理onNewConnection和onData数据接收等事件。
- HTTP协议处理：L7层编解码：对于HTTP协议，数据会继续经过L7层的编解码处理，然后向上游发送请求。
- 请求处理与删除：当请求处理完毕后，Envoy会调用deferredDelete删除请求对象，并记录相关的统计观测数据。
- 异步I/O：异步发送数据：Envoy使用异步I/O方式发送网络数据，这样可以降低对线程内其他操作的阻塞，提高整体性能和响应速度
Envoy常用部署方式
- 网格内调用（Sidecar + iptables）
  - 原理：以 Sidecar 代理形式对每个Pod中的应用容器对应部署一个Envoy容器，然后Envoy 通过自动注入的 iptables 规则实现出入站流量自动转发到 Envoy
  - 调用路径：客户端请求 ────> 服务 Pod ────> iptables 重定向 ────> Envoy Sidecar ────> 目标服务
- 网格外调用（Gateway）
  - 原理：Envoy 作为 Ingress Gateway 部署在网格边缘，作为外部流量的入口点
  - 调用路径：外部客户端 ────> 负载均衡器 ────> Envoy Ingress Gateway ────> 服务网格内部
与其他代理的对比

控制平面核心组件

xDS协议

xDS协议
- 定义：xDS（eXtensible Discovery Service，可扩展发现服务）是一组基于 gRPC 实现的发现服务协议集合，用于将控制面生成的配置动态下发至数据面代理
- 作用
  - 动态配置更新：无需重启服务即可实时更新路由、负载均衡等配置，满足微服务架构的弹性需求。
  - 分层解耦设计：各 xDS 层独立更新，如修改路由规则（RDS）不影响端点发现（EDS），提高系统稳定性。
  - 跨平台兼容性：xDS 是 Envoy 的标准协议，Istio 通过 xDS 可对接多种服务注册中心
- C/S工作方式
  - xDS协议服务器：Istio 通过控制平面组件 Pilot 作为 xDS 服务器，向数据平面的 Envoy 代理推送配置
  - 控制面：Istiod 实现 xDS 服务器，通过 DiscoveryServer 组件处理 gRPC 请求。
  - 数据面：Envoy 作为 xDS 客户端，其API抽象为Service Mesh控制平面与数据平面的标准接口------xDS，从而能够订阅并应用配置
- Istio通过服务发现获取了整个网格的服务视图，用户则通过Istio提供的一系列资源对象定义了服务间的访问规则，然而网格中真正进行流量转发的是底层的Proxy。因此，Pilot还需要将服务及其流量管理规则下发至Proxy，而下发过程中，两者之间交互的协议即为xDS协议。
xDS的组成（"xDS" 中的 "x" 是一个通配符，代表一系列具体的配置服务）
- CDS（Cluster Discovery Service）：集群发现服务，用于配置 "上游服务集群"（如目标服务的地址、负载均衡策略、超时设置等）。
- EDS（Endpoint Discovery Service）：端点发现服务，用于配置集群中的具体实例（如服务的 IP + 端口，支持动态扩缩容、健康检查后的实例更新）。
- LDS（Listener Discovery Service）：监听器发现服务，用于配置代理的 "监听端口"（如 Envoy 监听的入站流量端口，定义如何接收流量）。
- RDS（Route Discovery Service）：路由发现服务，用于配置流量路由规则（如基于路径、Header、权重的路由策略，决定流量转发到哪个集群）。
- SDS（Secret Discovery Service）：密钥发现服务，用于配置 TLS 证书、密钥等安全材料（支持动态更新加密配置）。
一次完整的 xDS 流程
- 请求（DiscoveryRequest）
  - 主动告诉控制平面："我是谁，我需要什么配置"。控制平面基于这些信息生成针对性的差异化配置，避免 "一刀切" 的无效推送
  - 请求中携带版本与资源哈希，使得控制平面可以根据版本判断是否推送，根据资源哈希判断推送 "新增 / 变更" 的资源（增量更新）
- 响应（DiscoveryResponse）
- 确认/拒绝（ACK/NACK）
xDS 在 Istio 中的工作流程
- 配置转换
  - 用户通过 Istio API（如 VirtualService、DestinationRule）定义流量规则。
  - Pilot 将这些规则转换为 xDS 格式的配置（LDS/RDS/CDS/EDS）。
- 动态发现机制
  - Envoy 代理启动时，通过 gRPC 连接向 Pilot 发起 xDS 请求。
  - Pilot 根据 Envoy 所在的服务网格位置（如命名空间、服务标签）生成对应的配置。
- 增量更新Delta xDS
  - 当服务实例变化（如上线 / 下线）或路由规则修改时，Pilot 主动推送增量更新，Envoy 无需重启即可应用新配置。
  - Istio 1.22 起默认模式，仅下发变更部分（如新增路由），显著降低控制面负载
xDS标准化子协议
- 监听发现服务（LDS，Listener Discovery Service）
  - 作用：管理 Envoy 的监听器配置，定义 Envoy 监听的网络端口和协议（HTTP/TCP）
- 路由发现服务（RDS，Route Discovery Service）
  - 作用：定义监听器接收到请求后的路由规则，包括域名匹配、路径重写、流量分配等。
- 集群发现服务（CDS，Cluster Discovery Service）
  - 作用：管理目标服务集群的配置，定义后端服务的逻辑分组，包括包含负载均衡策略和健康检查配置等
- 端点发现服务（EDS，Endpoint Discovery Service）
  - 作用：提供集群中具体实例的端点信息（IP、端口、健康状态等），是服务发现的核心
- 密钥发现服务（SDS，Secret Discovery Service）：管理 TLS 证书和密钥，实现服务间的安全通信
Pilot：
- 主要功能：管理和配置部署在特定 Istio 服务网格中的所有 sidecar 代理实例
- 将高级路由策略转化为 Envoy 可执行的底层配置
主要功能（适配器+API转换层+推送器）
- 适配器：虽然前文对于Service以及Istio资源对象进行了分别的描述，但事实上两者是一致的，都只是一种资源，Pilot对它进行了标准的定义并用它去适配Kubernetes等各个平台
- API转换层：Pilot从上层获取了Service以及VirtualServices等Istio资源对象，但是它们与xDS定义的Listener等Envoy要求的资源对象并不存在直接对应关系，因此需要进行一层API的转换
- 推送器：Service以及VirtualService等Istio资源对象并非一成不变的，而Listener等xDS API对象则由前者直接推导得到，因此一旦前者发生变更，后者必须重新推导并推送
xDS 与 Istio 资源的映射关系

Istio 资源	对应 xDS 协议	核心功能映射
VirtualService	RDS （Route Discovery Service）	定义请求路由规则
DestinationRule	CDS （Cluster Discovery Service）	定义集群负载均衡和健康检查策略
ServiceEntry	CDS/EDS （Endpoint Discovery Service）	引入外部服务到服务网格
Gateway	LDS （Listener Discovery Service）	定义网格入口的监听器配置
Sidecar	LDS/RDS	控制服务间通信的网络范围和规则

Pilot组件

概述
- 定义：Pilot（引导员）是 Istio 服务网格中控制平面的核心组件，负责管理和配置数据平面的代理（如 Envoy），实现服务发现、流量管理和策略执行
- 作用：将高层的路由规则转换为底层代理可执行的配置。
核心功能
- 统一服务发现：让业务容器对应的辅助容器Sidecar知道现在有哪些服务可以调用
  - 聚合：收集所有 Pilot 连接的底层基础设施平台（如 Kubernetes, Consul, VMs, Cloud Foundry 等）中服务的所有可用实例（Endpoint）及其网络位置（IP:Port）等信息
  - 标准化：将不同平台和格式的服务信息，转化合并成一个平台无关的统一服务目录
  - 告知 Sidecar：将统一服务目录动态地推送给每个业务容器对应的辅助容器Sidecar 代理
- 流量管理配置翻译：将用户定义的网络规则翻译成底层可执行的复杂代理配置
  - 翻译：将用户描述流量管理的自定义资源 (Custom Resource Definitions - CRDs) ，翻译成 Sidecar代理能够理解和执行的底层的网络配置
  - 关键CRD
    - VirtualService（虚拟服务，去哪）：控制流量发起方的路由规则，使请求被导向目标服务
    - DestinationRule（目标策略，如何处理）：定义流量接收方的处理策略，控制目标服务的处理行为
    - Gateway（网关，谁可进&谁能出）：定义网格边界流量出入口的端口和协议，具体路由规则需通过 VirtualService 绑定
    - ServiceEntry（服务条目，外部服务纳管）：支持将外部服务加入网格注册表，使外部服务也可进行流量控制
两种数据平面模式
- Sidecar 模式
  - 此模式会为集群中启动的每个 Pod 都部署一个 Envoy 代理，或者与在虚拟机上运行的服务并行运行一个 Envoy 代理。
  - 部署的每个应用都有一个 Envoy 代理被注入（在创建时使用动态 Webhook 来修改 Pod 规约）作为 Sidecar
- Ambient 模式
  - 此模式在每个节点上使用四层代理，另外可以选择为每个命名空间使用一个 Envoy 代理来实现七层功能。
  - 所有流量都通过仅支持四层的节点代理进行代理，应用也可选择通过 Envoy 代理进行路由，以获得七层功能
图解
- 底层解耦：Pilot在服务网格中负责维护Istio服务的抽象模型，而不依赖底层运行的平台类型（K8s、Mesos等）
Pilot与Envoy代理之间维持一个gRPC长连接，所有配置的分发都基于此链接的一个Stream，配置的下发采用异步方式

其他

概述

为什么不"使用 eBPF"？
为什么不使用每个节点的代理？

少年，我观你骨骼清奇，颖悟绝伦，必成人中龙凤。不如点赞·收藏·关注一波

🚩点此跳转到首行↩︎

【云原生网络】Istio基础篇

文章目录

概述

基础知识

技术架构

概述

数据平面核心组件

网络代理Envoy

控制平面核心组件

xDS协议

Pilot组件

其他

概述

参考博客