Skip to main content
版本：v1.1

YurtAppManager

Yurt-App-Manager是OpenYurt集群提供边缘单元化管理的功能组件，全面提升在边缘场景下的应用部署效率，降低边缘节点和应用运维的复杂度。

组件介绍​

  • 在边缘计算场景下，边缘节点通常具备很强的区域性、地域性、或者其他逻辑上的分组特性，比如具有相同的CPU架构、运营商或云提供商，不同分组的节点间往往存在网络不互通、资源不共享、资源异构、应用独立等明显的隔离属性。这也是边缘节点池的由来。

  • 相同的应用和镜像，可能需要部署到不同的节点池中。

  • 原生Kubernetes Service的后端端点扁平分布在集群中任意节点。因此，跨跃不同分组节点的Service流量，会大概率出现访问不可达、或者访问效率低下的问题。

img

针对以上的场景和问题，OpenYurt 从三个层面来解决：

  • 节点单元化： 节点池，以节点池视角对不同边缘区域下的主机进行统一管理和运维

  • 应用的单元化： 单元化部署，使用新的单元化部署模型将用户的工作负载部署在不同的节点池中，业务的实例数，版本都可以按照节点池的维度进行统一管理。

  • 流量的单元化： Service 拓扑，通过简单配置来限制Service后端Endpoint的访问范围，例如只能由相同节点池的节点访问，或者只能本节点访问。

而Yurt-App-Manager是 Kubernetes 的一个标准扩展，它可以配合 Kubernetes 使用，提供 NodePool 和 YurtAppSet(之前名为UnitedDeployment) 两种控制器，从主机维度和应用维度来提供边缘场景下节点和应用的运维能力。

边缘节点池概述​

OpenYurt的Yurt-App-Manager 的组件提供了节点池Node Pool控制器，将节点按照特定属性（地域，CPU架构，云提供商）等等，抽象成节点池概念，以节点池的维度对节点进行统一管理。

传统的做法是用Kubernetes 打Label 的方式来对主机进行分类管理，但是随着节点规模和Label数量的增加，对节点主机分类运维（例如：批量设置调度策略、traints等）会变得越来越复杂，如下图所示：

img

NodePool 以节点组的维度对节点划分做了更高维度的抽象，可以从节点池视角对不同边缘区域下的主机进行统一管理和运维，如下图所示：

img

单元化部署应用模型​

随着地域分布越来越多，以及不同地域对应用的差异化需求，使得运维变得越来越复杂，具体表现在以下几个方面：

  • 镜像版本升级，需要将每个Deployment逐一修改。

  • 需要自定义Deployment的命名规范，以此来表明相同的应用。

  • 相同应用的多个Deployment，除了name，nodeselectors, replicas 这些特性外，其他的差异化配置比较小。

单元化部署（YurtAppSet）是OpenYurt默认提供Yurt-App-Manager组件所提供的能力，是kubernetes CRD 资源，通过更上层次的抽象，对这些子的Deployment 进行统一管理：create/update/delete。

img

YurtAppSet 控制器可以提供一个模板来定义应用，并通过管理多个 workload 来匹配下面不同的区域。 每个 YurtAppSet 下每个区域的 workload 被称为 pool， 目前 pool 支持使用两种workload： StatefulSet 和 Deployment。控制器会根据 YurtAppSet 中pool的配置创建子的workload 资源对象，每个资源对象都有一个期望的 replicas Pod 数量。通过一个YurtAppSet 实例就可以自动维护多个 Deployment 或者 Statefulset 资源，同时还能具备replicas 等的差异化配置。

如若获取更直观的操作体验，请查看 Yurt-App-Manager 使用教程和开发者教程。

更多关于 Yurt-App-Manager 的讨论请参考社区 issue 和 pull request：

编辑本页
Last updated on by Ihor Sychevskyi