作者朱瑜堅，騰訊云后臺開發工程師，熟悉 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 名詞解釋

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_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 表項累積值生效還是單獨生效”，“垃圾回識訓回收哪些表項”，“表項打滿后的具體行為如何”等問題說不清、道不明，因此，筆者嘗試通過幾個小實驗驗證了具體的行為模式，相比直接閱讀晦澀的內核原始碼，實驗法也許也是一個研究問題和理解機制的捷徑了，希望能夠幫助到各位讀者，

【騰訊云原生】云說新品、云研新術、云游新活、云賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！

標籤：其他

上一篇：【分析】自動化測驗解決方案

下一篇：QingStor 物件存盤攜手愛數 AnyBackup 護航海量資料安全