3. Ingress 控制器架构深度解析：数据平面与控制平面分离、Ingress 资源对象到实际配置的转换流程

在生产环境中，Ingress 控制器是南北向流量的核心网关。理解其内部架构——特别是数据平面与控制平面的分离机制，以及从声明式 Ingress 资源到实际代理配置的转换流程——是诊断延迟、优化性能的基础。本章将深入剖析这两大核心机制。

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

现代 Ingress 控制器（如 NGINX Ingress Controller、Traefik、Envoy-based 控制器）普遍采用控制平面与数据平面分离的设计。这种架构带来了弹性伸缩、故障隔离和独立升级的能力。

• 控制平面 (Control Plane)：运行在 Kubernetes Pod 中，负责监听 API Server 的 Ingress、Service、Endpoint、Secret 等资源变化，生成并下发配置。它不处理实际的用户流量。
• 数据平面 (Data Plane)：负责处理实际的 HTTP/HTTPS 请求。通常由高性能反向代理（如 NGINX、Envoy、HAProxy）构成，执行路由、负载均衡、TLS 终止、限流等操作。

3.2 Ingress 资源对象到实际配置的转换流程

当用户创建或更新一个 Ingress 资源时，控制器内部会经历一个严谨的转换流水线，最终生成数据平面可执行的配置（如 nginx.conf、Envoy 的 cds/lds 资源）。理解这个流程有助于定位配置生效延迟或路由错误。

3.2.1 核心转换步骤

1. 资源监听与事件触发：控制平面通过 Informer 机制监听 Ingress、Service、Endpoint、Secret 等资源的变化。任何变更都会触发 reconciliation 循环。
2. Ingress 对象解析与校验：解析 Ingress 的 spec.rules、spec.tls、metadata.annotations。校验后端 Service 是否存在、TLS Secret 是否有效。
3. 构建内部模型 (Internal Model)：将多个 Ingress 资源合并、去重、排序，构建一个统一的内部路由模型。这一步会处理冲突的路径、优先级、正则表达式。
4. 生成数据平面配置：根据内部模型，结合控制器自身的全局配置（如 ConfigMap），生成数据平面特定的配置结构（如 NGINX 的 Upstream 块、Server 块）。
5. 配置下发与生效：将生成的配置写入数据平面。对于 NGINX，通常通过 reload 或 lua-resty 热更新；对于 Envoy，通过 xDS 协议推送增量更新。

3.3 关键配置转换细节对比

不同的 Ingress 控制器在配置转换的细节上存在显著差异，这些差异直接影响延迟和运维复杂度。下表对比了主流控制器的实现方式。

3.4 配置转换流程中的延迟关键点

从 Ingress 资源创建到流量路由生效，整个流程中存在多个潜在的延迟点。作为 SRE，需要对这些点进行监控和优化。

• API Server 到 Informer 的延迟：Watch 事件的网络延迟或 Informer 的缓存落后。可通过 kubectl describe ingress 观察 Events 的时间戳。
• Reconciliation 队列积压：当集群中 Ingress 资源数量巨大或变更频繁时，控制平面的工作队列可能积压。监控 work_queue_depth 指标。
• 内部模型构建复杂度：复杂的 Annotation 解析、正则路由、跨 Namespace 引用会增加 CPU 开销和构建时间。
• 配置下发与生效时间：对于 reload 型控制器，这是最大的延迟来源。需要监控 reload_seconds 和 reload_errors。