TKE容器網絡中的ARP Overflow問題探究及其解決方法是什么

這篇文章將為大家詳細講解有關TKE容器網絡中的ARP Overflow問題探究及其解決方法是什么，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

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 名詞解釋

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 涉及到的內核參數

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

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

3.3 ARP 緩存垃圾回收機制

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

1. arp 表項數量 < gc_thresh2，不啟動。

2. gc_thresh2 =< arp 表項數量 <= gc_thresh3，按照 gc_interval 定期啟動

3. gc_thresh3 < arp 表項數量 <= gc_thresh4，5秒后啟動

4. arp 表項數量 > gc_thresh4，立即啟動

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

4. 進一步探究

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

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

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

這里做了一個簡單的實驗來驗證：

1. 在節點 default ns 上的 gc_thresh2, gc_thresh3 和 gc_thresh4 設置成60 。

2. 在節點上創建了 19 個獨立網卡模式的 Pod

3. 任意選擇一個 pod ping 其他的 pod，以此產生 arp 緩存

4. 用 shell 腳本掃描節點上的所有 pod，計算 arp 表項的和，可以得到：

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

4.2 不可回收的 ARP 表項達到 gc_thresh4 時，會發生什么

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

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

1. 將任意兩個 Pod 的基礎老化時間 base_reachable_time 調長到 1800秒，以此產生不可回收的 ARP 表項。

2. 設置 gc_thresh4 為 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_thresh2echo 16384 > /proc/sys/net/ipv4/neigh/default/gc_thresh3echo 32768 > /proc/sys/net/ipv4/neigh/default/gc_thresh4

6. 總結

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

關于TKE容器網絡中的ARP Overflow問題探究及其解決方法是什么就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。