Ingress 控制器基础：Nginx Ingress 与 Kong Ingress 架构对比
在生产集群中，Ingress 控制器是南北向流量的核心入口。不同的控制器在架构设计、组件构成和 Watch 机制上存在显著差异，直接影响调试策略和升级窗口的稳定性。本节从架构对比入手，深入分析 Nginx Ingress 与 Kong Ingress 的核心组件与工作原理。
一、核心组件与 Watch 机制
所有 Ingress 控制器都遵循相同的控制循环模式：通过 Watch 机制监听 Kubernetes API Server 中的资源变化，然后将期望状态同步到数据平面。下图展示了通用的 Ingress 控制器控制循环架构：
调试要点： Watch 连接中断或事件丢失是升级窗口中最常见的故障模式。调试时应优先检查 Controller 与 API Server 之间的 Watch 连接状态，以及事件处理队列的积压情况。
二、Nginx Ingress 架构详解
Nginx Ingress 是 Kubernetes 生态中最成熟的 Ingress 控制器，基于 Nginx 反向代理实现。其架构分为控制平面和数据平面，两者通常运行在同一个 Pod 中。
2.1 核心组件
| 组件 | 角色 | 关键行为 |
|---|---|---|
| Ingress Controller | 控制循环主进程 | Watch Ingress/Service/Endpoint/Secret 资源；生成 nginx.conf；通过 reload 或 lua 热更新应用配置 |
| Nginx 进程 | 数据平面 | 接收 HTTP/HTTPS 流量；执行反向代理、负载均衡、SSL 终止；通过共享内存与 Controller 通信 |
| Lua 脚本 (nginx.tmpl) | 配置模板引擎 | Controller 使用 Go 模板生成 nginx.conf；Lua 脚本在运行时处理动态路由和变量注入 |
| Leader Election | 高可用选主 | 多副本部署时通过 Endpoint 或 ConfigMap 选主，仅 Leader 执行 Watch 和配置生成 |
2.2 配置生成与热加载
Nginx Ingress 的配置更新流程是调试升级窗口的关键路径：
- 事件触发： Ingress 资源变更 → API Server 推送 Watch 事件到 Controller 的 workqueue。
- 配置渲染： Controller 从 workqueue 取出事件，读取所有关联 Ingress 规则，调用
nginx.tmpl模板生成新的nginx.conf。 - 校验与写入： 新配置写入临时文件，执行
nginx -t语法校验；校验通过后覆盖正式配置文件。 - Reload 或热更新： 默认执行
nginx -s reload重启 worker 进程；启用 Lua 模式时通过共享内存动态更新路由，避免 reload。
# 调试常用命令：查看 Controller 日志中的配置生成事件
kubectl logs -n ingress-nginx deployment/ingress-nginx-controller | grep -E "ConfigMap|reload|sync"
# 查看当前 nginx.conf 内容（需进入 Pod）
kubectl exec -n ingress-nginx deployment/ingress-nginx-controller -- cat /etc/nginx/nginx.conf | head -100
升级窗口风险： Nginx Ingress 的 reload 操作会导致 worker 进程重启，造成瞬时连接中断（通常 1-3 秒）。在流量高峰期或大规模配置变更时，reload 频率过高可能引发 502/504 错误。建议使用
--enable-dynamic-configuration 启用 Lua 热更新模式。
三、Kong Ingress 架构详解
Kong Ingress 基于 OpenResty 和 Lua 构建，采用控制平面与数据平面分离的架构。其核心优势在于动态路由能力，无需 reload 即可生效。
3.1 核心组件
| 组件 | 角色 | 关键行为 |
|---|---|---|
| Kong Ingress Controller (KIC) | 控制平面 | Watch Ingress/Custom Resource (CRD)；通过 Admin API 将配置推送到 Kong 数据平面 |
| Kong Gateway (Proxy) | 数据平面 | 运行 OpenResty；通过 Admin API 接收路由、服务、上游等配置；支持声明式配置（DB-less 模式） |
| Admin API | 配置接口 | KIC 通过 HTTP 调用 Admin API 创建/更新/删除路由、服务、上游、插件等对象 |
| KongPlugin CRD | 插件扩展 | 用户通过 CRD 定义插件配置；KIC 将其转换为 Admin API 调用，动态注入到路由或服务中 |
3.2 动态配置与 DB-less 模式
Kong 支持两种配置模式，在升级窗口中的行为差异显著：
- DB 模式： 配置持久化到 PostgreSQL 或 Cassandra；KIC 通过 Admin API 写入数据库，Kong 从数据库读取配置。支持多节点配置共享，但数据库成为额外依赖。
- DB-less 模式： 配置以声明式 YAML/JSON 文件形式加载到 Kong 内存中；KIC 通过 Admin API 的
/config端点推送全量配置。无需数据库，配置变更即时生效，无 reload 开销。
# 调试常用命令：查看 KIC 日志中的配置同步事件
kubectl logs -n kong deployment/ingress-kong | grep -E "Admin API|config|sync|reconfigure"
# 查看当前 Kong 路由配置（通过 Admin API）
kubectl exec -n kong deployment/kong-gateway -- curl -s http://localhost:8001/routes | jq .
升级窗口优势： Kong 在 DB-less 模式下配置变更完全动态，无需 reload 或重启 worker 进程，连接零中断。这是 Nginx Ingress 与 Kong Ingress 在升级窗口演练中最关键的架构差异。
四、架构对比总结
下表从调试和升级窗口角度，对比两种控制器的核心差异：
| 对比维度 | Nginx Ingress | Kong Ingress |
|---|---|---|
| 配置生效方式 | Reload worker 进程（默认）或 Lua 热更新 | Admin API 动态更新，无 reload |
| 配置变更延迟 | 秒级（reload 耗时 + 事件队列积压） | 毫秒级（Admin API 即时生效） |
| 升级窗口连接中断 | 有（reload 时 1-3 秒中断） | 无（DB-less 模式） |
| Watch 资源类型 | Ingress/Service/Endpoint/Secret/ConfigMap | Ingress/Service/Endpoint/Secret + CRD (KongPlugin/KongIngress) |
| 调试入口 | Controller 日志 + nginx.conf 校验 + Prometheus metrics | KIC 日志 + Admin API 查询 + Kong 状态端点 |
| 多副本一致性 | Leader Election + 独立配置生成 | 共享 Admin API / 数据库，配置全局一致 |
两种架构在 Watch 机制上本质相同——都依赖 Controller 与 API Server 之间的 List/Watch 长连接。差异主要体现在配置推送到数据平面的路径上：Nginx Ingress 通过文件写入 + reload，Kong Ingress 通过 Admin API 动态注入。这一差异决定了升级窗口中的流量中断风险和调试关注点。