這一篇文章主要是對service發現新的理解
為什么要使用service服務發現？
首先pod的IP，是動態的，當我們重啟一個pod的時候，它會給它分配一個新的IP，但是如果微服務a想要去調用微服務b，他是需要知道微服務b所有健康pod的當前地址的，這使得服務發現變得很困難，服務發現機制又是微服務架構的核心需求
第二個就是負載均衡，當我們有多個pod的副本用于同一個應用的時候，我們希望流量能夠均勻的分發到這些pod上，所以我們需要一個機制來抽象后邊所有的pod，這個機制就是service發現。當你向service發送請求的時候kube-proxy組件它會通過IPVS或者iptables將請求負載均衡到后端健康的pod上
并且客戶端它是需要一個穩定的，不變的地址來連接這個服務的，就是service它發揮作用的地方，在創建一個service對象的時候，k8s會為其分配一個虛擬的在集群中穩定的IP地址，這個然后service會被自動注冊到集群的DNS服務中，那么客戶端就可以直接通過一個穩定的DNS名稱來訪問服務
headless service、clusterIP、NodeIP、LoadBalancer、Ingress、GateWay API等六種類型service
headless service、clusterIP、NodeIP、LoadBalancer、Ingress
【K8s】Service發現：跟蹤后端的IP-CSDN博客
【K8s】Service發現 2-CSDN博客
GateWay API
Gateway API 是 Kubernetes 新一代的流量管理接口。在ingress的yaml文件里，基礎設施和業務邏輯同時定義，Gateway API的進步就是，讓這個過程可以角色分離，讓不同團隊（基礎設施、集群運維、應用開發等）都能夠獨立且安全地管理流量。
它主要有三個核心組件：
1.GatewayClass (網關類)：定義了集群中哪種負載均衡器可用，以及由哪個控制器（如 Nginx,
Istio 等）來管理，它是一個集群級別的、全局性的資源。
2.Gateway (網關)：是根據 GatewayClass 模板在集群中創建的一個實際流量入口點，它配置
了監聽的端口（如 80, 443）、協議、TLS 證書，并決定允許哪些命名空間的應用（通過 Route）
附加到它上面。
3.Route (路由)：將來自 Gateway 的流量，根據匹配規則（如主機名、路徑、請求頭），轉發
到具體的后端服務（Service），它是應用開發者定義服務如何暴露的地方。
這個模型清晰地劃分了職責：GatewayClass(模板) → Gateway(實例) → HTTPRoute(規則)
1.集群管理員提供 GatewayClass (比如，我們支持 Nginx 網關)。
2.運維團隊創建一個 Gateway (比如，在生產環境創建一個監聽 443 端口的 Nginx 網關實例)。
3.應用開發者創建一個 HTTPRoute (比如，將 api.myapp.com/v1 的流量路由到我的 v1-
service)。
這種分離使得網絡管理更加安全、靈活且易于擴展，是它相對于傳統 Ingress 的最大優勢??
?
?
?
?
)
