Ingress 是 Kubernetes 中专为 HTTP/HTTPS 设计的七层统一入口，作为 Service 的“总闸门”，通过 Ingress 资源定义路由规则，由 Ingress Controller（如 nginx-ingress）实时编译生效，支持基于域名、路径等智能路由，以及 TLS 终止、路径重写、限流、灰度发布等治理能力。
Ingress 是 Kubernetes 中专为 HTTP/HTTPS 流量设计的统一入口，它不替代 Service，而是站在 Service 之上，把多个服务“收口”到一个或少数几个公网 IP 和端口下，实现基于域名、路径、请求头等七层信息的智能路由。
核心定位：Service 的“总闸门”
Service 只能做四层（TCP/UDP）转发，比如固定端口映射；而 Ingress 工作在七层（HTTP/HTTPS），能看懂请求里的 Host、Path、Cookie 甚至 Header。这意味着：
- 一个公网 IP + 80/443 端口，就能承载 dozens 个不同域名的服务（如 api.example.com、admin.example.com、static.example.com）
- 同一域名下，不同路径可指向不同后端（如 /v1/users → user-service，/assets → cdn-service）
- 无需为每个服务单独申请 LoadBalancer 或规划 NodePort 端口，避免资源浪费和端口冲突
工作依赖：Ingress 资源 + Ingress Controller 缺一不可
Ingress 本身只是 YAML 定义的一组规则（类似说明书），真正干活的是 Ingress Controller（如 nginx-ingress、Traefik、Istio Gateway）。两者关系如下：
- Ingress 资源：声明“我要怎么路由”，例如 “所有访问 shop.myapp.io 且路径以 /api 开头的请求，转发给 api-svc:80”
- Ingress Controller：持续监听集群中 Ingress、Service、Endpoint、Secret 等资源变化，把规则实时编译成 Nginx/Envoy 配置，并热加载生效
- 没有 Controller，Ingress 资源只是静态文本，不会产生任何流量效果
关键能力支撑统一入口
真正让 Ingress 成为“统一入口”的，不只是路由，还包括配套的七层治理能力：
- TLS 终止：在入口处统一卸载 HTTPS，用 Secret 挂载证书，后端服务可继续用 HTTP，简化部署
- 路径重写与转发：如将 /api/v1/→ /v1/，适配后端服务的实际路径结构
- 跨域（CORS）、限流（RateLimit）、自定义错误页：集中配置，避免每个服务重复实现
- 灰度与金丝雀：通过 annotation 或 CRD 控制部分流量切到新版本服务，无需改应用代码
典型部署示意
外部用户访问 https://app.company.com/login：
- DNS 解析到 Ingress Controller 所在的 LoadBalancer 或 NodeIP
- Ingress Controller 接收请求，匹配 Ingress 规则中的 host: app.company.com 和 path: /login
- 查找到对应后端 Service（如 auth-svc），再通过 Endpoint 找到真实 Pod IP
- 完成 TLS 解密、Header 注入、日志记录后，将请求代理至目标 Pod
