PS： 以下都是博主的自學筆記 + 個人理解的概括，很抱歉沒有準備圖文形式描述，歡迎大家提問交流。
在上一章節的基本概念中，我們有提到Service基本概念。 我們知道Service是對Pod訪問的一種抽象。
本章節，我們來聊一下，Service的工作原理。 概括總結幾個常見疑惑。
一、負載均衡方式
Round Robin方式，對於這種方式我們成爲“Cluster IP” 模式的Service;
二、 Kubernetes Service 究竟是如何工作的呢？
實際上，Service是由 kube-proxy組件，加上 iptables來共同實現的。
- kube-proxy 創建一條 iptables 規則。這條 iptables 規則的含義是：凡是目的地址是 clusterip(service vip如：10.0.1.17）、目的端口是 80 的 IP 包，都應該跳轉到另外一條名叫 KUBE-SVC-NWV5X2332I4OT4T3 的 iptables 鏈進行處理。
- 而這個規則是一組隨機模式的 iptables鏈，隨機轉發地址是 xxx,xxx,xxx,如： （KUBE-SEP-WNBA2IHDGP2BOBGZ、KUBE-SEP-X3P2623AGDH6CDF3 和 KUBE-SEP-57KPRZ3JQVENLNBR）
- 而者三條鏈(其實就是三條 DNAT規則)指向的最終目的地就是 service代理的三個pod
- DNAT規則就是，就是在 PREROUTING 檢查點之前，也就是在路由之前，將流入 IP 包的目的地址和端口，改成–to-destination 所指定的新的目的地址和端口。可以看到，這個目的地址和端口，正是被代理 Pod 的 IP 地址和端口。
這樣，訪問 Service VIP 的 IP 包經過上述 iptables 處理之後，就已經變成了訪問具體某一個後端 Pod 的 IP 包了。不難理解，這些 Endpoints 對應的 iptables 規則，正是 kube-proxy 通過監聽 Pod 的變化事件，在宿主機上生成並維護的。
三、kube-proxy的ipvs模式又是啥？
kube-proxy iptables 模式需要一直刷新、監聽、更改，消耗CPU資源，限制了kubernetes 項目承載更多的Pod。 kube-proxy就是解決這個問題行之有效的方法；
- 當我們創建了前面的 Service 之後，kube-proxy 首先會在宿主機上創建一個虛擬網卡（叫作：kube-ipvs0），併爲它分配 Service VIP 作爲 IP 地址；
- kube-proxy 就會通過 Linux 的 IPVS 模塊，爲這個 IP 地址設置三個 IPVS 虛擬主機，並設置這三個虛擬主機之間使用輪詢模式 (rr) 來作爲負載均衡策略；
- 這三個 IPVS 虛擬主機的 IP 地址和端口，對應的正是三個被代理的 Pod；
四、Service與DNS關係
在 Kubernetes 中，Service 和 Pod 都會被分配對應的 DNS A 記錄（從域名解析 IP 的記錄）
-
ClusterIp Service: {serviceName}.{namespace}.svc.cluster.local (可簡寫成 [svcname.namespace])，訪問這條A記錄的時候，解析到的是 service 的 vip
-
ClusterIp Service Pod 被分配的A記錄：
-
Headless Service： {serviceName}.{namespace}.svc.cluster.local
-
訪問這條A記錄的時候，解析到的是 service 的 vip，解析到的時候 Pod ip 的集合
-
Headless Service Pods: ...svc.cluster.local