KubeSphere v3.1.0 通過集成 KubeEdge，將節點和資源的管理延伸到了邊緣，也是 KubeSphere 正式支持邊緣計算的第一個版本。
筆者也第一時間搭建和試用了邊緣節點相關的功能，但是在邊緣節點納管之後遇到了一些監控的小問題，在排查過程中也順帶了解了一下 KubeSphere 對於邊緣節點的監控原理，發出來和大家分享，方便其他的開發者能夠更快的排查問題或進行二次開發。
環境版本和構成
通過 KubeKey 安裝，參數如下，其餘組件版本默認未改動。 Kubernetes : v1.19.8 KubeSphere : v3.1.0
| 主機名稱 | 角色 |
|---|---|
| k8s-worker-03 | worker |
| k8s-worker-02 | master |
| k8s-worker-01 | master,etcd |
問題現象
通過生成的 keadm 命令行將邊緣節點加入集羣，並在邊緣節點上部署 POD，該 POD 的監控信息不能顯示。
監控原理
定位和解決問題之前，肯定是要先搞懂工作原理。
1. KubeEdge
KubeEdge 的 Edgecore 組件對 Kubelet 進行了輕量化改造，Edgecore 和 Cloudcore(雲端)也不在同一個 Cluster 網絡中，通過 k8s 默認的方式進行 metrics 獲取肯定是行不通的(logs 和 exec 原理相同)。
當前 KubeEdge 的實現方法是 kube-apiserver 上的 iptables 轉發給雲端的 Cloudcore，Cloudcore 通過和 Edgecore 之間的 WebSocket 通道向邊緣端進行消息和數據傳遞。
KubeEdge 官方的使用手冊和文檔：https://kubeedge.io/en/docs/advanced/metrics/
爲了便於大家理解，作者畫了一張圖，整體的流程請參考如下：
2. Metrics-server
原生的 K8S 中就是通過 Metrics-server 這個官方組件進行節點和 POD 的 CPU/Memory 等數據的監控。
簡而言之，Metrics-server 通過 Pull 的方式去每個節點上拉取監控數據，放在自身的內存中，提供 K8S 的 API 供 kubectl top 這樣的 client 來查詢。
Metrics-server 的詳細設計，可以參考 github 的官方說明：https://github.com/kubernetes-sigs/metrics-server
Metrcis-server 的啓動參數中，有一個參數要特別說明一下："kubelet-use-node-status-port"。
在 KubeEdge 的官方文檔中，也提到了啓動 Metrics-server 時要指定該參數，至於原因文檔中並未提及，這裏簡單說明一下。這個參數的意思是：“調用 kubelet 服務時，用該 Node 上報的 port，而不是默認的 port”。我們知道 kubelet 的 metrcis 接口默認是監聽在 10250 端口的，而 KubeEdge 的 edgecore 將 metrics 接口默認監聽在 10350 端口，如果不加這個參數，metrice-server 就會通過類似"edgenodeIP:10250/stat/summary"這樣的請求去獲取監控數據，結果肯定獲取失敗的。
我們通過 KubeSphere 環境的 yaml 文件，也能清晰地看到這一點配置：
3. KubeSphere
上面講到了，Metrics-server 已經從 KubeEdge 那裏獲取到了邊緣節點的監控數據，那麼 KubeSphere 只要從 Metrics-server 提供的 K8S API 中即可獲取到邊緣節點的實時監控數據用來在前端進行展示。
稍微翻了一下 KubeSphere 的代碼，和我們的預想是一致的，KubeSphere 通過 metrics-server 拿到了當前版本展示的監控數據。
4. EdgeWatcher
從上述第 1 點 KubeEdge 的工作原理來看，是需要在 kube-apiserver 所在的節點上進行 iptables 轉發規則設置的(將所有 10350 的請求都轉發給 Cloudcore 的 10003 端口進行處理)。
那麼每一個邊緣節點加入集羣的時候不可能由運維人員手動進行 iptables 的規則設置，所以 KubeSphere 就自研了 EdgeWatcher 這樣一個組件。這個組件的目的應該是有以下幾點：
- 提供 kubeedge group API(添加邊緣節點時前端調用該 group API)
- 邊緣節點加入集羣時，設置 IPtables 規則(logs exec metrics 都需要)
- 驗證邊緣節點指定的 IP 是否可用，IP 需要全局唯一
EdgeWatcher 暫未開源，作者從社區轉載了下面這張 EdgeWatcher 的工作原理圖，供大家參考：
關於邊緣節點 IP 需要全局唯一的問題，作者還是有很多想說的，後續有時間再開一篇，和大家一起探討。
5. 總體概覽
其實通過對上述監控組件的瞭解，我們也基本能勾勒出 KubeSphere v3.1 在基於 KubeEdge 的邊緣集成中，所作的努力和工作。下面是作者簡單畫的一張整體組件架構的圖，供大家參考：
問題定位
既然原理都搞清楚了，下面就簡單說一下定位的過程和思路。
1. Metrics-server
首先我們判斷 metrics-server 有沒有正常提供服務，能不能獲取到邊緣數據。
從下面的命令結果可以看出，邊緣節點(k8s-agent)的監控數據和非邊緣節點的 POD 的監控數據都是沒有問題的。
只有邊緣節點上的 POD 的監控數據獲取不到。
2. KubeEdge
再來看 KubeEdge 提供的 10350 端口的 metrics 服務，有沒有問題。
我們可以看到，KubeEdge 的 edgecore 提供的 10350 端口的服務也是沒有問題的，可以從中獲取到邊緣節點和邊緣 POD(nginx-xxx)的監控數據。
3. 總結
從上面的分析可以得出以下結論：
- Metrcis-server 沒問題
- KubeEdge 的 edgecore 在邊緣節點的服務沒問題
- cloudcore 和 edgecore 之間的通路沒有問題(通過查看 edgecore 的日誌，可以看到 stat/summary 的調用，但是 POD 的監控數據調用則沒有)
最後再去確認其他可以獲取邊緣 POD 節點的信息，發現只有 docker 版本的差別，出問題的是 v18.09.1，而正常的節點版本如下：
至此，基本能斷定是 docker 版本過低造成的，至於是哪個接口和 metrics-server 不能兼容，就不花太多時間去調查分析，有經驗的開發者可以留言共享一下。
結論
基於這個問題，我們對 Docker 版本進行了測試，最終確認在 Kubesphere v3.1、 metrics-server 版本(v0.4.2)、 KubeEdge v1.6.1 的場景下，Docker 版本要大於等於 v19.3.0 才能支持邊緣 POD 的監控。KubeEdge 官方最新版本 v1.7.1 已經發布，從 v1.6.2 的 Changelog 來看，該問題已經被修復了。造成該 pod metrics 丟失的原因，應該是 edgecore 使用的 K8s 版本過低導致的。詳情可參考官方 KubeEdge v1.6.2的 Changelog。
後記
雖然問題不是很大，但是通過這個小問題能把邊緣監控的脈絡搞清楚，是比問題本身更有意義的。
通過這樣的分析和總結，問題定位和二次開發的效率纔會更高，希望我們社區的開發者一起把 KubeSphere 做得更好更完善。
本文由博客一文多發平臺 OpenWrite 發佈！