控制器做了什么
Ingress 只是一份声明式的路由意图，真正让它落地的是 Ingress Controller：它监听 Ingress、Service、Secret、Endpoints 等对象的变化，把规则渲染成反向代理（多数实现是 nginx、Traefik、Envoy 等）的配置并热加载，同时自身作为数据面承接全部入口流量。它通常由两部分组成——控制器进程与承接流量的 Service（LoadBalancer 或 NodePort），两者都健康时入口才可用。
基本信息
| 常见实现 | ingress-nginx、Traefik、HAProxy Ingress、Contour、云厂商实现 |
|---|---|
| 组成 | 控制器工作负载（Deployment 或 DaemonSet）+ 承接流量的 Service |
| 数据面 | 进程把规则渲染为代理配置并 reload |
| 配置来源 | Ingress 对象、Service、TLS Secret、控制器自身的 ConfigMap |
| 高可用 | 多副本 + 反亲和 + PodDisruptionBudget，外部入口由 LB 或 VIP 提供 |
典型使用场景
- 域名接入：为业务提供统一的七层入口，按 host 与 path 分发到不同 Service
- TLS 终止：在入口处统一加载证书，业务容器不必各自处理证书
- 统一出入口治理：限流、超时、重试、访问日志在入口层集中配置
- 灰度与切流：通过权重、灰度注解或独立 Ingress 对象逐步放量
- 排障入口链路：先看控制器是否健康，再看上游 LB 是否指向健康节点
健康检查路径
健康检查路径
kubectl -n ingress-nginx get deploy,pods,svc # 控制器、Pod 与入口 Service
kubectl -n ingress-nginx get pods -o wide # 分布在哪几个节点
kubectl -n ingress-nginx logs deploy/ingress-nginx-controller --tail=30
kubectl -n ingress-nginx rollout status deploy/ingress-nginx-controller
kubectl get ingressclass # 集群里有哪些入口实现，谁在管你的规则入口故障分层
| 层 | 表现 | 检查点 |
|---|---|---|
| 外部入口 | 域名解析到地址但连接超时 | LB 是否指向健康节点、安全组与端口放行 |
| 控制器工作负载 | 入口返回 502 或 503 | 控制器 Pod 是否就绪、日志有无后端连接错误 |
| 规则渲染 | 路由不符预期或全部落到默认后端 | Ingress 是否被控制器认领、ingressClassName 是否匹配 |
| 后端服务 | 部分路径 502 | 对应 Service 的 Endpoints 是否为空 |
控制器通常部署在自己的命名空间（例如 ingress-nginx），与业务不在同一个命名空间。排查时不要只在自己业务命名空间里找 Pod，同时注意服务可能由多个入口实现共同管理，用 IngressClass 确认哪一个是这套规则的执行者。
控制器是全局共享组件：升级或重启会影响集群里所有入口站点，必须安排在窗口期，并确认多副本滚动策略、反亲和与 PDB 都已配置，避免滚动时出现入口完全不可用的空档。