关于阿里云:CNStack-云服务云组件打造丰富的云原生技术中台生态

3次阅读

共计 4952 个字符，预计需要花费 13 分钟才能阅读完成。

作者：刘裕惺

CNStack 相干浏览：

CNStack 多集群服务：基于 OCM 打造欠缺的集群治理能力

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

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

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

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

本文将针对云服务 & 云组件本身及其相干工具链进行一个零碎的分享。

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

在 CNStack 体系内，咱们心愿每个面向用户提供的服务既互相解耦又可无缝合作，同时还能够简略疾速复用 CNStack 平台提供的根底能力。针对此指标与冀望，咱们提出了云服务的概念，通过云服务：

基于 CNStack 平台，可在其上一直的增长新的云服务，以实现能力的扩大。
各云服务之间的生命周期与公布可齐全解耦，包含与 CNStack 平台之间（实际上 CNStack 本身也是一个云服务）。
基于 CNStack 平台，可疾速简略应用平台提供的用户、租户、鉴权、审计、许可证、多集群部署、UI 框架等根底能力，以及与平台既有能力或其余云服务无缝的合作能力。

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

云服务组件，作为云服务中组件的一员，其生命周期和云服务统一；云服务下的组件依据其部署个性又辨别为管制面和数据面，其中：

<!—->

1. 管制面组件，即管控类组件，仅在主集群上部署。
2. 数据面组件，即非管控类组件，能够在主集群 / 客用集群部署，其生命周期和健康状况，在集群之间互相独立。

<!—->

集群组件，由集群管理员独自保护，生命周期由集群管理员负责，其往往集群维度内全局惟一。
我的项目组件，由我的项目管理员在我的项目命名空间中部署，其可与用户自研软件一起编排实现业务流程，其生命周期由具体使用者负责。

非凡申明：云服务 & 云组件本身与社区已存在的 Helm Chart、OAM（Open Application Model）等利用定义并不抵触，而是将这些利用定义做为云服务 & 云组件的其中一种反对形式（以后云服务 & 云组件仅反对 Helm Chart）。

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

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

依据云服务 & 云组件申明主动达到终态

<!—->

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

<!—->

针对云服务 & 云组件的每次变更，基于 Kubernetes ControllerRevision 记录历史变更
保护云服务 & 云组件的状态信息

<!—->

1. 通过 LabelMarker，将所有属于云服务 / 云组件的 workload 打标，workload 列表通过解析 helm manifest 获取
2. 云服务 & 云组件 status 控制器，会依据云服务 & 云组件相干标签，获取并聚合 workload 的状态信息，作为云服务 & 云组件的实在状态

<!—->

高扩大能力反对，如通过扩大云组件部署器，反对多集群，边缘节点等简单场景部署

<!—->

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 也是基于该形式进行管控）。云服务提供方，须要针对受权环境，提供相应的服务质量保障。

云服务无需关怀 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 作为输入载体，可在其之上一直的丰盛其生态系统。围绕云服务 & 云组件，咱们：

联合 Sealer，实现了模型标准，并在反对 Helm Chart 的根底上，保留了其将来反对 OAM 等利用定义的扩展性。
构建了生命周期管理工具，cn-app-operator，其残缺的反对云服务 & 云组件的全生命周期治理，并在将来会扩大反对如多集群灰度等更高阶的能力。
CNStack 平台内置了白屏化治理平台，CNStack 能力核心，使云服务 & 云组件的操作 & 治理 & 运维老本大幅升高，并可无缝对接 UI 框架，身份 & 拜访治理等根底能力。
甚至打造了阿里云私有云产品 – 云原生利用交付平台（Application Delivery Platform，简称 ADP）（实现了云服务 & 云组件的 CI/CD，罕用中间件云组件的反对，基于私有云环境在线验证，一键产出云服务 & 云组件 Sealer 交付包，License 受权治理等能力），不便云服务 & 云组件的集成，测试和公布。

另外除了由阿里云官网来提供云服务 & 云组件外，咱们也心愿将这个扩大能力交给用户以及社区。目前所有用户皆可通过 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-…