Service 详解：Kubernetes 集群的"服务发现与负载均衡器"

AI 协助说明： 本页由 Codex 协助核验和修复站内链接；正文的技术事实和适用范围未因本次修改而改变，仍以文中来源及当前官方文档为准。

阅读边界#

本文把 Service 当作一个 API 资源 来讲：如何用 selector、端口、类型、亲和与流量策略描述“哪些后端以什么入口被访问”，以及如何在对象层定位配置错误。

本文不逐包展开 DNS、ClusterIP、EndpointSlice、DNAT、kube-proxy 或 eBPF 的运行时实现。遇到“Service 存在但请求不通”时，请接着阅读 Service 转发链路。相关专题还有 CoreDNS 详解、kube-proxy 详解、Calico 流量走向 和 Pod 优雅退出。

结论：Service 是稳定入口的声明，不是业务代理进程#

Pod 的 IP、数量和所在节点会随发布、扩缩容、故障恢复而变化。Service 用一个稳定的名称和（多数情况下）稳定的虚拟 IP，表示一组网络后端及其访问策略：

Service spec
  ├─ selector：匹配哪些 Pod
  ├─ ports：入口端口如何映射到后端端口
  ├─ type / traffic policy：从哪里进入、哪些端点可以被选中
  └─ EndpointSlice：控制器维护的实际后端快照

Service 不会替应用做健康检查、认证、重试或七层路由；它也不是网络防火墙。应用是否接收新流量主要由 readiness 和 EndpointSlice 状态决定，访问许可则由 NetworkPolicy、CNI 与外部网络策略共同决定。

Service 资源模型#

一个常见的集群内 HTTP Service：

apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: default
spec:
  type: ClusterIP
  selector:
    app.kubernetes.io/name: web
  ports:
    - name: http
      protocol: TCP
      appProtocol: http
      port: 80
      targetPort: http
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 10800
  internalTrafficPolicy: Cluster

appProtocol 是给实现者和工具的应用协议提示，不会替代 protocol；protocol 决定 TCP、UDP 或 SCTP（集群支持时）的传输协议。

selector、Pod 与 EndpointSlice#

对带 selector 的 Service，EndpointSlice 控制器根据匹配的 Pod 自动创建、更新 EndpointSlice；正常情况下，未就绪的 Pod 不会成为常规新流量的可选后端。不要把旧的 Endpoints 对象当作完整事实来源：它已被弃用，并且在大量后端时可能被截断；排查和自动化应读取 EndpointSlice。

EndpointSlice 中最值得在对象层观察的是：

终止端点的状态传播与连接排空属于运行时话题；请看 Pod 优雅退出 和 Service 转发链路。

无 selector 的 Service#

Service 也可以不选择 Pod，例如后端是集群外地址或由自定义控制器维护。此时需自行创建 discovery.k8s.io/v1 的 EndpointSlice，并给它设置 kubernetes.io/service-name: <service-name> 标签。端点地址不能是另一个 Service 的 ClusterIP；Service VIP 不能再作为 Service VIP 的后端。

这是一种明确的运维接口，不应靠手改旧 Endpoints 对象实现。还要注意：无 selector 的 Service 无法通过 API Server 的 kubectl port-forward service/... 代理到任意外部端点。

port、targetPort 与 nodePort#

ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: http
    nodePort: 30080

对于 targetPort: http，应让后端 Pod 的相应容器声明同名端口，例如：

containers:
  - name: web
    ports:
      - name: http
        containerPort: 8080

这不会自动让进程监听 8080；应用仍需实际监听该端口。

Service 类型与使用决策#

Headless Service 与 StatefulSet#

Headless Service 常和 StatefulSet 配合。StatefulSet 在 spec.serviceName 中引用它后，Pod 可以获得稳定的单体 DNS 名称：

<pod-name>.<service-name>.<namespace>.svc.cluster.local

这适合数据库、副本集等需要识别具体成员的系统；客户端要自行处理返回的多个地址和故障切换。无状态 Deployment 的普通服务调用通常更适合使用 ClusterIP Service。

会话亲和与流量策略#

sessionAffinity#

可选值是 None（默认）和 ClientIP。后者使来自同一客户端 IP 的连接在超时时间内尽量选择同一后端：

spec:
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 10800

它不能替代 Cookie、令牌或应用层一致性设计：经 NAT 后多个用户可能共用一个源 IP，连接重建、端点下线和数据面差异也会改变实际命中结果。

internalTrafficPolicy、externalTrafficPolicy 与 trafficDistribution#

trafficDistribution 是“优先选择拓扑上更近端点”的提示；不要把它和上表的硬限制混为一谈。使用它前应核对 Kubernetes 版本、所用 kube-proxy 或 eBPF 数据面是否支持，并观察 EndpointSlice 的拓扑信息。

Service 与常见工作负载/入口的关系#

对象级排查：先确认声明与后端集合#

以下命令只验证 Kubernetes 对象是否表达正确；DNS、节点规则、CNI 路由和 NetworkPolicy 的逐层排查见 Service 转发链路。

1. 检查 Service 本身#

kubectl -n default get svc web -o wide
kubectl -n default describe svc web
kubectl -n default get svc web -o yaml
kubectl -n default get svc web -o jsonpath='{.spec.clusterIP}{"\n"}'

确认 namespace、type、selector、port/targetPort/nodePort、clusterIP 以及两种 traffic policy 是否符合预期。LoadBalancer 还应查看 describe 中的事件和 status.loadBalancer。

2. 用同一组标签检查 Pod 与就绪状态#

kubectl -n default get pods -l app.kubernetes.io/name=web -o wide --show-labels
kubectl -n default get pods -l app.kubernetes.io/name=web

最常见的错误是 Service selector 和 Deployment 模板标签不一致，或 Pod 尚未 Ready。此时应先修正标签、readinessProbe 或应用监听，不要先重启 kube-proxy。

3. 以 EndpointSlice 为准核对后端#

kubectl -n default get endpointslice -l kubernetes.io/service-name=web -o wide
kubectl -n default get endpointslice -l kubernetes.io/service-name=web -o yaml

# 仅用于兼容性观察；Endpoints API 已弃用，不应作为自动化依据
kubectl -n default get endpoints web

核对地址、端口和 ready/serving/terminating。如果没有 EndpointSlice，优先检查 selector、Pod namespace、Pod labels 与 Ready 状态；如果地址存在而端口错误，检查 targetPort 和应用实际监听端口。

4. 按入口类型补充验证#

最小实践清单#

• 用稳定且专用的标签作为 Service selector，不要选择过宽的通用标签。
• 为多端口 Service 和 Pod 端口命名，减少 targetPort 变更带来的发布风险。
• 为承接流量的应用设置 readinessProbe，并在发布/缩容时验证 EndpointSlice 变化。
• 默认从 ClusterIP 开始；只有明确需要时才选 NodePort、LoadBalancer 或 Headless。
• 把网络访问控制写在 NetworkPolicy 和基础设施安全组中，不把 Service 当作安全边界。
• 遇到“对象正确但访问失败”，停止在 Service YAML 上反复修改，按 运行时数据链路 分层定位。

参考资料#

• Kubernetes Service
• Service traffic policies
• EndpointSlices
• DNS for Services and Pods