在上一篇監控問題排查的文章中，筆者分析了 KubeSphere 3.1.0 整合 KubeEdge 中的邊緣監控原理和問題排查思路，在介紹 EdgeWatcher 元件時提到了“邊緣節點的內網 IP 需要叢集內唯一”這樣的限制條件。本文就來深入分析一下這個問題，並嘗試給各位邊緣開發者提供一些解決的建議和思路。

正常場景

在邊緣節點加入雲端叢集時，需要指定 “Node Name” 和 “Internal IP”，顧名思義，就是邊緣節點的節點名稱和內網 IP 地址。這裡的內網 IP 地址就是本文的主題，該地址需要在叢集內唯一。

KubeSphere 在 EdgeWatcher 中提供了使用者指定的內網 IP是否被佔用的驗證功能。驗證失敗(IP 已被佔用)的情況下，則不會為該邊緣節點提供加入叢集的命令列輸出。下面兩張圖展示了驗證成功和失敗的場景。

驗證成功：

驗證失敗：

可以說，KubeSphere 在這一點上已經做的非常用心了，給使用者提供了 UI 的 “Validate” 按鈕和後臺 API，不管是直接使用還是基於 KubeSphere 的二次開發都會非常便捷。

非法場景

在上一節中展示了內網 IP 被佔用的結果就是不能加入叢集，因為該 IP 已經被註冊在了 EdgeWatcher 中，不能再被其他邊緣節點使用。

那麼如果一個 IP 還沒有被註冊到 EdgeWatcher 中，也就是邊緣節點沒有被真正接入叢集時，還是可以跳過這一步驗證，將相同內網 IP 的兩個邊緣節點加入同一個叢集中，製造這個非法的使用場景。

這個非法場景帶來的問題就是：相同 IP 的“較早加入叢集”的邊緣節點在 logs exec 和 metrics 的功能上都會失效。即下圖的運維功能都是沒有資料的。

之前，筆者也在 KubeSphere 的開發者社群提過這個問題，同時也和負責邊緣模組的社群開發者有過交流，確認了在 KubeSphere 的產品設計上，內網 IP 需要管理員或者使用者自行按需進行規劃，保證不重複。

潛在問題

私有部署的場景下，做到 IP 的統一規劃是比較容易的。那麼如果基於 KubeSphere 的邊緣解決方案在公有云場景中會怎麼樣呢？

公有云使用者不受規劃限制，同時併發量比較大，出現“相同 IP 加入叢集”這個問題的概率會非常大。最終會導致部分使用者的 logs exec 和 metrics 功能失效，大量問題工單隨之而來，使用者黏度下降。所以公有云場景下，這個問題是必須要解決的，下面我們就詳細分析一下問題的根本原因和解決思路。

根本原因

解決問題前，要把問題產生的根本原因摸清楚，這樣才能有的放矢地去解決和處理問題。

在上一篇文章中，其實也簡要介紹了 metrics 資料獲取在 KubeEdge 邊緣場景下的實現原理：kube-apiserver 上的 iptables 轉發給雲端的 Cloudcore，Cloudcore 通過和 Edgecore 之間的 WebSocket 通道向邊緣端進行訊息和資料傳遞。

logs 和 exec 功能的實現原理與 metrics 是一樣的。下面這張圖簡要的描述了這幾項功能在 KubeEdge 下的工作流程。

結合上面這張圖的 cloudcore (KubeEdge 雲端元件)的紅色部分，來解釋一下為什麼內網 IP 需要叢集內唯一。

邊緣節點(edgecore，即 KubeEdge 邊緣元件)在連線到雲端叢集時，和雲端之間會建立一個 websocket 通道。雲端為了後續通過該 websocket 通道和邊緣節點通訊，需要將這個通道作為 session 儲存在雲端。表現在資料結構上就是一個“內網 IP”為 key，session (websocket 通道)為 value 的 map。

看到這裡，各位開發者應該就很容易理解了，如果內網 IP 相同，則會覆蓋較早加入叢集的邊緣節點的 session 記錄。這時雲端去查詢“被覆蓋了 session 的邊緣節點”上 POD 的監控和運維資料，肯定是找不到的。

問題的根本原因找到了，解決的思路也就比較明確了，下一小節筆者簡單闡述下這個問題的解決思路。

下圖是在 KubeEdge 的邊緣場景下，logs 功能的時序圖，感興趣的開發者可以進一步瞭解。

解決思路

上一節梳理清楚了根本原因，解決思路也就比較清晰明瞭。本著非侵入式的改造原則，儘量少改動 KubeSphere 和 KubeEdge，對上層業務邏輯進行增強和擴充套件是筆者心目中的最佳選擇。

既然根本原因是 IP 衝突導致 session 被覆蓋，那就很自然的想到提供叢集內不重複 IP 的分配服務，也就是常說的 IPAM。在雲端的業務邏輯層引入 IPAM 服務，為使用者邊緣節點提供叢集內唯一的 IP 分配能力。

同時還需要關注一點的是，IPAM 服務分配出來的唯一 IP 屬於內部實現，不能當作 “Internal IP” 展示給使用者。使用者看到的邊緣節點內網 IP 地址仍然是使用者自行規劃和填寫的 IP，只不過改造後的內網 IP 不再作為 session 的 key，也不再需要進行衝突查驗，只在頁面上展示方便使用者搜尋，提高產品的易用性。

下面就是該思路下的節點加入流程圖，供各位開發者參考。

根據上面的流程圖，筆者也大概羅列一下上述解決方案，需要修改的點：

1. 新建叢集內 IPAM 服務，提供分配，回收 IP 等功能，注意併發處理。
2. 新建業務層節點服務，提供節點名稱，展示用 IP，唯一 IP 等持久化能力。
3. 修改 keadm 和 edgecore，支援 node IP 可選
4. 修改 cloudcore，在節點註冊時通過節點名稱查詢唯一 IP，作為 Internal IP 註冊節點。
5. 在業務層北向介面隱藏唯一 IP(K8s 上的 internal IP)，替換成使用者輸入的展示 IP。

後記

通過對現象和原理的分析，我們提出了在公有云環境下基於 KubeSphere 的邊緣節點 IP 衝突問題的解決方案。限於筆者的技術能力，有可能還存在著更為簡單有效的解決辦法，歡迎各位開發者提出寶貴意見，讓我們一起把基於 KubeSphere 的邊緣解決方案做大做強。

本文由部落格一文多發平臺 OpenWrite 釋出！