1. Ingress概述:什么是Ingress、Ingress与Service的关系、Ingress Controller的作用
1.1 什么是Ingress
在Kubernetes集群中,Ingress是一种API资源对象,用于管理从集群外部到集群内部服务的HTTP/HTTPS路由。它提供了基于域名、路径、TLS证书等规则的流量分发能力,是Kubernetes官方推荐的七层(应用层)流量入口方案。
核心定义:Ingress定义了从集群外部访问内部服务的规则集合,包括主机名、URL路径、后端Service映射以及TLS配置。
Ingress解决了以下关键问题:
- 统一入口:多个Service共享一个公网IP和端口,避免为每个Service创建独立的负载均衡器。
- 七层路由:支持基于域名(Host)和路径(Path)的精细化流量分发。
- TLS终止:在入口层统一管理SSL/TLS证书,后端Service无需处理加密。
- 虚拟主机:同一IP下托管多个域名,每个域名指向不同的后端服务。
1.2 Ingress与Service的关系
Ingress与Service是互补而非替代的关系。Service负责集群内部的负载均衡和Pod发现,而Ingress负责集群外部的七层路由和流量治理。下表清晰展示了两者的职责边界:
| 对比维度 | Service | Ingress |
|---|---|---|
| 层级 | 四层(TCP/UDP) | 七层(HTTP/HTTPS) |
| 路由粒度 | IP + 端口 | 域名 + 路径 |
| 外部访问方式 | NodePort / LoadBalancer | 通过Ingress Controller暴露 |
| TLS支持 | 不支持(需自行实现) | 原生支持TLS终止 |
| 负载均衡 | Pod级别轮询 | 支持会话保持、重写、限流等高级策略 |
| 典型场景 | 内部服务间通信、TCP/UDP协议 | Web应用、REST API、微服务网关 |
最佳实践:Ingress不直接访问Pod,而是将流量转发到对应的Service。Service再通过标签选择器将请求分发到后端Pod。因此,Ingress + Service + Pod构成了完整的三层流量模型。
1.3 Ingress Controller的作用
Ingress资源本身只是一个声明式规则定义,并不具备流量转发能力。真正执行这些规则的是Ingress Controller——一个运行在集群中的反向代理或负载均衡器软件。
Ingress Controller的核心职责包括:
- 监听Ingress资源:通过Kubernetes API实时监控Ingress、Service、Secret等资源的变化。
- 动态配置代理规则:将Ingress规则转换为Nginx、HAProxy、Traefik等代理软件的配置文件。
- 流量转发:接收外部请求,根据配置的域名和路径规则将流量路由到对应的后端Service。
- TLS终止:加载Secret中的证书,解密HTTPS请求后以HTTP转发给后端。
- 健康检查与高可用:监控后端Pod状态,自动剔除故障节点。
下图展示了Ingress、Ingress Controller、Service和Pod之间的完整协作关系:
1.4 常见Ingress Controller对比
社区中有多种成熟的Ingress Controller实现,选择时需考虑性能、功能特性和生态兼容性:
| Controller | 底层引擎 | 核心特性 | 适用场景 |
|---|---|---|---|
| Nginx Ingress | Nginx + Lua | 成熟稳定、配置灵活、社区活跃 | 生产环境首选,通用场景 |
| Traefik | Go自研 | 自动发现、支持多种协议、动态配置 | 微服务、服务网格、边缘路由 |
| HAProxy Ingress | HAProxy | 高性能、低延迟、TCP/UDP支持好 | 高吞吐量、四层/七层混合场景 |
| Kong Ingress | OpenResty | 插件生态丰富、API网关能力 | API管理、认证限流、可观测性 |
| Istio Ingress Gateway | Envoy | 服务网格原生、流量治理强大 | 服务网格架构、金丝雀发布 |
注意:Ingress Controller必须作为Pod运行在集群中,通常以Deployment + Service(LoadBalancer或NodePort)的方式部署。如果集群中没有运行任何Ingress Controller,创建的Ingress资源将不会生效。
1.5 最小Ingress示例
以下是一个完整的Ingress资源配置示例,展示了如何将域名 app.example.com 的流量路由到 my-service 的80端口:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: example-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
ingressClassName: nginx
rules:
- host: app.example.com
http:
paths:
- path: /api
pathType: Prefix
backend:
service:
name: my-service
port:
number: 80
- path: /
pathType: Prefix
backend:
service:
name: web-service
port:
number: 8080
tls:
- hosts:
- app.example.com
secretName: app-tls-secret
该配置的关键要素:
- ingressClassName:指定使用哪个Ingress Controller(本例为nginx)。
- rules:定义路由规则,每个rule包含host和paths。
- pathType:支持
Prefix(前缀匹配)和Exact(精确匹配)。 - tls:配置HTTPS证书,证书存储在名为
app-tls-secret的Secret中。
关键理解:Ingress是Kubernetes集群的流量入口抽象层,它将外部请求的七层路由规则与内部Service解耦。Ingress Controller则是这个抽象层的执行引擎,负责将声明式规则转化为实际的流量转发行为。两者配合,实现了集群入口的标准化、可扩展和可治理。