轉自：https://www.cnblogs.com/linuxk/p/9605901.html
原文還有定義和創建 service 的 demo。這裏只轉自 service 概念，服務發現，請求路由這幾部分。
文中的 iptables，即 linux 內核防火牆的 iptables。
一、Service的概念
運行在Pod中的應用是向客戶端提供服務的守護進程，比如，nginx、tomcat、etcd等等，它們都是受控於控制器的資源對象，存在生命週期，我們知道Pod資源對象在自願或非自願終端後，只能被重構的Pod對象所替代，屬於不可再生類組件。而在動態和彈性的管理模式下，Service爲該類Pod對象提供了一個固定、統一的訪問接口和負載均衡能力。是不是覺得一堆話都沒聽明白呢？？？？
其實，就是說Pod存在生命週期，有銷燬，有重建，無法提供一個固定的訪問接口給客戶端。並且爲了同類的Pod都能夠實現工作負載的價值，由此Service資源出現了，可以爲一類Pod資源對象提供一個固定的訪問接口和負載均衡，類似於阿里雲的負載均衡或者是LVS的功能。
但是要知道的是，Service和Pod對象的IP地址，一個是虛擬地址，一個是Pod IP地址，都僅僅在集羣內部可以進行訪問，無法接入集羣外部流量。而爲了解決該類問題的辦法可以是在單一的節點上做端口暴露（hostPort）以及讓Pod資源共享工作節點的網絡名稱空間（hostNetwork）以外，還可以使用NodePort或者是LoadBalancer類型的Service資源，或者是有7層負載均衡能力的Ingress資源。
Service是Kubernetes的核心資源類型之一，Service資源基於標籤選擇器將一組Pod定義成一個邏輯組合，並通過自己的IP地址和端口調度代理請求到組內的Pod對象，如下圖所示，它向客戶端隱藏了真是的，處理用戶請求的Pod資源，使得從客戶端上看，就像是由Service直接處理並響應一樣，是不是很像負載均衡器呢！
Service對象的IP地址也稱爲Cluster IP，它位於爲Kubernetes集羣配置指定專用的IP地址範圍之內，是一種虛擬的IP地址，它在Service對象創建之後保持不變，並且能夠被同一集羣中的Pod資源所訪問。Service端口用於接受客戶端請求，並將請求轉發至後端的Pod應用的相應端口，這樣的代理機制，也稱爲端口代理，它是基於TCP/IP 協議棧的傳輸層。
二、Service的實現模型
在 Kubernetes 集羣中，每個 Node 運行一個 kube-proxy 進程。kube-proxy 負責爲 Service 實現了一種 VIP（虛擬 IP）的形式，而不是 ExternalName 的形式。 在 Kubernetes v1.0 版本，代理完全在 userspace。在 Kubernetes v1.1 版本，新增了 iptables 代理，但並不是默認的運行模式。 從 Kubernetes v1.2 起，默認就是 iptables 代理。在Kubernetes v1.8.0-beta.0中，添加了ipvs代理。在 Kubernetes v1.0 版本，Service 是 “4層”（TCP/UDP over IP）概念。 在 Kubernetes v1.1 版本，新增了 Ingress API（beta 版），用來表示 “7層”（HTTP）服務。
kube-proxy 這個組件始終監視着apiserver中有關service的變動信息，獲取任何一個與service資源相關的變動狀態，通過watch監視，一旦有service資源相關的變動和創建，kube-proxy都要轉換爲當前節點上的能夠實現資源調度規則（例如：iptables、ipvs）
2.1、userspace代理模式
這種模式，當客戶端Pod請求內核空間的service iptables後，把請求轉到給用戶空間監聽的kube-proxy 的端口，由kube-proxy來處理後，再由kube-proxy將請求轉給內核空間的 service ip，再由service iptalbes根據請求轉給各節點中的的service pod。
由此可見這個模式有很大的問題，由客戶端請求先進入內核空間的，又進去用戶空間訪問kube-proxy，由kube-proxy封裝完成後再進去內核空間的iptables，再根據iptables的規則分發給各節點的用戶空間的pod。這樣流量從用戶空間進出內核帶來的性能損耗是不可接受的。在Kubernetes 1.1版本之前，userspace是默認的代理模型。
2.2、 iptables代理模式
客戶端IP請求時，直接請求本地內核service ip，根據iptables的規則直接將請求轉發到到各pod上，因爲使用iptable NAT來完成轉發，也存在不可忽視的性能損耗。另外，如果集羣中存在上萬的Service/Endpoint，那麼Node上的iptables rules將會非常龐大，性能還會再打折扣。iptables代理模式由Kubernetes 1.1版本引入，自1.2版本開始成爲默認類型。
2.3、ipvs代理模式
Kubernetes自1.9-alpha版本引入了ipvs代理模式，自1.11版本開始成爲默認設置。客戶端IP請求時到達內核空間時，根據ipvs的規則直接分發到各pod上。kube-proxy會監視Kubernetes Service對象和Endpoints，調用netlink接口以相應地創建ipvs規則並定期與Kubernetes Service對象和Endpoints對象同步ipvs規則，以確保ipvs狀態與期望一致。訪問服務時，流量將被重定向到其中一個後端Pod。
與iptables類似，ipvs基於netfilter 的 hook 功能，但使用哈希表作爲底層數據結構並在內核空間中工作。這意味着ipvs可以更快地重定向流量，並且在同步代理規則時具有更好的性能。此外，ipvs爲負載均衡算法提供了更多選項，例如：
- rr：
輪詢調度 - lc：最小連接數
dh：目標哈希sh：源哈希sed：最短期望延遲nq：不排隊調度
注意： ipvs模式假定在運行kube-proxy之前在節點上都已經安裝了IPVS內核模塊。當kube-proxy以ipvs代理模式啓動時，kube-proxy將驗證節點上是否安裝了IPVS模塊，如果未安裝，則kube-proxy將回退到iptables代理模式。
如果某個服務後端pod發生變化，標籤選擇器適應的pod有多一個，適應的信息會立即反映到apiserver上,而kube-proxy一定可以watch到etc中的信息變化，而將它立即轉爲ipvs或者iptables中的規則，這一切都是動態和實時的，刪除一個pod也是同樣的原理。如圖：
