📚 课程目录第4章 GitOps工具选型

4. Envoy 网关架构概览：核心组件与数据面/控制面分离

Envoy 是云原生时代高性能、可编程的七层代理与网关，其架构围绕四个核心抽象构建：Listener、Cluster、Route、Endpoint。理解这四者的关系以及数据面与控制面分离的设计，是进行 Envoy 网关参数配置与 GitOps 交付的基础。

4.1 核心组件：四层抽象模型

Envoy 将网络流量处理路径抽象为四个层级，每个层级负责独立的职责，通过静态文件或动态 xDS 协议进行配置。

组件	职责	类比
Listener	定义 Envoy 监听的 IP 地址、端口及传输层协议（TCP/UDP）。它是流量的入口。	机场的登机口
Route	定义匹配规则（域名、路径、Header）并将请求路由到指定 Cluster。支持权重分流、重定向、直接响应。	登机牌上的目的地标签
Cluster	定义一组提供相同服务的上游主机集合，以及连接池、负载均衡策略、健康检查等行为。	飞往同一城市的航班机组
Endpoint	Cluster 中具体的上游主机实例（IP:Port），是流量的最终目的地。	航班上的具体座位

关键原则： 在 GitOps 场景下，这四个组件的配置通常以 Kubernetes CRD（如 EnvoyProxy、HTTPRoute）的形式存储在 Git 仓库中，通过控制器转换为 Envoy 原生 xDS 资源。

4.2 数据面与控制面分离架构

Envoy 原生采用 数据面（Data Plane） 与 控制面（Control Plane） 分离的架构。数据面负责处理实际流量，控制面负责下发配置与策略。这种分离带来了极致的扩展性与运维灵活性。

数据面（Envoy Proxy）：无状态、高性能转发。只负责执行，不负责决策。通过 xDS API 从控制面拉取最新的 Listener、Cluster、Route、Endpoint 配置。
控制面（如 Istio Pilot、Kuma CP、自定义 xDS Server）：有状态、集中决策。负责将用户意图（如 Istio VirtualService、DestinationRule）转换为 Envoy 可理解的 xDS 资源，并推送给所有数据面实例。

  GitOps 集成点： 控制面本身也可以作为 GitOps 的“Agent”。用户将网关配置提交到 Git 仓库，GitOps Operator（如 Argo CD）将配置同步到 Kubernetes 集群，控制面监听到 CRD 变化后，自动生成并推送 xDS 配置给 Envoy 数据面。

4.3 xDS 协议：控制面与数据面的通信桥梁

xDS（Discovery Service）是 Envoy 数据面与控制面之间的标准通信协议集合。每个核心组件对应一个独立的 xDS API：

LDS (Listener Discovery Service)：下发 Listener 配置。
RDS (Route Discovery Service)：下发 Route 配置。
CDS (Cluster Discovery Service)：下发 Cluster 配置。
EDS (Endpoint Discovery Service)：下发 Endpoint 配置。

控制面通过 gRPC 流或 REST-JSON 将配置推送给 Envoy。Envoy 在收到新配置后，会优雅地热更新，不中断现有连接。

GitOps 实践注意： 当使用 GitOps 管理 Envoy 配置时，控制面本身也需要被 GitOps 管理。确保控制面的 CRD 定义（如 Istio Operator、Kuma CRDs）与 Envoy 数据面版本兼容，避免因 xDS 版本不匹配导致配置下发失败。

4.4 核心组件配置示例（静态文件）

以下是一个简化的 Envoy 静态配置片段，展示了四个核心组件如何协同工作：

static_resources:
  listeners:
  - name: listener_http
    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: local_route
            virtual_hosts:
            - name: backend
              domains: ["*"]
              routes:
              - match: { prefix: "/api" }
                route: { cluster: service_cluster }
          http_filters:
          - name: envoy.filters.http.router

  clusters:
  - name: service_cluster
    connect_timeout: 0.25s
    type: STRICT_DNS
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: service_cluster
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address: { address: 10.0.0.1, port_value: 80 }
        - endpoint:
            address:
              socket_address: { address: 10.0.0.2, port_value: 80 }

  GitOps 映射： 在 Kubernetes 环境中，上述静态配置通常由控制面自动生成。GitOps 仓库中存储的是更高级别的抽象（如 HTTPRoute），而非原始的 Envoy 配置。控制面负责将 HTTPRoute 转换为 RouteConfiguration，将 Backend 转换为 Cluster 和 Endpoint。

4.5 架构优势总结

热更新：通过 xDS 动态下发配置，Envoy 无需重启即可生效，适合频繁变更的 GitOps 流程。
可观测性：数据面暴露丰富的指标（请求数、延迟、错误率），控制面可集中采集并关联配置版本。
多租户隔离：每个数据面实例独立运行，控制面可以按租户或命名空间隔离配置。
声明式管理：控制面将 Git 仓库中的声明式配置（CRD）转换为 Envoy 原生配置，实现“配置即代码”。