一、引子
Kubernetes Pod 是有生命周期的，它們可以被創建，也可以被銷毀，然后一旦被銷毀生命就永遠結束。通過ReplicationController 能夠動態地創建和銷毀Pod（列如，需要進行擴縮容，或者執行滾動升級）；每個Pod都會獲取它自己的IP地址，即使這些IP地址不總是穩定可依賴的。這會導致一個問題；在Kubernetes集群中，如果一組Pod（稱為backend）為其他Pod（稱為frontend）提供服務，那么哪些frontend該如何發現，並連接到這組Pod中的那些backend呢？
關於Service
Kubernetes Service定義了這樣一種抽象：一個Pod的邏輯分組，一種可以訪問它們不同的策略--通常稱為微服務。這一組Pod能夠被Service訪問到，通常是通過Label Sekector實現的；
舉個例子，考慮一個圖片處理backend，它運行了3個副本。這些副本是可交換的 -- frontend不需要關心它們調用了哪個backend副本。然后組成這一組backend程序的Pod實際上可能會發生變化，frontend客戶端不應該也沒必要知道，而且也不需要跟蹤這一組backend的狀態。Service定義的抽象能夠解耦這種關聯。
對Kubernetes集群中的應用，Kubernetes提供了簡單的Endpoints API，只要service中的一組Pod發生變更，應用程序就會被更新。對非Kubernetes集群中的應用，Kubernetes提供了基本VIP的網橋的方式訪問Service，再由Service重定向到backend Pod。
二、定義Service
一個Service在Kubernetes中是一個REST對象，和Pod類似。像所有的REST對象一樣，Service定義可以基於POST方式，請求apiserver創建新的實例。例如，假定有一組Pod，它們對外暴漏了9376端口，同時還被打上“app=MyApp”標簽。
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376
上述配置將創建一個名稱為“my-service”的Service對象，它會將請求代理到使用TCP端口9376，並且具有標簽“app=MyApp”的pod上。這個Service將被指派一個IP地址（通常為“Cluster IP”）它會被服務的代理使用。該Service的selector將會持續評估，處理結果將被POST到一個名稱為"my-service"的Endpoints對象上。
需要注意的是，Servie能夠將一個接收端口映射到任意的targetPort。默認情況下，targetPort將被設置為與port字段相同的值。可能更有趣的是，targetPort可以是一個字符串，引用了backend Pod的一個端口的名稱；但是，實際指派給該端口名稱的端口號，在每個backend Pod中可能並不相同。對於部署和設計Service，這種方式會提供更大的靈活性。例如，可以在backend軟件下一個版本中，修改Pod暴露的端口，並不會中斷客戶端的調用。
Kubernetes service能夠支持TCP和UDP協議，默認TCP協議
三、沒有selector的Service
Service抽象了該如何訪問Kubernetes Pod，但也能抽象其他類型的backend，例如：
- 希望在生產環境中使用外部的數據庫集群，但測試環境使用自己的數據庫。
- 希望服務指向另一個Namespace中或其他集群中的服務。
- 正在將工作負載轉移到Kubernetes集群，和運行在Kubernetes集群之外的backend。
在任何這些場景中，都能夠定義沒有selector 的 Service ：
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
ports:
- protocol: TCP
port: 80
targetPort: 9376
由於這個Service沒有selector，就不會創建相關的Endpoints對象。可以手動將Service映射到指定的Endpoints：
kind: Endpoints
apiVersion: v1
metadata:
name: my-service
subsets:
- addresses:
- ip: 1.2.3.4
ports:
- port: 9376
注意：Endpoint IP地址不能loopback（127.0.0.0/8），link-local(169.254.0.0/16),或者link-local多播（224.0.0.0/24）。
訪問沒有selector的Service，與selector的Service的原理相同。請求被路由到用戶定義的Endpoint（該示例中為1.2.3.4:9376）
ExternalName service是Service的特別，它沒有selector，也沒有定義任何的端口和Endpoint。相反地，對於運行在集群外部的服務，它通過返回該外部服務的別名這種方式來提供服務。
kind: Service
apiVersion: v1
metadata:
name: my-service
namespace: prod
spec:
type: ExternalName
externalName: my.database.example.com
當查詢主機 my-service.prod.svc.CLUSTER時，集群的DNS服務將返回一個值為my.database.example.com的CNAME記錄，訪問這個服務的功能方式與其他的相同，唯一不同的是重定向發生的DNS層，而且不會進行代理或轉發。如果后續決定要將數據庫遷移到Kubetnetes中，可以啟動對應的Pod，增加合適的Selector或Endpoint，修改service的typt。
四、VIP和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.0版本，Service是“4層”（TCP/UDP over IP）概念。在Kubernetes v1.1版本，新增了 Ingress API（beta版），用來表示“7層”（HTTP）服務。
五、userspace代理模式
這種模式，kube-proxy會監視Kubernetes master對service對象和Endpoints對象的添加和移除。對每個Service，它會在本地Node上打開一個端口（隨機選擇）。任何連接到“代理端口”的請求，都會被代理到Service的backend Pods中的某一個上面（如 Endpoints 所報告的一樣）。使用哪個backend Pod，是基於Service的SessionAffinity來確定的。最后，它安裝iptables規則，捕獲到達該Service的clusterIP（是虛擬IP）和Port的請求，並重定向到代理端口，代理端口再代理請求到backend Pod。
網絡返回的結果是，任何到達Service的IP：Port的請求，都會被代理到一個合適的backend，不需要客戶端知道關於Kubernetes，service或pod的任何信息。
默認的策略是，通過round-robin算法來選擇backend Pod。實現基於客戶端IP的會話親和性，可以通過設置service.spec.sessionAffinity的值為“ClientIP”（默認值為“None”）；
六、iptables代理模式
這種模式，kube-proxy會監視Kubernetes master對象和Endpoinnts對象的添加和移除。對每個Service，它會安裝iptables規則，從而捕獲到達該Service的clusterIP（虛擬IP）和端口的請求，進而將請求重定向到Service的一組backend中某個上面。對於每個Endpoints對象，它也會安裝iptables規則，這個規則會選擇一個backend Pod。
默認的策略是，隨機選擇一個backend。實現基於客戶端IP的會話親和性，可以將service.spec.sessionAffinity的值設置為“ClientIP”（默認值為“None”）
和userspace代理類似，網絡返回的結果是，任何到達Service的IP：Port的請求，都會被代理到一個合適的backend，不需要客戶端知道關於Kubernetes，service或Pod的任何信息。這應該比userspace代理更快，更可靠。然而，不想userspace代理，如果始出選擇的Pod沒有響應，iptables代理不能自動地重試另一個Pod，所以它需要依賴readiness probes；
https://jimmysong.io/kubernetes-handbook/images/services-iptables-overview.jpg
七、ipvs代理模式
這種模式，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代理模式。
八、多端口Service
很多Service需要暴露多個端口。對於這種情況，Kubernetes 支持在Service對象中定義多個端口。當使用多個端口時，必須給出所有端口的名稱，這樣Endpoint就不會產生歧義，例如：
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- name: http
protocol: TCP
port: 80
targetPort: 9376
- name: https
protocol: TCP
port: 443
targetPort: 9377
九、選擇自己的IP地址
在Service創建的請求中，可以通過設置spec.cluster IP字段來指定自己的集群IP地址。比如，希望替換一個已經存在的DNS條目，或者遺留系統已經配置了一個固定IP且很難重新配置。用戶選擇的IP地址必須合法，並且這個IP地址在service-cluster-ip-range CIDR 范圍內，這對 API Server 來說是通過一個標識來指定的。 如果 IP 地址不合法，API Server 會返回 HTTP 狀態碼 422，表示值不合法。
十、為何不使用round-robin DNS？
一個不時出現的問題是，為什么我們都使用VIP的方式，而不使用標准的round-robin DNS，有如下幾個原因：
- 長久以來，DNS 庫都沒能認真對待 DNS TTL、緩存域名查詢結果
- 很多應用只查詢一次 DNS 並緩存了結果
- 就算應用和庫能夠正確查詢解析，每個客戶端反復重解析造成的負載也是非常難以管理的
我們盡力阻止用戶做那些對他們沒有好處的事情，如果很多人都來問這個問題，我們可能會選擇實現它。
十一、服務發現
Kubernetes 支持2種基本的服務發現模式 —— 環境變量和 DNS。
十二、環境變量
當Pod運行在NOde上，kubelet會為每個活躍的Service添加一組環境變量。它同時支持Docker links兼容變量，簡單的{SVCNAME}_SERVICE_HOST 和 {SVCNAME}_SERVICE_PORT 變量，這里 Service 的名稱需大寫，橫線被轉換成下划線。
舉個例子，一個名稱為 "redis-master" 的 Service 暴露了 TCP 端口 6379，同時給它分配了 Cluster IP 地址 10.0.0.11，這個 Service 生成了如下環境變量：
REDIS_MASTER_SERVICE_HOST=10.0.0.11
REDIS_MASTER_SERVICE_PORT=6379
REDIS_MASTER_PORT=tcp://10.0.0.11:6379
REDIS_MASTER_PORT_6379_TCP=tcp://10.0.0.11:6379
REDIS_MASTER_PORT_6379_TCP_PROTO=tcp
REDIS_MASTER_PORT_6379_TCP_PORT=6379
REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11
這意味着需要有順序的要求 —— Pod 想要訪問的任何 Service 必須在 Pod 自己之前被創建，否則這些環境變量就不會被賦值。DNS 並沒有這個限制。
十三、DNS
一個可選（盡管強烈推薦）集群插件 是 DNS 服務器。 DNS 服務器監視着創建新 Service 的 Kubernetes API，從而為每一個 Service 創建一組 DNS 記錄。 如果整個集群的 DNS 一直被啟用，那么所有的 Pod 應該能夠自動對 Service 進行名稱解析。
例如，有一個名稱為 "my-service" 的 Service，它在 Kubernetes 集群中名為 "my-ns" 的 Namespace 中，為 "my-service.my-ns" 創建了一條 DNS 記錄。 在名稱為 "my-ns" 的 Namespace 中的 Pod 應該能夠簡單地通過名稱查詢找到 "my-service"。 在另一個 Namespace 中的 Pod 必須限定名稱為 "my-service.my-ns"。 這些名稱查詢的結果是 Cluster IP。
Kubernetes 也支持對端口名稱的 DNS SRV（Service）記錄。 如果名稱為 "my-service.my-ns" 的 Service 有一個名為 "http" 的 TCP 端口，可以對 "_http._tcp.my-service.my-ns" 執行 DNS SRV 查詢，得到 "http" 的端口號。
Kubernetes DNS 服務器是唯一的一種能夠訪問 ExternalName 類型的 Service 的方式。 更多信息可以查看 DNS Pod 和 Service。
十四、發布服務 —— 服務類型
對一些應用（如 Frontend）的某些部分，可能希望通過外部（Kubernetes 集群外部）IP 地址暴露 Service。
Kubernetes ServiceTypes 允許指定一個需要的類型的 Service，默認是 ClusterIP 類型。
Type 的取值以及行為如下：
- ClusterIP：通過集群的內部 IP 暴露服務，選擇該值，服務只能夠在集群內部可以訪問，這也是默認的 ServiceType。
- NodePort：通過每個 Node 上的 IP 和靜態端口（NodePort）暴露服務。NodePort 服務會路由到 ClusterIP 服務，這個 ClusterIP 服務會自動創建。通過請求
: ，可以從集群的外部訪問一個 NodePort 服務。 - LoadBalancer：使用雲提供商的負載均衡器，可以向外部暴露服務。外部的負載均衡器可以路由到 NodePort 服務和 ClusterIP 服務。
- ExternalName：通過返回 CNAME 和它的值，可以將服務映射到 externalName 字段的內容（例如， foo.bar.example.com）。 沒有任何類型代理被創建，這只有 Kubernetes 1.7 或更高版本的 kube-dns 才支持。
十五、NodePort 類型
如果設置 type 的值為 "NodePort"，Kubernetes master 將從給定的配置范圍內（默認：30000-32767）分配端口，每個 Node 將從該端口（每個 Node 上的同一端口）代理到 Service。該端口將通過 Service 的 spec.ports[*].nodePort 字段被指定。
如果需要指定的端口號，可以配置 nodePort 的值，系統將分配這個端口，否則調用 API 將會失敗（比如，需要關心端口沖突的可能性）。
這可以讓開發人員自由地安裝他們自己的負載均衡器，並配置 Kubernetes 不能完全支持的環境參數，或者直接暴露一個或多個 Node 的 IP 地址。
需要注意的是，Service 將能夠通過
十六、LoadBalancer 類型
使用支持外部負載均衡器的雲提供商的服務，設置 type 的值為 "LoadBalancer"，將為 Service 提供負載均衡器。 負載均衡器是異步創建的，關於被提供的負載均衡器的信息將會通過 Service 的 status.loadBalancer 字段被發布出去。
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376
nodePort: 30061
clusterIP: 10.0.171.239
loadBalancerIP: 78.11.24.19
type: LoadBalancer
status:
loadBalancer:
ingress:
- ip: 146.148.47.155
來自外部負載均衡器的流量將直接打到 backend Pod 上，不過實際它們是如何工作的，這要依賴於雲提供商。 在這些情況下，將根據用戶設置的 loadBalancerIP 來創建負載均衡器。 某些雲提供商允許設置 loadBalancerIP。如果沒有設置 loadBalancerIP，將會給負載均衡器指派一個臨時 IP。 如果設置了 loadBalancerIP，但雲提供商並不支持這種特性，那么設置的 loadBalancerIP 值將會被忽略掉。