kube-proxy IPVS 模式的工作原理

米開朗基楊發表於2021-06-16

原文連結:https://fuckcloudnative.io/posts/ipvs-how-kubernetes-services-direct-traffic-to-pods/

Kubernetes 中的 Service 就是一組同 label 型別 Pod 的服務抽象,為服務提供了負載均衡和反向代理能力,在叢集中表示一個微服務的概念。kube-proxy 元件則是 Service 的具體實現,瞭解了 kube-proxy 的工作原理,才能洞悉服務之間的通訊流程,再遇到網路不通時也不會一臉懵逼。

kube-proxy 有三種模式:userspaceiptablesIPVS,其中 userspace 模式不太常用。iptables 模式最主要的問題是在服務多的時候產生太多的 iptables 規則,非增量式更新會引入一定的時延,大規模情況下有明顯的效能問題。為解決 iptables 模式的效能問題,v1.11 新增了 IPVS 模式(v1.8 開始支援測試版,並在 v1.11 GA),採用增量式更新,並可以保證 service 更新期間連線保持不斷開。

目前網路上關於 kube-proxy 工作原理的文件幾乎都是以 iptables 模式為例,很少提及 IPVS,本文就來破例解讀 kube-proxy IPVS 模式的工作原理。為了理解地更加徹底,本文不會使用 Docker 和 Kubernetes,而是使用更加底層的工具來演示。

我們都知道,Kubernetes 會為每個 Pod 建立一個單獨的網路名稱空間 (Network Namespace) ,本文將會通過手動建立網路名稱空間並啟動 HTTP 服務來模擬 Kubernetes 中的 Pod。

本文的目標是通過模擬以下的 Service 來探究 kube-proxy 的 IPVSipset 的工作原理:

apiVersion: v1
kind: Service
metadata:
  name: app-service
spec:
  clusterIP: 10.100.100.100
  selector:
    component: app
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080

跟著我的步驟,最後你就可以通過命令 curl 10.100.100.100:8080 來訪問某個網路名稱空間的 HTTP 服務。為了更好地理解本文的內容,推薦提前閱讀以下的文章:

  1. How do Kubernetes and Docker create IP Addresses?!
  2. iptables: How Docker Publishes Ports
  3. iptables: How Kubernetes Services Direct Traffic to Pods

注意:本文所有步驟皆是在 Ubuntu 20.04 中測試的,其他 Linux 發行版請自行測試。

準備實驗環境

首先需要開啟 Linux 的路由轉發功能:

$ sysctl --write net.ipv4.ip_forward=1

接下來的命令主要做了這麼幾件事:

  • 建立一個虛擬網橋 bridge_home
  • 建立兩個網路名稱空間 netns_dustinnetns_leah
  • 為每個網路名稱空間配置 DNS
  • 建立兩個 veth pair 並連線到 bridge_home
  • netns_dustin 網路名稱空間中的 veth 裝置分配一個 IP 地址為 10.0.0.11
  • netns_leah 網路名稱空間中的 veth 裝置分配一個 IP 地址為 10.0.021
  • 為每個網路名稱空間設定預設路由
  • 新增 iptables 規則,允許流量進出 bridge_home 介面
  • 新增 iptables 規則,針對 10.0.0.0/24 網段進行流量偽裝
$ ip link add dev bridge_home type bridge
$ ip address add 10.0.0.1/24 dev bridge_home

$ ip netns add netns_dustin
$ mkdir -p /etc/netns/netns_dustin
echo "nameserver 114.114.114.114" | tee -a /etc/netns/netns_dustin/resolv.conf
$ ip netns exec netns_dustin ip link set dev lo up
$ ip link add dev veth_dustin type veth peer name veth_ns_dustin
$ ip link set dev veth_dustin master bridge_home
$ ip link set dev veth_dustin up
$ ip link set dev veth_ns_dustin netns netns_dustin
$ ip netns exec netns_dustin ip link set dev veth_ns_dustin up
$ ip netns exec netns_dustin ip address add 10.0.0.11/24 dev veth_ns_dustin

$ ip netns add netns_leah
$ mkdir -p /etc/netns/netns_leah
echo "nameserver 114.114.114.114" | tee -a /etc/netns/netns_leah/resolv.conf
$ ip netns exec netns_leah ip link set dev lo up
$ ip link add dev veth_leah type veth peer name veth_ns_leah
$ ip link set dev veth_leah master bridge_home
$ ip link set dev veth_leah up
$ ip link set dev veth_ns_leah netns netns_leah
$ ip netns exec netns_leah ip link set dev veth_ns_leah up
$ ip netns exec netns_leah ip address add 10.0.0.21/24 dev veth_ns_leah

$ ip link set bridge_home up
$ ip netns exec netns_dustin ip route add default via 10.0.0.1
$ ip netns exec netns_leah ip route add default via 10.0.0.1

$ iptables --table filter --append FORWARD --in-interface bridge_home --jump ACCEPT
$ iptables --table filter --append FORWARD --out-interface bridge_home --jump ACCEPT

$ iptables --table nat --append POSTROUTING --source 10.0.0.0/24 --jump MASQUERADE

在網路名稱空間 netns_dustin 中啟動 HTTP 服務:

$ ip netns exec netns_dustin python3 -m http.server 8080

開啟另一個終端視窗,在網路名稱空間 netns_leah 中啟動 HTTP 服務:

$ ip netns exec netns_leah python3 -m http.server 8080

測試各個網路名稱空間之間是否能正常通訊:

$ curl 10.0.0.11:8080
$ curl 10.0.0.21:8080
$ ip netns exec netns_dustin curl 10.0.0.21:8080
$ ip netns exec netns_leah curl 10.0.0.11:8080

整個實驗環境的網路拓撲結構如圖:

安裝必要工具

為了便於除錯 IPVS 和 ipset,需要安裝兩個 CLI 工具:

$ apt install ipset ipvsadm --yes

本文使用的 ipset 和 ipvsadm 版本分別為 7.5-1~exp11:1.31-1

通過 IPVS 來模擬 Service

下面我們使用 IPVS 建立一個虛擬服務 (Virtual Service) 來模擬 Kubernetes 中的 Service :

$ ipvsadm \
  --add-service \
  --tcp-service 10.100.100.100:8080 \
  --scheduler rr
  • 這裡使用引數 --tcp-service 來指定 TCP 協議,因為我們需要模擬的 Service 就是 TCP 協議。
  • IPVS 相比 iptables 的優勢之一就是可以輕鬆選擇排程演算法,這裡選擇使用輪詢排程演算法。

目前 kube-proxy 只允許為所有 Service 指定同一個排程演算法,未來將會支援為每一個 Service 選擇不同的排程演算法,詳情可參考文章 IPVS-Based In-Cluster Load Balancing Deep Dive

建立了虛擬服務之後,還得給它指定一個後端的 Real Server,也就是後端的真實服務,即網路名稱空間 netns_dustin 中的 HTTP 服務:

$ ipvsadm \
  --add-server \
  --tcp-service 10.100.100.100:8080 \
  --real-server 10.0.0.11:8080 \
  --masquerading

該命令會將訪問 10.100.100.100:8080 的 TCP 請求轉發到 10.0.0.11:8080。這裡的 --masquerading 引數和 iptables 中的 MASQUERADE 類似,如果不指定,IPVS 就會嘗試使用路由表來轉發流量,這樣肯定是無法正常工作的。

譯者注:由於 IPVS 未實現 POST_ROUTING Hook 點,所以它需要 iptables 配合完成 IP 偽裝等功能。

測試是否正常工作:

$ curl 10.100.100.100:8080

實驗成功,請求被成功轉發到了後端的 HTTP 服務!

在網路名稱空間中訪問虛擬服務

上面只是在 Host 的網路名稱空間中進行測試,現在我們進入網路名稱空間 netns_leah 中進行測試:

$ ip netns exec netns_leah curl 10.100.100.100:8080

哦豁,訪問失敗!

要想順利通過測試,只需將 10.100.100.100 這個 IP 分配給一個虛擬網路介面。至於為什麼要這麼做,目前我還不清楚,我猜測可能是因為網橋 bridge_home 不會呼叫 IPVS,而將虛擬服務的 IP 地址分配給一個網路介面則可以繞過這個問題。

譯者注

Netfilter 是一個基於使用者自定義的 Hook 實現多種網路操作的 Linux 核心框架。Netfilter 支援多種網路操作,比如包過濾、網路地址轉換、埠轉換等,以此實現包轉發或禁止包轉發至敏感網路。

針對 Linux 核心 2.6 及以上版本,Netfilter 框架實現了 5 個攔截和處理資料的系統呼叫介面,它允許核心模組註冊核心網路協議棧的回撥功能,這些功能呼叫的具體規則通常由 Netfilter 外掛定義,常用的外掛包括 iptables、IPVS 等,不同外掛實現的 Hook 點(攔截點)可能不同。另外,不同外掛註冊進核心時需要設定不同的優先順序,例如預設配置下,當某個 Hook 點同時存在 iptables 和 IPVS 規則時,iptables 會被優先處理。

Netfilter 提供了 5 個 Hook 點,系統核心協議棧在處理資料包時,每到達一個 Hook 點,都會呼叫核心模組中定義的處理函式。呼叫哪個處理函式取決於資料包的轉發方向,進站流量和出站流量觸發的 Hook 點是不一樣的。

核心協議棧中預定義的回撥函式有如下五個:

  1. NF_IP_PRE_ROUTING: 接收的資料包進入協議棧後立即觸發此回撥函式,該動作發生在對資料包進行路由判斷(將包發往哪裡)之前。
  2. NF_IP_LOCAL_IN: 接收的資料包經過路由判斷後,如果目標地址在本機上,則將觸發此回撥函式。
  3. NF_IP_FORWARD: 接收的資料包經過路由判斷後,如果目標地址在其他機器上,則將觸發此回撥函式。
  4. NF_IP_LOCAL_OUT: 本機產生的準備傳送的資料包,在進入協議棧後立即觸發此回撥函式。
  5. NF_IP_POST_ROUTING: 本機產生的準備傳送的資料包或者經由本機轉發的資料包,在經過路由判斷之後,將觸發此回撥函式。

iptables 實現了所有的 Hook 點,而 IPVS 只實現了 LOCAL_INLOCAL_OUTFORWARD 這三個 Hook 點。既然沒有實現 PRE_ROUTING,就不會在進入 LOCAL_IN 之前進行地址轉換,那麼資料包經過路由判斷後,會進入 LOCAL_IN Hook 點,IPVS 回撥函式如果發現目標 IP 地址不屬於該節點,就會將資料包丟棄。

如果將目標 IP 分配給了虛擬網路介面,核心在處理資料包時,會發現該目標 IP 地址屬於該節點,於是可以繼續處理資料包。

dummy 介面

當然,我們不需要將 IP 地址分配給任何已經被使用的網路介面,我們的目標是模擬 Kubernetes 的行為。Kubernetes 在這裡建立了一個 dummy 介面,它和 loopback 介面類似,但是你可以建立任意多的 dummy 介面。它提供路由資料包的功能,但實際上又不進行轉發。dummy 介面主要有兩個用途:

  • 用於主機內的程式通訊
  • 由於 dummy 介面總是 up(除非顯式將管理狀態設定為 down),在擁有多個物理介面的網路上,可以將 service 地址設定為 loopback 介面或 dummy 介面的地址,這樣 service 地址不會因為物理介面的狀態而受影響。

看來 dummy 介面完美符合實驗需求,那就建立一個 dummy 介面吧:

$ ip link add dev dustin-ipvs0 type dummy

將虛擬 IP 分配給 dummy 介面 dustin-ipvs0 :

$ ip addr add 10.100.100.100/32 dev dustin-ipvs0

到了這一步,仍然訪問不了 HTTP 服務,還需要另外一個黑科技:bridge-nf-call-iptables。在解釋 bridge-nf-call-iptables 之前,我們先來回顧下容器網路通訊的基礎知識。

基於網橋的容器網路

Kubernetes 叢集網路有很多種實現,有很大一部分都用到了 Linux 網橋:

  • 每個 Pod 的網路卡都是 veth 裝置,veth pair 的另一端連上宿主機上的網橋。
  • 由於網橋是虛擬的二層裝置,同節點的 Pod 之間通訊直接走二層轉發,跨節點通訊才會經過宿主機 eth0。

Service 同節點通訊問題

不管是 iptables 還是 ipvs 轉發模式,Kubernetes 中訪問 Service 都會進行 DNAT,將原本訪問 ClusterIP:Port 的資料包 DNAT 成 Service 的某個 Endpoint (PodIP:Port),然後核心將連線資訊插入 conntrack 表以記錄連線,目的端回包的時候核心從 conntrack 表匹配連線並反向 NAT,這樣原路返回形成一個完整的連線鏈路:

但是 Linux 網橋是一個虛擬的二層轉發裝置,而 iptables conntrack 是在三層上,所以如果直接訪問同一網橋內的地址,就會直接走二層轉發,不經過 conntrack:

  1. Pod 訪問 Service,目的 IP 是 Cluster IP,不是網橋內的地址,走三層轉發,會被 DNAT 成 PodIP:Port。

  2. 如果 DNAT 後是轉發到了同節點上的 Pod,目的 Pod 回包時發現目的 IP 在同一網橋上,就直接走二層轉發了,沒有呼叫 conntrack,導致回包時沒有原路返回 (見下圖)。

    由於沒有原路返回,客戶端與服務端的通訊就不在一個 “頻道” 上,不認為處在同一個連線,也就無法正常通訊。

開啟 bridge-nf-call-iptables

啟用 bridge-nf-call-iptables 這個核心引數 (置為 1),表示 bridge 裝置在二層轉發時也去呼叫 iptables 配置的三層規則 (包含 conntrack),所以開啟這個引數就能夠解決上述 Service 同節點通訊問題。

所以這裡需要啟用 bridge-nf-call-iptables :

$ modprobe br_netfilter
$ sysctl --write net.bridge.bridge-nf-call-iptables=1

現在再來測試一下連通性:

$ ip netns exec netns_leah curl 10.100.100.100:8080

終於成功了!

開啟 Hairpin(髮夾彎)模式

雖然我們可以從網路名稱空間 netns_leah 中通過虛擬服務成功訪問另一個網路名稱空間 netns_dustin 中的 HTTP 服務,但還沒有測試過從 HTTP 服務所在的網路名稱空間 netns_dustin 中直接通過虛擬服務訪問自己,話不多說,直接測一把:

$ ip netns exec netns_dustin curl 10.100.100.100:8080

啊哈?竟然失敗了,這又是哪裡的問題呢?不要慌,開啟 hairpin 模式就好了。那麼什麼是 hairpin 模式呢? 這是一個網路虛擬化技術中常提到的概念,也即交換機埠的VEPA模式。這種技術藉助物理交換機解決了虛擬機器間流量轉發問題。很顯然,這種情況下,源和目標都在一個方向,所以就是從哪裡進從哪裡出的模式。

怎麼配置呢?非常簡單,只需一條命令:

$ brctl hairpin bridge_home veth_dustin on

再次進行測試:

$ ip netns exec netns_dustin curl 10.100.100.100:8080

還是失敗了。。。

然後我花了一個下午的時間,終於搞清楚了啟用混雜模式後為什麼還是不能解決這個問題,因為混雜模式和下面的選項要一起啟用才能對 IPVS 生效:

$ sysctl --write net.ipv4.vs.conntrack=1

最後再測試一次:

$ ip netns exec netns_dustin curl 10.100.100.100:8080

這次終於成功了,但我還是不太明白為什麼啟用 conntrack 能解決這個問題,有知道的大神歡迎留言告訴我!

譯者注:IPVS 及其負載均衡演算法只針對首個資料包,後繼的包必須被 conntrack 表優先反轉,如果沒有 conntrack,IPVS 對於回來的包是沒有任何辦法的。可以通過 conntrack -L 檢視。

開啟混雜模式

如果想讓所有的網路名稱空間都能通過虛擬服務訪問自己,就需要在連線到網橋的所有 veth 介面上開啟 hairpin 模式,這也太麻煩了吧。有一個辦法可以不用配置每個 veth 介面,那就是開啟網橋的混雜模式。

什麼是混雜模式呢?普通模式下網路卡只接收發給本機的包(包括廣播包)傳遞給上層程式,其它的包一律丟棄。混雜模式就是接收所有經過網路卡的資料包,包括不是發給本機的包,即不驗證MAC地址。

如果一個網橋開啟了混雜模式,就等同於將所有連線到網橋上的埠(本文指的是 veth 介面)都啟用了 hairpin 模式。可以通過以下命令來啟用 bridge_home 的混雜模式:

$ ip link set bridge_home promisc on

現在即使你把 veth 介面的 hairpin 模式關閉:

$ brctl hairpin bridge_home veth_dustin off

仍然可以通過連通性測試:

$ ip netns exec netns_dustin curl 10.100.100.100:8080

優化 MASQUERADE

在文章開頭準備實驗環境的章節,執行了這麼一條命令:

$ iptables \
  --table nat \
  --append POSTROUTING \
  --source 10.0.0.0/24 \
  --jump MASQUERADE

這條 iptables 規則會對所有來自 10.0.0.0/24 的流量進行偽裝。然而 Kubernetes 並不是這麼做的,它為了提高效能,只對來自某些具體的 IP 的流量進行偽裝。

為了更加完美地模擬 Kubernetes,我們繼續改造規則,先把之前的規則刪除:

$ iptables \
  --table nat \
  --delete POSTROUTING \
  --source 10.0.0.0/24 \
  --jump MASQUERADE

然後新增針對具體 IP 的規則:

$ iptables \
  --table nat \
  --append POSTROUTING \
  --source 10.0.0.11/32 \
  --jump MASQUERADE

果然,上面的所有測試都能通過。先別急著高興,又有新問題了,現在只有兩個網路名稱空間,如果有很多個怎麼辦,每個網路名稱空間都建立這樣一條 iptables 規則?我用 IPVS 是為了啥?就是為了防止有大量的 iptables 規則拖垮效能啊,現在豈不是又繞回去了。

不慌,繼續從 Kubernetes 身上學習,使用 ipset 來解決這個問題。先把之前的 iptables 規則刪除:

$ iptables \
  --table nat \
  --delete POSTROUTING \
  --source 10.0.0.11/32 \
  --jump MASQUERADE

然後使用 ipset 建立一個集合 (set) :

$ ipset create DUSTIN-LOOP-BACK hash:ip,port,ip

這條命令建立了一個名為 DUSTIN-LOOP-BACK 的集合,它是一個 hashmap,裡面儲存了目標 IP、目標埠和源 IP。

接著向集合中新增條目:

$ ipset add DUSTIN-LOOP-BACK 10.0.0.11,tcp:8080,10.0.0.11

現在不管有多少網路名稱空間,都只需要新增一條 iptables 規則:

$ iptables \
  --table nat \
  --append POSTROUTING \
  --match set \
  --match-set DUSTIN-LOOP-BACK dst,dst,src \
  --jump MASQUERADE

網路連通性測試也沒有問題:

$ curl 10.100.100.100:8080
$ ip netns exec netns_leah curl 10.100.100.100:8080
$ ip netns exec netns_dustin curl 10.100.100.100:8080

新增虛擬服務的後端

最後,我們把網路名稱空間 netns_leah 中的 HTTP 服務也新增到虛擬服務的後端:

$ ipvsadm \
  --add-server \
  --tcp-service 10.100.100.100:8080 \
  --real-server 10.0.0.21:8080 \
  --masquerading

再向 ipset 的集合 DUSTIN-LOOP-BACK 中新增一個條目:

$ ipset add DUSTIN-LOOP-BACK 10.0.0.21,tcp:8080,10.0.0.21

終極測試來了,試著多執行幾次以下的測試命令:

$ curl 10.100.100.100:8080

你會發現輪詢演算法起作用了:

總結

相信通過本文的實驗和講解,大家應該理解了 kube-proxy IPVS 模式的工作原理。在實驗過程中,我們還用到了 ipset,它有助於解決在大規模叢集中出現的 kube-proxy 效能問題。如果你對這篇文章有任何疑問,歡迎和我進行交流。

參考文章

相關文章