到目前為止，我們已經建立 Deployment 與 Pod replica，也知道 Pod 可以被刪除、重建並重新排程。

不過假設某個 API 要呼叫另一個服務，卻把對方某一顆 Pod 的位址直接填在程式設定裡，例如 http://10.244.1.7:8080。如果那顆 Pod 被刪除後重新建立，新 Pod 可能會換一個 IP，而程式仍呼叫舊 IP，就可能找不到服務。

Service 就是 Kubernetes 提供的穩定入口，常會透用 selector 找出目前符合條件的 Pod，讓呼叫端不必每次都因為變動的 Pod IP 而去頻繁的改相關設定或程式碼。 

Service 如何找到後端 Pod？

以下是一個簡單範例：

yaml
apiVersion: v1
kind: Service
metadata:
name: catalog-api
spec:
selector:
app.kubernetes.io/name: catalog-api
ports:
- name: http
port: 80
targetPort: http

這份 Service 有三個主要設定：

對有設定 selector 的 Service，Kubernetes Control Plane 中的 EndpointSlice controller（端點切片控制器） 會依據符合條件的 Pod，建立或更新 EndpointSlice（端點切片）。

EndpointSlice 是 Kubernetes 用來記錄 Service 後端端點的物件，內容包含 Pod 位址、Port 與端點狀態。

當 Pod 數量較多時，同一個 Service 也可能對應多個 EndpointSlice。這個 controller 是 Kubernetes 的內建 Controller，會隨著 Service 或 Pod 狀態變化協調更新後端清單。實際流量通常會導向其中 Ready 的 endpoint。

Pod 被 Deployment 替換時，EndpointSlice 也會隨之更新。

所以從上述也可以了解到，Service 本身不參與建立、刪除 Pod 的相關事件。

實際封包要怎麼在 Node 上被轉送，會依叢集的網路實作而不同。

例如 kube-proxy 是常見的 Service 實作元件，某些 CNI 方案也能實作或接手處理分 Service 流量。不論底層細節如何，應用程式層的重點是：呼叫 Service，不要直接依賴某一顆 Pod IP。

三個最常用的 Service Type

Service Type 決定 Service 主要在哪個範圍可被存取。今天的主角是 ClusterIP、NodePort 與 LoadBalancer。

ClusterIP：給叢集內部服務使用的預設入口

未指定 type 時，Service 預設就是 ClusterIP。Kubernetes 會配置一個叢集內可使用的虛擬 IP，讓其他 Pod 可以透過 Service name 連線。

同一個 Namespace 中，呼叫端通常可以直接使用：

text
http://catalog-api

叢集的 DNS Service（例如 CoreDNS）會把 Service name 解析成對應的叢集內的入口。與直接叫某一顆 Pod 不同的是：後端 Pod 即使被替換，catalog-api 這個 Service 名稱仍保持不變。

NodePort：每台 Node 都開出同一個 Port

NodePort 會讓每台 Node 的 Service proxy 配置同一個 Port，並在叢集設定允許的 Node IP 上接受流量。只要外部用戶端能連到其中一台可達的 Node，就能經由 NodeIP:NodePort 進入該 Service，再被轉送到符合 selector 的 Pod；預設行為仍會受到 kube-proxy mode 與 nodePortAddresses 設定影響。

它適合學習或某些直接暴露服務的情境，但要注意它暴露的是 Node 層級入口，不代表 Pod 一定就在你連到的那台 Node 上。也因為要處理 Node IP、網路路由與防火牆，正式環境通常會再交由專門的 Load Balancer、Ingress 或 Gateway 來管理對外流量。

LoadBalancer：Kubernetes 提出需求，平台負責配置

LoadBalancer 不代表 Kubernetes 自己憑空產生一台負載平衡器。它是向叢集所整合的平台提出需求：請建立或配置一個外部 Load Balancer，並把流量導向這個 Service。

VIP：可被叢集外部看見的虛擬 IP

VIP（Virtual IP，虛擬 IP） 是用戶端用來連線的入口 IP，它不屬於某一顆固定 Pod 或單一網卡。
Load Balancer 可以把送到這個 IP 與 Port 的連線，依據不同規則轉送到對應的 Service。

使用者連線到 https://api.example.com 時，DNS 可將名稱解析到一個 VIP；使用者不需要知道後面有幾顆 Node、Pod 是否剛被重建，或實際流量最後進到哪一顆 Pod。這正是外部 Load Balancer 與 Service 要共同提供的穩定入口，整體概念上會有點像 nginx 的反向代理。

叢集完成配置後，會將可供連線的資訊寫入 Service 的 .status.loadBalancer.ingress；可以設定 ip，也可以設定 hostname。因此建議是讓 Client 端指向對應的 FQDN，而不是 VIP。

同一份 type: LoadBalancer YAML，在不同平台背後可能是完全不同的提供者：

所以，type: LoadBalancer 是 Kubernetes 的通用介面，不是某一種固定產品或網路拓樸。Kubernetes 也提供 .spec.loadBalancerClass，讓叢集可明確指定由哪一種 Load Balancer 實作接手；具體註解、可用協定、健康檢查與是否能直接導向 Pod，都要查閱該平台或 Controller 的文件。

另外兩種：ExternalName 與 Headless Service

ExternalName 與前面三種不同，它不會建立 selector、EndpointSlice 或 Proxy，而是回傳一個外部 DNS 名稱的 CNAME。它適合建立名稱別名，但不適合拿來取代一般 Pod Service。

Headless Service 則是將 clusterIP 設為 None 的特殊設定，不是額外的 Service Type。它通常讓呼叫端直接取得後端 Pod 的 DNS 資訊，常見於需要自行處理節點身分或連線對象的 Stateful 工作負載。這兩種先知道存在即可。

Docker Compose 的 service name 與 container_name 有何不同？

Docker Compose 與 Kubernetes 都能讓服務用名稱互相呼叫，但背後模型不同：

因此，從 Docker Compose 遷移時，最接近「呼叫服務名稱」的概念是 Kubernetes Service。

實務案例：External IP 一直是 <pending>，不代表是 selector 壞掉

曾經遇過 LoadBalancer Service 的 External IP 一直停在 <pending>。後端 Pod 正常、selector 也正確，但平台無法分配對應 IP：指定的 IP 不在 IPAM Pool 範圍內，或是可用 IP 已耗盡。

後來發現應該往這些邏輯去排查才比較有效率：

• Service、selector、EndpointSlice 是否正確，是 Kubernetes 物件與後端 Pod 的問題。
• 外部 IP、VIP、平台 Load Balancer 是否可配置，是否為該叢集平台與 Controller 的問題。

遇到這類情況，先看 kubectl describe service 中的 Event，比起直接修改 selector 或重建 Pod 更容易找到根因。

今日結論

Service 讓呼叫端以穩定名稱與入口存取一群可替換的 Pod。ClusterIP 適合叢集內流量；NodePort 在 Node 層級開 Port；LoadBalancer 則要求平台配置外部入口。

參考資料

• Kubernetes：Service
• Kubernetes：EndpointSlices
• Kubernetes：DNS for Services and Pods
• Kubernetes：Service 的 LoadBalancer 與 loadBalancerClass
• Avi Kubernetes Operator：LoadBalancer Service 與 Avi Virtual Service 的對應
• Microsoft Learn：AKS Services、Load Balancer 與 IP
• Amazon EKS：Load Balancing Best Practices
• MetalLB：Concepts（IP 配發與 L2／BGP 宣告）
• CNCF：MetalLB 專案頁