1. Ingress控制器概述
1.1 Ingress概念
Ingress是Kubernetes原生的API资源对象，用于管理集群外部访问集群内服务的HTTP和HTTPS路由规则。它位于集群边缘，充当流量入口的统一网关，将外部请求按域名、路径等规则转发至内部Service。
核心定义：Ingress定义了从集群外部到集群内部服务的HTTP(S)路由规则集合，是七层（应用层）流量治理的标准化抽象。
1.2 Ingress控制器作用
Ingress资源本身仅声明路由规则，真正实现流量转发需要部署Ingress控制器。控制器作为集群内的Pod运行，持续监听Ingress、Service、Endpoint等资源变化，动态生成反向代理配置（如Nginx、Envoy配置），并负责实际的流量接入与转发。
- 规则解析：读取Ingress资源中的host、path、backend等字段，构建路由映射表。
- 配置生成：将路由映射转换为底层代理软件（如Nginx、HAProxy）的配置文件。
- 动态更新：监听资源变更，热更新代理配置，无需重启或重载整个进程。
- 流量接入：作为集群的流量入口，接收外部请求并转发至对应的Service后端Pod。
- 高级特性：支持TLS终止、虚拟主机、路径重写、会话保持、速率限制等。
1.3 Ingress与Service的关系
Ingress与Service是互补而非替代的关系。Service提供四层（TCP/UDP）负载均衡与Pod选择能力，Ingress在Service之上提供七层路由与域名管理。
| 对比维度 | Service（ClusterIP/NodePort） | Ingress |
|---|---|---|
| 层级 | 四层（传输层） | 七层（应用层） |
| 路由粒度 | IP + 端口 | 域名 + 路径 + HTTP头 |
| TLS终止 | 不支持 | 原生支持 |
| 虚拟主机 | 不支持 | 支持多域名共享同一IP |
| 路径重写 | 不支持 | 支持（如 /api → /） |
| 典型场景 | 内部服务间通信、TCP/UDP协议 | 外部HTTP(S)流量、微服务网关 |
最佳实践：Ingress作为集群入口，后端必须指向Service。Service负责将流量分发至Pod，Ingress负责智能路由。两者配合形成“Ingress → Service → Pod”的三层流量模型。
1.4 Ingress控制器选型对比
社区存在多种Ingress控制器实现，选型需综合考虑性能、功能、生态、运维复杂度等因素。以下为主流控制器的核心对比：
| 控制器 | 底层引擎 | 性能 | 功能丰富度 | 社区活跃度 | 典型场景 |
|---|---|---|---|---|---|
| Nginx Ingress | Nginx + Lua | 高 | 高 | 极高（K8s官方维护） | 通用场景、中小规模集群 |
| Traefik | Go自研 | 中高 | 高 | 高 | 微服务、动态配置、自动发现 |
| HAProxy Ingress | HAProxy | 极高 | 中 | 中 | 高并发、TCP/UDP混合流量 |
| Envoy Ingress | Envoy | 高 | 极高 | 高 | 服务网格、高级流量治理 |
| Kong Ingress | OpenResty + 插件 | 中高 | 极高（插件生态） | 高 | API网关、认证限流、插件扩展 |
选型注意：Ingress控制器并非Kubernetes内置组件，需要自行部署。不同控制器的Annotation语法、配置方式、CRD扩展差异较大，切换成本较高。建议在项目初期根据团队技术栈和业务规模选定后长期使用，避免频繁更换。