云原生 Service 后端端点 怎样处理

我排查 Service 时最容易踩的坑，是把“有 ClusterIP”误认为“已经有可用后端”。Service 只是稳定的访问入口，真正决定流量能不能落到目标地址的，是 selector、EndpointSlice 以及端点的 ready/serving 状态。按 Kubernetes 的当前模型处理时，可以先记住一句话：集群内 Pod 优先让 selector 自动维护；没有 selector 时，直接维护 EndpointSlice；只需要 DNS 别名时才使用 ExternalName。

官方地址：https://kubernetes.io/docs/concepts/services-networking/service/

一、先把 Service 和后端端点分开看

Service 解决的是“调用方访问哪个稳定名字或虚拟 IP”，EndpointSlice 解决的是“这项服务当前有哪些后端地址”。带 selector 的 Service 通常由控制面根据标签匹配 Pod，并持续更新 EndpointSlice；数据面组件再依据这些对象配置转发路径。Pod 被替换时，调用方不需要跟着修改目标地址。

因此排查要分三层记录：第一层确认 Service 的端口和类型，第二层确认 selector 或手工 EndpointSlice 的来源，第三层确认端点是否处于可服务状态。只看第一层，容易得到“Service 存在但请求仍失败”的片面结论。

二、集群内 Pod 后端优先交给 selector

后端就是 Deployment、StatefulSet 或其他工作负载创建的 Pod 时，最稳妥的方式是让 Service 写出与 Pod 一致的 selector。示例只展示对象关系，不代表已经在本机集群执行：

apiVersion: v1
kind: Service
metadata:
  name: checkout-api
spec:
  selector:
    app: checkout
  ports:
    - name: http
      port: 80
      targetPort: 8080
# selector 负责找到带 app=checkout 的 Pod，port 是 Service 端口，targetPort 是容器端口。

发现端点为空时，先对照三组事实：Pod 是否真的带有 app=checkout 标签，Service 的 targetPort 是否能对应容器端口，EndpointSlice 中的 ready 或 serving 是否允许接收流量。可以用下面的命令读取对象关系；输出是排查入口，不要把命令本身当作成功证据：

# 先看 Service 的 selector、端口和事件，再按服务名汇总 EndpointSlice
kubectl describe service checkout-api
kubectl get endpointslice -l kubernetes.io/service-name=checkout-api -o wide

# 查看被 selector 命中的 Pod，确认标签和就绪状态来自同一批工作负载
kubectl get pods -l app=checkout -o wide

如果 Pod 数量正常但可用端点为零，优先查标签和就绪条件；如果 ready 端点存在但 P95 延迟升高，再查应用处理时间、连接池和节点资源，而不是先重建 Service。

三、无 selector 时用 EndpointSlice 接入外部后端

迁移期间、外部数据库或跨集群服务可能暂时没有可由 Kubernetes selector 匹配的 Pod。这时可以创建不带 selector 的 Service，再由维护方直接创建 EndpointSlice。当前官方文档推荐用 EndpointSlice 表达这类手工后端，旧 Endpoints API 已经弃用。

apiVersion: v1
kind: Service
metadata:
  name: legacy-orders
spec:
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 9376
---
apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
  name: legacy-orders-1
  labels:
    kubernetes.io/service-name: legacy-orders
addressType: IPv4
ports:
  - name: http
    protocol: TCP
    port: 9376
endpoints:
  - addresses:
      - "10.4.5.6"
    conditions:
      ready: true
# Service 只提供稳定入口，EndpointSlice 明确维护外部后端地址和端口。

这条路径的代价是生命周期责任转移给维护方：外部地址变化、健康状态变化和下线时机都要由控制器或发布流程更新 EndpointSlice。不要手工写一个地址后就认为它会像 selector 一样自动跟随实例变化。

另外，无 selector 的 Service 不能被 API Server 当作任意外部地址代理，诸如 kubectl port-forward service/legacy-orders 的路径会受到限制。这是权限边界，不是端点配置少写了一个字段。

四、用指标判断端点处理是否稳定

我更倾向于把端点排查写成一张小表，而不是只截一条 kubectl get 输出。下面的数值是观测模板，实际阈值应按业务基线设置：

判断顺序可以固定为“先资源、后请求”：先确认 Service 找到了正确的 EndpointSlice，再看端点是否 ready/serving，最后把成功率和 P95 与发布前基线比较。这样能把“没有后端”“有后端但不可服务”和“有后端但性能下降”分成三类问题。

五、容易混淆的三种方案

• headless Service：把 clusterIP 设为 None，适合调用方直接发现端点；它不等于手工外部后端，是否自动生成 EndpointSlice 仍取决于有没有 selector。
• ExternalName：把 Service 映射成 DNS CNAME，不建立代理，也不负责把请求转发到目标主机；需要稳定的 Kubernetes 数据面入口时不要把它当作 ClusterIP。
• LoadBalancer：它是在 ClusterIP/NodePort 能力之上请求外部负载均衡器，后端仍然依赖 Service 的端点集合；它解决暴露方式，不替代端点维护。

如果目标只是把一组集群外地址纳入统一 Service 入口，选择“无 selector Service + EndpointSlice”；如果目标只是让名字解析到另一个域名，选择 ExternalName；如果目标是提供集群外访问，再根据云环境考虑 LoadBalancer。先说清楚后端来源，再决定 Service 类型，通常比改参数更快。

相关问题

为什么 Service 有 ClusterIP 但访问仍然超时？

ClusterIP 只说明入口对象存在。继续检查 selector 是否命中 Pod、EndpointSlice 是否包含地址、ready/serving 是否允许接流量，以及 Service 端口和 targetPort 是否对应。

手工维护端点还要不要创建 Endpoints？

新配置优先直接创建 discovery.k8s.io/v1 的 EndpointSlice。Endpoints API 已弃用，只有在兼容旧控制器时才需要评估遗留对象的影响。

滚动发布时 terminating 端点为什么偶尔还能收到请求？

EndpointSlice 同时记录 serving、terminating 和 ready。代理通常会避开 terminating 端点，但在所有端点都处于终止状态时，可能仍使用同时 serving 的端点完成收尾，具体行为要结合实现和发布策略判断。

把 Service 当成入口、把 EndpointSlice 当成后端集合、把指标当成判断依据，云原生 Service 的端点问题就能从“感觉路由不对”变成可分层处理的工程问题。