久久国产精品一区二区三区四区,久色婷婷小香蕉久久,国产日韩欧美在线播放不卡,另类av一区二区

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

01Underlay網絡解決方案

為什么需要 Underlay 網絡解決方案？在數據中心私有云中，有許多需要 Underlay 網絡的應用場景：

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

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

【資料圖】

02Underlay 網絡中的僵尸 IP 問題

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

在實際的生產中，難免會遇到集群中出現僵尸 IP，如：

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

在使用 Underlay 網絡的 Kubernetes 集群中，當出現僵尸 IP 時，可能會帶來如下的一些問題：

Underlay 網絡下 IP 資源有限：在大規模集群中，Pod 的數量可能非常龐大，IPAM 會為每個 Pod 實例分配指定的 Underlay 子網 IP 以進行網絡通信，如果出現僵尸 IP 問題，可能會導致大量的 IP 資源浪費，或將面臨無 Underlay IP 資源可用的局面。固定 IP 需求，導致新 Pod 啟動失敗：將一個擁有 10 個 IP 地址的 IP 池，固定給 10 個副本的應用使用，如出現上述的僵尸 IP 問題，舊的 Pod IP 無法被回收，新 Pod 將因為缺少 IP 資源，且無法獲取到可用的 IP，從而無法啟動。這將對應用的穩定性和可靠性造成威脅，甚至可能導致整個應用程序都無法正常運行。03解決方案：Spiderpool

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

Spiderpool 通過如下的 IP 回收機制，以解決 Underlay 網絡中出現的故障 IP 問題：

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

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

1. 創建 1000 個 Pod，同時限制可用的 IPv4/IPv6 地址數量均為 1000 個，確保可用的 IP 地址數量與 Pod 數量為 1:1。

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

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

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

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

測試數據如下：

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

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

05總結

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

關鍵詞：