OpenYurt v0.3.0 重磅发布:全面提升边缘场景下应用部署效率
作者 | 張杰(冰羽)
來源|阿里巴巴云原生公眾號
簡介
OpenYurt 是由阿里云開源的基于原生 Kubernetes 構建的、業內首個對于 Kubernetes 非侵入式的邊緣計算項目,目標是擴展 Kubernetes 以無縫支持邊緣計算場景。它提供了完整的 Kubernetes API 兼容性;支持所有 Kubernetes 工作負載、服務、運營商、CNI 插件和 CSI 插件;提供良好的節點自治能力,即使邊緣節點與云端斷網,在邊緣節點中運行的應用程序也不會受影響。OpenYurt 可以輕松部署在任何 Kubernetes 集群服務中,讓強大的云原生能力擴展到邊緣。
OpenYurt v0.3.0 重磅發布
北京時間 2021 年 1 月 8 號,Openyurt 發布 v0.3.0 版本,首次提出節點池和單元化部署概念,新增云端 Yurt-App-Manager 組件,全面提升在邊緣場景下的應用部署效率,降低邊緣節點和應用運維的復雜度。全面優化 yurthub、yurt-tunnel 核心組件的性能,yurtctl 提供 kubeadm 的 provider,可以快速方便地將由 kubeadm 創建的 Kubernetes 集群轉換成 Openyurt 集群。
1. Yurt-App-Manger 為邊緣應用運維而生
經過與社區同學的廣泛討論,OpenYurt 提供 OpenYurt Yurt-App-Manager 組件。Yurt-App-Manager 是 Kubernetes 的一個標準擴展,它可以配合 Kubernetes 使用,提供 NodePool 和 UnitedDeployment 兩種控制器,從主機維度和應用維度來提供邊緣場景下節點和應用的運維能力。
1)節點池:NodePool
在邊緣場景下,邊緣節點通常具備很強的區域性、地域性、或者其他邏輯上的分組特性(比如相同 CPU 架構、同一個運營商、云提供商),不同分組的節點間往往存在網絡不互通、資源不共享、資源異構、應用獨立等明顯的隔離屬性,這也是 NodePool 的由來。
NodePool 顧名思義,我們可以稱之為節點池、節點組或者節點單元。而對具備共同屬性的 woker node 進行管理,傳統的做法是用 Label 的方式來對主機進行分類管理,但是隨著節點和 Label 數量的增加,對節點主機分類運維(例如:批量設置調度策略、taints 等)效率和靈活性會越來越差,如下圖所示:
NodePool 以節點組的維度對節點劃分做了更高維度的抽象,可以從節點池視角對不同邊緣區域下的主機進行統一管理和運維,如下圖所示:
2)單元化部署:UnitedDeployment
在邊緣場景下,相同的應用可能需要部署在不同地域下的計算節點上,以 Deployment 為例,傳統的做法是先將相同地域的計算節點設置相同的 Label,然后創建多個 Deployment,每個 Deployment 通過 nodeSelectors 選定不同的 Label,依次來達到相同的應用部署到不同地域的需求。但是這些代表相同應用的多個 Deployment,除了 name、nodeselectors、replicas 這些特性外,其他的差異化配置非常小。如下圖所示:
但是隨著地域分布越來越多,以及不同地域對應用的差異化需求,使得運維變得越來越復雜,具體表現在以下幾個方面:
- 鏡像版本升級,需要將每個 Deployment 逐一修改。
- 需要自定義 Deployment 的命名規范,以此來表明相同的應用。
- 隨著邊緣場景越來越復雜,需求增多,每個節點池的 Deployment 會有一些差異化的配置,不好管理。
單元化部署(UnitedDeployment)通過更上層次的抽象,對這些子的 Deployment 進行統一管理: 自動創建/更新/刪除。如下圖所示:
UnitedDeployment 控制器可以提供一個模板來定義應用,并通過管理多個 workload 來匹配下面不同的區域。每個 UnitedDeployment 下每個區域的 workload 被稱為 pool, 目前 pool 支持使用兩種 workload:StatefulSet 和 Deployment。控制器會根據 UnitedDeployment 中 pool 的配置創建子的 workload 資源對象,每個資源對象都有一個期望的 replicas Pod 數量。通過一個 UnitedDeployment 實例就可以自動維護多個 Deployment 或者 Statefulset 資源,同時還能具備 replicas 等的差異化配置。如若獲取更直觀的操作體驗,請查看 Yurt-App-Manager 使用教程和開發者教程。
更多關于 Yurt-App-Manager 的討論請參考社區 issue 和 pull request:
- issue 124: UnitedDeployment usages
- issue 171: [feature request] the definition of NodePool and UnitedDeployment
- pull request 173: [proposal] add nodepool and uniteddployment crd proposal
2. 節點自治組件 yurt-hub
yurt-hub 是運行在 Kubernetes 集群中每個節點上運行的守護程序,它的作用是作為(Kubelet、Kubeproxy、CNI 插件等)的出站流量的代理。它在邊緣節點的本地存儲中緩存 Kubernetes 節點守護進程可能訪問的所有資源的狀態。如果邊緣節點離線,則這些守護程序可以幫助節點在重新啟動后恢復狀態,達到邊緣自治的能力。在 v0.3.0 版本中,社區對 yurt-hub 做了大量的功能性增強,主要包括:
-
yurt-hub 鏈接云端 kube-apiserver 時,自動向 kube-apiserver 申請證書,并支持證書過期自動輪轉。
-
在 watch 云端資源時,增加超時機制。
-
當本地緩存數據不存在時候,優化 response。
3. 云邊運維通道組件 yurt-tunnel
yurt-tunnel 包括云端的 TunnelServer 和每個邊緣節點上運行的 TunnelAgent 組成。TunnelServer 通過反向代理與在每個邊緣節點中運行的 TunnelAgent 守護進程建立連接,并以此在公共云的控制平面與處于企業內網環境的邊緣節點之間建立安全的網絡訪問。在 v0.3.0 版本中,社區對 yurt-tunnel 組件,在可靠性、穩定性、集成測試方面都做了大量的增強。
4. OpenYurt 運維組件 yurtctl
在 v0.3.0 版本中,yurtctl 支持 kubeadm provider,可以快速方便地將由 kubeadm 創建的原生 Kubernetes 集群轉換成能夠適應邊緣弱網環境的 Kubernetes 集群, 極大提升 OpenYurt 的使用體驗。
更多實踐操作請關注: 《OpenYurt 入門 - 在樹莓派上玩轉 OpenYurt》
未來計劃
OpenYurt V0.3.0 版本發布,進一步提升了原生 Kubernetes 在邊緣場景的擴展能力,同時在針對邊緣場景下的應用部署的問題發布了 Yurt-App-Manger 組件,后續 OpenYurt 社區會在設備管理、邊緣運維調度、社區治理和貢獻者體驗方面持續投入,再次感謝 Intel/Vmware 的同學參與,同時也非常歡迎有興趣的同學加入參與共建,共同打造一個穩定,可靠的完全云原生的邊緣計算平臺。
更多社區詳情請關注:https://github.com/alibaba/openyurt。
相關鏈接
-
OpenYurt Release v0.3.0
-
OpenYurt v0.3.0 CHANGELOG
-
OpenYurt 使用教程
-
OpenYurt 官網
如果您對于 OpenYurt 有任何疑問,歡迎使用釘釘搜索群號(31993519)加入釘釘交流群。
總結
以上是生活随笔為你收集整理的OpenYurt v0.3.0 重磅发布:全面提升边缘场景下应用部署效率的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 林昊获中国计算机学会杰出工程师奖,阿里中
- 下一篇: 解读容器的 2020:寻找云原生的下一站