从流量入口到容器实例：图解 K8s Service、Endpoints 与 Pod 的联动机制

1. 当流量撞上Kubernetes大门

想象一下你走进一家网红餐厅，门口的服务员会先确认你的预约信息（Service），然后根据当前空闲的餐桌情况（Endpoints）把你引导到具体的座位（Pod）。在Kubernetes集群里，外部流量想要访问容器化服务时，同样会经历这样精密的协作流程。

最近在调试线上服务时，我发现很多开发者虽然会用kubectl create service命令创建服务，却不清楚请求究竟是怎么找到目标容器的。有次我们的订单服务突然出现503错误，排查半天才发现是Endpoints没有自动更新导致的。今天就带大家用"餐厅订位"的视角，拆解这个看似简单实则精妙的流量路由机制。

Service的本质是永不褪色的名片。即使背后的Pod因为版本更新或故障替换全部重建，Service的VIP（虚拟IP）和DNS名称始终不变。这就像餐厅总机号码不会因为装修换厨师就变更。我常用这个命令快速验证Service基础配置：

kubectl get svc order-service -o yaml

2. 三层联动机制详解

2.1 Service：流量的第一道安检

创建Service时有个容易踩坑的细节：selector字段就像安检机的X光，只有带匹配标签的Pod才能进入后续流程。上周我们团队就有人误删了deployment里的app: order-service标签，导致所有Pod从Endpoints列表中消失。来看个典型配置：

apiVersion: v1 kind: Service metadata: name: payment-gateway spec: selector: app: payment tier: backend ports: - protocol: TCP port: 80 targetPort: 8080

关键点在于端口映射：port是服务对外暴露的端口，targetPort才是Pod实际监听的端口。这就像餐厅门口写的"本店在3楼"（port），实际用餐区在301-310房间（targetPort）。

2.2 Endpoints：实时更新的座位表

Endpoints的自动更新机制特别有意思。kube-controller-manager会持续扫描集群状态，任何Pod的创建/删除/状态变更都会触发Endpoints更新。用这个命令可以看到动态变化：

watch -n 1 kubectl get endpoints payment-gateway

我做过一个实验：同时删除所有Pod副本，15秒内Endpoints列表就清空了。当新Pod启动并通过Readiness探针后，又会被自动加入。这解释了为什么建议Readiness探针检查时间要小于Pod启动间隔，否则会出现服务抖动。

2.3 Pod：真正的服务提供者

虽然Pod是最终处理请求的单元，但有个反直觉的事实：Pod根本不知道Service的存在。这就像厨师不需要记住每个顾客是通过哪个渠道预定的。这种松耦合设计使得Pod可以自由扩缩容。

调试时有个技巧：如果Service不通，可以先直接访问Pod IP验证基础功能：

kubectl get pods -l app=payment -o wide curl <pod-ip>:8080/health

3. 实战中的特殊场景处理

3.1 无selector的Service

有时候需要集成外部数据库这类非Pod服务，这时可以手动创建Endpoints对象。去年我们迁移MongoDB时就用了这个方案：

apiVersion: v1 kind: Service metadata: name: legacy-mongodb spec: ports: - port: 27017 --- apiVersion: v1 kind: Endpoints metadata: name: legacy-mongodb subsets: - addresses: - ip: 192.168.1.100 ports: - port: 27017

注意两个metadata.name必须相同，这是他们建立关联的契约。我建议在YAML里用---分隔这两个资源定义，避免apply时顺序出错。

3.2 会话保持难题

默认的轮询负载均衡在某些场景下会出问题。比如购物车服务需要会话保持，可以通过sessionAffinity: ClientIP配置。但要注意这会导致流量分布不均，我们曾经因此触发了单个Pod的CPU告警。

更现代的方案是用trafficPolicy: Local配合podAntiAffinity，确保相同客户端的请求始终落到同一可用区的Pod。这需要仔细计算副本分布，我一般用这个命令监控：

kubectl top pods -l app=cart-service --sort-by=cpu

4. 深度调试技巧

4.1 网络策略的影响

当Service突然无法访问时，除了检查Endpoints，别忘了NetworkPolicy可能拦截了流量。有次我们的鉴权服务突然失联，最终发现是新部署的NetworkPolicy忘了添加端口例外：

kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: api-allow spec: podSelector: matchLabels: app: auth-service ingress: - ports: - port: 8080 from: - namespaceSelector: matchLabels: role: frontend

4.2 DNS缓存陷阱

CoreDNS对Service记录的默认缓存时间是30秒。在快速迭代时，我建议在测试环境调整这个参数：

kubectl edit configmap coredns -n kube-system

在Corefile里添加：

cache 5

曾经有个发布事故就是因为旧版本Pod已终止，但客户端仍解析到旧IP，导致五分钟的报错。现在我们的CI流程里都会包含这个检查项：

dig +short payment-gateway.default.svc.cluster.local

5. 性能优化实践

5.1 大规模集群的优化

当Endpoints数量超过5000时，kube-proxy的iptables模式会出现明显延迟。我们通过以下方案解决了这个问题：

1. 切换为ipvs模式：

kubectl edit cm kube-proxy -n kube-system # 修改mode: "ipvs"

2. 对核心服务启用EndpointSlice：

kubectl label ns production topology.kubernetes.io/endpoint-slice-enabled=true

实测下来，API服务器的CPU使用率下降了40%。但要注意旧版本Kubernetes对EndpointSlice的支持可能不完整，我们是在1.21版本后才全面启用的。

5.2 精准的HPA配置

HorizontalPodAutoscaler如果直接监控Service流量，会因为负载均衡特性导致误判。更准确的方案是：

metrics: - type: Pods pods: metric: name: http_requests target: averageValue: 500 type: AverageValue

这个配置来自我们线上商品搜索服务的真实案例，配合自定义指标适配器，扩容准确率提升了70%。关键是要确保metrics-server的采集间隔合理：

kubectl top pods --containers