TKE 容器網絡中的 ARP Overflow 問題探究及其解決之道

作者朱瑜堅,騰訊雲後台開發工程師,熟悉 CNI 容器網絡相關技術,負責騰訊雲 TKE 的容器網絡的構建和相關網絡組件的開發維護工作,作為主力開發實現了 TKE 下一代容器網絡方案。

1. 問題背景

1.1 問題描述

最近,某內部客戶的 TKE VPC-CNI 模式的獨立網卡集群上出現了 pod 間訪問不通的情況,問題 pod ping 不通任何其他 pod 和節點。

查看 dmesg 內核日誌,有如下報錯信息:neighbour: arp_cache: neighbor table overflow!(下圖為後續復現的日誌截圖)

並且,這個集群規模較大,約有 1000 個節點,30000 個 pod,基本可以懷疑是由於集群規模較大,導致 ARP 表項過多,從而引起 ARP Overflow 的問題。

1.2 名詞解釋

名詞 說明
TKE 全稱 Tencent Kubernetes Engine, 騰訊雲容器服務,是基於原生 kubernetes 提供以容器為核心的、高度可擴展的高性能容器管理服務
VPC-CNI 模式 是容器服務 TKE 基於 CNI 和 VPC 彈性網卡實現的容器網絡能力
Pod Pod 是 kubernetes 的基本資源管理單位,擁有獨立的網絡命名空間,1個 Pod 可包含多個容器

2. 問題初步分析

從如上報錯信息可知,這個問題的基本原因在於 ARP 緩存表打滿了。這裡涉及到內核的 ARP 緩存垃圾回收機制。當 ARP 表項太多且又沒有可回收的表項的時候,新表項就會無法插入。

這就導致網絡包發送時無法找到對應的硬件地址(MAC)。使得網絡包不能發送。

那麼具體什麼情況會導致新表項無法插入呢?回答這個問題,我們需要先深入了解一下 ARP 緩存老化及垃圾回收機制。

3. ARP 緩存老化回收機制

3.1 ARP 緩存表項狀態機

如上圖,是整個 ARP 表項的生命周期及其狀態機。

我們知道,對於 TCP/IP 網絡包發送時,網絡棧需要對端的 MAC 地址才能讓網絡包轉換成二層的數據結構——幀,從而在網絡中傳輸。而對於不同廣播域的 IP 地址,其對端 MAC 地址為網關,發送端會將網絡包發給網關讓其轉發,而對於同廣播域中的 IP 地址,其對端 MAC 地址即與 IP 地址對應。

而通過 IP 地址找到 MAC 地址就是 ARP 協議的主要工作內容。ARP 協議的工作過程此處不再贅述,而通過 ARP 協議找到 IP 地址對應的 MAC 地址後,會將該對應關係存儲在本機上一段時間,以減少 ARP 協議的通信頻率,加快網絡包的發送。該對應關係,即 ARP 緩存表項,其狀態機或整個生命周期可描述如下:

  1. 初始時,對於任何網絡包發送時,內核協議棧需要找到目的 IP 地址對應的對端 MAC 地址,如果這時 ARP 緩存中沒有命中,則會新插入一條狀態為 Incomplete 的表項。Incomplete 狀態會嘗試發送 ARP 包,請求某 IP 地址對應的 MAC 地址。
  2. 若收到 ARP 回應的,表項狀態就變為 Reachable。
  3. 若嘗試了一定次數後沒收到響應,表項即變為 Failed。
  4. Reachable 表項在到達超時時間後,會變成 Stale 狀態,Stale 狀態的表項已不可再使用。
  5. Stale 的表項若有被引用來發包,則表項會變為 Delay 狀態。
  6. Delay 狀態的表項也不可使用來發包,但在 Delay 狀態到期前,收到 ARP 的本機確認,則重新轉為 Reachable 狀態。
  7. Delay 狀態到期,表項變為 Probe 狀態,該狀態與 Incomplete 狀態類似。
  8. Stale 狀態到期後,會被啟動的垃圾回收起回收刪除。

通過以下命令可查看當前網絡命名空間(network namespace) 中 arp 表項及其狀態:

ip neigh

如:

本機確認:這是代指本機收到了一個源 mac 地址匹配的網絡包,這個網絡包表示此次網絡通信的「上一跳」即是該 mac 地址的機器,能收到這個網絡包即說明該 mac 地址可達。因此即可把該表項轉為 Reachable 狀態。通過這一機制,內核可減少 ARP 的通信需求。

3.2 涉及到的內核參數

以下列出了該機制中主要涉及的內核參數:

參數 含義 默認值
/proc/sys/net/ipv4/neigh/default/base_reachable_time Reachable 狀態基礎過期時間,每個表項過期時間是在[1/2base_reachable_time,3/2base_reachable_time]之間 30秒
/proc/sys/net/ipv4/neigh/default/base_reachable_time_ms Reachable 狀態基礎過期時間,毫秒表示 30秒
/proc/sys/net/ipv4/neigh/default/gc_stale_time Stale 狀態過期時間 60秒
/proc/sys/net/ipv4/neigh/default/delay_first_probe_time delay 狀態過期到 Probe 的時間 5秒
/proc/sys/net/ipv4/neigh/default/gc_interval gc 啟動的周期時間 30秒
/proc/sys/net/ipv4/neigh/default/gc_thresh1 少於這個值,gc 不會啟動 2048
/proc/sys/net/ipv4/neigh/default/gc_thresh2 ARP表的最多紀錄的軟限制,允許超過該數字5秒 4096
/proc/sys/net/ipv4/neigh/default/gc_thresh3 ARP表的最多紀錄的硬限制,大於該數目,gc立即啟動,並強制回收 8192

其中,gc 相關的內核參數是對所有網卡(interface)生效的。但是各種到期時間的設置是僅對單獨網卡(interface)生效的,default 值僅對新增接口設備生效。

3.3 ARP 緩存垃圾回收機制

由其緩存表項的狀態機我們知道,不是所有的表項都會被回收,只有 Stale 狀態過期後,Failed 的表項可能會被回收。另外,ARP 緩存表項的垃圾回收是觸髮式的,需要回收的表項不一定立刻會被回收,ARP 緩存表項的垃圾回收有四種啟動邏輯:

  1. arp 表項數量 < gc_thresh1,不啟動。
  2. gc_thresh1 =< arp 表項數量 <= gc_thresh2,按照 gc_interval 定期啟動
  3. gc_thresh2 < arp 表項數量 <= gc_thresh3,5秒後啟動
  4. arp 表項數量 > gc_thresh3,立即啟動

對於不可回收的表項,垃圾回收即便啟動了也不會對其進行回收。因此當不可回收的表項數量大於 gc_thresh3 的時候,垃圾回收也無能為力了。

4. 進一步探究

4.1 垃圾回收閾值是按命名空間級別生效還是子機級別生效

我們知道,每個獨立的網絡命名空間是有完整的網絡協議棧的。那麼,ARP 緩存的垃圾回收也是每個命名空間單獨處理的嗎?

從涉及的內核參數可以看出,gc 相關的內核參數是對所有接口設備生效的,因此,這裡可以推測垃圾回收的閾值也是子機級別生效的,而不是按網絡命名空間。

這裡做了一個簡單的實驗來驗證:

  1. 在節點 default ns 上的 gc_thresh1, gc_thresh2 和 gc_thresh3 設置成60 。
  2. 在節點上創建了 19 個獨立網卡模式的 Pod
  3. 任意選擇一個 pod ping 其他的 pod,以此產生 arp 緩存
  4. 用 shell 腳本掃描節點上的所有 pod,計算 arp 表項的和,可以得到:

可以發現, 各命名空間的累計 arp 表項的數目在每次達到 60 之後就會快速下降,也就是達到 60 之後就產生了垃圾回收。重複幾次都是類似的結果,因此,這說明了垃圾回收在計算 ARP 表項是否觸發閾值時,是計算各命名空間的累計值,也就是按子機級別生效,而非命名空間級別。

4.2 不可回收的 ARP 表項達到 gc_thresh3 時,會發生什麼

由前面的介紹我們知道,垃圾回收機制並非回收任意 ARP 緩存,因此,當所有可達狀態的 ARP 表項打滿 ARP 緩存表時,也即達到 gc_thresh3 時,會發生什麼行為?可以推測,此時舊的無法回收,新的 ARP 表項也無法插入,新的網絡包會無法發送,也即發生了本次文章所描述的問題。

為了驗證這一點,繼續在以上環境中實驗:

  1. 將任意兩個 Pod 的基礎老化時間 base_reachable_time 調長到 1800秒,以此產生不可回收的 ARP 表項。
  2. 設置 gc_thresh3 為 40,以此更容易觸發問題
  3. 選擇調整了老化時間的 pod ping 其他的 pod,以此產生 arp 緩存。
  4. 可以發現,當到達閾值的時候,ping 會產生丟包或不通:

查看內核日誌 dmesg -T,可以看到文章開頭描述的信息:neighbour: arp_cache: neighbor table overflow!

以上實驗說明了,不可回收的 ARP 表項打滿 ARP 表會讓新的表項無法插入,從而網絡不通。

4.3 為什麼相比 TKE 的全局路由模式和單網卡多 IP 模式,獨立網卡模式更容易產生這個問題

要回答這個問題,我們先簡單看一下 TKE 各網絡模式的原理介紹

全局路由模式

該網絡模式下,每個節點上的容器 IP 是預先分配到節點上的,這些 IP 同屬一個子網,且每個節點就是一個小子網。我們知道,ARP 協議是為二層通信服務的,因此,該網絡方案中,每個 Pod 的網絡命名空間內的 ARP 表最大可能保存了節點上所有其他 Pod 的 ARP 表項,最後節點的 ARP 表項的數量最大即為 節點子網 IP 數的平方,如節點的子網大小是128,則其 ARP 表項最大可能為 127 的平方,約 16000。

共享網卡模式

該網絡模式下,每個節點會綁定輔助彈性網卡,節點上的 Pod 共享使用該輔助網卡,每個 Pod 內不會做網絡包的路由,只會有一條 ARP 表項,實際的路由控制在節點的 default 命名空間內完成。因此,該網絡模式下,ARP 緩存表幾乎是共享的,又因為網卡只能屬於 1 個子網,因此每個節點的 Pod ARP 緩存表只能存儲一個子網的 IP-MAC 映射關係,至多數量為各網卡所在子網內 IP 的數量和,如子網是 /22,即含有約 1000 個 ip, 那麼 arp 表項也大概有 1000,由於節點網卡配額一般不超過 10,因此該節點的最大 ARP 表項一般不超過 10000。

下一代網絡方案——獨立網卡模式

獨立網卡模式是 TKE 團隊推出的下一代「零損耗」容器網絡方案,其基本原理如下圖所示:

即母機虛擬出的彈性網卡,直接置於容器中,使容器獲得與 CVM 子機一樣的網絡通信能力和網絡管理能力,大大提升了容器網絡的數據面能力,真正做到「零損耗」。

目前,獨立網卡網絡方案已在 TKE 產品中開放白名單測試,歡迎內外部客戶體驗試用。

以上網絡方案中,每個 Pod 都會獨佔一個網卡,也會擁有獨立的命名空間和獨立的 ARP 緩存表。而每個網卡都可以屬於不同的子網。因此,在獨立網卡模式里,ARP 緩存表項數量至多為同可用區的子網 IP 數量之和。這一數量量級是可以很輕易上萬的,很容易就突破了默認的 ARP 緩存設置。也就觸發了這個問題。

5. 解決方案

從以上的分析可以看出,這個問題,調大垃圾回收的閾值,可以比較好的解決問題。因此,臨時的解決方案,就是調大 ARP 緩存表的垃圾回收閾值:

echo 8192 > /proc/sys/net/ipv4/neigh/default/gc_thresh1echo 16384 > /proc/sys/net/ipv4/neigh/default/gc_thresh2echo 32768 > /proc/sys/net/ipv4/neigh/default/gc_thresh3

6. 總結

ARP 緩存打滿之後,Pod 就會網絡不通。初看起來很簡單,但是其背後的 ARP 緩存老化和垃圾回收機制也是比較複雜的。查詢了很多資料,但是都對「垃圾回收閾值是對各命名空間的 ARP 表項累積值生效還是單獨生效」,「垃圾回收會回收哪些表項」,「表項打滿後的具體行為如何」等問題說不清、道不明。因此,筆者嘗試通過幾個小實驗驗證了具體的行為模式。相比直接閱讀晦澀的內核源碼,實驗法也許也是一個研究問題和理解機制的捷徑了。希望能夠幫助到各位讀者。

【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊,掃碼關注同名公眾號,及時獲取更多乾貨!!