九大云原生产品之华为云OSC云原生服务中心

课程目标

学完本课程后，您将能够:

了解云原生应用管理技术现状与发展趋势

了解华为云OSC云原生服务中心产品与功能

华为云云原生基础设施产品解决方案全景图

Helm等一些通用应用管理技术能够很好地帮我们实现k&s应用打包和标准化交付，对于一些复杂应用的生命周期管理则力有不逮;相应地，致力于复杂应用管理的Operator相关技术，典型的如Operator Framework等，更多着眼于底层通用能力的实现，对于应用行为方式规范，用户体验等考虑则不尽人意...

云原生服务中心（Operator Service Center，简称OSC）是一个云原生服务生命周期治理平台，为用户提供了大量开箱即用的云原生服务，并支持用户上传私有服务。OSC支持服务的订阅、部署、运维、更新等操作。

云原生服务中心对服务的管理方式深度匹配云原生2.0中“以应用为中心”的核心，有效解决了传统容器平台“以资源为中心”的管理方式的各种不便，如有状态应用云原生化改造难、缺乏应用级运维视图、同一个服务无法适配多个部署场景。华为云原生基础设施（云容器引擎CCE、容器镜像服务SWR、容器洞察引擎CIE、智能边缘平台IEF等）通过OSC对外开放云原生能力，如弹性伸缩、多云部署、云边协同、应用级自动化运维等，全面支持企业架构云原生化。

目录

1．云原生应用管理技术现状与发展趋势

2．华为云OSC云原生服务中心产品介绍与功能演示

云进入以“应用为中心”的云原生阶段，Operator的出现，提供了一套行之有效的标准规范，把运维知识固化成高级语言Go/Java代码，使得运维知识可以像普通软件一样交付，并能支持具备高级运维能力以及高可靠的有状态应用批量交付。

虚拟化的一致性和隔离性差；容器隔离应用运行环境，对容器外不感知，容器能力差；k8s管理容器依赖的资源，管理能力仅限于k8s基础资源，不支持应用级；HELM包管理工具，持续交付，无法管理应用运行态；云原生应用管理技术以应用级资源编排和管理，对运行时管理，可一次开发，Run AnyWhere。

Helm & kustomize通用应用管理技术；KUDO, KubeVela, Operator Framework：不同味道的Operator技术生态。

云原生服务中心是一个云原生服务生命周期治理平台，包括服务订阅、退订、上传、升级等，实例的部署、运维、更新、删除等操作。

服务订阅

服务中心包含华为自研服务、合作伙伴开发的服务以及开源服务，所有服务都支持用户订阅，只有订阅成功的服务，用户才可以部署实例。

服务退订

用户可以随时终止订阅服务，被取消订阅的服务对应的实例及其资源都会被删除。

服务上传

用户按照Helm、Operator Framework的规范或者OSC的开发规范开发的服务，可上传到云原生服务中心作为私有服务进行管理。

服务升级

在云原生服务中心的某服务有了新版本后，如果用户订阅了该服务，会收到升级提示，用户可以将服务及其对应的实例升级到指定版本。

实例部署

云原生服务中心所有的服务都支持一键部署。用户可在部署过程中指定运行时参数，按照业务需要分配规模以及相关资源。

实例运维

云原生服务中心提供实例的运维视图，在一个视图中可以查看实例的监控、日志等运维信息，如果需要深入的数据分析，可以从运维视图跳转到对应的云服务。

实例更新

用户可以在线调整运行时参数，调整业务分配规模，通过修改配置方式更新实例。

实例删除

当实例承载的业务生命周期结束，用户可以通过删除实例回收相关资源。

Helm & Kustomize应用包管理技术

配置按行为方式分为三类

●应用打包

●应用配置

●运行时配置

Helm(结合Kustomize)能够实现

●应用打包和描述

●生命周期管理

●依赖管理

●应用定制化

●应用程序发现

Operator解决Kubernetes管理有状态应用的问题

利用K8s的API扩展性以及Controller原理，提供了一-种批量交付有状态容器应用的标准， 简化了用户获得有状态容器应用实例的过程。

●K8s定义应用

扩展API,定义与k8s原生资源一致

●运维知识集成到应用

运维专业知识，通过代码集成到Operator应用，自动化运维，一次开发，Run Anywhere

●K8s Controller模式管理应用

K8s Controller模式，Operator利用K8s平台能力,实现应用从创建到销毁的全生命周期管理。

KUDO，零代码编排Operator

KUDO虽然可以快速实现operator,依然是触发式编程，而不是响应式编程，不支持自动化运维

玩家

发布商: D2iQ ，2019年11月开源

定位:帮助K8s基础弱以及开发能力的开发者利用YAML快速编排Operator

使用场景

1.执行工作流:并行或者串行，备份、恢复、数据迁移

2.补充工作逻辑:扩缩容之后的数据重新分片或者数据均衡或者周期任务

零代码

1.支持YAML文件声明式开发Operator

2.以Plan, Phase, Step编排资源依赖、创建顺序

不足

全自动运维能力不完善:只能编排K8s既有资源，无法支持状态维护和Day2  Operation

OAM & Kubevela，能力复用，快速编排能力组件

OAM与Kubevela的目标用户有能力复用需求的企业级k8s平台，社区已有的通用能力少，需要依靠开源开发者来丰富，各个玩家开发的trait组件可能与平台能力耦合，通用性不强

玩家

发布商:微软,阿里，4Paradigm, Crossplane, upbond

定位:提供通用的云原生应用模型定义

使用场景

1.业务运维分离:业务开发聚焦应用的业务流程，运维开发聚焦应用的运维能力，适用于开发和运维有专门的团队，运维能力由平台团队实现

2.混合编排:应用的组件可以是基础组件，也可以是用户自定义的组件

3.通用能力复用:大部分应用的运维能力相似，比如指标监控、告警上报、日志管理、弹性伸缩、动态路由等，可复用能够提高企业开发效率

4.业务组件复用:使用CUE语言可开发支持不同工作协议的组件

不足：

1.学习门槛高: K8s知识、OAM语义、Kubevela命令、CUE语言

2.不支持运行时管理:面向应用而非应用编程，不具备Day2 Operation

3.不适合小规模团队:优势是能力复用，但是组件开发门槛高，复用诉求不高的团队和企业，使用OAM的开发效率没有优势

4.灵活性低:无法直接编排K8s工作负载,封装的K8s组件丢失的K8s能力，只能通过patch-trait补齐

Operator Framework ,高自由度开发Operator

较受欢迎的开发Operator的开源项目,在kubebuilder的基础上扩展的能力，目的是方便openshift管理，没有提供通用能力，降低开发者负担

玩家

发布商: Red Hat,201 8年发布

定位:发展为Operator开发标准，赋予Operator应用定义

使用场景

1.开发兼容Openshift的Operator

2.希望通过动态UI为Operator开发控制台

高度自由

1.只受K8s能力约束，没有其它额外的约束

2.在不计开发成本的条件下，开发者可以实现出功能完备的Operator

不足

1.没有提供可复用的能力，所有的运维能力都需要开发者实现

2.更关注底层功能实现，交互体验设计上有所考虑但不够深入

"以应用为中心”面临的挑战

有状态应用管理能力有限

Kubernetes提供的标准化的StatefulSet无法处理不同应用之间的差异化，对面向终态的K8s,不能被描述，就不能被管理

无应用开发规范

Operator机制为开发者提供了自由，但是应用的通用云原生能力如弹性、日志、告警、监控等特性存在重复造轮子的问题，开发者无法聚焦业务开发

不易跨云部署

云原生的一大特性是跨云能力，需要快速实现服务跨云部署，告别产商锁定

企业难实现服务统一管理

以应用为中心的云原生架构鼓励进行服务复用，会造成平台中存在大量云原生服务;不同服务单独运维管理入口的方式大大增加管理成本;

企业自研应用和订阅的第三方应用需要统一管理

生态丰富

云原生服务中心提供各种类型服务，满足不同行业和应用场景。不仅提供了数据库、消息、缓存等通用中间件，还提供了新技术领域的AI、大数据、高性能计算、边缘等应用。除了Helm以及Operator社区应用，还有多个合作伙伴提供商业级应用，为企业业务的可靠运行保驾护航。

简单易用

云原生服务中心的管理控制台简单易用，支持服务的全生命周期治理。

应用级运维视图

传统的运维方式应用于资源割裂，都聚焦在资源层级，没有应用统一视图。云原生服务中心提供的应用级运维视图支持用户在同一视图中查看监控、日志信息。

服务开发规范，助力企业快速实现服务云原生改造

Day0服务定义:兼容开源，支持以Operator Framework和Helm两种社区标准作为输入，转换为标准服务包;扩展开源，低成本对接平台高阶能力

Day1服务开发:提供即插即用的公共能力，在基础服务资源声明文件的基础上补充配置，0代码实现服务运维对接

1.纵向可视化:服务->微服务-> K8s资源工作负载全链路查看

2.横向可视化:跨集群、跨AZ、 跨云部署的服务的运维数据拥有统一视图界面

3.控制台管理:伙伴的服务大部分都有独立控制台，实例详情支持独立控制台的管理和跳转

4.运维策略管理:告警、日志、监控、伸缩支持变更管理策略，如修改指标告警阈值、日志采集策略、指标汇聚策略、弹性伸缩策略

5.非侵入式:业务代码不适配云平台，避免厂商锁定

1.开发者可以通过简单的配置完成对ServiceEntity(服务主体)资源对象的监控对接，监控指标能够以服务实例(而非原始的k8s资源对象)的维度进行汇聚，其他一些内置的公共运维能力，如"backup"也可以通过声明的形式直接引用。

2.backup会触发数据备份动作

3.服务实例相应的监控指标将以开发者预定义的聚合规则和标签进行展示

4.Engine包含各种现成的公共能力，包括生命周期管理、可观察性、安全性、高可用性、备份/迁移和可评估性相关的功能

基于成熟度模型在各个层次提供平台能力的支撑，服务“上得易，跑得好”

天然分布式云架构，全球跨云、跨地域高效部署

一次上架，全域发放：中心上架  | Region同步

跨云一键部署：跨K8s集群 |  跨AZ | 跨区域 | 边缘

全链路视图：应用->region->集群->资源

灵活计费：与MarketPlace打通，计费机制灵活

应用场景

服务中心包含华为自研服务、合作伙伴开发的服务以及开源服务，供用户自主选择，帮助用户快速构建业务生态。

价值

服务市场服务种类丰富，不仅包含微服务架构中需要的无状态应用，还包含了中间件（包括常用的消息、缓存、数据库等）、AI、大数据、边缘等有状态应用。用户可以根据业务场景在服务中心自主订阅。

优势

服务种类丰富

服务中心的服务种类涵盖主流中间件，覆盖AI、大数据、边缘等行业，最大程度满足用户一站式构建业务生态的需求，免除重复采购、运维的成本。

匹配硬件

提供有硬件架构需要的服务，比如ARM、GPU、NPU，满足不同计算场景。

服务目录管理，助力企业能力共享（混合云场景）

多源对接

●支持对接企业既有的镜像仓库和制品仓库

完善的租户隔离模型

●公开或者私有

●指定用户可见，其他用户可以从服务市场订阅

●基于角色访问权限控制，精细控制每个租户权限，保障每个服务的可见性和操作权限

提高服务管理效率

●为服务打上自定义分组标签,分类管理

上线

●OSC提供技术支持,协助企业应用快速云原生化成长为行业云原生服务，沉淀行业应用，形成行业公共服务，上架到云市场，技术与行业的双引擎驱动行业发展。

OSC开源项目生态建设

开发者拓展：

1.伙伴开发者:引导合作伙伴关注生态项目，增加项目活跃度

2.开源合作:从拓展的伙伴中邀请共同经营开源社区

3. 宣传文章:与MO合作，定期发布宣传文章

4.沙箱实验:制作沙箱实验，让开发者免费体验

社区建设：

1.社区主页:设计和实现社区主页，并提供国际化支持

2.社区文档:入门文档、开发文档、原理文档

3.社区视频:原理视频，沙箱视频

4.博客区:社区主页设置博客区，邀请mvp入驻,分享使用心得和最佳实践

本课总结

通用应用管理技术：以Helm, Kustomize为代表，单独或结合使用，能够应对简单(无状态)应用的打包发布、生命周期管理、以及- -定程度的应用定制化等通用场景

Operator原理：针对复杂应用，以CRD的形式声明，将运维知识集成到软件中，通过K8s Controller模式管理应用

典型Operator技术(生态)：KUDO:追求零编码的形式快速实现Operator,能力边界与通用管理技术相近，无法很好地完成复杂应用的状态维护

Kubevela:通过完整的应用模型定义，较好地实现社区已有云原生通用能力接入;模型和语法较复杂,用户学习门槛和开发成本较高，但用户体验和产品化相关设计仍不够深入

OSC服务总结：

体验上:强调服务化的用户体验

生态兼容方面:兼容Helm, Operator Framework等第三方生态作为服务包原始物料,降低已有业务搬迁的门]槛

能力范围:实现从服务开发、基本的服务实例部署到后续的实例生命周期维护和运维操作的完整覆盖

公共能力方面:支持能力复用机制，避免开发者重复造轮子，并提供一系列即插即用的公共能力， 降低开发成本

场景覆盖方面:支持从OSC 中心向公有云线上各region,以及线下的专属云站点和边缘节点分发服务实例，真正做到一-次上架,全域发放

拥抱开源:后续OSC的服务规范及全栈能力都将作为开源项目贡献社区，用户没有厂商绑定的顾虑

OSC云原生服务中心官网: https://support.huaweicloud.com/productdesc-osc/osc_ productdesc _0001.html

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。