摘要：當(dāng)通過訪問應(yīng)用時，流量經(jīng)由表中的規(guī)則鏈處理后，跳轉(zhuǎn)到子鏈，而此鏈包含了對具體處理的規(guī)則。再次防火墻規(guī)則，發(fā)現(xiàn)經(jīng)由的模塊，以方式均衡的分發(fā)流量，也即負(fù)載均衡模式為輪訓(xùn)。

? 在K8S集群內(nèi)部，應(yīng)用常使用Service互訪，那么，了解Service技術(shù)優(yōu)缺點(diǎn)將有利于應(yīng)用規(guī)劃與部署，鑒于此，本文將通過簡單案例以探索Cluster-Ip類型Service服務(wù)的利弊。

? 為便于講解，我們先創(chuàng)建如下應(yīng)用及Service服務(wù)：

# kubectl run --image=nginx nginx-web-1 --image-pull-policy="IfNotPresent"
# kubectl expose deployment nginx-web-1 --port=80 --target-port=80

? 作者的K8S環(huán)境是1.9版本，其Service內(nèi)部服務(wù)由Kube-Proxy¹提供，且默認(rèn)用iptables技術(shù)實(shí)現(xiàn)，故本文探索K8S集群Service技術(shù)，即研究iptables在K8S上的技術(shù)實(shí)現(xiàn)。

? 如下可知，通過nginx-web-1服務(wù)可實(shí)際訪問到后端pod：

# nginx pod ip地址：
# kubectl describe pod nginx-web-1-fb8d45f5f-dcbtt | grep "IP"
IP:             10.129.1.22

# Service服務(wù)，通過172.30.132.253:80則實(shí)際訪問到10.129.1.22:80
# kubectl describe svc nginx-web-1 
...
Type:              ClusterIP
IP:                172.30.132.253
Port:                80/TCP
TargetPort:        80/TCP
Endpoints:         10.129.1.22:80
Session Affinity:  None
...

# 重置nginx web頁面：
# kubectl exec -it nginx-web-1-fb8d45f5f-dcbtt -- 
               sh -c "echo hello>/usr/share/nginx/html/index.html"

# curl 10.129.1.22
hello
# curl 172.30.132.253
hello

? Service服務(wù)分配的CLUSTER-IP以及監(jiān)聽的端口均虛擬的，即在K8S集群節(jié)點(diǎn)上執(zhí)行ip a與netstat -an命令均無法找到，其實(shí)際上，IP與Port是由iptables配置在每K8S節(jié)點(diǎn)上的。在節(jié)點(diǎn)上執(zhí)行如下命令可找到此Service相關(guān)的iptables配置，簡析如下：

當(dāng)通過Service服務(wù)IP：172.30.132.253:80訪問時，匹配第3條規(guī)則鏈（KUBE-SERVICES）后，跳轉(zhuǎn)到第4條子鏈（KUBE-SVC-...）上；

第4條子鏈做簡單注釋后，繼而跳轉(zhuǎn)到第1、2規(guī)則鏈（KUBE-SEP-...）上；

當(dāng)源Pod通過Service訪問自身時，匹配第1條規(guī)則，繼而跳轉(zhuǎn)到KUBE-MARK-MASQ鏈中；

匹配到第2條規(guī)則，此時通過DNAT被重定向到后端Pod：108.29.1.22:80。

# iptables-save | grep nginx-web-1
-A KUBE-SEP-UWNFTKZFYWNNNTK7 -s 10.129.1.22/32 -m comment --comment "demo/nginx-web-1:" 
   -j KUBE-MARK-MASQ
-A KUBE-SEP-UWNFTKZFYWNNNTK7 -p tcp -m comment --comment "demo/nginx-web-1:" 
   -m tcp -j DNAT --to-destination 10.129.1.22:80
-A KUBE-SERVICES -d 172.30.132.253/32 -p tcp -m comment 
   --comment "demo/nginx-web-1: cluster IP" -m tcp --dport 80 -j KUBE-SVC-SNP24T7IBBNZDJ76
-A KUBE-SVC-SNP24T7IBBNZDJ76 -m comment --comment "demo/nginx-web-1:" 
   -j KUBE-SEP-UWNFTKZFYWNNNTK7

? 詳細(xì)分析iptables規(guī)則，執(zhí)行iptables-save命令可發(fā)現(xiàn)nat的PREROUTING與OUTPUT鏈中均有KUBE-SERVICES規(guī)則鏈，且處于第一順位。

*nat
-A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE-SERVICES
-A OUTPUT -m comment --comment "kubernetes service portals" -j KUBE-SERVICES

當(dāng)通過Service訪問應(yīng)用時，流量經(jīng)由nat表中的PREROUTING規(guī)則鏈處理后，跳轉(zhuǎn)到KUBE-SERVICES子鏈，而此鏈包含了對具體Service處理的規(guī)則。如下所示，訪問172.30.132.253:80將被跳轉(zhuǎn)到KUBE-SEP-...子規(guī)則鏈中。

-A KUBE-SERVICES -d 172.30.132.253/32 -p tcp -m comment 
   --comment "demo/nginx-web-1: cluster IP" -m tcp --dport 80 -j KUBE-SVC-SNP24T7IBBNZDJ76
-A KUBE-SVC-SNP24T7IBBNZDJ76 -m comment --comment "demo/nginx-web-1:" 
   -j KUBE-SEP-UWNFTKZFYWNNNTK7

? 如下所示，KUBE-SEP-...子鏈存在兩條規(guī)則：

第1條規(guī)則：Pod通過Service訪問自身時匹配，此規(guī)則僅作標(biāo)記（MARK）處理；

第2條規(guī)則：通過DNAT重定向到后端Pod實(shí)例上，至此，通過Service最終將流量導(dǎo)向到后端實(shí)例上；

-A KUBE-SEP-UWNFTKZFYWNNNTK7 -s 10.129.1.22/32 -m comment --comment "demo/nginx-web-1:" 
   -j KUBE-MARK-MASQ
-A KUBE-SEP-UWNFTKZFYWNNNTK7 -p tcp -m comment --comment "demo/nginx-web-1:" 
   -m tcp -j DNAT --to-destination 10.129.1.22:80

-A KUBE-MARK-MASQ -j MARK --set-xmark 0x1/0x1

? 執(zhí)行如下命令將Deployment擴(kuò)展為3個Pod后，繼而再觀察Service負(fù)載均衡方面的技術(shù)或問題。

# kubectl scale deploy/nginx-web-1 --replicas=3

? 再次dump防火墻規(guī)則，發(fā)現(xiàn)Service經(jīng)由iptables的statistic模塊，以random方式均衡的分發(fā)流量，也即負(fù)載均衡模式為輪訓(xùn)。

存在3條DNAT與KUBE-MARK-MASQ規(guī)則，分別對應(yīng)3個后端Pod實(shí)地址；

KUBE-SERVICES鏈中存在3條子鏈，除最后一條KUBE-SVC-...子鏈外，其余子鏈?zhǔn)褂媚Kstatistic的random模式做流量分割或負(fù)載均衡：第1條KUBE-SVC-...應(yīng)用33%流量，第2條KUBE-SVC-...規(guī)則應(yīng)用剩余的50%流量，第3條KUBE-SVC-...規(guī)則應(yīng)用最后的流量。

# iptables-save | grep nginx-web-1
-A KUBE-SEP-BI762VOIAZZWU5S7 -s 10.129.1.27/32 -m comment --comment "demo/nginx-web-1:" 
   -j KUBE-MARK-MASQ
-A KUBE-SEP-BI762VOIAZZWU5S7 -p tcp -m comment --comment "demo/nginx-web-1:" 
   -m tcp -j DNAT --to-destination 10.129.1.27:80

-A KUBE-SEP-CDQIKEVSTA766BRK -s 10.129.1.28/32 -m comment --comment "demo/nginx-web-1:" 
   -j KUBE-MARK-MASQ
-A KUBE-SEP-CDQIKEVSTA766BRK -p tcp -m comment --comment "demo/nginx-web-1:" 
   -m tcp -j DNAT --to-destination 10.129.1.28:80

-A KUBE-SEP-W5HTO42ZVNHJQWBG -s 10.129.3.57/32 -m comment --comment "demo/nginx-web-1:" 
   -j KUBE-MARK-MASQ
-A KUBE-SEP-W5HTO42ZVNHJQWBG -p tcp -m comment --comment "demo/nginx-web-1:" 
   -m tcp -j DNAT --to-destination 10.129.3.57:80

-A KUBE-SERVICES -d 172.30.132.253/32 -p tcp -m comment 
   --comment "demo/nginx-web-1: cluster IP" -m tcp --dport 80 -j KUBE-SVC-SNP24T7IBBNZDJ76

-A KUBE-SVC-SNP24T7IBBNZDJ76 -m comment --comment "demo/nginx-web-1:" 
   -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-BI762VOIAZZWU5S7
-A KUBE-SVC-SNP24T7IBBNZDJ76 -m comment --comment "demo/nginx-web-1:" 
   -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-CDQIKEVSTA766BRK
-A KUBE-SVC-SNP24T7IBBNZDJ76 -m comment --comment "demo/nginx-web-1:" 
   -j KUBE-SEP-W5HTO42ZVNHJQWBG

? 如下所示，調(diào)整Service服務(wù)，打開會話保持功能，并設(shè)置會話保持期限為3小時（PS：若不設(shè)置，則默認(rèn)是3小時）：

# kubectl edit svc nginx-web-1
...
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 10800
...

? 繼續(xù)觀察iptables實(shí)現(xiàn)，發(fā)現(xiàn)在原有基礎(chǔ)上，iptables規(guī)則中添加了recent模塊，此模塊被用于會話保持功能，故kube-proxy通過在iptables中結(jié)合statistic與recent模塊，實(shí)現(xiàn)了Service的輪訓(xùn)負(fù)載均衡與會話保持功能。

通過Service服務(wù)訪問應(yīng)用，封包進(jìn)入KUBE-SERVICES規(guī)則鏈，并跳轉(zhuǎn)到KUBE-SVC-...子鏈中；

在KUBE-SVC-SNP...子鏈中，recent位于statistic模塊前，故而，有如下情況出現(xiàn)：

當(dāng)客戶端第一次訪問Service時，KUBE-SVC-...子鏈中的規(guī)則（-m recent --rcheck --seconds 10800 --reap ...--rsource）池中未記錄客戶端地址，故封包匹配失敗，從而封包被后續(xù)的statistic模塊規(guī)則處理后，均衡分發(fā)到KUBE-SEP-...子鏈中，此鏈中使用recent模塊的--set參數(shù)將客戶源地址記錄到規(guī)則池后，DNAT到實(shí)際后端實(shí)例上；

KUBE-SVC-...子鏈中recent模塊配置了源地址記錄期限，若客戶端3（--seconds 10800 --reap）小時內(nèi)未訪問服務(wù)，則recent規(guī)則池中的客戶端記錄將被移除，此時客戶端再次訪問Service就如同第一次訪問Service一樣；

當(dāng)客戶端在3小時內(nèi)再次訪問Service時，匹配KUBE-SVC-...子鏈中的recent模塊規(guī)則后，跳轉(zhuǎn)到KUBE-SEP子鏈，其規(guī)則中recent模塊--set參數(shù)將更新規(guī)則池中的Record TTL，而后DNAT到實(shí)際后端實(shí)例上；

# iptables-save | grep nginx-web-1
-A KUBE-SEP-BI762VOIAZZWU5S7 -s 10.129.1.27/32 -m comment --comment "demo/nginx-web-1:" 
   -j KUBE-MARK-MASQ
-A KUBE-SEP-BI762VOIAZZWU5S7 -p tcp -m comment --comment "demo/nginx-web-1:" 
   -m recent --set --name KUBE-SEP-BI762VOIAZZWU5S7 --mask 255.255.255.255 
   --rsource -m tcp -j DNAT --to-destination 10.129.1.27:80
# 省略2條類似的KUBE-SEP規(guī)則
...

-A KUBE-SERVICES -d 172.30.132.253/32 -p tcp -m comment 
   --comment "demo/nginx-web-1: cluster IP" -m tcp --dport 80 -j KUBE-SVC-SNP24T7IBBNZDJ76

-A KUBE-SVC-SNP24T7IBBNZDJ76 -m comment --comment "demo/nginx-web-1:" 
   -m recent --rcheck --seconds 10800 --reap --name KUBE-SEP-BI762VOIAZZWU5S7 
   --mask 255.255.255.255 --rsource -j KUBE-SEP-BI762VOIAZZWU5S7
# 省略2條類似的KUBE-SVC規(guī)則
...

-A KUBE-SVC-SNP24T7IBBNZDJ76 -m comment --comment "demo/nginx-web-1:" 
   -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-BI762VOIAZZWU5S7
-A KUBE-SVC-SNP24T7IBBNZDJ76 -m comment --comment "demo/nginx-web-1:" 
   -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-CDQIKEVSTA766BRK
-A KUBE-SVC-SNP24T7IBBNZDJ76 -m comment --comment "demo/nginx-web-1:" 
   -j KUBE-SEP-W5HTO42ZVNHJQWBG

? K8S中的Service服務(wù)可提供負(fù)載均衡及會話保持功能，其通過Linux內(nèi)核netfilter模塊來配置iptables實(shí)現(xiàn)，網(wǎng)絡(luò)封包在內(nèi)核中流轉(zhuǎn)，且規(guī)則匹配很少，故效率非常高；而Service負(fù)載均衡分發(fā)比較薄弱，其通過statistic的random規(guī)則實(shí)現(xiàn)輪訓(xùn)分發(fā)，無法實(shí)現(xiàn)復(fù)雜的如最小鏈接分發(fā)方式，鑒于此，K8S 1.9后續(xù)版本調(diào)整了kube-proxy服務(wù)，其可通過ipvs實(shí)現(xiàn)Service負(fù)載均衡功能。