Ingress 是 Kubernetes 里的一份“七层路由说明书”：用声明式 YAML 描述“哪个域名、哪条路径的 HTTP/HTTPS 请求，应该转发到集群内的哪个 Service”。重点是，它只是一份说明书，本身不具备任何流量转发能力。
打个比方。写字楼前台墙上贴着一张分机表：找财务拨 801，找人事拨 802。这张表就是 Ingress。真正把电话接过去的是机房里那台交换机，也就是 Ingress Controller。表贴得再漂亮，交换机没通电，电话照样打不通；交换机在跑，但没人往表上写新分机，新部门也接不进来。
工作机制是这样的：Ingress Controller 是跑在集群里的一个真实进程（常见实现有 Nginx Ingress Controller、Traefik、HAProxy，各家云厂商也都有自己的版本），它持续监听 API Server 上 Ingress 对象的变化，把规则翻译成自己认识的配置（比如重新生成 nginx.conf 再热加载），然后由这个进程实际承接外部流量、做 TLS 终止和转发。
IngressClass 解决的是“谁来管”的问题。一个集群里可能同时装着好几个控制器，IngressClass 就是给说明书盖章的部门名：Ingress 通过 spec.ingressClassName 声明自己归哪个控制器处理。如果没写，集群也没有标记默认 Class，这条规则就没人认领。
| 对象 | 是什么 | 干活吗 |
|---|---|---|
| Ingress | 七层路由规则的声明 | 不干活，只描述意图 |
| Ingress Controller | 真正的代理与负载均衡进程 | 干活，读规则并执行 |
| Service | 集群内一组 Pod 的稳定访问入口（四层） | 是 Ingress 的转发目标 |
| IngressClass | 标记规则归属哪个控制器 | 分配任务 |
对从业者的实际意义，可以归结为一句话：规则写了不生效，先查控制器，再查 IngressClass。具体顺序是：kubectl get ingress 看 ADDRESS 一栏是否为空，kubectl describe 看 Events 有没有报错；确认控制器 Pod 是否在运行、日志里有没有异常；确认 ingressClassName 写没写、拼没拼错、集群里有没有默认 Class；最后确认后端 Service 名称和端口对得上。
还有一个容易忽略的地方：Ingress 的很多高级能力靠注解（annotations）实现，而注解是各控制器自己定义的，换一个控制器往往要重写一遍。如果业务需要更细的灰度切流、TCP/UDP 路由，可以评估一下 Gateway API。具体字段和支持范围以官方文档为准。