1.

一個簡單想法,在k8s里部署httpd服務,服務成功running.
外部流量怎么訪問到真正提供服務的pod呢？
示例見下:

svc： [root@k8s-master1 test]# kubectl get svc NAME? ? ? ? ? TYPE? ? ? ? CLUSTER-IP? ? ? EXTERNAL-IP?? PORT(S)? ? ?? AGE httpd-svc? ?? NodePort? ? 10.254.17.8? ?? <none>? ? ? ? 80:8572/TCP?? 7spod: [root@k8s-master1 test]# kubectl get pod NAME? ? ? ? ? ? ? ? ? ? ? ? READY? ?? STATUS? ? RESTARTS?? AGE httpd-app-bbcbfb6cd-dfwbs?? 1/1? ? ?? Running?? 0? ? ? ? ? 37s

svc和pod的映射關系

[root@k8s-master2 ~]# kubectl describe svc httpd-svc Name:? ? ? ? ? ? ? ? ? ?? httpd-svc Namespace:? ? ? ? ? ? ? ? default Labels:? ? ? ? ? ? ? ? ?? <none> Annotations:? ? ? ? ? ? ? kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"httpd-svc","namespace":"default"},"spec":{"ports":[{"port":80}],"selector":{"a... Selector:? ? ? ? ? ? ? ?? app=httpd-app Type:? ? ? ? ? ? ? ? ? ?? NodePort IP:? ? ? ? ? ? ? ? ? ? ?? 10.254.17.8 Port:? ? ? ? ? ? ? ? ? ?? <unset>? 80/TCP TargetPort:? ? ? ? ? ? ?? 80/TCP NodePort:? ? ? ? ? ? ? ?? <unset>? 8572/TCP Endpoints:? ? ? ? ? ? ? ? 172.30.32.4:80 Session Affinity:? ? ? ?? None External Traffic Policy:? Cluster Events:? ? ? ? ? ? ? ? ?? <none>

外部流量訪問到svc,然后svc跳轉pod訪問應用.
svc怎么跳轉訪問pod的呢？
kube-proxy實現svc到pod的訪問和負載均衡.
k8s低版本1.8版本前,kube-proxy默認使用iptables模式轉發流量到pod.
1.8版本之后,kube-proxy默認使用ipvs模式.

2.

ipvs基礎知識

ipvs常用的模式:
VS/NAT模式（Network address translation）
VS/TUN模式（tunneling）
VS/DR模式（Direct routing）

VS/NAT模式,基本原理和過程,
以下圖片和文字來于文檔:https://www.cnblogs.com/randomlee/p/9046612.html

這個是通過網絡地址轉換的方法來實現調度的。首先調度器(LB)接收到客戶的請求數據包時（請求的目的IP為VIP），根據調度算法決定將請求發送給哪個后端的真實服務器（RS）。然后調度就把客戶端發送的請求數據包的目標IP地址及端口改成后端真實服務器的IP地址（RIP）,這樣真實服務器（RS）就能夠接收到客戶的請求數據包了。真實服務器響應完請求后，查看默認路由（NAT模式下我們需要把RS的默認路由設置為LB服務器。）把響應后的數據包發送給LB,LB再接收到響應包后，把包的源地址改成虛擬地址（VIP）然后發送回給客戶端。

調度過程IP包詳細圖：

原理圖簡述：

1)客戶端請求數據，目標IP為VIP

2)請求數據到達LB服務器，LB根據調度算法將目的地址修改為RIP地址及對應端口（此RIP地址是根據調度算法得出的。）并在連接HASH表中記錄下這個連接。

3)數據包從LB服務器到達RS服務器webserver，然后webserver進行響應。Webserver的網關必須是LB，然后將數據返回給LB服務器。

4)收到RS的返回后的數據，根據連接HASH表修改源地址VIP&目標地址CIP，及對應端口80.然后數據就從LB出發到達客戶端。

5)客戶端收到的就只能看到VIP\DIP信息。

3.

iptables基礎知識

以下文字來源于文檔:
https://www.cnblogs.com/ggjucheng/archive/2012/08/19/2646466.html?tdsourcetag=s_pcqq_aiomsg

iptables簡介
? ? netfilter/iptables（簡稱為iptables）組成Linux平臺下的包過濾防火墻，與大多數的Linux軟件一樣，這個包過濾防火墻是免費的，它可以代替昂貴的商業防火墻解決方案，完成封包過濾、封包重定向和網絡地址轉換（NAT）等功能。

iptables基礎

? ? 規則（rules）其實就是網絡管理員預定義的條件，規則一般的定義為“如果數據包頭符合這樣的條件，就這樣處理這個數據包”。規則存儲在內核空間的信息包過濾表中，這些規則分別指定了源地址、目的地址、傳輸協議（如TCP、UDP、ICMP）和服務類型（如HTTP、FTP和SMTP）等。當數據包與規則匹配時，iptables就根據規則所定義的方法來處理這些數據包，如放行（accept）、拒絕（reject）和丟棄（drop）等。配置防火墻的主要工作就是添加、修改和刪除這些規則。

iptables和netfilter的關系：
? ? 這是第一個要說的地方，Iptables和netfilter的關系是一個很容易讓人搞不清的問題。很多的知道iptables卻不知道netfilter。其實iptables只是Linux防火墻的管理工具而已，位于/sbin/iptables。真正實現防火墻功能的是netfilter，它是Linux內核中實現包過濾的內部結構。

iptables傳輸數據包的過程
① 當一個數據包進入網卡時，它首先進入PREROUTING鏈，內核根據數據包目的IP判斷是否需要轉送出去。
② 如果數據包就是進入本機的，它就會沿著圖向下移動，到達INPUT鏈。數據包到了INPUT鏈后，任何進程都會收到它。本機上運行的程序可以發送數據包，這些數據包會經過OUTPUT鏈，然后到達POSTROUTING鏈輸出。
③ 如果數據包是要轉發出去的，且內核允許轉發，數據包就會如圖所示向右移動，經過FORWARD鏈，然后到達POSTROUTING鏈輸出。

iptables的規則表和鏈：
? ? 表（tables）提供特定的功能，iptables內置了4個表，即filter表、nat表、mangle表和raw表，分別用于實現包過濾，網絡地址轉換、包重構(修改)和數據跟蹤處理。

? ? 鏈（chains）是數據包傳播的路徑，每一條鏈其實就是眾多規則中的一個檢查清單，每一條鏈中可以有一條或數條規則。當一個數據包到達一個鏈時，iptables就會從鏈中第一條規則開始檢查，看該數據包是否滿足規則所定義的條件。如果滿足，系統就會根據該條規則所定義的方法處理該數據包；否則iptables將繼續檢查下一條規則，如果該數據包不符合鏈中任一條規則，iptables就會根據該鏈預先定義的默認策略來處理數據包。

規則表：
1.filter表——三個鏈：INPUT、FORWARD、OUTPUT
作用：過濾數據包? 內核模塊：iptables_filter.
2.Nat表——三個鏈：PREROUTING、POSTROUTING、OUTPUT
作用：用于網絡地址轉換（IP、端口） 內核模塊：iptable_nat
3.Mangle表——五個鏈：PREROUTING、POSTROUTING、INPUT、OUTPUT、FORWARD
作用：修改數據包的服務類型、TTL、并且可以配置路由實現QOS內核模塊：iptable_mangle(別看這個表這么麻煩，咱們設置策略時幾乎都不會用到它)
4.Raw表——兩個鏈：OUTPUT、PREROUTING
作用：決定數據包是否被狀態跟蹤機制處理? 內核模塊：iptable_raw
(這個是REHL4沒有的，不過不用怕，用的不多)

規則鏈：

1.INPUT——進來的數據包應用此規則鏈中的策略
2.OUTPUT——外出的數據包應用此規則鏈中的策略
3.FORWARD——轉發數據包時應用此規則鏈中的策略
4.PREROUTING——對數據包作路由選擇前應用此鏈中的規則
（記住！所有的數據包進來的時侯都先由這個鏈處理）
5.POSTROUTING——對數據包作路由選擇后應用此鏈中的規則
（所有的數據包出來的時侯都先由這個鏈處理）

規則表之間的優先順序：
Raw——mangle——nat——filter
規則鏈之間的優先順序（分三種情況）：

第一種情況：入站數據流向

? ? 從外界到達防火墻的數據包，先被PREROUTING規則鏈處理（是否修改數據包地址等），之后會進行路由選擇（判斷該數據包應該發往何處），如果數據包的目標主機是防火墻本機（比如說Internet用戶訪問防火墻主機中的web服務器的數據包），那么內核將其傳給INPUT鏈進行處理（決定是否允許通過等），通過以后再交給系統上層的應用程序（比如Apache服務器）進行響應。

第二沖情況：轉發數據流向

? ? 來自外界的數據包到達防火墻后，首先被PREROUTING規則鏈處理，之后會進行路由選擇，如果數據包的目標地址是其它外部地址（比如局域網用戶通過網關訪問QQ站點的數據包），則內核將其傳遞給FORWARD鏈進行處理（是否轉發或攔截），然后再交給POSTROUTING規則鏈（是否修改數據包的地址等）進行處理。

第三種情況：出站數據流向
? ?? 防火墻本機向外部地址發送的數據包（比如在防火墻主機中測試公網DNS服務器時），首先被OUTPUT規則鏈處理，之后進行路由選擇，然后傳遞給POSTROUTING規則鏈（是否修改數據包的地址等）進行處理。

4.

k8s中的ipvs使用

上面特意的詳細記錄ipvs的NAT模式基礎知識和iptables的基礎知識.
因為k8s里的ipvs使用的就是NAT模式.而且ipvs并不能實現kube-proxy的全部功能,比如包過濾,源地址轉換,masquared(偽裝)轉換等,這些都需要iptables來處理.

檢索k8s集群中iptables的鏈,表,規則

表,見下:

[root@k8s-node1 ~]# iptables-save # Generated by iptables-save v1.4.21 on Tue Mar 26 09:46:00 2019 *filter :INPUT ACCEPT [129:42061] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [124:9766] :DOCKER - [0:0] :DOCKER-ISOLATION - [0:0] :KUBE-FIREWALL - [0:0] :KUBE-FORWARD - [0:0] -A INPUT -j KUBE-FIREWALL -A FORWARD -m comment --comment "kubernetes forwarding rules" -j KUBE-FORWARD -A FORWARD -j DOCKER-ISOLATION -A FORWARD -o docker0 -j DOCKER -A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i docker0 ! -o docker0 -j ACCEPT -A FORWARD -i docker0 -o docker0 -j ACCEPT -A FORWARD -s 172.30.0.0/16 -j ACCEPT -A FORWARD -d 172.30.0.0/16 -j ACCEPT -A OUTPUT -j KUBE-FIREWALL -A DOCKER-ISOLATION -j RETURN -A KUBE-FIREWALL -m comment --comment "kubernetes firewall for dropping marked packets" -m mark --mark 0x8000/0x8000 -j DROP -A KUBE-FORWARD -m comment --comment "kubernetes forwarding rules" -m mark --mark 0x4000/0x4000 -j ACCEPT -A KUBE-FORWARD -s 172.30.0.0/16 -m comment --comment "kubernetes forwarding conntrack pod source rule" -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A KUBE-FORWARD -d 172.30.0.0/16 -m comment --comment "kubernetes forwarding conntrack pod destination rule" -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT COMMIT # Completed on Tue Mar 26 09:46:00 2019 # Generated by iptables-save v1.4.21 on Tue Mar 26 09:46:00 2019 *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [3:180] :POSTROUTING ACCEPT [3:180] :DOCKER - [0:0] :KUBE-FIREWALL - [0:0] :KUBE-LOAD-BALANCER - [0:0] :KUBE-MARK-DROP - [0:0] :KUBE-MARK-MASQ - [0:0] :KUBE-NODE-PORT - [0:0] :KUBE-POSTROUTING - [0:0] :KUBE-SERVICES - [0:0] -A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE-SERVICES -A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER -A OUTPUT -m comment --comment "kubernetes service portals" -j KUBE-SERVICES -A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER -A POSTROUTING -m comment --comment "kubernetes postrouting rules" -j KUBE-POSTROUTING -A POSTROUTING -s 172.30.30.0/24 ! -o docker0 -j MASQUERADE -A DOCKER -i docker0 -j RETURN -A KUBE-FIREWALL -j KUBE-MARK-DROP -A KUBE-LOAD-BALANCER -j KUBE-MARK-MASQ -A KUBE-MARK-DROP -j MARK --set-xmark 0x8000/0x8000 -A KUBE-MARK-MASQ -j MARK --set-xmark 0x4000/0x4000 -A KUBE-NODE-PORT -p tcp -m comment --comment "Kubernetes nodeport TCP port for masquerade purpose" -m set --match-set KUBE-NODE-PORT-TCP dst -j KUBE-MARK-MASQ -A KUBE-POSTROUTING -m comment --comment "kubernetes service traffic requiring SNAT" -m mark --mark 0x4000/0x4000 -j MASQUERADE -A KUBE-POSTROUTING -m comment --comment "Kubernetes endpoints dst ip:port, source ip for solving hairpin purpose" -m set --match-set KUBE-LOOP-BACK dst,dst,src -j MASQUERADE -A KUBE-SERVICES ! -s 172.30.0.0/16 -m comment --comment "Kubernetes service cluster ip + port for masquerade purpose" -m set --match-set KUBE-CLUSTER-IP dst,dst -j KUBE-MARK-MASQ -A KUBE-SERVICES -m addrtype --dst-type LOCAL -j KUBE-NODE-PORT -A KUBE-SERVICES -m set --match-set KUBE-CLUSTER-IP dst,dst -j ACCEPT COMMIT # Completed on Tue Mar 26 09:46:00 2019 [root@k8s-node1 ~]#

可見,在這里只有兩種表,nat和filter

規則鏈,見下:

[root@k8s-node1 ~]# iptables -L -n Chain INPUT (policy ACCEPT) target? ?? prot opt source? ? ? ? ? ? ?? destination? ? ? ?? KUBE-FIREWALL? all? --? 0.0.0.0/0? ? ? ? ? ? 0.0.0.0/0? ? ? ? ??Chain FORWARD (policy ACCEPT) target? ?? prot opt source? ? ? ? ? ? ?? destination? ? ? ?? KUBE-FORWARD? all? --? 0.0.0.0/0? ? ? ? ? ? 0.0.0.0/0? ? ? ? ? ? /* kubernetes forwarding rules */ DOCKER-ISOLATION? all? --? 0.0.0.0/0? ? ? ? ? ? 0.0.0.0/0? ? ? ? ?? DOCKER? ?? all? --? 0.0.0.0/0? ? ? ? ? ? 0.0.0.0/0? ? ? ? ?? ACCEPT? ?? all? --? 0.0.0.0/0? ? ? ? ? ? 0.0.0.0/0? ? ? ? ? ? ctstate RELATED,ESTABLISHED ACCEPT? ?? all? --? 0.0.0.0/0? ? ? ? ? ? 0.0.0.0/0? ? ? ? ?? ACCEPT? ?? all? --? 0.0.0.0/0? ? ? ? ? ? 0.0.0.0/0? ? ? ? ?? ACCEPT? ?? all? --? 172.30.0.0/16? ? ? ? 0.0.0.0/0? ? ? ? ?? ACCEPT? ?? all? --? 0.0.0.0/0? ? ? ? ? ? 172.30.0.0/16? ? ??Chain OUTPUT (policy ACCEPT) target? ?? prot opt source? ? ? ? ? ? ?? destination? ? ? ?? KUBE-FIREWALL? all? --? 0.0.0.0/0? ? ? ? ? ? 0.0.0.0/0? ? ? ? ??Chain DOCKER (1 references) target? ?? prot opt source? ? ? ? ? ? ?? destination? ? ? ??Chain DOCKER-ISOLATION (1 references) target? ?? prot opt source? ? ? ? ? ? ?? destination? ? ? ?? RETURN? ?? all? --? 0.0.0.0/0? ? ? ? ? ? 0.0.0.0/0? ? ? ? ??Chain KUBE-FIREWALL (2 references) target? ?? prot opt source? ? ? ? ? ? ?? destination? ? ? ?? DROP? ? ?? all? --? 0.0.0.0/0? ? ? ? ? ? 0.0.0.0/0? ? ? ? ? ? /* kubernetes firewall for dropping marked packets */ mark match 0x8000/0x8000Chain KUBE-FORWARD (1 references) target? ?? prot opt source? ? ? ? ? ? ?? destination? ? ? ?? ACCEPT? ?? all? --? 0.0.0.0/0? ? ? ? ? ? 0.0.0.0/0? ? ? ? ? ? /* kubernetes forwarding rules */ mark match 0x4000/0x4000 ACCEPT? ?? all? --? 172.30.0.0/16? ? ? ? 0.0.0.0/0? ? ? ? ? ? /* kubernetes forwarding conntrack pod source rule */ ctstate RELATED,ESTABLISHED ACCEPT? ?? all? --? 0.0.0.0/0? ? ? ? ? ? 172.30.0.0/16? ? ? ? /* kubernetes forwarding conntrack pod destination rule */ ctstate RELATED,ESTABLISHED

5.

ipvs訪問pod的整個過程是怎樣的呢？
這些分析和思路都是個人理解.
結合開始svc示例,進行分析.
見下:

示例:

svc： httpd-svc? ?? NodePort? ? 10.254.17.8? ?? <none>? ? ? ? 80:8572/TCP?? 7spod： httpd-app-bbcbfb6cd-dfwbs?? 1/1? ? ?? Running?? 1? ? ? ? ? 22h? ? ?? 172.30.32.2?? k8s-master3

通過nodeIP:8572訪問http應用,應用訪問請求到達node節點.node就是ipvs里的LB

根據iptables的規則執行順序,首先執行的是nat里的PREROUTING規則,見下:

-A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE-SERVICES -A KUBE-SERVICES ! -s 172.30.0.0/16 -m comment --comment "Kubernetes service cluster ip + port for masquerade purpose" -m set --match-set KUBE-CLUSTER-IP dst,dst -j KUBE-MARK-MASQ -A KUBE-MARK-MASQ -j MARK --set-xmark 0x4000/0x4000

##執行完PREROUTING規則,數據打上0x4000/0x4000的標記.

數據進來了,執行INPUT規則,見下:

-A INPUT -j KUBE-FIREWALL -A KUBE-FIREWALL -j KUBE-MARK-DROP -A KUBE-MARK-DROP -j MARK --set-xmark 0x8000/0x8000

##如果進來的數據帶有0x8000/0x8000標記,丟棄,進來的數據帶有的標記是0x4000/0x4000,因此,數據正常繼續前進

這時申請訪問的地址是vip(svc的ip)
內核的ipvs響應,ipvs根據調度算法將目的地址修改為后端的RL(其實就是pod的地址),數據轉發,用到的規則,見下:

-A FORWARD -m comment --comment "kubernetes forwarding rules" -j KUBE-FORWARD -A KUBE-FORWARD -d 172.30.0.0/16 -m comment --comment "kubernetes forwarding conntrack pod destination rule" -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

##目的地址是172.32.0.0/16的允許轉發,172.32.0.0/16就是pod的地址

訪問請求數據到達pod,pod響應,響應數據到達LB,用到規則

-A KUBE-FORWARD -s 172.30.0.0/16 -m comment --comment "kubernetes forwarding conntrack pod source rule" -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

##源地址是172.32.0.0/16的允許轉發

最后使用POSRTOUTING規則,見下:

-A POSTROUTING -m comment --comment "kubernetes postrouting rules" -j KUBE-POSTROUTING -A KUBE-POSTROUTING -m comment --comment "kubernetes service traffic requiring SNAT" -m mark --mark 0x4000/0x4000 -j MASQUERADE -A KUBE-POSTROUTING -m comment --comment "Kubernetes endpoints dst ip:port, source ip for solving hairpin purpose" -m set --match-set KUBE-LOOP-BACK dst,dst,src -j MASQUERADE

##把后端的RL地址(pod的ip地址)修改成LB的地址,就是SNAT.輸出

以上分析可見,使用的是IPVS的NAT模式.

這些過程和理解是基于上面記錄的iptables基礎知識里的數據包傳輸,見下:
③ 如果數據包是要轉發出去的，且內核允許轉發，數據包就會如圖所示向右移動，經過FORWARD鏈，然后到達POSTROUTING鏈輸出。

6.

ipvs的LB和vip

LB是安裝ipvs的節點
vip是service的ip,內核需要識別VIP(servicede ip)是本機的ip,因此將svc的ip綁定在node的kube-ipvs0上

10: kube-ipvs0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWNlink/ether 82:88:22:c3:e1:e8 brd ff:ff:ff:ff:ff:ffinet 10.254.17.8/32 brd 10.254.17.8 scope global kube-ipvs0valid_lft forever preferred_lft foreverinet 10.254.0.1/32 brd 10.254.0.1 scope global kube-ipvs0valid_lft forever preferred_lft foreverinet 10.254.30.179/32 brd 10.254.30.179 scope global kube-ipvs0valid_lft forever preferred_lft foreverinet 10.254.0.2/32 brd 10.254.0.2 scope global kube-ipvs0valid_lft forever preferred_lft foreverinet 10.254.173.49/32 brd 10.254.173.49 scope global kube-ipvs0valid_lft forever preferred_lft forever

7.

修改ipvs模式

[root@k8s-master2 ~]# systemctl status kube-proxy ● kube-proxy.service - Kubernetes Kube-Proxy ServerLoaded: loaded (/etc/systemd/system/kube-proxy.service; enabled; vendor preset: disabled)Active: active (running) since Tue 2019-03-26 09:04:19 CST; 1h 45min agoDocs: https://github.com/GoogleCloudPlatform/kubernetes Main PID: 892 (kube-proxy)Memory: 26.3MCGroup: /system.slice/kube-proxy.service? 892 /opt/k8s/bin/kube-proxy --config=/etc/kubernetes/kube-proxy.config.yaml --alsologtostderr=true --logtostderr=false --log-dir=... [root@k8s-master2 ~]# cat /etc/kubernetes/kube-proxy.config.yaml apiVersion: kubeproxy.config.k8s.io/v1alpha1 bindAddress: 192.168.32.129 clientConnection:kubeconfig: /etc/kubernetes/kube-proxy.kubeconfig clusterCIDR: 172.30.0.0/16 healthzBindAddress: 192.168.32.129:10256 hostnameOverride: k8s-master2 kind: KubeProxyConfiguration metricsBindAddress: 192.168.32.129:10249 mode: "ipvs"

mode這個值設置模式.

8.

ipvs命令

[root@k8s-master1 ~]# ipvsadm -Ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags-> RemoteAddress:Port? ? ? ? ?? Forward Weight ActiveConn InActConn TCP? 192.168.32.128:8572 rr-> 172.30.32.2:80? ? ? ? ? ? ?? Masq? ? 1? ? ? 0? ? ? ? ? 0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ???? [root@k8s-master1 ~]#

轉載于:https://blog.51cto.com/goome/2369150

總結

以上是生活随笔為你收集整理的k8s实践7:ipvs结合iptables使用过程分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。