K8s 中，Service 是 定义 Pod 访问规则的抽象资源 ，核心作用是解决 Pod 动态变化（IP 漂移、扩缩容、故障重建）导致的访问问题，为一组功能相同的 Pod 提供稳定、统一的访问入口，同时实现负载均衡和服务发现。
一、核心问题：为什么需要 Service？
Pod 存在两个关键特性，直接导致无法直接对外提供服务：
- IP 动态变化：Pod 重启、重建、扩缩容后，IP 会重新分配（无固定 IP）；
- Pod 数量动态变化：扩缩容时 Pod 数量增减，客户端无法感知。
Service 相当于 "中间代理"------ 客户端只需要访问 Service 的固定地址，无需关心背后 Pod 的 IP 和数量变化，由 Service 负责转发请求到可用 Pod。
二、Service 的 4 大核心作用
1. 提供稳定访问入口（核心价值）
Service 一旦创建，会分配一个固定的 ClusterIP（集群内部 IP） 和 DNS 名称（集群内可通过 Service 名称直接访问），无论背后的 Pod 如何变化，Service 地址始终不变。
示例：
- 3 个 Nginx Pod 扩缩容为 5 个，Pod IP 全部变化；
- 客户端仍通过 Service 的 ClusterIP（如
10.96.0.10）或 DNS 名称（如nginx-service.default.svc.cluster.local）访问，无需修改任何配置。
2. 实现 Pod 负载均衡
Service 会自动关联匹配的 Pod（通过 selector 标签匹配），并将客户端请求均匀转发到多个 Pod，避免单个 Pod 负载过高，提升服务可用性。
核心逻辑：
- Service 通过
spec.selector定义标签匹配规则（如app: nginx）； - 所有带有
app: nginx标签的 Pod 会自动加入该 Service 的 "后端池"； - 支持 3 种负载均衡策略（默认
RoundRobin轮询）：RoundRobin：轮询转发到每个 Pod；SessionAffinity: ClientIP：基于客户端 IP 粘性会话（同一客户端请求始终转发到同一 Pod）；None：随机转发（需依赖集群底层网络支持）。
3. 支持服务发现（集群内 / 外）
- 集群内服务发现 ：K8s 内置 DNS 服务（如 CoreDNS）会为每个 Service 自动创建 DNS 记录，集群内其他 Pod 可通过「Service 名称 + 命名空间」直接访问（无需记 ClusterIP）。示例：
nginx-service.default.svc.cluster.local（default为命名空间，可省略，直接用nginx-service访问）。 - 集群外服务发现 ：通过
NodePort、LoadBalancer类型的 Service，将服务暴露到集群外部，外部客户端可通过节点 IP + 端口或负载均衡器地址访问。
4. 故障自动隔离（高可用保障）
Service 会通过 K8s 的健康检查机制（如 Pod 就绪探针 readinessProbe）感知 Pod 状态：
- 当 Pod 故障（未就绪 / 宕机）时，自动从 Service 后端池中移除，不再转发请求；
- 当 Pod 恢复就绪后，自动重新加入后端池，实现故障自愈，无需人工干预。
三、Service 的 4 种核心类型（适配不同访问场景）
| 类型 | 核心作用 | 访问方式 | 适用场景 |
|---|---|---|---|
| ClusterIP | 集群内访问（默认类型） | 集群内 Pod 通过 ClusterIP 或 DNS 名称访问 | 集群内微服务间通信 |
| NodePort | 暴露服务到集群外部（节点端口映射） | 外部客户端通过「节点 IP:NodePort」访问 | 测试环境、临时外部访问 |
| LoadBalancer | 借助云厂商负载均衡器暴露服务（云原生） | 外部客户端通过负载均衡器公网地址访问 | 生产环境、公网服务暴露 |
| ExternalName | 将 Service 映射到外部服务（无后端 Pod） | 集群内通过 Service 名称访问外部服务 | 集群内 Pod 访问外部服务（如云数据库） |