nginx ingress controller 的核心作用是将 kubernetes 声明式路由规则实时转化为动态生效的七层反向代理行为：它通过 watch 机制监听 ingress 资源变更，动态生成并热加载 nginx 配置，依赖 service/endpoints 自动同步后端 pod 列表，且需通过 loadbalancer、nodeport 或 daemonset 等方式暴露至集群外部以接收流量。
云原生架构下，Nginx Ingress Controller 的核心作用是把 Kubernetes 的声明式路由规则，实时转化为可执行的七层反向代理行为。它不是静态配置的网关，而是一个持续感知、自动适配、动态生效的控制平面组件。
它监听并响应 Ingress 资源变化
Ingress Controller 以 Pod 形式运行在集群中，启动后立即与 Kubernetes API Server 建立长连接（watch 机制），持续监听 Ingress 和 IngressClass 资源的创建、更新与删除事件。一旦检测到变更，就触发全量或增量配置重建流程。
它动态生成并热加载 Nginx 配置
控制器内部包含一个配置生成器，会将所有匹配当前 IngressClass 的 Ingress 规则（含 host、path、TLS 设置、重写策略等）解析为标准 Nginx 配置片段。这些片段被组合成完整的 /etc/nginx/nginx.conf 或分文件结构，并直接写入自身容器的文件系统。随后调用 nginx -s reload 实现零中断热更新——整个过程无需重启进程，毫秒级生效。
它依赖 Service 和 Endpoints 定位真实后端
Ingress 规则中指定的 serviceName 和 servicePort 并不直接指向 Pod，而是交由 Kubernetes 的 Service 抽象层处理。Controller 通过查询对应 Service 的 Endpoints 对象，获取当前健康、就绪的 Pod IP+Port 列表，并将其作为 upstream server 写入 Nginx 配置。这意味着：Pod 扩缩容、滚动更新、故障剔除，都会被自动反映在 Nginx 的 upstream 中。
它本身需要被外部流量访问到
Ingress Controller 自身必须暴露在集群外部，常见方式包括：
- LoadBalancer 类型 Service：云厂商自动分配公网 IP 和 CLB，流量经四层负载均衡直达 Controller Pod
- NodePort + 外部 LB：在各节点开放固定端口，再由外部硬件/云 LB 转发至任意节点的 NodePort
- DaemonSet + HostNetwork：每个节点直接监听宿主机 80/443 端口，适合高性能或网络受限场景
无论哪种方式，最终目标都是让外部 HTTP/HTTPS 请求能抵达 Nginx 进程，由其依据已加载的配置完成域名匹配、路径路由、SSL 终止、Header 改写等 L7 处理，再转发至后端 Service。
