CNStack 云服务&云组件：打造丰富的云原生技术中台生态

作者：刘裕惺

CNStack 相关阅读：

CNStack 多集群服务：基于OCM 打造完善的集群管理能力

CNStack 虚拟化服务：实现虚拟机和容器资源的共池管理

CNStack 云边协同平台：实现原生边缘竟能如此简单

01 前言

CNStack 2.0（以下简称 CNStack） 作为阿里云云原生最佳实践的输出载体，其目标是提供一个开放、共享、标准化的云原生生态系统，使企业能够更加轻松地构建和管理云原生应用。其中，在平台侧能力扩展方面，CNStack 基于“云服务” 及 “云组件”标准规范及相应工具链，提供了开放、标准、易用的能力。

目前，CNStack 已发布的云服务包括：多集群管理，分布式应用管理、分布式存储、虚拟化服务、云边协同、服务网格等，前面几篇文章中，也已陆陆续续的专文介绍了多集群、虚拟化、云边协同等云服务。后续也会有更多的云服务&云组件上架 CNStack 并专文介绍。

本文将针对云服务&云组件自身及其相关工具链进行一个系统的分享。

02 云服务&云组件简介

在具体介绍云服务&云组件之前，首先我们需要阐述一下云服务&云组件的定位以及其存在的意义。

在 CNStack 体系内，我们希望每个面向用户提供的服务既相互解耦又可无缝协作，同时还可以简单快速复用CNStack 平台提供的基础能力。针对此目标与期望，我们提出了云服务的概念，通过云服务：

  1. 基于 CNStack 平台，可在其上不断的增长新的云服务，以实现能力的扩展。

  2. 各云服务之间的生命周期与发布可完全解耦，包括与 CNStack 平台之间（实际上 CNStack 自身也是一个云服务）。

  3. 基于 CNStack 平台，可快速简单使用平台提供的用户、租户、鉴权、审计、许可证、多集群部署、UI 框架等基础能力，以及与平台既有能力或其他云服务无缝的协作能力。

云服务作为一个整体提供特定的服务，而其背后真正的实体还是由云组件组成。同时考虑到组件维度更细粒度的使用场景，在 CNStack 体系内，将云组件区分为如下几种类型：

  1. 云服务组件，作为云服务中组件的一员，其生命周期和云服务一致；云服务下的组件根据其部署特性又区分为控制面和数据面，其中：
    1. 控制面组件，即管控类组件，仅在主集群上部署。
    2. 数据面组件，即非管控类组件，可以在主集群/客用集群部署，其生命周期和健康状况，在集群之间相互独立。

  1. 集群组件，由集群管理员单独维护，生命周期由集群管理员负责，其往往集群维度内全局唯一。

  2. 项目组件，由项目管理员在项目命名空间中部署，其可与用户自研软件一起编排实现业务流程，其生命周期由具体使用者负责。

image.png

特殊声明：云服务&云组件自身与社区已存在的 Helm Chart、OAM（Open Application Model）等应用定义并不冲突，而是将这些应用定义做为云服务&云组件的其中一种支持方式（当前云服务&云组件仅支持 Helm Chart）。

03 基于 cn-app-operator，实现云服务&云组件的完整生命周期管理

针对云服务&云组件的生命周期管理，CNStack 基于 cn-app-operator 组件以 Kubernetes CRD 模式进行管理，对于云服务方来说，只需将云服务/云组件的定义丢到集群里，接下来就交给 cn-app-operator 组件即可。

image.png

上述是 cn-app-operator 在用户提交一个云服务/云组件后，其针对云服务/云组件的生命周期的管理 （注：所有云服务&云组件的声明都是在主集群中） ：

  1. 根据云服务&云组件声明自动到达终态
    1. 根据云服务+云服务配置声明，自动创建出对应的云组件（注：也可单独提交云组件）
    2. 针对云服务，允许提供单独的云服务配置，针对云组件部分参数进行覆盖（云组件默认参数与覆盖参数的 merge 由 cn-app-operator 自动完成），以实现定义和配置的解耦
    3. 针对集群组件（即集群范围内唯一的云组件），其生命周期独立于云服务。其部署行为为：如果集群内未部署该组件，则进行部署；如果集群内已部署该组件，则仅在更高版本被声明时，进行升级；否则不做任何行为改变
    4. 根据云组件声明，通过 helm install/upgrade/rollback 等方式，使其达到云组件定义的期望状态
    5. 具体 action 会执行 helm install/helm upgrade / helm rollback， 由 cn-app-operator 自动判断
    6. 监听云服务配置，多集群信息等触发上述行为的自动变更

  1. 针对云服务&云组件的每次变更，基于 Kubernetes ControllerRevision 记录历史变更

  2. 维护云服务&云组件的状态信息

    1. 通过 LabelMarker，将所有属于云服务/云组件的 workload 打标，workload 列表通过解析 helm manifest 获取
    2. 云服务&云组件 status 控制器，会根据云服务&云组件相关标签，获取并聚合 workload 的状态信息，作为云服务&云组件的真实状态
  1. 高扩展能力支持，如通过扩展云组件部署器，支持多集群，边缘节点等复杂场景部署
    1. 基于 OCM(open-cluster-management)，扩展 cn-app-operator 组件部署器，将 helm release 下发到相应的集群中。其中决定云服务组件需要部署到哪些集群上，通过匹配云服务中组件的 ClusterLabelSelector 定义与多集群 ManagedCluster 对象的 Labels来决定。
    2. 云边协同云服务，通过扩展 cn-app-operator 组件部署器，支持将 helm release 部署至边缘节点上

同时为保证云服务服务质量，cn-app-operator 为云服务提供授权保护服务，主要为云服务提供 License 信息的加密保护以及基础部署控制（CNStack 自身的商务 License 也是基于该方式进行管控）。云服务提供方，需要针对授权环境，提供相应的服务质量保证。

  1. 云服务无需关心 License 的生成、校验等基础能力，会由 cn-app-operator 统一提供

  2. 可通过 ServiceMonitor 暴露当前使用用量，cn-app-operator 会自动与 License 中授权用量做对比，如果超出用量，则拒绝云服务的部署/变更

  3. 云服务也可通过 cn-app-operator 提供的接口获取授权信息并实现云服务自身的授权保护逻辑

04 基于Sealer，实现云服务&云组件的 build，share，run

Sealer[ˈsiːlər] 是云原生 PaaS 团队贡献给 CNCF 基金会的开源项目，其核心目标在于实现分布式软件的 Build、Share、Run 能力，探索分布式软件更好的协作与交付方式。其使用类似 Docker Image 的方式，将分布式软件部署所需的所有依赖统一在 Build 阶段打包在 Sealer Image 中， 并在 Run 节点可通过 Clusterfile 配置来描述/覆盖启动 Sealer Image 中的分布式软件的默认配置，其中 Sealer Image 自身是符合 OCI 规范的，其可基于已有 Docker Registry/OCI Registry 进行存储&分发。

image.png

云服务&云组件的发布包规范遵循 Sealer 项目，通过 Sealer Image，将云服务/云组件（包含定义、附件等）、cn-app-operator 甚至是 K8s 集群自身以及部署依赖所有的 container images 等统一构建打包，在部署阶段通过 sealer run 命令可实现一键部署 K8s 集群 + 所有云服务以及一键增量部署云服务&云组件，使 CNStack 自身（包含 K8s 集群）与云服务云组件的交付方式统一且简单。

image.png

05 基于 CNStack 能力中心，实现云服务&云组件的白屏化管理

基于 CNStack 平台部署的云服务&云组件，便可无缝对接 CNStack 平台提供的的能力中心（白屏化管理），IAM（账号管理，身份认证，访问控制，操作审计等），UI 框架等基础能力。其中，IAM 和 UI 框架等会在后续专文介绍。

在白屏化管理方面，通过 CNStack 能力中心，管理员将云服务/云组件交付包（即前面提到的打包了云服务/云组件的 Sealer Image ）导入能力中心，即可实现云服务/云组件的部署，升级，变配，卸载等一系列生命周期管理能力及日志监控告警等运维能力。其中：

  1. 除通过交付包（即 Sealer Image）导入外，云组件交付包也可以基于一个标准的 Helm Chart 包，通过能力中心白屏直接导入并使用

  2. 云组件的日志接入，无需额外配置即可直接使用，其中相关 Pod 的 stdout 会默认被采集

  3. 云服务&云组件的监控告警也只需做简单的配置，就可快速接入，具体接入方式及使用后续会有专文介绍

云服务列表&云服务运维：

image.png

image.png

云组件列表&云组件运维：

image.png

image.png

如上所述，在客户局点中，所有的云服务&云组件当前都需要通过手动导入包的方式进行导入，而如果在满足单向出网络的局点中，能够打通外部云服务&云组件市场，从而实现在线安装，更新等服务，将会使云服务&云组件的使用更加便捷。能力中心目前也已经正在规划该项能力，敬请期待。

另外在白屏能力上值得一提的就是云服务的多集群部署能力，前文提到，通过匹配云服务中组件的 ClusterLabelSelector 定义与多集群 ManagedCluster 对象的 Labels 来决定云服务组件部署到的集群。这就需要操作人员来手动维护 ManagedCluster 对象的 Label  使其满足云服务组件 ClusterLabelSelector 的声明，而通过能力中心， 无需关心上述声明，仅需通过能力中心操作部署/卸载即可，能力中心会自动完成 ManagedCluster 相应 Label 的变更操作。

image.png

06 总结

通过云服务&云组件，使 CNStack 作为输出载体，可在其之上不断的丰富其生态系统。围绕云服务&云组件，我们：

  1. 结合 Sealer，完成了模型规范，并在支持 Helm Chart 的基础上，保留了其未来支持 OAM 等应用定义的扩展性。
  2. 构建了生命周期管理工具，cn-app-operator，其完整的支持云服务&云组件的全生命周期管理，并在未来会扩展支持如多集群灰度等更高阶的能力。
  3. CNStack 平台内置了白屏化管理平台， CNStack 能力中心，使云服务&云组件的操作&管理&运维成本大幅降低，并可无缝对接 UI 框架，身份&访问管理等基础能力。
  4. 甚至打造了阿里云公有云产品 - 云原生应用交付平台（Application Delivery Platform，简称 ADP）（实现了云服务&云组件的 CI/CD，常用中间件云组件的支持，基于公有云环境在线验证，一键产出云服务&云组件 Sealer 交付包，License 授权管理等能力），方便云服务&云组件的集成，测试和发布。

另外除了由阿里云官方来提供云服务&云组件外，我们也希望将这个扩展能力交给用户以及社区。目前所有用户皆可通过 ADP 平构建自己的云服务&云组件，同时我们也正在着手准备将云服务&云组件模型的定义、生命周期管理工具 cn-app-operator 以及相关完整的工具链逐步在 CNStack 社区进行开源。

相关链接：

posted @ 2023-04-15 14:21  阿里云云原生  阅读(115)  评论(0)  编辑  收藏  举报