在 Underlay 網(wǎng)絡中，如何回收僵尸 IP？云原生網(wǎng)絡開源項目--Spiderpool 提供了相應的解決方案，讓我們一探究竟。

01Underlay網(wǎng)絡解決方案

為什么需要 Underlay 網(wǎng)絡解決方案？在數(shù)據(jù)中心私有云中，有許多需要 Underlay 網(wǎng)絡的應用場景：

• 低延遲和高吞吐量：在一些需要低延遲和高吞吐量的應用場景中，Underlay 網(wǎng)絡方案通常比 Overlay 網(wǎng)絡方案更具優(yōu)勢。由于 Underlay 網(wǎng)絡是基于物理網(wǎng)絡構建的，因此可以提供更快速和穩(wěn)定的網(wǎng)絡傳輸服務。
• 傳統(tǒng)主機應用上云：在數(shù)據(jù)中心內(nèi)，許多傳統(tǒng)主機應用仍然使用傳統(tǒng)的網(wǎng)絡對接方式，例如服務暴露和發(fā)現(xiàn)、多子網(wǎng)對接等。在這種情況下，使用 Underlay 網(wǎng)絡解決方案可以更好地滿足這些應用的需求。
• 數(shù)據(jù)中心網(wǎng)絡管理：數(shù)據(jù)中心管理人員通常需要對應用實施安全管控，例如使用防火墻、Vlan 隔離等手段。此外，他們還需要使用傳統(tǒng)的網(wǎng)絡觀測手段實施集群網(wǎng)絡監(jiān)控。使用 Underlay 網(wǎng)絡解決方案可以更方便地實現(xiàn)這些需求。
• 獨立的宿主機網(wǎng)卡規(guī)劃：在一些特殊的應用場景下，例如 Kubevirt、存儲項目、日志項目等，需要實施獨立的宿主機網(wǎng)卡規(guī)劃，以保證底層子網(wǎng)的帶寬隔離。使用Underlay 網(wǎng)絡解決方案可以更好地支持這些應用的需求，從而提高應用的性能和可靠性。

隨著數(shù)據(jù)中心私有云的不斷普及，Underlay 網(wǎng)絡作為數(shù)據(jù)中心網(wǎng)絡架構的重要組成部分，已經(jīng)被廣泛應用于數(shù)據(jù)中心的網(wǎng)絡架構中，以提供更高效的網(wǎng)絡傳輸和更好的網(wǎng)絡拓撲管理能力。

02Underlay 網(wǎng)絡中的僵尸 IP 問題

什么是僵尸 IP ？在 IPAM 中記錄了分配給 Pod 使用的 IP 地址，但是這些 Pod 在 Kubernetes 集群中已經(jīng)不復存在，這些 IP 可稱為 僵尸 IP 。

在實際的生產(chǎn)中，難免會遇到集群中出現(xiàn)僵尸 IP ，如：

• 在集群中 delete Pod 時，但由于網(wǎng)絡異?；?cni 二進制 crash 等問題，導致調(diào)用 cni delete 失敗，從而導致 IP 地址無法被 cni 回收。
• 節(jié)點意外宕機后，集群中的 Pod 永久處于 `deleting` 狀態(tài)，Pod 占用的 IP 地址無法被釋放。

在使用 Underlay 網(wǎng)絡的 Kubernetes 集群中，當出現(xiàn)僵尸 IP 時，可能會帶來如下的一些問題：

• Underlay 網(wǎng)絡下 IP 資源有限：在大規(guī)模集群中，Pod 的數(shù)量可能非常龐大，IPAM 會為每個 Pod 實例分配指定的 Underlay 子網(wǎng) IP 以進行網(wǎng)絡通信，如果出現(xiàn)僵尸 IP 問題，可能會導致大量的 IP 資源浪費，或?qū)⒚媾R無 Underlay IP 資源可用的局面。
• 固定 IP 需求，導致新 Pod 啟動失?。簩⒁粋€擁有 10 個 IP 地址的 IP 池，固定給 10 個副本的應用使用，如出現(xiàn)上述的僵尸 IP 問題，舊的 Pod IP 無法被回收，新 Pod 將因為缺少 IP 資源，且無法獲取到可用的 IP，從而無法啟動。這將對應用的穩(wěn)定性和可靠性造成威脅，甚至可能導致整個應用程序都無法正常運行。

03解決方案：Spiderpool

Spiderpool(https://github.com/spidernet-io/spiderpool) 是一個 Kubernetes 的 Underlay 網(wǎng)絡解決方案，通過提供輕量級的 meta 插件和 IPAM 插件，Spiderpool 靈活地整合與強化了開源社區(qū)中現(xiàn)有的 CNI 項目，最大程度的簡化 Underlay 網(wǎng)絡下 IPAM 的運維工作，使得多 CNI 協(xié)同工作真正的可落地，支持運行在裸金屬、虛擬機、公有云等環(huán)境下。

Spiderpool 通過如下的 IP 回收機制，以解決 Underlay 網(wǎng)絡中出現(xiàn)的故障 IP 問題：

• 對處于 Terminating 狀態(tài)的 Pod，Spiderpool 將在 Pod 的 spec.terminationGracePeriodSecond 后，自動釋放其 IP 地址。該功能可通過環(huán)境變量 SPIDERPOOL_GC_TERMINATING_POD_IP_ENABLED 來控制。該能力能夠用以解決節(jié)點意外宕機的故障場景。
• 在 cni delete 失敗等故障場景，如果一個曾經(jīng)分配了 IP 的 Pod 被銷毀后，但在 IPAM 中還記錄分配著 IP 地址，形成了僵尸 IP 的現(xiàn)象。Spiderpool 針對這種問題，會基于周期和事件掃描機制，自動回收這些僵尸 IP 地址。

04等比例 IP分配測試

IPAM 要求能夠精準地分配 IP 地址，同時 Spiderpool 還具備了健壯的故障 IP 回收能力，筆者做了如下的等比例 IP 分配測試，來進行驗證。本次等比例 IP 分配測試，基于 0.3.1 版本的 CNI Specification，以 Macvlan 搭配 Spiderpool（版本 v0.6.0）作為測試方案，并選擇了開源社區(qū)中的 Whereabouts（版本 v0.6.2）搭配 Macvlan 、Kube-ovn（版本 v1.11.8）Calico-ipam（版本 v3.26.1）幾種網(wǎng)絡解決方案為對比，測試場景如下：

1. 創(chuàng)建 1000 個 Pod，同時限制可用的 IPv4/IPv6 地址數(shù)量均為 1000 個，確?？捎玫?IP 地址數(shù)量與 Pod 數(shù)量為 1:1。

2. 使用如下命令一次性地重建這 1000 個 Pod，記錄被重建的 1000 個 Pod 全部 Running 的耗時。驗證在固定 IP 地址時，并發(fā)重建的 Pod 在涉及 IP 地址的回收、搶占與沖突的場景下，各 IPAM 插件能否快速的調(diào)節(jié)好有限的 IP 地址資源，保證應用恢復的速度。

~# kubectl get pod | grep "prefix" | awk '{print $1}' | xargs kubectl delete pod

3. 將所有節(jié)點下電后再上電，模擬故障恢復，記錄 1000 個 Pod 再次達到 Running 的耗時。

4. 刪除所有的 Deployment，記錄所有 Pod 完全消失的耗時。

測試數(shù)據(jù)如下：

Spiderpool 與 Kube-ovn 的 IPAM 分配原理，是整個集群節(jié)點的所有 Pod 都從同一個 CIDR 中分配 IP，所以 IP 分配和釋放需要面臨激烈的競爭，IP 分配性能的挑戰(zhàn)會更大；Whereabouts 和 Calico 的 IPAM 分配原理，是每個節(jié)點都有一個小的 IP 集合，所以 IP 分配的競爭比較小，IP 分配性能的挑戰(zhàn)會小。但從實驗數(shù)據(jù)上看，雖然 Spdierpool 的 IPAM 原理是 "吃虧" 的，但是分配 IP 的性能卻是很好的。

在測試 Macvlan + Whereabouts 這個組合期間，創(chuàng)建的場景中 922 個 Pod 在 14m25s 內(nèi)以較為均勻的速率達到 Running 狀態(tài)，自此之后的 Pod 增長速率大幅降低，最終 1000 個 Pod 花了 21m49s 達到 Running 狀態(tài)。至于重建的場景，在 55 個 Pod 達到 Running 狀態(tài)后，Whereabouts 無法繼續(xù)分配 IP 給 Pod。由于測試場景中 IP 地址數(shù)量與 Pod 數(shù)量為 1:1，如果 IPAM 組件未能正確的回收 IP，新 Pod 將因為缺少 IP 資源，且無法獲取到可用的 IP，從而無法啟動。

05總結

從上面的測試可以發(fā)現(xiàn)，Spiderpool 在各種測試場景下表現(xiàn)優(yōu)秀。雖然 Spiderpool 是一種適用于 Underlay 網(wǎng)絡下的 IPAM 解決方案，但是其 IP 分配以及回收的能力，相較于主流 Overlay CNI （如 Calico）也毫不遜色，盡管 Spiderpool 面臨著更多的、復雜的 IP 地址搶占與沖突的問題。