OpenYurt v0.3.0 重磅發佈：全面提高邊緣場景下應用部署效率

做者 | 張傑（冰羽）
來源|阿里巴巴雲原生公衆號

簡介

OpenYurt 是由阿里雲開源的基於原生 Kubernetes 構建的、業內首個對於 Kubernetes 非侵入式的邊緣計算項目，目標是擴展 Kubernetes 以無縫支持邊緣計算場景。它提供了完整的 Kubernetes API 兼容性；支持全部 Kubernetes 工做負載、服務、運營商、CNI 插件和 CSI 插件；提供良好的節點自治能力，即便邊緣節點與雲端斷網，在邊緣節點中運行的應用程序也不會受影響。OpenYurt 能夠輕鬆部署在任何 Kubernetes 集羣服務中，讓強大的雲原生能力擴展到邊緣。

OpenYurt v0.3.0 重磅發佈

北京時間 2020 年 11 月 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 官網