在Kubernetes中,Service和Pod是解耦的访问关系:Service为动态变化的Pod提供稳定的访问入口和负载均衡。
核心关系
1. 访问抽象层
-
Pod:最小部署单元,有独立IP但动态变化(重启/迁移会变)
-
Service:固定虚拟IP/DNS,作为Pod组的稳定代理
2. 标签选择器关联
Service通过selector匹配Pod标签:
yaml
# Service定义
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: myapp # 选择匹配此标签的Pod
ports:
- port: 80
targetPort: 9376
yaml
# Pod标签
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp # 被Service选中
spec:
containers:
- name: myapp
image: myapp:1.0
3. 负载均衡
Service自动将流量分发到所有匹配的Pod:
text
客户端 → Service (10.96.1.1)
↓ 负载均衡
+-------+-------+-------+
↓ ↓ ↓ ↓
Pod A Pod B Pod C Pod D
关键特性对比
| 特性 | Pod | Service |
|---|---|---|
| IP地址 | 动态变化(Pod IP) | 固定不变(ClusterIP) |
| 生命周期 | 短暂,随时可能重启 | 长期存在,独立于Pod |
| 网络标识 | 仅集群内可访问 | 可通过多种方式暴露(ClusterIP/NodePort/LB) |
| DNS名称 | 无独立DNS | 有DNS:<service>.<ns>.svc.cluster.local |
| 扩展性 | 水平扩展产生多个副本 | 自动发现所有副本Pod |
实际工作流程
-
创建Pod时:给Pod打上标签(如
app: frontend) -
创建Service时:设置selector匹配相同标签
-
Service Controller:
-
监控集群中Pod变化
-
维护Endpoint对象(Pod IP列表)
-
更新kube-proxy的iptables/ipvs规则
-
-
流量转发:
-
客户端访问Service IP/DNS
-
kube-proxy拦截并转发到实际Pod
-
访问方式示例
bash
# 集群内访问 curl http://my-service.default.svc.cluster.local # 端口映射(NodePort类型) curl http://<Node-IP>:30080 # 负载均衡(LoadBalancer类型) curl http://<云厂商提供的LB-IP>
特殊类型
-
Headless Service:
clusterIP: None,DNS直接返回Pod IP列表,用于有状态应用 -
ExternalName:将服务映射到外部DNS
-
无selector的Service:手动维护Endpoint,接入外部服务
总结
Pod是实际运行容器的载体,Service是访问这些容器的网络抽象。这种分离实现了:
-
动态扩缩容时客户端无需感知
-
服务发现和负载均衡
-
部署与访问的解耦
-
稳定的服务标识(DNS名称)
Service通过标签与Pod建立松耦合关系,使得Pod可以自由地创建、销毁、迁移,而服务访问始终保持稳定。

被折叠的 条评论
为什么被折叠?



