[发明专利]有状态应用实例运维组件的生成方法、装置、设备及介质

说明书

本发明实施例提供了一种有状态应用实例运维组件的生成方法、装置、设备及介质，其中，该方法包括：获取学习数据，所述学习数据包括Kubernetes Operator的编写语法、应用状态的原理以及有状态应用实例的运维数据；采用深度学习算法分析所述学习数据，得到Kubernetes Operator对象的特征数据，根据所述特征数据生成Kubernetes Operator的软件包，所述特征数据包括Kubernetes Operator对象的全生命周期活动的抽象特征。该方案可以有利于提高效率，有利于提高构建的Kubernetes Operator的性能或准确性。

技术领域

本发明涉及运维技术领域，特别涉及一种有状态应用实例运维组件的生成方法、装置、设备及介质。

背景技术

Kubernetes(简称k8s)作为一个跨主机集群的开源容器调度平台，提供了以容器为中心的基础架构并从2017年开始已经成为了容器编排领域的事实标准。

如图1所示，Kubernetes项目编排能力的核心在于其声明式API的设计和使用，通过对REST路径下API群组进行CRUD操作，可以获取和变更资源信息。Kubernetes中存在多种资源类型，如pods(最小的原子调度单位)、service(服务)、events(事件)等。通常情况下，大部分使用者只关心pod、service这种直接关乎服务运行成功与否的资源类型，而只有在集群发生异常或是服务部署发生异常，需要进行问题追踪时，才会关注集群运行信息。

目前针对集群内部运行信息的记录，主要通过events进行。Events包含了kubernetes运行过程中核心组件kubelet和ControllerManager(控制管理器)产生的信息，分析events包含信息和events变更历史可以有效追踪问题，从而有的放矢的解决问题。业内目前查看events主要通过kubectl(二进制可执行文件，通过访问kube-apiserver产生效果)命令进行，具体命令如kubectl get events和kubectl describe[resourceName]均可以或者events内容。现有方式为命令行级别操作，需要具备访问集群权限。要获取准确的events信息需要设置繁杂的参数做多条件匹配，且最终的查询结果显示不够友好。对于一些特定需求，如查询一个应用升级前后对应pod名字变化，需要多次查询人工匹配，且不容易进行操作常态化。

Kubernetes管理有状态应用的高可用、故障保障、持久化，仍然是一个困难的工作。Kubernetes 1.5版提供了StatefulSet来处理有状态应用，但实现和效果并不好。为了解决这个问题，Kubernetes 1.9+后，Kubernetes Operator出现了，它可以很好的解决有状态应用的高可用、故障保障、持久化。如图2所示，Kubernetes Operator是CoreOS推出的旨在简化复杂有状态应用管理的框架，它是一个感知应用状态的控制器，通过扩展Kubernetes API来自动创建、管理和配置应用实例。Kubernetes Operator基于CustomerResources Define扩展了新的应用资源，并通过控制器来保证应用处于预期状态。比如etcd operator通过下面的三个步骤模拟了管理etcd(一种分布式数据库)集群的行为：

1、通过KubernetesAPI观察集群的当前状态；

2、分析当前状态与期望状态的差别；

3、调用etcd集群管理API或KubernetesAPI消除这些差别。