作者:刘裕惺
CNStack 相关阅读:
CNStack 多集群服务:基于OCM 打造完善的集群管理能力
CNStack 虚拟化服务:实现虚拟机和容器资源的共池管理
CNStack 云边协同平台:实现原生边缘竟能如此简单
CNStack 2.0(以下简称 CNStack) 作为阿里云云原生最佳实践的输出载体,其目标是提供一个开放、共享、标准化的云原生生态系统,使企业能够更加轻松地构建和管理云原生应用。其中,在平台侧能力扩展方面,CNStack 基于“云服务” 及 “云组件”标准规范及相应工具链,提供了开放、标准、易用的能力。
目前,CNStack 已发布的云服务包括:多集群管理,分布式应用管理、分布式存储、虚拟化服务、云边协同、服务网格等,前面几篇文章中,也已陆陆续续的专文介绍了多集群、虚拟化、云边协同等云服务。后续也会有更多的云服务&云组件上架 CNStack 并专文介绍。
本文将针对云服务&云组件自身及其相关工具链进行一个系统的分享。
在具体介绍云服务&云组件之前,首先我们需要阐述一下云服务&云组件的定位以及其存在的意义。
在 CNStack 体系内,我们希望每个面向用户提供的服务既相互解耦又可无缝协作,同时还可以简单快速复用CNStack 平台提供的基础能力。针对此目标与期望,我们提出了云服务的概念,通过云服务:
基于 CNStack 平台,可在其上不断的增长新的云服务,以实现能力的扩展。
各云服务之间的生命周期与发布可完全解耦,包括与 CNStack 平台之间(实际上 CNStack 自身也是一个云服务)。
基于 CNStack 平台,可快速简单使用平台提供的用户、租户、鉴权、审计、许可证、多集群部署、UI 框架等基础能力,以及与平台既有能力或其他云服务无缝的协作能力。
云服务作为一个整体提供特定的服务,而其背后真正的实体还是由云组件组成。同时考虑到组件维度更细粒度的使用场景,在 CNStack 体系内,将云组件区分为如下几种类型:
集群组件,由集群管理员单独维护,生命周期由集群管理员负责,其往往集群维度内全局唯一。
项目组件,由项目管理员在项目命名空间中部署,其可与用户自研软件一起编排实现业务流程,其生命周期由具体使用者负责。
特殊声明:云服务&云组件自身与社区已存在的 Helm Chart、OAM(Open Application Model)等应用定义并不冲突,而是将这些应用定义做为云服务&云组件的其中一种支持方式(当前云服务&云组件仅支持 Helm Chart)。
针对云服务&云组件的生命周期管理,CNStack 基于 cn-app-operator 组件以 Kubernetes CRD 模式进行管理,对于云服务方来说,只需将云服务/云组件的定义丢到集群里,接下来就交给 cn-app-operator 组件即可。
上述是 cn-app-operator 在用户提交一个云服务/云组件后,其针对云服务/云组件的生命周期的管理 (注:所有云服务&云组件的声明都是在主集群中) :
针对云服务&云组件的每次变更,基于 Kubernetes ControllerRevision 记录历史变更
维护云服务&云组件的状态信息
同时为保证云服务服务质量,cn-app-operator 为云服务提供授权保护服务,主要为云服务提供 License 信息的加密保护以及基础部署控制(CNStack 自身的商务 License 也是基于该方式进行管控)。云服务提供方,需要针对授权环境,提供相应的服务质量保证。
云服务无需关心 License 的生成、校验等基础能力,会由 cn-app-operator 统一提供
可通过 ServiceMonitor 暴露当前使用用量,cn-app-operator 会自动与 License 中授权用量做对比,如果超出用量,则拒绝云服务的部署/变更
云服务也可通过 cn-app-operator 提供的接口获取授权信息并实现云服务自身的授权保护逻辑
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 进行存储&分发。
云服务&云组件的发布包规范遵循 Sealer 项目,通过 Sealer Image,将云服务/云组件(包含定义、附件等)、cn-app-operator 甚至是 K8s 集群自身以及部署依赖所有的 container images 等统一构建打包,在部署阶段通过 sealer run 命令可实现一键部署 K8s 集群 + 所有云服务以及一键增量部署云服务&云组件,使 CNStack 自身(包含 K8s 集群)与云服务云组件的交付方式统一且简单。
基于 CNStack 平台部署的云服务&云组件,便可无缝对接 CNStack 平台提供的的能力中心(白屏化管理),IAM(账号管理,身份认证,访问控制,操作审计等),UI 框架等基础能力。其中,IAM 和 UI 框架等会在后续专文介绍。
在白屏化管理方面,通过 CNStack 能力中心,管理员将云服务/云组件交付包(即前面提到的打包了云服务/云组件的 Sealer Image )导入能力中心,即可实现云服务/云组件的部署,升级,变配,卸载等一系列生命周期管理能力及日志监控告警等运维能力。其中:
除通过交付包(即 Sealer Image)导入外,云组件交付包也可以基于一个标准的 Helm Chart 包,通过能力中心白屏直接导入并使用
云组件的日志接入,无需额外配置即可直接使用,其中相关 Pod 的 stdout 会默认被采集
云服务&云组件的监控告警也只需做简单的配置,就可快速接入,具体接入方式及使用后续会有专文介绍
云服务列表&云服务运维:
云组件列表&云组件运维:
如上所述,在客户局点中,所有的云服务&云组件当前都需要通过手动导入包的方式进行导入,而如果在满足单向出网络的局点中,能够打通外部云服务&云组件市场,从而实现在线安装,更新等服务,将会使云服务&云组件的使用更加便捷。能力中心目前也已经正在规划该项能力,敬请期待。
另外在白屏能力上值得一提的就是云服务的多集群部署能力,前文提到,通过匹配云服务中组件的 ClusterLabelSelector 定义与多集群 ManagedCluster 对象的 Labels 来决定云服务组件部署到的集群。这就需要操作人员来手动维护 ManagedCluster 对象的 Label 使其满足云服务组件 ClusterLabelSelector 的声明,而通过能力中心, 无需关心上述声明,仅需通过能力中心操作部署/卸载即可,能力中心会自动完成 ManagedCluster 相应 Label 的变更操作。
通过云服务&云组件,使 CNStack 作为输出载体,可在其之上不断的丰富其生态系统。围绕云服务&云组件,我们:
另外除了由阿里云官方来提供云服务&云组件外,我们也希望将这个扩展能力交给用户以及社区。目前所有用户皆可通过 ADP 平构建自己的云服务&云组件,同时我们也正在着手准备将云服务&云组件模型的定义、生命周期管理工具 cn-app-operator 以及相关完整的工具链逐步在 CNStack 社区进行开源。
相关链接:
CNStack 产品官网
https://www.aliyun.com/activity/middleware/cnstack
CNStack 社区版(免费下载使用)
https://github.com/alibaba/CNStackCommunityEdition
ADP(Application Delivery Platform) 产品官网
https://help.aliyun.com/product/191542.html
CNCF Sealer 项目
https://github.com/sealerio/sealer
CNCF OCM 项目
https://open-cluster-management.io/
Helm
https://helm.sh/
OAM(Open Application Model)
https://oam.dev/
Kubernetes ControllerRevision
https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/controller-revision-v1/