🎯 課程目標___HTMLTAG_1__HTMLTAG_2___了解 Kubernetes 中需要服務的原因、服務類型以及何時使用每種類型，EndpointSlices 是取代 Endpoints API、使用 CoreDNS 進行基於 DNS 的服務發現的新標準。
1。為什麼我們需要服務？
Pod 具有 動態 IP — 每次重新建立 Pod 時（在崩潰、更新、擴充功能之後），它都會獲得一個新 IP。如果服務 A 想要呼叫服務 B，則服務 A 無法硬編碼 B 的 IP。
Service 為一組 Pod 提供穩定的 endpoint__HTMLTAG_12___（IP 和 DNS 名稱）。服務的流量將負載平衡到健康的 Pod。
2。服務類型
2.1 ClusterIP（預設）
使用叢集中的內部 IP 公開服務。只能從集群內部存取。
___程式碼區塊_0___2.2 NodePort
透過節點的 IP 和靜態連接埠 (30000-32767) 在叢集外部公開服務.
___程式碼區塊_1___存取：http://
2.3 負載平衡器
建立外部負載平衡器（在雲端提供者上：AWS ELB、GCP CLB、Azure LB）。用於雲端上的生產。
___程式碼區塊_2___
現代替代方案：使用 Gateway API（請參閱模組 4）— 更具表現力，無供應商鎖定。
2.4 外部名稱
將服務對應到叢集外部的 DNS 名稱。沒有負載平衡，只有 CNAME。
___程式碼區塊_3___
3。使用 DNS 進行服務發現
CoreDNS 為每個服務建立 DNS 記錄。格式：
___程式碼區塊_4___
___程式碼區塊_5___
4。 EndpointSlices — 新標準 K8s 1.33+
在之前，Kubernetes 使用 Endpoints 資源來儲存 Pod 的 IP 清單。問題：當 Pod 數量較多（數千）時，Endpoints 物件很大，導致更新時網路開銷。
___HTMLTAG_51__HTMLTAG_52___EndpointSlices 分割為切片（預設最大 100 個端點/切片），顯著提高可擴充性。
- 端點 API：已棄用的 K8s 1.33___HTMLTAG_58__HTMLTAG_59___
- EndpointSlices：目前標準，自 K8s 1.21 起引入
___程式碼區塊_6___
___程式碼區塊_7___
5。無頭服務
無頭服務（clusterIP：無）沒有 ClusterIP。 DNS查詢直接回傳Pod的IP，沒有負載平衡。用於 StatefulSets 為每個 Pod 提供穩定的 DNS 名稱。
___程式碼區塊_8___
___程式碼區塊_9___
6。會話關聯性
預設情況下，每個請求都會循環傳送到隨機 Pod。如果您需要黏性會話：
___程式碼區塊_10___7。 kube-proxy 和服務實作
kube-proxy 運行在每個 Node 上，透過建立 iptables/nftables 規則來實現服務負載平衡。
___HTMLTAG_78__HTMLTAG_79___iptables 模式：傳統、最流行
___HTMLTAG_82__HTMLTAG_83___nftables 模式：2026 年推薦（IPVS 已棄用 K8s 1.35）
當封包到達 ClusterIP 時，iptables/nftables 規則會重新導向到隨機 IP Pod (DNAT)。
8。服務最佳實務
- 總是使用
ClusterIP 進行內部服務
- 使用網關API而不是
LoadBalancer類型進行外部暴露
- 清楚地命名服務，使用一致的標籤
- 使用
targetPort__HTMLTAG_104___ 作為連接埠名稱而不是連接埠號碼（在 Pod 中更改連接埠時的靈活性）
- 監控 EndpointSlices 以偵錯連線問題__HTMLTAG_107___
摘要
- Service = 動態 Pod 的穩定端點__HTMLTAG_113___
- ClusterIP：內部；NodePort：開發/測試； LoadBalancer：雲端生產（但優先考慮API網關）
- EndpointSlices 取代 Endpoints API（已棄用 K8s 1.33）
- Headless Service：DNS 直接回傳 Pod IP，用於 StatefulSets
- CoreDNS：
svc-name.namespace.svc.cluster.local___HTMLTAG_122__HTMLTAG_123___