目錄
- k8s 中的 service 如何找到綁定的 Pod 以及如何實(shí)現(xiàn) Pod 負(fù)載均衡
- 前言
- endpoint
- kube-proxy
- userspace 模式
- iptables
- ipvs
- kernelspace
- 服務(wù)發(fā)現(xiàn)
- 環(huán)境變量
- DNS
- 總結(jié)
- 參考
k8s 中的 service 如何找到綁定的 Pod 以及如何實(shí)現(xiàn) Pod 負(fù)載均衡
前言
Service 資源主要用于為 Pod 對(duì)象提供一個(gè)固定、統(tǒng)一的訪問(wèn)接口及負(fù)載均衡的能力。
service 是一組具有相同 label pod 集合的抽象，集群內(nèi)外的各個(gè)服務(wù)可以通過(guò) service 進(jìn)行互相通信。
當(dāng)創(chuàng)建一個(gè) service 對(duì)象時(shí)也會(huì)對(duì)應(yīng)創(chuàng)建一個(gè) endpoint 對(duì)象，endpoint 是用來(lái)做容器發(fā)現(xiàn)的，service 只是將多個(gè) pod 進(jìn)行關(guān)聯(lián)，實(shí)際的路由轉(zhuǎn)發(fā)都是由 kubernetes 中的 kube-proxy 組件來(lái)實(shí)現(xiàn)，因此，service 必須結(jié)合 kube-proxy 使用，kube-proxy 組件可以運(yùn)行在 kubernetes 集群中的每一個(gè)節(jié)點(diǎn)上也可以只運(yùn)行在單獨(dú)的幾個(gè)節(jié)點(diǎn)上，其會(huì)根據(jù) service 和 endpoints 的變動(dòng)來(lái)改變節(jié)點(diǎn)上 iptables 或者 ipvs 中保存的路由規(guī)則。
endpoint
endpoint 是 k8s 集群中的一個(gè)資源對(duì)象，存儲(chǔ)在 etcd 中，用來(lái)記錄一個(gè) service 對(duì)應(yīng)的所有 pod 的訪問(wèn)地址。
service 通過(guò) selector 和 pod 建立關(guān)聯(lián)。k8s 會(huì)根據(jù) service 關(guān)聯(lián)到 pod 的 podIP 信息組合成一個(gè) endpoint。
如果 service 沒有 selector 字段，當(dāng)一個(gè) service 被創(chuàng)建的時(shí)候，endpoint controller 不會(huì)自動(dòng)創(chuàng)建 endpoint。
$ kubectl get svc -n study-k8s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE go-web-svc ClusterIP 10.233.55.112 <none> 8000/TCP 9d $ kubectl get endpoints -n study-k8s NAME ENDPOINTS AGE go-web-svc 10.233.111.171:8000,10.233.111.172:8000,10.233.72.153:8000 + 2 more... 9d
栗如
上面的 service go-web-svc，就有一個(gè)對(duì)應(yīng)的 endpoint，ENDPOINTS 里面展示的就是 service 關(guān)聯(lián)的 pod 的 ip 地址和端口。
其中 endpoint controller 負(fù)載維護(hù) endpoint 對(duì)象，主要的功能有下面幾種
1、負(fù)責(zé)生成和維護(hù)所有endpoint對(duì)象的控制器；
2、負(fù)責(zé)監(jiān)聽 service 和對(duì)應(yīng) pod 的變化；
3、監(jiān)聽到 service 被刪除，則刪除和該 service 同名的 endpoint 對(duì)象；
4、監(jiān)聽到新的 service 被創(chuàng)建，則根據(jù)新建 service 信息獲取相關(guān) pod 列表，然后創(chuàng)建對(duì)應(yīng) endpoint 對(duì)象；
5、監(jiān)聽到 service 被更新，則根據(jù)更新后的 service 信息獲取相關(guān) pod 列表，然后更新對(duì)應(yīng) endpoint 對(duì)象；
6、監(jiān)聽到 pod 事件，則更新對(duì)應(yīng)的 service 的 endpoint 對(duì)象，將 podIp 記錄到 endpoint中；
kube-proxy
kube-proxy 是 Kubernetes 的核心組件，部署在每個(gè) Node 節(jié)點(diǎn)上，它是實(shí)現(xiàn) Kubernetes Service 的通信與負(fù)載均衡機(jī)制的重要組件; kube-proxy 負(fù)責(zé)為 Pod 創(chuàng)建代理服務(wù)，從 apiserver 獲取所有 server 信息，并根據(jù) server 信息創(chuàng)建代理服務(wù)，實(shí)現(xiàn)server到Pod的請(qǐng)求路由和轉(zhuǎn)發(fā)，從而實(shí)現(xiàn)K8s層級(jí)的虛擬轉(zhuǎn)發(fā)網(wǎng)絡(luò)。
在 k8s 中提供相同服務(wù)的一組 pod 可以抽象成一個(gè) service，通過(guò) service 提供統(tǒng)一的服務(wù)對(duì)外提供服務(wù)，kube-proxy 存在于各個(gè) node 節(jié)點(diǎn)上，負(fù)責(zé)為 service 提供 cluster 內(nèi)部的服務(wù)發(fā)現(xiàn)和負(fù)載均衡，負(fù)責(zé) Pod 的網(wǎng)絡(luò)代理，它會(huì)定時(shí)從 etcd 中獲取 service 信息來(lái)做相應(yīng)的策略，維護(hù)網(wǎng)絡(luò)規(guī)則和四層負(fù)載均衡工作。k8s 中集群內(nèi)部的負(fù)載均衡就是由 kube-proxy 實(shí)現(xiàn)的，它是 k8s 中內(nèi)部的負(fù)載均衡器，也是一個(gè)分布式代理服務(wù)器，可以在每個(gè)節(jié)點(diǎn)中部署一個(gè)，部署的節(jié)點(diǎn)越多，提供負(fù)載均衡能力的 Kube-proxy 就越多，高可用節(jié)點(diǎn)就越多。
簡(jiǎn)單點(diǎn)講就是 k8s 內(nèi)部的 pod 要訪問(wèn) service ，kube-proxy 會(huì)將請(qǐng)求轉(zhuǎn)發(fā)到 service 所代表的一個(gè)具體 pod，也就是 service 關(guān)聯(lián)的 Pod。
同理對(duì)于外部訪問(wèn) service 的請(qǐng)求，不論是 Cluster IP+TargetPort 的方式；還是用 Node 節(jié)點(diǎn) IP+NodePort 的方式，都被 Node 節(jié)點(diǎn)的 Iptables 規(guī)則重定向到 Kube-proxy 監(jiān)聽 Service 服務(wù)代理端口。kube-proxy 接收到 Service 的訪問(wèn)請(qǐng)求后，根據(jù)負(fù)載策略，轉(zhuǎn)發(fā)到后端的 Pod。
kube-proxy 的路由轉(zhuǎn)發(fā)規(guī)則是通過(guò)其后端的代理模塊實(shí)現(xiàn)的，其中 kube-proxy 的代理模塊目前有四種實(shí)現(xiàn)方案，userspace、iptables、ipvs、kernelspace 。
userspace 模式
userspace 模式在 k8s v1.2 后就已經(jīng)被淘汰了，userspace 的作用就是在 proxy 的用戶空間監(jiān)聽一個(gè)端口，所有的 svc 都轉(zhuǎn)到這個(gè)端口，然后 proxy 內(nèi)部應(yīng)用層對(duì)其進(jìn)行轉(zhuǎn)發(fā)。proxy 會(huì)為每一個(gè) svc 隨機(jī)監(jiān)聽一個(gè)端口，并增加一個(gè) iptables 規(guī)則。
從客戶端到 ClusterIP:Port 的報(bào)文都會(huì)通過(guò) iptables 規(guī)則被重定向到 Proxy Port，Kube-Proxy 收到報(bào)文后，然后分發(fā)給對(duì)應(yīng)的 Pod。
userspace 模式下，流量的轉(zhuǎn)發(fā)主要是在用戶空間下完成的，上面提到了客戶端的請(qǐng)求需要借助于 iptables 規(guī)則找到對(duì)應(yīng)的 Proxy Port，因?yàn)?iptables 是在內(nèi)核空間，這里就會(huì)請(qǐng)求就會(huì)有一次從用戶態(tài)到內(nèi)核態(tài)再返回到用戶態(tài)的傳遞過(guò)程, 一定程度降低了服務(wù)性能。所以就會(huì)認(rèn)為這種方式會(huì)有一定的性能損耗。
默認(rèn)情況下，用戶空間模式下的 kube-proxy 通過(guò)輪轉(zhuǎn)算法選擇后端。
iptables
首先來(lái)簡(jiǎn)單了解下 iptables：
iptables 是 Linux 中最常用的一種防火墻工具，除了防火墻它還可以用作 IP 轉(zhuǎn)發(fā)和簡(jiǎn)單的負(fù)載均衡功能。基于 Linux 中的 netfilter 內(nèi)核模塊實(shí)現(xiàn)。 Netfilter 在協(xié)議中添加了一些鉤子，它允許內(nèi)核模塊通過(guò)這些鉤子注冊(cè)回調(diào)函數(shù)，這樣經(jīng)過(guò)鉤子的所有數(shù)據(jù)都會(huì)被注冊(cè)在響應(yīng)鉤子上的函數(shù)處理，包括修改數(shù)據(jù)包內(nèi)容、給數(shù)據(jù)包打標(biāo)記或者丟掉數(shù)據(jù)包等。iptables 是運(yùn)行在用戶態(tài)的一個(gè)程序，通過(guò) netlink 和內(nèi)核的 netfilter 框架打交道，具有足夠的靈活性來(lái)處理各種常見的數(shù)據(jù)包操作和過(guò)濾需求。它允許將靈活的規(guī)則序列附加到內(nèi)核的數(shù)據(jù)包處理管道中的各種鉤子上。
Netfilter 是 Linux 2.4.x 引入的一個(gè)子系統(tǒng)，它作為一個(gè)通用的、抽象的框架，提供一整套的 hook 函數(shù)的管理機(jī)制，使得諸如數(shù)據(jù)包過(guò)濾、網(wǎng)絡(luò)地址轉(zhuǎn)換(NAT)和基于協(xié)議類型的連接跟蹤成為了可能。
在 kubernetes v1.2 之后 iptables 成為默認(rèn)代理模式，這種模式下，kube-proxy 會(huì)監(jiān)視 Kubernetes master 對(duì) Service 對(duì)象和 Endpoints 對(duì)象的添加和移除。 對(duì)每個(gè) Service，它會(huì)安裝 iptables 規(guī)則，從而捕獲到達(dá)該 Service 的 clusterIP（虛擬 IP）和端口的請(qǐng)求，進(jìn)而將請(qǐng)求重定向到 Service 的一組 backend 中的某個(gè)上面。因?yàn)榱髁哭D(zhuǎn)發(fā)都是在內(nèi)核進(jìn)行的，所以性能更高更加可靠。
可以看到該模式下 iptables 來(lái)做用戶態(tài)的入口，kube-proxy 只是持續(xù)監(jiān)聽 Service 以及 Endpoints 對(duì)象的變化， iptables 通過(guò)設(shè)置的轉(zhuǎn)發(fā)策略，直接將對(duì) VIP 的請(qǐng)求轉(zhuǎn)發(fā)給后端 Pod，iptables 使用 DNAT 來(lái)完成轉(zhuǎn)發(fā)，其采用了隨機(jī)數(shù)實(shí)現(xiàn)負(fù)載均衡。
如果 kube-proxy 在 iptables 模式下運(yùn)行，并且所選的第一個(gè) Pod 沒有響應(yīng)，則連接失敗。 這與用戶空間模式不同：在這種情況下，kube-proxy 將檢測(cè)到與第一個(gè) Pod 的連接已失敗， 并會(huì)自動(dòng)使用其他后端 Pod 重試。
該模式相比 userspace 模式，克服了請(qǐng)求在用戶態(tài)-內(nèi)核態(tài)反復(fù)傳遞的問(wèn)題，性能上有所提升，但使用 iptables NAT 來(lái)完成轉(zhuǎn)發(fā)，存在不可忽視的性能損耗，iptables 模式最主要的問(wèn)題是在 service 數(shù)量大的時(shí)候會(huì)產(chǎn)生太多的 iptables 規(guī)則，使用非增量式更新會(huì)引入一定的時(shí)延，大規(guī)模情況下有明顯的性能問(wèn)題。
ipvs
當(dāng)集群的規(guī)模比較大時(shí)，iptables 規(guī)則刷新就會(huì)很慢，難以支撐大規(guī)模的集群。因?yàn)?iptables 的底層實(shí)現(xiàn)是鏈表，對(duì)路由規(guī)則的增刪查改都需要遍歷一次鏈表。
在 kubernetes v1.2 之后 ipvs 成為kube-proxy的默認(rèn)代理模式。ipvs 正是解決這一問(wèn)題的，ipvs 是 LVS 的負(fù)載均衡模塊，與 iptables 比較像的是，ipvs 的實(shí)現(xiàn)雖然也基于 netfilter 的鉤子函數(shù)，但是它卻使用哈希表作為底層的數(shù)據(jù)結(jié)構(gòu)并且工作在內(nèi)核態(tài)，也就是說(shuō) ipvs 在重定向流量和同步代理規(guī)則有著更好的性能，幾乎允許無(wú)限的規(guī)模擴(kuò)張。
ipvs 支持三種負(fù)載均衡模式：
1、DR模式（Direct Routing）；
2、NAT 模式（Network Address Translation）；
3、Tunneling（也稱 ipip 模式）。
三種模式中只有 NAT 支持端口映射，所以 ipvs 使用 NAT 模式。linux 內(nèi)核原生的 ipvs 只支持 DNAT，當(dāng)在數(shù)據(jù)包過(guò)濾，SNAT 和支持 NodePort 類型的服務(wù)這幾個(gè)場(chǎng)景中ipvs 還是會(huì)使用 iptables。
ipvs 也支持更多的負(fù)載均衡算法：
-
rr：round-robin/輪詢；
-
lc：least connection/最少連接；
-
dh：destination hashing/目標(biāo)哈希；
-
sh：source hashing/源哈希；
-
sed：shortest expected delay/預(yù)計(jì)延遲時(shí)間最短；
-
nq：never queue/從不排隊(duì)
kernelspace
kernelspace 模式是 windows 上的代理模式，這里不展開討論了
服務(wù)發(fā)現(xiàn)
service 的 endpoints 解決了容器發(fā)現(xiàn)問(wèn)題，但是不提前知道 service 的 Cluster IP，就無(wú)法知道 service 服務(wù)了。Kubernetes 支持兩種基本的服務(wù)發(fā)現(xiàn)模式 —— 環(huán)境變量和 DNS。
環(huán)境變量
當(dāng)一個(gè) pod 創(chuàng)建完成之后，kubelet 會(huì)在該 pod 中注冊(cè)該集群已經(jīng)創(chuàng)建的所有 service 相關(guān)的環(huán)境變量，但是需要注意的是，在 service 創(chuàng)建之前的所有 pod 是不會(huì)注冊(cè)該環(huán)境變量的，所以在平時(shí)使用時(shí)，建議通過(guò) DNS 的方式進(jìn)行 service 之間的服務(wù)發(fā)現(xiàn)。
舉個(gè)例子，一個(gè)名稱為 redis-primary 的 Service 暴露了 TCP 端口 6379， 同時(shí)給它分配了 Cluster IP 地址 10.0.0.11，這個(gè) Service 生成了如下環(huán)境變量：
REDIS_PRIMARY_SERVICE_HOST=10.0.0.11 REDIS_PRIMARY_SERVICE_PORT=6379 REDIS_PRIMARY_PORT=tcp://10.0.0.11:6379 REDIS_PRIMARY_PORT_6379_TCP=tcp://10.0.0.11:6379 REDIS_PRIMARY_PORT_6379_TCP_PROTO=tcp REDIS_PRIMARY_PORT_6379_TCP_PORT=6379 REDIS_PRIMARY_PORT_6379_TCP_ADDR=10.0.0.11
DNS
可以在集群中部署 CoreDNS 服務(wù)(舊版本的 kubernetes 群使用的是 kubeDNS)， 來(lái)達(dá)到集群內(nèi)部的 pod 通過(guò)DNS 的方式進(jìn)行集群內(nèi)部各個(gè)服務(wù)之間的通訊。
當(dāng)前 kubernetes 集群默認(rèn)使用 CoreDNS 作為默認(rèn)的 DNS 服務(wù)，主要原因是 CoreDNS 是基于 Plugin 的方式進(jìn)行擴(kuò)展的，簡(jiǎn)單，靈活，并且不完全被Kubernetes所捆綁。
同時(shí) k8s 中也建議使用 DNS 來(lái)做服務(wù)發(fā)現(xiàn)。
Kubernetes DNS 服務(wù)器是唯一的一種能夠訪問(wèn) ExternalName 類型的 Service 的方式。
總結(jié)
k8s 中一般使用 Service 為 Pod 對(duì)象提供一個(gè)固定、統(tǒng)一的訪問(wèn)接口及負(fù)載均衡的能力；
k8s 中的負(fù)載均衡主要借助于 endpoint 和 kube-proxy 來(lái)實(shí)現(xiàn)；
endpoint 是 k8s 集群中的一個(gè)資源對(duì)象，存儲(chǔ)在 etcd 中，用來(lái)記錄一個(gè) service 對(duì)應(yīng)的所有 pod 的訪問(wèn)地址，當(dāng)一個(gè) service 關(guān)聯(lián)的 pod 被刪除，更新，新增，對(duì)應(yīng)的 endpoint 資源都會(huì)更新；
kube-proxy 是 Kubernetes 的核心組件，部署在每個(gè) Node 節(jié)點(diǎn)上，它是實(shí)現(xiàn) Kubernetes Service 的通信與負(fù)載均衡機(jī)制的重要組件; kube-proxy 負(fù)責(zé)為 Pod 創(chuàng)建代理服務(wù)，從 apiserver 獲取所有 server 信息，并根據(jù) server 信息創(chuàng)建代理服務(wù)，實(shí)現(xiàn)server到Pod的請(qǐng)求路由和轉(zhuǎn)發(fā)，從而實(shí)現(xiàn)K8s層級(jí)的虛擬轉(zhuǎn)發(fā)網(wǎng)絡(luò)；
kube-proxy 的路由轉(zhuǎn)發(fā)規(guī)則是通過(guò)其后端的代理模塊實(shí)現(xiàn)的，其中 kube-proxy 的代理模塊目前有四種實(shí)現(xiàn)方案，userspace、iptables、ipvs、kernelspace ；
service 的 endpoints 和 kube-proxy 解決了容器的發(fā)現(xiàn)和負(fù)載均衡的問(wèn)題，但是 service 服務(wù)如何被內(nèi)部的服務(wù)找到呢，Kubernetes 支持兩種基本的服務(wù)發(fā)現(xiàn)模式 —— 環(huán)境變量和 DNS；
其中 k8s 中推薦使用 DNS 來(lái)做 service 的服務(wù)發(fā)現(xiàn)，當(dāng)前 kubernetes 集群默認(rèn)使用 CoreDNS 作為默認(rèn)的 DNS 服務(wù)，主要原因是 CoreDNS 是基于 Plugin 的方式進(jìn)行擴(kuò)展的，簡(jiǎn)單，靈活，并且不完全被Kubernetes所捆綁。
參考
【kubernetes service 原理解析】https://zhuanlan.zhihu.com/p/111244353
【service selector】https://blog.csdn.net/luanpeng825485697/article/details/84296765
【一文看懂 Kube-proxy】https://zhuanlan.zhihu.com/p/337806843
【Kubernetes 【網(wǎng)絡(luò)組件】kube-proxy使用詳解】https://blog.csdn.net/xixihahalelehehe/article/details/115370095
【Service】https://jimmysong.io/kubernetes-handbook/concepts/service.html
【Service】https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/
【k8s 中的 service 如何找到綁定的 Pod 以及如何實(shí)現(xiàn) Pod 負(fù)載均衡】https://boilingfrog.github.io/2022/10/16/k8s中的service如何找到綁定的Pod以及如何實(shí)現(xiàn)Pod負(fù)載均衡/
