作者 | 张杰（冰羽）
起源 | 阿里巴巴云原生公众号
简介
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](https://github.com/alibaba/op…
- pull request 173: [[proposal] add nodepool and uniteddployment crd proposal](https://github.com/alibaba/op…
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）退出钉钉交换群。