Ingress-nginx中nginx是受ingress-nginx-controller驱动的动态反向代理引擎，控制器监听API变更、生成并重载nginx.conf，nginx仅执行配置不参与决策，手动修改配置会被覆盖。
nginx 在 K8s Ingress 中不是单纯的服务代理，而是由 ingress-nginx-controller 驱动的、动态生成并实时 reload 的反向代理引擎。它本身不直接读取 Kubernetes API，真正起调度作用的是控制器组件；nginx 只是被写入配置、执行转发的“执行层”。
ingress-nginx-controller 是配置生成与热更新的核心
ingress-nginx-controller 以 Pod 形式运行，持续监听 Kubernetes API Server 中的 Ingress、Service、Endpoint 等资源变化。一旦检测到新增、修改或删除操作，它会：
- 解析 Ingress 资源中定义的 host、path、TLS 配置等规则
- 结合后端 Service 的 selector 和 Endpoint 的实际 Pod IP 列表，生成精确的 upstream 块
- 将最终生成的 nginx.conf（含 server 块、location 块、proxy_pass、SSL 设置等）写入容器内 /etc/nginx/nginx.conf
- 调用 nginx -s reload 触发平滑重载，不中断现有连接
nginx 本身只负责执行，不参与决策
Pod 内的 nginx 进程不主动感知集群状态，也不解析 YAML 或调用 API。它的配置完全由控制器注入，行为完全受控于：
- Ingress 资源声明的路由逻辑（如 host: api.example.com → service: api-svc）
- ConfigMap 中的全局参数（如 proxy-read-timeout、http-snippets）
- Annotation 中的单资源定制（如 nginx.ingress.kubernetes.io/rewrite-target: /v1）
这意味着：删掉一个 Ingress 对象，控制器会在几秒内移除对应 server 块；改一个 annotation，reload 后 nginx 就按新规则转发——整个过程无需人工介入 nginx 进程或配置文件。
配置生效链条清晰可追溯
从用户定义到流量落地，完整链路为：
- 你编写 ingress.yaml（含 host/path/backend）→ 提交到集群
- ingress-nginx-controller 拉取变更 → 渲染出 nginx 配置片段
- 覆盖写入 /etc/nginx/nginx.conf → 执行 nginx -s reload
- 外部请求命中 host + path → nginx 匹配 location → proxy_pass 到 service 的 ClusterIP → kube-proxy 转发至真实 Pod
这个链条里没有静态文件维护，没有手动 reload，也没有跨组件配置同步问题——所有动态性都来自控制器对 API 的响应式编程。
为什么不能直接改 nginx.conf？
因为控制器会定期或在下一次变更时覆盖该文件。任何手动编辑都会在下次 Ingress 更新或控制器重启后丢失。真正持久化配置的方式只有两种：
- 通过 Ingress resource 的 annotations 控制单条路由行为
- 通过 kube-system/nginx-configuration ConfigMap 控制全局行为（如启用 gzip、自定义 error_page）
绕过这套机制等于脱离 Kubernetes 声明式管控，失去自动同步能力，也违背 Ingress 设计初衷。
