Service是Kubernetes的一個重要資源類型，它通常可以理解爲一種微服務。通過規則定義出多個Pod的邏輯組合，service可以通過標籤選擇器來訪問到對應的pod。
概述
既然Service是一種核心資源，那爲什麼會出現service資源類型呢？它的具體意義又在哪裏呢？
Service資源是在pod的訪問基礎上產生的，例如，當我們使用Deployment創建多個副本的pod資源後，如果出現pod資源的擴縮容操作，隨之變化的是pod的IP地址訪問接口，那整個pod的訪問必然會受到影響，也就無法有效使用應用，爲此，Kubernetes特意設計了Service資源來解決該問題。
總的來說Service資源就是基於標籤選擇器將一組pod定義爲一個邏輯組合，並通過自己的IP地址和端口調度代理至組內的Pod對象上，它向客戶端隱藏了真實處理用戶請求的Pod資源，使得客戶端看上去就像由Service提供處理。
那既然真實的服務響應是由pod來執行，那service和pod之間由是怎樣有效轉發連接的呢？
虛擬IP
service對象一般會提供一個虛擬IP（Virtual IP），它在service創建之後就保持不變，並且能夠被同一集羣中的Pod資源所訪問。Service端口用於接收客戶端請求並將其轉發給後端的pod應用的相應端口，這種代理機制稱爲“端口代理”或四層代理，工作於TCP/IP協議棧的傳輸層。
一般通過標籤選擇器匹配到的後端pod不止一個，Service資源會通過API Server持續監聽（watch）匹配到的後端pod對象，並實時更新各對象的變動。不過需要特殊說明的是，Service並不是直接鏈接到pod對象，它們中間還有一個Endpoints資源對象，它是一個由IP地址和端口組成的列表，這些IP地址和端口都來自於Service的標籤選擇器匹配到的Pod資源。
在衆多的Pod對象中，Service資源總是能夠已正確的方式進行流量調度，它們之間由是如何實現的呢？
服務代理
這就是我們要具體介紹的Kubernetes提供的服務端口代理的幾種不同方式。
簡單來說，一個Service對象就是工作節點上的一些iptables或ipvs規則，用於將到達Service對象IP地址的流量調度轉發至相應的Endpoints對象指向的IP地址和端口之上。Kubernetes集羣中的每個節點都會有產生一個Kube-proxy對象，它通過API-Server持續監控各Service及其關聯的Pod對象，並將其變化實時反映至當前節點的iptables或ipvs規則上。
Kube-proxy、service、pod的關係如下圖所示：
Kube-Proxy將請求代理至相應端點的方式有三種：userspace（有戶空間）、iptables、ipvs。
userspace代理模型
這裏的userspace是指Linux操作系統的用戶空間。這種模型中，Kube-proxy負責跟蹤API Server上的service和Endpoints對象的的變動（創建或移除）。對於每個service對象它會打開一個本地端口（運行於用戶空間的Kube-proxy進程負責監聽），任何到達此代理端口的連接請求都會被代理至當前Service資源後端的各Pod對象上，至於會挑選哪個pod取決於service資源的調度方式，默認爲輪詢（roundrobin），如下圖所示：
這種代理模式請求流量到達內核空間後經由套接字送往用戶空間的Kube-proxy，而後由它送回內核空間，並調度至後端pod。這種方式請求會在內核和用戶空間之間來回轉發導致效率不高。
iptables代理模型
iptables代理模式和前一種代理模式是類似的，都是由Kube-proxy來跟蹤監聽API-server上的service和Endpoints的變更。但是有一點不同的是iptables規則直接捕獲到達cluster IP和port的流量，並將其重定向至當前Service的後端，對於每個Endpoints對象，Service資源會爲其創建iptables規則並關聯至挑選的後端pod資源，默認算法是隨機調度（random）。iptables代理模式在Kubernetes1.1版本引入，並在1.2版開始成爲默認類型。
在創建service資源時，集羣中每個節點上的Kube-proxy都會接受到通知並將其定義爲當前節點上的iptables規則，用於轉發工作接口接收到的iptables進行調度和目標地址轉換（DNAT）後再轉發至集羣內部的pod對象上。
相對於用戶空間來講，iptables模型無須將流量在用戶空間和內核空間來回切換，因更加高效和可靠。
ipvs代理模型
Kubernetes從1.9版本引入ipvs代理模型，且從1.11版本起成爲默認設置。它和iptables模型很類似，唯一一點不同的是在其請求流量的調度功能由ipvs實現，餘下的功能仍由iptables完成。
ipvs是建立在netfilter的鉤子函數上，但它使用hash表作爲底層數據結構並工作於內核空間，因此流量轉發速度特別快、規則同步性很好，而且它支持衆多調度算法，rr（輪詢）、lc（最小連接數）、dh（目標哈希）、sh（源哈希）、sed(最短期望延遲)、nq（不排隊調度）。
參考書籍《Kubernetes進階實戰》
個人github賬號：https://github.com/SpecialAll