Kubernetes把Service藏了8年

2024年Stack Overflow调研显示，67%的开发者自认"懂Kubernetes"，但能用Service正确排查跨Pod通信故障的不到23%。

这个差距不是能力问题，是教的人根本没讲清楚Service到底在解决什么。

Pod的IP像临时工手机号

原文作者花了很长时间才想通一件事：Pods是设计来死掉的。

扩容时新建、缩容时销毁、节点故障时迁移——IP地址跟着变来变去。你的API昨天还在10.0.0.5，今天可能就换到了10.0.0.19。

这时候如果另一个服务写死了IP去调用，等于把快递地址填成了前同事的出租屋。

Service做的第一件事，是给这群"临时工"配了一个前台总机。不管背后谁在值班，对外永远同一个号码。

Selector是Service的寻人启事

很多人误以为Service和Deployment、ReplicaSet之间有某种"绑定关系"。

没有。

Service的配置里只有一段selector：

```yaml selector: app: minha-api ```

它的逻辑粗暴到近乎可爱：「我不管你是谁，只要label对得上，流量就往你那送。」

这意味着你可以手动创建一个Standalone Pod，只要label匹配，Service照样把它纳入负载均衡池。反过来，Deployment更新了label，哪怕Pod还在跑，Service也会瞬间"失明"。

原文作者用了一个精准的类比：Service不"认识"任何控制器，它只认标签。像快递柜只认取件码，不管你是谁派来的。

Load Balancing是赠品，不是主角

三个Pod在跑：A（10.0.0.1）、B（10.0.0.2）、C（10.0.0.3）。

客户端→Service→随机分发到A/B/C。这个流程里，调用方不需要知道任何Pod的存在，也不需要手动维护IP列表。

但这里有个细节常被忽略：Kubernetes的Service负载均衡是四层（传输层）的。它基于iptables或IPVS做流量转发，不解析HTTP内容。这意味着如果Pod A已经过载，Service不会"聪明"地把新请求转给空闲的B——它只管轮询或随机。

要更精细的七层负载均衡，得上Ingress或Service Mesh。Service的定位从来就不是"智能调度"，而是"可靠连通"。

两个类型决定生死边界

ClusterIP和LoadBalancer的选择，本质是"谁能访问"的权限设计。

ClusterIP（默认）只在集群内部暴露。微服务A调微服务B、后端连数据库——这些场景用ClusterIP，IP不流出节点，攻击面最小。

LoadBalancer则申请一个外部IP，云厂商会自动给它挂一个四层负载均衡器。适合前端直接调用的API，但每开一个都是真金白银。

原文作者的实践建议很实在：默认用ClusterIP，被迫了才上LoadBalancer。很多团队反着来，先开LoadBalancer图省事，结果月底账单教你做人。

他还提了一个维护技巧：用named ports。把containerPort: 8080写成name: http，后续改端口号不用动Service配置。小习惯，大省心。

Endpoints是最后的 debugger

Service配好了，请求还是不通？

先看Endpoints。`kubectl get endpoints `会列出Service实际匹配到的Pod IP。如果这里为空，说明selector写错了，或者Pod的label没打对。

这是Kubernetes里最常见的"我以为连上了"陷阱。Service配置看起来完美，但Endpoints空空如也——流量根本无处可去。

原文作者把Service总结为「让孤立的容器变成真正可用的分布式系统」。这个表述略鸡汤，但核心没错：容器编排的难点从来不是"跑起来"，而是"连起来"。

Service就是Kubernetes对"连通性"这个问题的答案。它不优雅，甚至有点糙——但8年过去，还没被替换掉。