一、核心区别(一句话)
- Service :四层(TCP/UDP) 稳定入口、服务发现、内部负载均衡。
- Ingress :七层(HTTP/HTTPS) 统一网关、域名 / 路径路由、SSL 终结、多服务复用入口。
二、详细对比
| 维度 | Service | Ingress |
|---|---|---|
| 网络层级 | 四层(传输层) | 七层(应用层) |
| 核心作用 | 固定 Pod 访问、内部 LB | 外部 HTTP 路由、多服务统一入口 |
| 协议 | TCP/UDP/SCTP | HTTP/HTTPS/HTTP/2 |
| 外部暴露 | NodePort/LoadBalancer(单服务) | 统一公网 IP / 域名(多服务共享) |
| SSL | 不支持(Pod 自己处理) | 支持统一 SSL 终结 |
| 路由 | 仅端口转发 | 域名、路径、Header 路由 |
| 依赖 | 原生(kube-proxy) | 必须部署 Ingress Controller |
| 关系 | 底层服务端点 | 上层网关(必须指向 Service) |
三、Service 类型与使用
1. 四种常用类型
-
ClusterIP(默认) 集群内部访问,不对外暴露。场景:微服务内部调用、数据库 / 缓存。
-
NodePort节点 IP + 固定端口对外暴露。场景:测试、简单外部访问。
-
LoadBalancer云厂商负载均衡,公网 IP。场景:单服务对外、云环境。
-
Headless无 ClusterIP,直接解析 Pod IP。场景:StatefulSet、数据库集群。
2. Service 示例(ClusterIP)
apiVersion: v1
kind: Service
metadata:
name: my-app-svc
spec:
selector:
app: my-app
ports:
- port: 80 # Service端口
targetPort: 8080 # Pod端口
type: ClusterIP
四、Ingress 与使用
1. 原理
- Ingress 资源:路由规则(域名、路径、SSL)。
- Ingress Controller:执行引擎(Nginx/Traefik/Envoy)。
- 流量路径 :
用户 → Ingress Controller → Service → Pod
2. Ingress 示例(Nginx)
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-app-ingress
annotations:
kubernetes.io/ingress.class: "nginx"
spec:
rules:
- host: app.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: my-app-svc # 必须指向Service
port:
number: 80
五、使用场景(怎么选)
✅ 用 Service
- 集群内微服务互相调用(ClusterIP)
- 暴露非 HTTP 服务:MySQL、Redis、MQ(TCP/UDP)
- 简单测试:临时用 NodePort
- 云厂商单服务公网:LoadBalancer
✅ 用 Ingress(+ Service)
- 生产 Web/API:多服务共用一个公网入口
- 域名路由:
a.com→svc1、b.com→svc2 - 路径拆分:
/api→api-svc、/web→web-svc - 统一 HTTPS / 证书、限流、重写、认证
- 省钱:减少云 LB 数量
六、总结
- Service 是基础:每个应用都要有,提供稳定端点。
- Ingress 是网关 :HTTP/HTTPS 外部入口,必须基于 Service。
- 最佳实践:
- 内部:ClusterIP Service
- 外部 Web:Ingress + ClusterIP Service
- 非 HTTP:LoadBalancer / NodePort Service