[[334029]]

前言

Kubernetes Pod是有生命周期的，它們可以被創(chuàng)建，也可以被銷(xiāo)毀，然而一旦被銷(xiāo)毀生命就永遠(yuǎn)結(jié)束。 通過(guò)ReplicationController能夠動(dòng)態(tài)地創(chuàng)建和銷(xiāo)毀Pod(例如，需要進(jìn)行擴(kuò)縮容，或者執(zhí)行滾動(dòng)升級(jí))。 每個(gè) Pod 都會(huì)獲取它自己的 IP 地址，可一旦銷(xiāo)毀后，重新創(chuàng)建后，IP地址會(huì)產(chǎn)生改變。 這會(huì)導(dǎo)致一個(gè)問(wèn)題：在 Kubernetes 集群中，如果一組 Pod(稱(chēng)為 backend)為其它 Pod (稱(chēng)為 frontend)提供服務(wù)，一旦backend的Pod重新創(chuàng)建，那么frontend的Pod該如何發(fā)現(xiàn)，并連接到這組 Pod 中的哪些 backend 呢?

Service

Service資源用于為pod對(duì)象提供一個(gè)固定、統(tǒng)一的訪問(wèn)接口及負(fù)載均衡的能力，并借助新一代DNS系統(tǒng)的服務(wù)發(fā)現(xiàn)功能，解決客戶(hù)端發(fā)現(xiàn)并訪問(wèn)容器化應(yīng)用的問(wèn)題。

注意：service只是在k8s集群內(nèi)部起作用，集群外部訪問(wèn)是無(wú)效的

實(shí)現(xiàn)原理

Service通過(guò)關(guān)注定義出多個(gè)POD對(duì)象組合而成的邏輯集合，以及訪問(wèn)這組POD的策略，Service關(guān)聯(lián)POD需要標(biāo)簽選擇器完成，其基于標(biāo)簽選擇器將一組POD定義成一個(gè)邏輯集合，并通過(guò)自己的IP地址和端口調(diào)度代理請(qǐng)求至后端POD之上。

apiVersion: v1 
kind: Service 
metadata: 
  name: a-service 
spec: 
  selector: 
    app: pod-label 
  ports: 
  - protocol: TCP 
    port: 80 
    targetPort: 9376 

上面的例子服務(wù)a-service關(guān)聯(lián)著label為【app:pod-label】的pod，這時(shí)候另一個(gè)服務(wù)B可以訪問(wèn)跟a-service服務(wù)綁定的service，service信息是固定的提前告訴B就行了，service通過(guò)Label Selector跟a服務(wù)的pod綁定,無(wú)論a的pod如何變化對(duì)b來(lái)說(shuō)都是透明的。

虛擬IP

service對(duì)象的IP地址稱(chēng)為cluster IP，位于K8S集群配置指定的專(zhuān)用IP地址范圍內(nèi)，其是一種虛擬IP地址，其在service對(duì)象創(chuàng)建后保持不變，并且能夠被同一集群中的POD資源訪問(wèn)，service端口接受客戶(hù)端的請(qǐng)求并將其轉(zhuǎn)發(fā)至后端POD中的相應(yīng)端口，因此，其又被稱(chēng)為四層代理，因其工作在TCP/IP層。

一個(gè)service對(duì)象就是工作節(jié)點(diǎn)上的一些iptables或ipvs，用于將到達(dá)service對(duì)象的IP地址的流量轉(zhuǎn)發(fā)到相應(yīng)的endpoint對(duì)象指定的IP地址和端口上，kube-proxy組件通過(guò)api-server持續(xù)監(jiān)控著各個(gè)service及其相關(guān)的POD對(duì)象，并將其創(chuàng)建或變動(dòng)實(shí)時(shí)反映到工作節(jié)點(diǎn)的iptable或ipvs上

服務(wù)代理

k8s群集中的每個(gè)節(jié)點(diǎn)都運(yùn)行一個(gè)kube-proxy的組件，kube-proxy其實(shí)是一個(gè)代理層負(fù)責(zé)實(shí)現(xiàn)service

userspace模式

客戶(hù)端訪問(wèn)ServiceIP(clusterIP)請(qǐng)求會(huì)先從用戶(hù)空間到內(nèi)核中的iptables，然后回到用戶(hù)空間kube-proxy，kube-proxy負(fù)責(zé)代理工作。

具體細(xì)節(jié)：

請(qǐng)求到達(dá)service后，其被轉(zhuǎn)發(fā)到內(nèi)核，經(jīng)由套接字送往用戶(hù)空間的kube-proxy，而后經(jīng)由kube-proxy送回內(nèi)核空間，并調(diào)度至后端POD，其傳輸方式效率太低。在1.1 版本之前，其是默認(rèn)的轉(zhuǎn)發(fā)策略。

iptables模式

客戶(hù)端訪問(wèn)ServiceIP(clusterIP)請(qǐng)求會(huì)由iptables直接重定向到后端

具體細(xì)節(jié)：

客戶(hù)端IP請(qǐng)求時(shí)，直接請(qǐng)求本地內(nèi)核service ip，根據(jù)iptables的規(guī)則直接將請(qǐng)求轉(zhuǎn)發(fā)到到各pod上，因?yàn)槭褂胕ptable NAT來(lái)完成轉(zhuǎn)發(fā)，也存在不可忽視的性能損耗。另外，如果集群中存在上萬(wàn)的Service/Endpoint，那么Node上的iptables rules將會(huì)非常龐大，性能還會(huì)再打折扣

Kubernetes v1.2之前默認(rèn)是userspace之后是iptables模式，iptables模式性能和可靠性更好，但是iptables模式依賴(lài)健康檢查，在沒(méi)有健康檢查的情況下如果一個(gè)pod不響應(yīng)，iptables模式不會(huì)切換另一個(gè)pod上

ipvs模型

此模型跟蹤API service上的service和endpoints對(duì)象的變動(dòng)，據(jù)此來(lái)調(diào)用netlink接口創(chuàng)建IPVS規(guī)則，并確保API server中的變動(dòng)保持同步，其流量調(diào)度策略在IPVS中實(shí)現(xiàn)，其余的在iptables中實(shí)現(xiàn)。

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

集群外部訪問(wèn)

我們?nèi)绾卧诩和庠L問(wèn)service呢?k8s提供了幾種方式

NodePort

通過(guò)每個(gè) Node 上的 IP 和靜態(tài)端口(NodePort)暴露服務(wù)。NodePort 服務(wù)會(huì)路由到 ClusterIP 服務(wù)，這個(gè) ClusterIP 服務(wù)會(huì)自動(dòng)創(chuàng)建。通過(guò)請(qǐng)求 NodeIP:Port，可以從集群的外部訪問(wèn)一個(gè) NodePort 服務(wù)。

這時(shí)要訪問(wèn)這個(gè)Service的話(huà)，只需要通過(guò)訪問(wèn)

<任何一臺(tái)宿主機(jī)器的IP>:Port

LoadBalancer

在NodePort基礎(chǔ)上，Kubernetes可以請(qǐng)求底層云平臺(tái)cloud provider 創(chuàng)建一個(gè)外部的負(fù)載均衡器，并將請(qǐng)求轉(zhuǎn)發(fā)到每個(gè)Node作為后端，進(jìn)行服務(wù)分發(fā)。

該模式需要底層云平臺(tái)(例如GCE、AWS)支持。

ExternalName

創(chuàng)建一個(gè)dns別名指到service name上，主要是防止service name發(fā)生變化，要配合dns插件使用。通過(guò)返回 CNAME 和它的值，可以將服務(wù)映射到 externalName 字段的內(nèi)容。

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

Ingress

上面我們提到幾種方式，但是當(dāng)集群服務(wù)很多的時(shí)候，NodePort方式最大的缺點(diǎn)是會(huì)占用很多集群機(jī)器的端口;LB方式最大的缺點(diǎn)則是每個(gè)service一個(gè)LB又有點(diǎn)浪費(fèi)和麻煩，并且需要k8s之外的支持; 而ingress則只需要一個(gè)NodePort或者一個(gè)LB就可以滿(mǎn)足所有service對(duì)外服務(wù)的需求。工作機(jī)制大致可以用下圖表示：

Ingress是基于service實(shí)現(xiàn)7層路由轉(zhuǎn)發(fā)能力的