技術文章 » 深度解析KubeEdge EdgeMesh 高可用架構

深度解析KubeEdge EdgeMesh 高可用架構

2022-11-22 18:01:57
摘要：通過高可用特性應用場景、高可用特性使用手冊、課題總結、未來展望等四個部分的內容來向大家介紹新版本EdgeMesh的高可用架構。

本文分享自華為雲社群《KubeEdge EdgeMesh 高可用架構詳解|KubeEdge雲原生邊緣計算社群》，作者：南開大學｜達益鑫。

EdgeMesh專案解決了邊緣計算場景下複雜網路的通訊問題，中心化的edgemesh-server作為一箇中繼元件，協助其他節點進行網路穿透和流量中轉。之前的edgemesh-server本身不具備高可用特性，會遇到效能瓶頸與單點故障問題，目前EdgeMesh v1.12版本的高可用架構不僅優化了上述問題，也帶來了更加穩定的系統執行時，還覆蓋了多種邊緣網路的痛點場景，如分散式動態中繼連線場景和私有區域網的網路自治場景等。此外，EdgeMesh 在v1.12中還帶來了基於PSK密碼的安全連線、對接HTTPS的邊緣Kube API Endpoint等特性和能力，整體提升了EdgeMesh的效能、穩定性與安全性。

作為開源之夏課題【EdgeMesh：高可用架構的設計與實現 】的實踐者，這是我第一次接觸開源社群相關的專案，非常有幸能深入地參與到KubeEdge開源專案的開發之中，也非常開心能夠參與EdgeMesh高可用特性的方案設計與程式碼開發。我將通過高可用特性應用場景、高可用特性使用手冊、課題總結、未來展望等四個部分的內容來向大家介紹新版本EdgeMesh的高可用架構以及我個人在KubeEdge社群的成長經歷。

高可用架構的主要目的是為了保障系統的穩定性以及提升系統的整體效能，此次EdgeMesh的高可用特性在原有功能的基礎上還覆蓋了多種邊緣網路的痛點場景。以下為EdgeMesh高可用特性在邊緣計算場景下的具體應用場景，使用者可以依據這些用例來理解本特效能提供的服務。

▍1.1 單點故障以及高負載場景

如圖所示，當單個節點承擔中繼功能時，所有其他的節點都需要連線該節點才能夠獲取網路連線的服務。在這樣的場景當中，單個節點的負載就會相應地增加，過高的通訊負載或者是密集的連線數量，在諸多情況下是限制服務效能的主要原因，同時如果該節點出現故障則會導致中繼連線斷開，使得中繼連線功能暫時性停滯。 為了能夠優化這部分的問題，覆蓋高負載存取場景，EdgeMesh 新版本考量使用分散式網路連線的思想，通過給予每一個節點能夠提供中繼功能的結構，使每一個節點都具有為其他節點提供中繼的能力。針對這部分場景需求，使用者可以在叢集初始化時指定多個特定的節點作為預設的中繼節點，依據自身情況調節叢集內負載的分配，EdgeMesh將會在提供中繼服務的時候，優先嚐試連線這些節點；如果不做設定，EdgeMesh也會尋找合適的節點執行中繼功能，分散減輕單個節點的中繼存取負擔。

▍1.2 分散式動態中繼連線場景

如圖所示，位於上海的邊緣應用A和B通過中繼互相通訊，需要把流量轉發到處於北京資料中心裡的relay節點，資料傳輸在遠距離的兩地之間繞了一圈，導致服務時延較長，使用者體驗較差。非常遺憾的是，邊緣計算場景下叢集規模經常橫跨多地或者是多區域部署，如果中繼節點距離請求服務的節點非常遙遠，就會造成極大的延遲，影響使用者的體驗。這個情況尤其是在中繼連線物件與自己不在相鄰地理位置下的時候，體現得尤為明顯。

為了能夠優化這部分的體驗，覆蓋遠距離服務場景，EdgeMesh新版本考量就近中繼的原則，使用者可以根據叢集節點的地理位置分佈情況，支援選擇一個地理位置適中的relay節點。當應用需要中繼連線服務的時候，edgemesh-agent就會動態優先選擇就近的relay節點作為中繼來提供網路連線服務，以此縮短中繼服務的時延。

▍1.3 私有區域網網路自治場景

如圖所示，在老版本的EdgeMesh的程式碼實現中，edgemesh-agent必須保持與雲上中繼服務edgemesh-server的連線，當區域網內的節點離線後，導致edgemesh-agent斷開與中繼節點的連線，斷連節點上的服務就徹底失去流量代理的能力了，這在部分私有區域網網路內或者是網路情況波動較大的環境當中會給使用者造成較大的困擾。

為了能夠優化這部分的問題，提高網路應用連線的穩定性，EdgeMesh 新版本考量了分散式管理及網路自治的想法，讓EdgeMesh能夠通過mDNS機制保障私有區域網網路內或者是離線區域網內節點之間的相互發現和轉發流量，維持應用服務的正常運轉。針對這部分場景需求，使用者並不需要再單獨設定任何的引數來啟用此功能，該功能一般面對兩種情形進行服務維持：a. 在剛部署EdgeMesh的時候，部分節點就已經在私有區域網下，那這個區域網內的節點依舊可以通過EdgeMesh來相互之間存取和轉發流量。

b. 在叢集正常運轉過程當中，部分節點離線後，這部分節點依舊可以通過EdgeMesh來維持相互之間的網路連線和流量轉發。

▍2.1 基本原理介紹

在EdgeMesh v1.12版本中，社群將edgemesh-server的能力合併到了edgemesh-agent的EdgeTunnel模組當中，使得具備中繼能力的edgemesh-agent能夠自動成為中繼伺服器，為其他節點提供內網穿透和中繼轉發的功能，新老系統架構對比如下：

EdgeMesh高可用特性的主要實現原理是：當叢集內有節點具備中繼能力時，其上的edgemesh-agent會承擔起中繼節點的角色，來為其他節點提供內網穿透和流量中繼轉發的服務。在叢集初始化或者是有節點新加入叢集時，EdgeMesh系統會基於mDNS機制發現區域網內的節點並作記錄，同時DHT機制會發現跨區域網的其他節點並對其發起連線建立請求，這樣當叢集內跨區域網的兩節點需要連線的時候，中繼節點就可以為它們提供流量中繼和協助內網穿透的服務。

EdgeMesh高可用特性的核心功能如上圖所示，叢集當中A節點與B節點通過R1中繼節點連線來提供服務，當R1節點無法提供中繼服務的時候，A、B節點可以通過高可用特性自動切換到中繼節點R2並重新建立連線。在這個過程當中使用者幾乎感受不到網路連線的變化。接下來我將簡單介紹不同情況下使用EdgeMesh高可用特性的方式。

▍2.2 部署時啟用高可用特性

您可以通過以下設定方法，在安裝EdgeMesh時啟用高可用特性，設定過程當中您可以依據叢集連線的需求設定中繼節點的地址：

# 啟用高可用特性
helm install edgemesh --namespace kubeedge \
--set agent.relayNodes[0].nodeName=k8s-master,agent.relayNodes[0].advertiseAddress="{1.1.1.1}" \
https://raw.githubusercontent.com/kubeedge/edgemesh/main/build/helm/edgemesh.tgz
  • relayNodes 引數是中繼節點表，型別為 []relayNode，您可以通過設定它來指定叢集中應該承擔中繼節點角色的edgemesh-agent。
  • relayNode.nodeName 引數使用節點名的方式來指定relay節點，這必須與K8s的節點名相同，您可以通過 kubectl get nodes 檢視您的k8s節點名。
  • relayNode.advertiseAddress 引數用於指定relay節點的地址，其應當與節點在K8s叢集當中的節點地址一致, 如果您購買了公有云的公網IP並掛載到此relay節點上，則 relayNode.advertiseAddress 引數最好應該填寫該公網IP地址。

需要注意的是：設定中繼節點的數量由 relayNodes[num] 中索引值 num 來規定，num 取值從 0 開始，relayNodes[0] 表示中繼節點1。

更多的安裝設定資訊請詳見：

  • helm安裝：

https://edgemesh.netlify.app/zh/guide/#helm-安裝

  • 手動安裝：

https://edgemesh.netlify.app/zh/guide/

▍2.3 執行時新增新中繼節點

如果您在使用EdgeMesh高可用特性時，想要在叢集當中新增新的中繼節點，可以通過修改 edgemesh-agent-cfg 當中的 relayNodes 引數來達到目的，以下為具體修改設定的方式：

kubectl -n kubeedge edit configmap edgemesh-agent-cfg
# 進入config 檔案當中進行編輯
apiVersion: v1
data:
 edgemesh-agent.yaml: |-
   modules:
 edgeProxy:
       enable: true
 edgeTunnel:
       enable: true
       # 設定新增或者是修改為新的中繼節點
 relayNodes:
       - nodeName: R1
 advertiseAddress:
         - 1.1.1.1
       - nodeName: R2   <------  在此設定新增節點
 advertiseAddress:
         - 192.168.5.103

之後您可以使用 kubeadm join 或者 keadm join 新增加新的中繼節點R2，接著通過以下操作檢視新增的中繼節點是否正常執行：

# 檢視節點是否正常新增
kubectl get nodes
NAME         STATUS   ROLES                  AGE    VERSION
k8s-master   Ready    control-plane,master   249d   v1.21.8
k8s-node1    Ready    <none>                 249d   v1.21.8
ke-edge1     Ready    agent,edge             234d   v1.19.3-kubeedge-v1.8.2
ke-edge2     Ready    agent,edge             5d     v1.19.3-kubeedge-v1.8.2
R2           Ready    agent,edge             1d     v1.19.3-kubeedge-v1.8.2 <------ 新節點
# 檢視中繼節點的 edgemesh-agent 是否正常執行
kubectl get all -n kubeedge -o wide
NAME                       READY   STATUS    RESTARTS   AGE   IP              NODE         NOMINATED NODE   READINESS GATES
pod/edgemesh-agent-59fzk   1/1     Running   0          10h   192.168.5.187   ke-edge1     <none>           <none>
pod/edgemesh-agent-hfsmz   1/1     Running   1          10h   192.168.0.229   k8s-master   <none>           <none>
pod/edgemesh-agent-tvhks   1/1     Running   0          10h   192.168.0.71    k8s-node1    <none>           <none>
pod/edgemesh-agent-tzntc   1/1     Running   0          10h   192.168.5.121   ke-edge2     <none>           <none>
pod/edgemesh-agent-kasju   1/1     Running   0          10h   192.168.5.103   R2           <none>           <none> <------ new edgemesh-agent running on R2

▍2.4 執行時轉化節點成中繼

如果您在叢集執行過程當中，想要將一些已有節點轉化為中繼節點，只需要修改 edgemesh-agent-cfg 當中的 relayNodes 引數即可, 以下為具體修改設定的方式：修改完此設定後，需要重啟R2節點（轉化節點）上的edgemesh-agent。在這個過程當中，假設新設定的節點有中繼能力，那麼在重新Tunnel模組執行時會執行以下邏輯：

  • edgemesh-agent會讀取configmap裡的中繼節點表relayNodes，檢查自己是否被使用者設定為中繼節點。如果在relayNodes中讀取到R2存在，則表明R2被設定為預設初始的中繼節點。
  • R2節點上的edgemesh-agent會嘗試成為relay ，啟動對應的中繼功能。
  • 如果發現該節點沒有中繼能力（一般掛載了公網IP的節點會具備中繼能力），那麼該節點還是不能承擔起中繼節點的角色，造成這個結果的原因可能是該節點的advertiseAddress並不能讓所有節點存取。

以上就是EdgeMesh高可用架構的原理以及應用場景的介紹了，此次課題結項完成了開源之夏的所有產出要求，也同時作為KubeEdge v1.12新版本的一個重要特性發布，非常高興能夠為開源社群及KubeEdge的開發和完善做出貢獻。於我個人而言，當初是在測試5G邊緣架構時認識到了KubeEdge, 併為其設計以及功能設想所折服，這與我理想的邊緣網路智慧架構有諸多的相似之處，也成為我參與開源之夏的契機。在專案開發當中，從功能設計、實現方案到程式碼編寫，各類問題層出不窮，主要是校內知識和研發方式與開源社群及工業環境脫節導致的問題，不過這些困難都在老師社群的幫助和自身努力之下逐一解決了，也是在這個過程當中領我體會到了開源工作中各社群之間相互借鑑推進，各個開發者之間相互幫助交流的強大，也更加理解到優秀的社群環境以及高效的社群例會機制能夠快速同步各處開發進度，修正不合理的開發方向和想法，集思廣益的同時步步為營，這樣讓我更加嚮往社群的工作了。

就EdgeMesh發展設想而言，此次開發已經實現了當初設想的目的，但在參與社群例會，瞭解整個開源專案的發展之中，許多的想法和創新也隨之湧現，是否能夠引入ebpf、Webassembly等新興技術來優化甚至是革新EdgeMesh提供的網路服務；是否可以將人工智慧引入到邊緣叢集的管理和自治當中，讓人工智慧作為基礎建設的一部分，這些設想都讓人熱血沸騰，忍不住想要參與到社群的開發和研究當中。就我個人而言，未來也會更多地參與到社群的開發和研究當中，一方面我原本所期盼的將科研成果轉化為產業價值的目標，已通過開源之夏初見眉目；另一方面，諸多的設想和創新還未能夠與大家交流，還未能夠得到實踐和測試；這些都不斷鼓勵著我更加深入到社群專案的研發當中。最後非常感謝王傑章老師的悉心教導，可以說老師的耐心溝通和鼓勵指導是專案能夠成功推進的重要動力；同時還要感謝開源之夏能夠給予我們機會參與到實際的開發當中，走出了高校學術的樓閣，儘管此次開源之夏已經結束，但我們的開源之旅卻正要開始。

附：KubeEdge社群貢獻和技術交流地址

網站: https://kubeedge.io

Github地址: https://github.com/kubeedge/kubeedge

Slack地址: https://kubeedge.slack.com

郵寄清單: https://groups.google.com/forum/#!forum/kubeedge

每週社群例會: https://zoom.us/j/4167237304Twitter: https://

twitter.com/KubeEdge

檔案地址: https://docs.kubeedge.io/en/latest/

 

點選關注，第一時間瞭解華為雲新鮮技術~