K8S中的Service的存在理由

歡迎關注頭條號：老顧聊技術

精品原創技術分享，知識的組裝工

前言

上篇文章中老顧介紹了相關pod、容器、node之間的通信，通過pod的ip進行通信，存在一定的問題。

Kubernetes Pod是有生命周期的，它們可以被創建，也可以被銷毀，然而一旦被銷毀生命就永遠結束。 通過ReplicationController能夠動態地創建和銷毀Pod（例如，需要進行擴縮容，或者執行滾動升級）。 每個 Pod 都會獲取它自己的 IP 地址，可一旦銷毀後，重新創建後，IP位址會產生改變。 這會導致一個問題：在 Kubernetes 集群中，如果一組 Pod（稱為 backend）為其它 Pod （稱為 frontend）提供服務，一旦backend的Pod重新創建，那麼frontend的Pod該如何發現，並連接到這組 Pod 中的哪些 backend 呢？

Service

Service資源用於為pod對象提供一個固定、統一的訪問接口及負載均衡的能力，並藉助新一代DNS系統的服務發現功能，解決客戶端發現並訪問容器化應用的問題。

注意：service只是在k8s集群內部起作用，集群外部訪問是無效的

實現原理

Service通過關註定義出多個POD對象組合而成的邏輯集合，以及訪問這組POD的策略，Service關聯POD需要標籤選擇器完成，其基於標籤選擇器將一組POD定義成一個邏輯集合，並通過自己的IP位址和埠調度代理請求至後端POD之上。

apiVersion: v1kind: Servicemetadata: name: a-servicespec: selector: app: pod-label ports: - protocol: TCP port: 80 targetPort: 9376

上面的例子服務a-service關聯著label為【app:pod-label】的pod，這時候另一個服務B可以訪問跟a-service服務綁定的service，service信息是固定的提前告訴B就行了，service通過Label Selector跟a服務的pod綁定,無論a的pod如何變化對b來說都是透明的。

虛擬IP

service對象的IP位址稱為cluster IP，位於K8S集群配置指定的專用IP位址範圍內，其是一種虛擬IP位址，其在service對象創建後保持不變，並且能夠被同一集群中的POD資源訪問，service埠接受客戶端的請求並將其轉發至後端POD中的相應埠，因此，其又被稱為四層代理，因其工作在TCP/IP層。

一個service對象就是工作節點上的一些iptables或ipvs，用於將到達service對象的IP位址的流量轉發到相應的endpoint對象指定的IP位址和埠上，kube-proxy組件通過api-server持續監控著各個service及其相關的POD對象，並將其創建或變動實時反映到工作節點的iptable或ipvs上

服務代理

k8s群集中的每個節點都運行一個kube-proxy的組件，kube-proxy其實是一個代理層負責實現service

userspace模式

客戶端訪問ServiceIP（clusterIP）請求會先從用戶空間到內核中的iptables，然後回到用戶空間kube-proxy，kube-proxy負責代理工作。

具體細節：

請求到達service後，其被轉發到內核，經由套接字送往用戶空間的kube-proxy，而後經由kube-proxy送回內核空間，並調度至後端POD，其傳輸方式效率太低。在1.1 版本之前，其是默認的轉發策略。

iptables模式

客戶端訪問ServiceIP（clusterIP）請求會由iptables直接重定向到後端

具體細節：

客戶端IP請求時，直接請求本地內核service ip，根據iptables的規則直接將請求轉發到到各pod上，因為使用iptable NAT來完成轉發，也存在不可忽視的性能損耗。另外，如果集群中存在上萬的Service/Endpoint，那麼Node上的iptables rules將會非常龐大，性能還會再打折扣

Kubernetes v1.2之前默認是userspace之後是iptables模式，iptables模式性能和可靠性更好，但是iptables模式依賴健康檢查，在沒有健康檢查的情況下如果一個pod不響應，iptables模式不會切換另一個pod上

ipvs模型

此模型跟蹤API service上的service和endpoints對象的變動，據此來調用netlink接口創建IPVS規則，並確保API server中的變動保持同步，其流量調度策略在IPVS中實現，其餘的在iptables中實現。

ipvs 支持眾多調度算法，如rr、lc、dh、sh、sed和nq 等。

集群外部訪問

我們如何在集群外訪問service呢？k8s提供了幾種方式

NodePort

通過每個 Node 上的 IP 和靜態埠（NodePort）暴露服務。NodePort 服務會路由到 ClusterIP 服務，這個 ClusterIP 服務會自動創建。通過請求 NodeIP:Port，可以從集群的外部訪問一個 NodePort 服務。

這時要訪問這個Service的話，只需要通過訪問

<任何一臺宿主機器的IP>:Port

LoadBalancer

在NodePort基礎上，Kubernetes可以請求底層雲平臺cloud provider 創建一個外部的負載均衡器，並將請求轉發到每個Node作為後端，進行服務分發。

該模式需要底層雲平臺（例如GCE、AWS）支持。

ExternalName

創建一個dns別名指到service name上，主要是防止service name發生變化，要配合dns插件使用。通過返回 CNAME 和它的值，可以將服務映射到 externalName 欄位的內容。

這隻有 Kubernetes 1.7 或更高版本的 kube-dns 才支持

Ingress

上面我們提到幾種方式，但是當集群服務很多的時候，NodePort方式最大的缺點是會佔用很多集群機器的埠；LB方式最大的缺點則是每個service一個LB又有點浪費和麻煩，並且需要k8s之外的支持； 而ingress則只需要一個NodePort或者一個LB就可以滿足所有service對外服務的需求。工作機制大致可以用下圖表示：

Ingress是基於service實現7層路由轉發能力的

總結

K8S中的概念還是比較多的，老顧只是拋磚引玉，小夥伴需要了解更多詳細的可以查看更多詳細的資料。今天老顧就介紹到這裡了，謝謝！！！

---End---

---

老顧的微服務網關分享課程，請大家多多支持

推薦閱讀

a、

b、

c、

d、

e、

f、

h、

g、

i、

1、基於RocketMq的SpringCloud Stream框架實戰入門

2、如何搭建消息中間件應用框架之SpringCloud Stream

3、面試必備：網關異常了怎麼辦？如何做全局異常處理？

4、Gateway網關系列(二)：SpringCloud Gateway入門實戰，路由規則

5、Gateway網關系列開篇：SpringCloud的官方網關Gateway介紹

6、API網關在微服務架構中的應用，這一篇就夠了

7、學習Lambda表達式看這篇就夠了，不會讓你失望的哦（續篇）

8、Lambda用在哪裡？幾種場景？

9、為什麼會出現Lambda表達式，你知道嗎？

10、不說「分布式事務」理論，直接上大廠阿里的解決方案，絕對實用

11、女程式設計師問到這個問題，讓我思考了半天，Mysql的「三高」架構

12、大廠二面：CAP原則為什麼只能滿足其中兩項？而不能同時滿足

13、阿里P7二面：聊聊零拷貝的原理

14、秒殺系統的核心點都在這裡，快來取

15、你了解如何利用token方式實現分布式Session嗎？

16、Mysql索引結構演變，為什麼最終會是那個結構呢？讓你一看就懂

17、一場比賽涉及到的知識，用通俗易通的方式介紹並發協調

18、企業實戰Redis全方面思考，你思考了嗎？

19、面試題：Thread的start和run的區別

20、面試題：什麼是CAS？CAS的作用以及缺點

21、如何訪問redis中的海量數據？避免事故產生

22、如何解決Redis熱點問題？以及如何發現熱點？

23、如何設計API接口，實現統一格式返回？

24、你真的知道在生產環境下如何部署tomcat嗎？

25、分享一線網際網路大廠分布式唯一ID設計 之 snowflake方案

26、分享大廠分布式唯一ID設計方案，快來圍觀

27、你想了解一線大廠的分布式唯一ID生成方案嗎？

28、你知道如何處理大數據量嗎？(數據拆分篇)

29、如何永不遷移數據和避免熱點? 根據伺服器指標分配數據量(揭秘篇)

30、你知道怎麼分庫分表嗎？如何做到永不遷移數據和避免熱點嗎？

31、你了解大型網站的頁面靜態化嗎？

32、你知道如何更新緩存嗎？如何保證緩存和資料庫雙寫一致性？

33、你知道怎麼解決DB讀寫分離，導致數據不一致問題嗎？

34、DB讀寫分離情況下，如何解決緩存和資料庫不一致性問題？

35、你真的知道怎麼使用緩存嗎？

36、如何利用鎖，防止緩存擊穿？重構思想的重要性

37、海量訂單產生的業務高峰期，如何避免消息的重複消費？

38、你知道如何保障生產端100%消息投遞成功嗎？

39、微服務下的分布式session該如何管理？

40、阿里二面：filter、interceptor、aspect應如何選擇？很多人中招

41、網際網路架構重要組員CDN，很多高級開發都沒有實操過，來看這裡

42、阿里二面：CDN緩存控制原理，看看能不能難住你

43、SpringCloud Alibaba之Nacos多環境多項目管理

44、SpringCloud Alibaba系列之Nacos配置中心玩法

45、SpringCloud Alibaba之Nacos註冊中心

46、SpringCloud Plus版本之SpringCloud Alibaba

47、SpringCloud Alibaba之Nacos集群、持久化

48、SpringCloud Alibaba之Nacos共享配置、灰度配置

49、SpringCloud Alibaba之Sentinel工作原理

50、SpringCloud Alibaba之Sentinel流控管理

51、SpringCloud Alibaba之Sentinel降級管理

52、SpringCloud Alibaba之Sentinel熱點參數限流

53、SpringCloud Alibaba之Sentinel的API實戰