作者 | 張杰（冰羽）
來源|阿里巴巴云原生公眾號

簡介

OpenYurt 是由阿里云開源的基于原生 Kubernetes 構建的、業(yè)內(nèi)首個對于 Kubernetes 非侵入式的邊緣計算項目，目標是擴展 Kubernetes 以無縫支持邊緣計算場景。它提供了完整的 Kubernetes API 兼容性；支持所有 Kubernetes 工作負載、服務、運營商、CNI 插件和 CSI 插件；提供良好的節(jié)點自治能力，即使邊緣節(jié)點與云端斷網(wǎng)，在邊緣節(jié)點中運行的應用程序也不會受影響。OpenYurt 可以輕松部署在任何 Kubernetes 集群服務中，讓強大的云原生能力擴展到邊緣。

OpenYurt v0.3.0 重磅發(fā)布

北京時間 2021 年 1 月 8 號，Openyurt 發(fā)布 v0.3.0 版本，首次提出節(jié)點池和單元化部署概念，新增云端 Yurt-App-Manager 組件，全面提升在邊緣場景下的應用部署效率，降低邊緣節(jié)點和應用運維的復雜度。全面優(yōu)化 yurthub、yurt-tunnel 核心組件的性能，yurtctl 提供 kubeadm 的 provider，可以快速方便地將由 kubeadm 創(chuàng)建的 Kubernetes 集群轉(zhuǎn)換成 Openyurt 集群。

1. Yurt-App-Manger 為邊緣應用運維而生

經(jīng)過與社區(qū)同學的廣泛討論，OpenYurt 提供 OpenYurt Yurt-App-Manager 組件。Yurt-App-Manager 是 Kubernetes 的一個標準擴展，它可以配合 Kubernetes 使用，提供 NodePool 和 UnitedDeployment 兩種控制器，從主機維度和應用維度來提供邊緣場景下節(jié)點和應用的運維能力。

1）節(jié)點池：NodePool

在邊緣場景下，邊緣節(jié)點通常具備很強的區(qū)域性、地域性、或者其他邏輯上的分組特性（比如相同 CPU 架構、同一個運營商、云提供商），不同分組的節(jié)點間往往存在網(wǎng)絡不互通、資源不共享、資源異構、應用獨立等明顯的隔離屬性，這也是 NodePool 的由來。

NodePool 顧名思義，我們可以稱之為節(jié)點池、節(jié)點組或者節(jié)點單元。而對具備共同屬性的 woker node 進行管理，傳統(tǒng)的做法是用 Label 的方式來對主機進行分類管理，但是隨著節(jié)點和 Label 數(shù)量的增加，對節(jié)點主機分類運維（例如：批量設置調(diào)度策略、taints 等）效率和靈活性會越來越差，如下圖所示：

NodePool 以節(jié)點組的維度對節(jié)點劃分做了更高維度的抽象，可以從節(jié)點池視角對不同邊緣區(qū)域下的主機進行統(tǒng)一管理和運維，如下圖所示：

2）單元化部署：UnitedDeployment

在邊緣場景下，相同的應用可能需要部署在不同地域下的計算節(jié)點上，以 Deployment 為例，傳統(tǒng)的做法是先將相同地域的計算節(jié)點設置相同的 Label，然后創(chuàng)建多個 Deployment，每個 Deployment 通過 nodeSelectors 選定不同的 Label，依次來達到相同的應用部署到不同地域的需求。但是這些代表相同應用的多個 Deployment，除了 name、nodeselectors、replicas 這些特性外，其他的差異化配置非常小。如下圖所示：

但是隨著地域分布越來越多，以及不同地域?qū)玫牟町惢枨?#xff0c;使得運維變得越來越復雜，具體表現(xiàn)在以下幾個方面：

• 鏡像版本升級，需要將每個 Deployment 逐一修改。
• 需要自定義 Deployment 的命名規(guī)范，以此來表明相同的應用。
• 隨著邊緣場景越來越復雜，需求增多，每個節(jié)點池的 Deployment 會有一些差異化的配置，不好管理。

單元化部署（UnitedDeployment）通過更上層次的抽象，對這些子的 Deployment 進行統(tǒng)一管理: 自動創(chuàng)建/更新/刪除。如下圖所示：

UnitedDeployment 控制器可以提供一個模板來定義應用，并通過管理多個 workload 來匹配下面不同的區(qū)域。每個 UnitedDeployment 下每個區(qū)域的 workload 被稱為 pool， 目前 pool 支持使用兩種 workload：StatefulSet 和 Deployment。控制器會根據(jù) UnitedDeployment 中 pool 的配置創(chuàng)建子的 workload 資源對象，每個資源對象都有一個期望的 replicas Pod 數(shù)量。通過一個 UnitedDeployment 實例就可以自動維護多個 Deployment 或者 Statefulset 資源，同時還能具備 replicas 等的差異化配置。如若獲取更直觀的操作體驗，請查看 Yurt-App-Manager 使用教程和開發(fā)者教程。

更多關于 Yurt-App-Manager 的討論請參考社區(qū) 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. 節(jié)點自治組件 yurt-hub

yurt-hub 是運行在 Kubernetes 集群中每個節(jié)點上運行的守護程序，它的作用是作為（Kubelet、Kubeproxy、CNI 插件等）的出站流量的代理。它在邊緣節(jié)點的本地存儲中緩存 Kubernetes 節(jié)點守護進程可能訪問的所有資源的狀態(tài)。如果邊緣節(jié)點離線，則這些守護程序可以幫助節(jié)點在重新啟動后恢復狀態(tài)，達到邊緣自治的能力。在 v0.3.0 版本中，社區(qū)對 yurt-hub 做了大量的功能性增強，主要包括：

• yurt-hub 鏈接云端 kube-apiserver 時，自動向 kube-apiserver 申請證書，并支持證書過期自動輪轉(zhuǎn)。

• 在 watch 云端資源時，增加超時機制。

• 當本地緩存數(shù)據(jù)不存在時候，優(yōu)化 response。

3. 云邊運維通道組件 yurt-tunnel

yurt-tunnel 包括云端的 TunnelServer 和每個邊緣節(jié)點上運行的 TunnelAgent 組成。TunnelServer 通過反向代理與在每個邊緣節(jié)點中運行的 TunnelAgent 守護進程建立連接，并以此在公共云的控制平面與處于企業(yè)內(nèi)網(wǎng)環(huán)境的邊緣節(jié)點之間建立安全的網(wǎng)絡訪問。在 v0.3.0 版本中，社區(qū)對 yurt-tunnel 組件，在可靠性、穩(wěn)定性、集成測試方面都做了大量的增強。

4. OpenYurt 運維組件 yurtctl

在 v0.3.0 版本中，yurtctl 支持 kubeadm provider，可以快速方便地將由 kubeadm 創(chuàng)建的原生 Kubernetes 集群轉(zhuǎn)換成能夠適應邊緣弱網(wǎng)環(huán)境的 Kubernetes 集群, 極大提升 OpenYurt 的使用體驗。

更多實踐操作請關注： 《OpenYurt 入門 - 在樹莓派上玩轉(zhuǎn) OpenYurt》

未來計劃

OpenYurt V0.3.0 版本發(fā)布，進一步提升了原生 Kubernetes 在邊緣場景的擴展能力，同時在針對邊緣場景下的應用部署的問題發(fā)布了 Yurt-App-Manger 組件，后續(xù) OpenYurt 社區(qū)會在設備管理、邊緣運維調(diào)度、社區(qū)治理和貢獻者體驗方面持續(xù)投入，再次感謝 Intel/Vmware 的同學參與，同時也非常歡迎有興趣的同學加入?yún)⑴c共建，共同打造一個穩(wěn)定，可靠的完全云原生的邊緣計算平臺。

更多社區(qū)詳情請關注：https://github.com/alibaba/openyurt。

相關鏈接

• OpenYurt Release v0.3.0

• OpenYurt v0.3.0 CHANGELOG

• OpenYurt 使用教程

• OpenYurt 官網(wǎng)

如果您對于 OpenYurt 有任何疑問，歡迎使用釘釘搜索群號（31993519）加入釘釘交流群。

總結(jié)

以上是生活随笔為你收集整理的OpenYurt v0.3.0 重磅发布：全面提升边缘场景下应用部署效率的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。