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 7s
pod:
[root@k8s-master1 test]# kubectl get pod
NAME READY STATUS RESTARTS AGE
httpd-app-bbcbfb6cd-dfwbs 1/1 Running 0 37ssvc和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/0x8000
Chain 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,ESTABLISHED5.
ipvs訪問pod的整個過程是怎樣的呢？
這些分析和思路都是個人理解.
結合開始svc示例,進行分析.
見下:
示例:
svc：
httpd-svc NodePort 10.254.17.8 <none> 80:8572/TCP 7s
pod：
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 DOWN
link/ether 82:88:22:c3:e1:e8 brd ff:ff:ff:ff:ff:ff
inet 10.254.17.8/32 brd 10.254.17.8 scope global kube-ipvs0
valid_lft forever preferred_lft forever
inet 10.254.0.1/32 brd 10.254.0.1 scope global kube-ipvs0
valid_lft forever preferred_lft forever
inet 10.254.30.179/32 brd 10.254.30.179 scope global kube-ipvs0
valid_lft forever preferred_lft forever
inet 10.254.0.2/32 brd 10.254.0.2 scope global kube-ipvs0
valid_lft forever preferred_lft forever
inet 10.254.173.49/32 brd 10.254.173.49 scope global kube-ipvs0
valid_lft forever preferred_lft forever7.
修改ipvs模式
[root@k8s-master2 ~]# systemctl status kube-proxy
● kube-proxy.service - Kubernetes Kube-Proxy Server
Loaded: 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 ago
Docs: https://github.com/GoogleCloudPlatform/kubernetes
Main PID: 892 (kube-proxy)
Memory: 26.3M
CGroup: /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 ~]#