作者 | 張傑（冰羽）
來源|
阿裡巴巴雲原生公衆号簡介
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 有任何疑問，歡迎使用釘釘搜尋群号（31993519）加入釘釘交流群。