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年過去，還沒被替換掉。