Ingress 与 Controller 的关系
Ingress 只是一份路由规则声明，真正干活的是 Ingress Controller：它监听 Ingress 对象的变化并生成反向代理配置。集群里通常只装一种主 controller；IngressClass 用来声明实现类，Ingress 通过 ingressClassName 关联到具体 controller。多套 controller 并存时，类不匹配的规则不会被任何一方处理，表现就是规则看着没问题但请求返回 404。
基本信息
| 部署形态 | 通常以 Deployment 或 DaemonSet 加 Service（LoadBalancer 或 NodePort）运行 |
|---|---|
| 真实入口 | controller 的 Service 拿到外部 IP 或端口，那才是用户实际访问的入口 |
| IngressClass | 声明实现类，可指定默认类；Ingress 通过 ingressClassName 关联 |
| 常见实现 | ingress-nginx、Traefik、云厂商的 LB Controller |
| 生效方式 | controller 监听到对象变化后重载配置，通常数秒到数十秒生效 |
| 行为差异 | 超时、上传大小、重定向等大多由注解控制，不同实现不通用 |
典型使用场景
- 用域名与路径把多个服务收敛到一个入口，减少暴露面
- TLS 终止与证书集中管理，后端服务只管明文 HTTP
- 灰度发布：按比例或按请求头分流到不同后端
- 多 controller 分工：内网与公网各一套，或按业务线隔离
- 配置默认 IngressClass 后简化规则，不必每条都写 className
查看与验证
查看与验证
kubectl get pods -n ingress-nginx # controller 是否在运行
kubectl get ingressclass # 有哪些实现类、谁是默认
kubectl get svc -n ingress-nginx ingress-nginx-controller # 外部 IP 才是入口
kubectl describe ingress web | tail -10 # 规则与后端解析结果
kubectl logs -n ingress-nginx deploy/ingress-nginx-controller --tail=50 # 转发与重载日志
curl -H 'Host: web.example.com' http://<入口IP>/ # 绕过 DNS 直接验证规则逐层排查顺序
| 层级 | 检查命令 | 典型症状 |
|---|---|---|
| 入口地址 | kubectl get svc -n ingress-nginx | 外部 IP 长时间 pending，说明 LB 未就绪 |
| controller | kubectl get pods -n ingress-nginx | Pod 未就绪时所有请求连接被拒或 502 |
| IngressClass | kubectl get ingressclass | 类不匹配时规则被忽略，返回 404 |
| 规则与 Service | kubectl describe ingress web | 后端端口或名称写错时返回 502 |
| Endpoints 与 Pod | kubectl get endpoints | 为空说明 selector 错或就绪探针未通过 |
controller 的 Service 一旦以公网负载均衡或 NodePort 暴露，入口就等于对全网开放：需要配合安全组限制来源、只放开 80 与 443，必要时叠加 WAF，避免后端服务被直接扫描。
接入链路要按层排查：LB 或 NodePort → controller → Ingress 规则 → Service → Endpoints → Pod，任一层断掉都表现为 404、502 或超时。注解在不同实现间不通用，换 controller 时注解要一并迁移，否则会被静默忽略。