主题
第11章 Ingress 与 Service 的关系
Ingress 不是 Service 类型,而是基于 HTTP/HTTPS 的七层路由规则。本章讲解 Ingress 如何与 Service 协作,实现统一的集群入口。
11.1 为什么需要 Ingress
假设你有 10 个微服务,每个服务都要外部访问。如果都用 LoadBalancer:
- 需要 10 个外部 IP。
- 成本高。
- 管理复杂。
Ingress 可以基于域名和路径将流量路由到不同的 Service,多个服务共享一个入口。
11.2 Ingress 架构
text
Internet
│
▼
┌─────────────┐
│ Ingress │ <- Ingress Controller (e.g., NGINX)
│ Controller │
└──────┬──────┘
│
▼
┌─────────────┐
│ Service │ <- 四层 ClusterIP/NodePort
│ ClusterIP │
└──────┬──────┘
│
▼
Backend PodsService 是四层的,Ingress 是七层的。Ingress 最终依赖 Service 将流量转发到 Pod。
11.3 Ingress 资源示例
yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: example-ingress
spec:
rules:
- host: api.example.com
http:
paths:
- path: /users
pathType: Prefix
backend:
service:
name: user-service
port:
number: 80
- path: /orders
pathType: Prefix
backend:
service:
name: order-service
port:
number: 80含义:
api.example.com/users/*-> user-service:80api.example.com/orders/*-> order-service:80
11.4 Ingress Controller
Ingress 资源只是规则,真正执行路由的是 Ingress Controller。常见的有:
| Controller | 特点 |
|---|---|
| NGINX Ingress Controller | 最常用,功能丰富 |
| Traefik | 云原生,支持动态配置 |
| HAProxy | 高性能 |
| Istio Gateway | 服务网格场景 |
Ingress Controller 本身通常通过 LoadBalancer 或 NodePort 暴露到外部。
11.5 Ingress 背后的 Service 类型
Ingress 通常指向 ClusterIP 类型的 Service:
yaml
apiVersion: v1
kind: Service
metadata:
name: user-service
spec:
type: ClusterIP
selector:
app: user
ports:
- port: 80
targetPort: 8080因为 Ingress Controller 已经在集群内部,可以直接用 ClusterIP 访问后端 Service。
11.6 Ingress vs LoadBalancer
| 特性 | Ingress | LoadBalancer |
|---|---|---|
| 层级 | 七层(HTTP/HTTPS) | 四层(TCP/UDP) |
| 基于域名/路径路由 | ✅ | ❌ |
| 多个服务共享入口 | ✅ | ❌ |
| SSL 终止 | ✅ | 部分云厂商支持 |
| 适用场景 | Web 应用、API 网关 | 非 HTTP 协议、TCP 服务 |
11.7 本章小结
- Ingress 是七层路由规则,不是 Service 类型。
- Ingress Controller 执行规则,将流量按域名/路径转发到 Service。
- Ingress 通常指向 ClusterIP Service。
- Web 应用优先用 Ingress,非 HTTP 协议可用 LoadBalancer。
本章练习
- 在你的测试集群部署 NGINX Ingress Controller。
- 创建两个 ClusterIP Service,再用一个 Ingress 按路径路由到它们。
- 配置本地 hosts,通过域名访问 Ingress。