📚 课程目录第1章 Envoy架构概述

1. Envoy 架构概述：数据平面与控制平面分离原理、xDS 协议基础、核心资源模型

1.1 数据平面与控制平面分离架构

Envoy 采用典型的数据平面（Data Plane）与控制平面（Control Plane）分离架构。这种设计将流量转发与策略下发解耦，是 Envoy 实现动态配置、热更新和故障隔离的架构基础。

  架构核心原则： 数据平面只负责高效转发流量，不存储全局状态；控制平面负责计算、校验和分发配置，不参与数据路径。两者通过标准 xDS 协议通信。

下表对比了数据平面与控制平面的职责与特性：

维度	数据平面（Envoy Sidecar / Gateway）	控制平面（如 Istiod / xDS Server）
核心职责	监听端口、解析请求、负载均衡、TLS 终止、流量镜像、健康检查	聚合服务注册信息、生成路由规则、下发证书、管理限流配额
状态特征	无状态或仅缓存本地配置，重启后从控制平面重新拉取	有状态，维护全量服务拓扑与配置版本
故障影响	单个 Envoy 故障仅影响本地流量，不扩散	控制平面故障不影响已下发的数据平面运行，但无法更新配置
性能要求	高吞吐、低延迟，通常运行在数据路径上	低延迟可接受，重点在于一致性和可用性
配置来源	通过 xDS 订阅从控制平面拉取	从 Kubernetes API、文件、GitOps 等上游获取

SRE 视角： 在故障排查中，分离架构意味着数据平面问题（如连接超时）与控制平面问题（如路由未下发）需要不同的诊断路径。回滚护栏应优先保护数据平面的稳定运行，避免控制平面异常配置直接冲击流量。

下图展示了 Envoy 数据平面与控制平面的分离关系及 xDS 通信路径：

1.2 xDS 协议基础

xDS（Discovery Service）是 Envoy 与控制平面之间的一组标准 gRPC/REST 协议，用于动态发现配置。每个 xDS 对应一类核心资源，Envoy 通过订阅这些资源实现零停机配置更新。

下表列出了主要的 xDS 协议及其对应的资源类型：

协议缩写	全称	资源类型	典型更新场景
LDS	Listener Discovery Service	Listener	新增/修改监听端口、TLS 证书更换
RDS	Route Discovery Service	RouteConfiguration	灰度发布路由、Header 匹配规则变更
CDS	Cluster Discovery Service	Cluster	新增上游服务、修改连接池大小
EDS	Endpoint Discovery Service	ClusterLoadAssignment	Pod 扩缩容、端点健康状态变化
SDS	Secret Discovery Service	Secret	TLS 证书轮换、私钥更新
HDS	Health Discovery Service	HealthCheckSpecifier	自定义健康检查策略

安全评估要点： xDS 协议是控制平面下发配置的唯一通道。在回滚场景中，必须确保 xDS 通道的 TLS 加密和身份认证，防止恶意控制平面下发篡改后的配置。同时，Envoy 应配置 xDS 配置版本校验，避免回滚到旧版时出现配置兼容性问题。

xDS 协议的工作流程遵循“订阅-推送-确认”模式：

订阅（Subscribe）： Envoy 启动时向控制平面发起 xDS 流式订阅请求，携带节点标识和资源类型。
推送（Push）： 控制平面在配置变更时，将全量或增量资源版本推送给 Envoy。
确认（ACK/NACK）： Envoy 应用配置后返回 ACK；若校验失败则返回 NACK，并保持旧配置运行。

以下是一个 Envoy 通过 LDS 订阅 Listener 配置的简化示例：

# Envoy 启动时向控制平面发送的 LDS 订阅请求（简化）
node:
  id: "sidecar~10.0.1.5~myapp-abc123~default"
  cluster: "my-cluster"
  metadata:
    role: "sidecar"
    version: "1.28.0"

# 控制平面推送的 Listener 配置（简化）
resources:
  - "@type": "type.googleapis.com/envoy.config.listener.v3.Listener"
    name: "listener_8080"
    address:
      socket_address:
        address: "0.0.0.0"
        port_value: 8080
    filter_chains:
      - filters:
          - name: "envoy.filters.network.http_connection_manager"
            typed_config:
              "@type": "type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager"
              stat_prefix: "ingress_http"
              route_config_name: "route_config_8080"
              http_filters:
                - name: "envoy.filters.http.router"

1.3 核心资源模型：Listener / Cluster / Endpoint / Route

Envoy 的配置模型围绕四个核心资源构建，它们共同定义了流量从入站到出站的完整路径。理解这些资源是进行故障排查和回滚设计的前提。

  资源依赖链： Listener → FilterChain → Route → Cluster → Endpoint。流量从 Listener 进入，经过路由匹配后转发到 Cluster 中的具体 Endpoint。

下表详细对比了四个核心资源的定义与关键属性：

资源	定义	关键属性	故障排查关注点
Listener	定义 Envoy 监听的 IP:Port 及网络过滤器链	地址、端口、TLS 上下文、过滤器链、连接限制	端口冲突、TLS 证书过期、过滤器顺序错误
Route	定义请求匹配规则（域名、路径、Header）及目标 Cluster	虚拟主机、匹配条件、路由动作、重定向/重写规则	路由未命中、权重分配错误、Header 条件冲突
Cluster	定义上游服务集群的连接策略、负载均衡算法、健康检查	连接超时、断路器阈值、负载均衡类型、TLS 上游	断路器触发、连接池耗尽、健康检查失败
Endpoint	定义 Cluster 中的具体后端实例（IP:Port + 元数据）	地址、端口、健康状态、权重、区域	端点不可达、权重为 0、区域感知路由异常

下图展示了 Listener → Route → Cluster → Endpoint 的完整流量路径及资源关系：

1.4 资源模型在故障排查中的意义

在安全评估驱动的回滚护栏设计中，理解资源模型有助于精准定位故障边界：

Listener 层故障： 通常表现为端口无法监听、TLS 握手失败。回滚时应优先检查 Listener 配置版本，避免证书或端口变更导致服务不可用。
Route 层故障： 表现为请求 404 或路由到错误 Cluster。回滚护栏应记录路由变更历史，支持按路由名称回退到上一版本。
Cluster 层故障： 表现为连接超时、断路器打开。回滚时需注意 Cluster 配置变更（如超时时间、连接池大小）是否与当前流量模式兼容。
Endpoint 层故障： 表现为部分请求失败、负载不均。回滚护栏应结合健康检查状态，避免将流量导向不健康的端点。

最佳实践： 在 Envoy 故障排查中，建议按照 Listener → Route → Cluster → Endpoint 的顺序逐层检查。xDS 的 NACK 日志通常能直接指示是哪一层资源校验失败，这是回滚决策的关键信号。