适用金融分布式架构云原生控制器的设计方法及系统技术方案

本发明专利技术提供一种适用金融分布式架构云原生控制器的设计方法及系统，包括：步骤S1：通过向kubernetes集群提交CibDeployment资源，实现业务部署；步骤S2：由控制器通过监听CibDeployment资源变化事件，触发CibDeployment资源的调解流程，完成业务的部署；步骤S3：在步骤S2完成业务部署后，分区故障检测与调度组件会定期对所有分区进行故障检测，一旦检测到某个分区节点全部故障，就将该分区内的副本转移到其他分区中，同时会检测已故障的分区是否恢复，如果分区故障恢复，会自动还原到无故障时的状态。本发明专利技术能够将一个业务按需部署到多个分区上，统一管理。统一管理。统一管理。

【技术实现步骤摘要】
适用金融分布式架构云原生控制器的设计方法及系统


[0001]本专利技术涉及云计算
，具体地，涉及一种适用金融分布式架构云原生控制器的设计方法及系统。

技术介绍

[0002]kubernetes(简称k8s)作为一个开源的容器化管理平台，在容器化领域得到了越来越多的应用。但是，它的组件多、配置复杂，进而导致其安装、部署和管控都比较复杂。
[0003]当前k8s已经成为了容器编排的事实标准。随着k8s的大规模使用并进入金融科技领域，原生组件可以满足大部分需求，但对于一些特殊的金融科技领域运用场景，还不能完全满足。

技术实现思路

[0004]针对现有技术中的缺陷，本专利技术提供一种适用金融分布式架构云原生控制器的设计方法及系统。
[0005]根据本专利技术提供的一种适用金融分布式架构云原生控制器的设计方法及系统，所述方案如下：
[0006]第一方面，提供了一种适用金融分布式架构云原生控制器的设计方法，所述方法包括：组件CibDeployment和InplaceSet；其中，CibDeployment主要实现分区控制，其下控制多个InplaceSet，每个InplaceSet对应一个分区，同时控制发布策略、故障感知和自动转移；InplaceSet仅实现副本保持和原地升级功能；
[0007]步骤S1：通过向k8s集群提交CibDeployment资源，实现业务部署；
[0008]步骤S2：由控制器通过监听CibDeployment资源变化事件，触发CibDeployment资源的调解流程，完成业务的部署；
[0009]步骤S3：在步骤S2完成业务部署后，分区故障检测与调度组件会定期对所有分区进行故障检测，一旦检测到某个分区节点全部故障，就将该分区内的副本转移到其他分区中，同时会检测已故障的分区是否恢复，如果分区故障恢复，会自动还原到无故障时的状态。
[0010]优选地，所述步骤S2包括：
[0011]步骤S2.1：CibDeployment控制器通过监听CibDeployment或InplaceSet资源的改变事件，触发资源调解流程，进入调解流程后，先通过资源标识获取到资源对象的详细信息；
[0012]步骤S2.2：通过步骤S2.1得到的CibDeployment资源信息，通过分区部署组件遍历CibDeployment的分区配置spec.regions，调用分区重载组件，完成分区差异化配置，然后调用发布组件，将业务部署到多个分区中，分区配置包括分区名称name、分区副本数replicas、分区标签matchLabels；
[0013]步骤S2.3：在步骤S2.2中，分区重载组件会读取分区重载配置spec.overrides，和
通用配置模板spce.template，再通过分区重载策略为各个分区生成各自的差异化配置，然后使用生成的差异化配置创建InplaceSet资源；
[0014]步骤S2.4在步骤S2.3中，发布组件会通过发布策略确定创建InplaceSet时设置的副本数，然后创建InplaceSet资源；
[0015]步骤S2.5：在步骤S2.4中，根据发布策略，完成第一个批次的发布后，如果分区InplaceSet的副本数还未达到期望的副本数，那么需要对InplaceSet扩容，会由分组滚动组件控制，将整个滚动过程分成多个批次进行，并且只有在当前批次完成后，才会开始下一个批次的扩容；
[0016]步骤S2.6：在步骤S2.4中，如果CibDeployment资源设置了等待确认策略spec.strategy.needWaitingForConfirm为true，那么在开启下一个批次的扩容前，还需要人工确认，确认完成后，才会开始下一个批次的扩容；
[0017]步骤S2.7：在步骤2.5中，开启下一个批次的扩容需要等待所有分区都扩容完成，扩容完成即为该分区InplaceSet下的Pod都应该处于available状态；
[0018]步骤S2.8：在步骤S2.1中，若监听到的CibDeployment资源正在进行升级，若配置升级策略spec.strategy.updateStrategy为InPlaceIfPossible，表示在满足原地升级条件下，就执行原地升级，即Pod不重建，仅替换Pod中的容器，保持Pod的IP、磁盘挂载、网络配置不变。
[0019]优选地，所述步骤S2.2包括：
[0020]步骤S2.2.1：在步骤S2.2中，为每个分区都创建InplaceSet资源，InplaceSet资源包含以下重要信息：
[0021]replicas：期望的pod副本数；
[0022]minReadySeconds：pod状态变为available前至少在ready状态等待的时间；
[0023]updateStrategy：设置原地升级策略，包含以下字段：
[0024]type：值为Roll或者InplaceIfPossible，Roll表示滚动升级，InplaceIfPossible表示如果能原地升级则原地升级，否则不原地升级；
[0025]gracePeriodSeconds：原地升级之前等待流量切换的时间；
[0026]template：描述pod的资源对象，是k8s内置的资源对象；
[0027]步骤S2.2.2：InplaceSet控制器监听InplaceSet和Pod资源的变化事件，若是Pod资源，则通过Pod的OwnerReference属性获取到对应的InplaceSet资源，从而触发InplaceSet资源的调解流程；在步骤S2.2.1中，监听到了InplaceSet资源的创建事件，触发InplaceSet资源的调解流程，首先通过副本保持组件完成副本数同步，然后通过原地升级组件，完成原地升级；
[0028]步骤S2.2.3：在步骤S2.2.2中，副本保持组件，通过InplaceSet的标签选择器筛选到对应的Pod列表，然后过滤掉Succeed和Failed的Pod，这两种Pod已完成自己的生命周期，如此得到当前InplaceSet下的Pod列表；得到Pod列表后，和InplaceSet期望的副本数对比，若实际的Pod数小于InplaceSet期望副本数，则需要创建Pod补齐空缺；若实际Pod数大于InplaceSet期望副本数，则需要删除多余的Pod；若实际Pod数等于InplaceSet期望副本数，则无需对Pod进行删除和创建操作；
[0029]步骤S2.2.4：在步骤S2.2.2中，原地升级组件先遍历步骤S2.2.3中获取到的Pod列
表，对Pod原地升级状态进行同步，然后检查升级策略配置spec.updateStrategy.type，若升级策略为InPlaceIfPossible，表示能够进行原地升级，然后检查InplaceSet是否存在原地升级注解cib.inplaceset.io/inplaceset...

【技术保护点】

【技术特征摘要】
1.一种适用金融分布式架构云原生控制器的设计方法，其特征在于，包括：组件CibDeployment和InplaceSet；其中，CibDeployment主要实现分区控制，其下控制多个InplaceSet，每个InplaceSet对应一个分区，同时控制发布策略、故障感知和自动转移；InplaceSet仅实现副本保持和原地升级功能；步骤S1：通过向kubernetes集群提交CibDeployment资源，实现业务部署；步骤S2：由控制器通过监听CibDeployment资源变化事件，触发CibDeployment资源的调解流程，完成业务的部署；步骤S3：在步骤S2完成业务部署后，分区故障检测与调度组件定期对所有分区进行故障检测，一旦检测到某个分区节点全部故障，就将该分区内的副本转移到其他分区中，同时检测已故障的分区是否恢复，如果分区故障恢复，自动还原到无故障时的状态。2.根据权利要求1所述的适用金融分布式架构云原生控制器的设计方法，其特征在于，所述步骤S2包括：步骤S2.1：CibDeployment控制器通过监听CibDeployment或InplaceSet资源的改变事件，触发资源调解流程，进入调解流程后，先通过资源标识获取到资源对象的详细信息；步骤S2.2：通过步骤S2.1得到的CibDeployment资源信息，通过分区部署组件遍历CibDeployment的分区配置spec.regions，调用分区重载组件，完成分区差异化配置，然后调用发布组件，将业务部署到多个分区中，分区配置包括分区名称name、分区副本数replicas、分区标签matchLabels；步骤S2.3：在步骤S2.2中，分区重载组件读取分区重载配置spec.overrides，和通用配置模板spce.template，再通过分区重载策略为各个分区生成各自的差异化配置，然后使用生成的差异化配置创建InplaceSet资源；步骤S2.4在步骤S2.3中，发布组件通过发布策略确定创建InplaceSet时设置的副本数，然后创建InplaceSet资源；步骤S2.5：在步骤S2.4中，根据发布策略，完成第一个批次的发布后，如果分区InplaceSet的副本数还未达到期望的副本数，那么需要对InplaceSet扩容，由分组滚动组件控制，将整个滚动过程分成多个批次进行，并且只有在当前批次完成后，才开始下一个批次的扩容；步骤S2.6：在步骤S2.4中，如果CibDeployment资源设置了等待确认策略spec.strategy.needWaitingForConfirm为true，那么在开启下一个批次的扩容前，还需要人工确认，确认完成后，才开始下一个批次的扩容；步骤S2.7：在步骤2.5中，开启下一个批次的扩容需要等待所有分区都扩容完成，扩容完成即为该分区InplaceSet下的Pod都应该处于available状态；步骤S2.8：在步骤S2.1中，若监听到的CibDeployment资源正在进行升级，若配置升级策略spec.strategy.updateStrategy为InPlaceIfPossible，表示在满足原地升级条件下，就执行原地升级，即Pod不重建，仅替换Pod中的容器，保持Pod的IP、磁盘挂载、网络配置不变。3.根据权利要求2所述的适用金融分布式架构云原生控制器的设计方法，其特征在于，所述步骤S2.2包括：步骤S2.2.1：在步骤S2.2中，为每个分区都创建InplaceSet资源，InplaceSet资源包含
以下重要信息：replicas：期望的pod副本数；minReadySeconds：pod状态变为available前至少在ready状态等待的时间；updateStrategy：设置原地升级策略，包含以下字段：type：值为Roll或者InplaceIfPossible，Roll表示滚动升级，InplaceIfPossible表示如果能原地升级则原地升级，否则不原地升级；gracePeriodSeconds：原地升级之前等待流量切换的时间；template：描述pod的资源对象，是k8s内置的资源对象；步骤S2.2.2：InplaceSet控制器监听InplaceSet和Pod资源的变化事件，若是Pod资源，则通过Pod的OwnerReference属性获取到对应的InplaceSet资源，从而触发InplaceSet资源的调解流程；在步骤S2.2.1中，监听到了InplaceSet资源的创建事件，触发InplaceSet资源的调解流程，首先通过副本保持组件完成副本数同步，然后通过原地升级组件，完成原地升级；步骤S2.2.3：在步骤S2.2.2中，副本保持组件，通过InplaceSet的标签选择器筛选到对应的Pod列表，然后过滤掉Succeed和Failed的Pod，这两种Pod已完成自己的生命周期，得到当前InplaceSet下的Pod列表；得到Pod列表后，和InplaceSet期望的副本数对比，若实际的Pod数小于InplaceSet期望副本数，则需要创建Pod补齐空缺；若实际Pod数大于InplaceSet期望副本数，则需要删除多余的Pod；若实际Pod数等于InplaceSet期望副本数，则无需对Pod进行删除和创建操作；步骤S2.2.4：在步骤S2.2.2中，原地升级组件先遍历步骤S2.2.3中获取到的Pod列表，对Pod原地升级状态进行同步，然后检查升级策略配置spec.updateStrategy.type，若升级策略为InPlaceIfPossible，表示能够进行原地升级，然后检查InplaceSet是否存在原地升级注解cib.inplaceset.io/inplaceset
‑
update
‑
spec，若存在，则表示当前需要进行原地升级；步骤S2.2.5：在步骤S2.2.4中，检测到有原地升级注解的存在，开始执行原地升级流程，遍历步骤S2.2.3得到的Pod列表，根据Pod注解中的原地升级注解，得到三个Pod列表，分别为处于原地升级状态中的Pod列表、已经完成原地升级的Pod列表、还未执行原地升级的Pod列表，然后判断已经完成原地升级和正处于原地升级状态的Pod总数，是否达到期望的原地升级副本数，若未达到，从还未执行原地升级的Pod列表中取出相差数量Pod，然后遍历执行原地升级。4.根据权利要求2所述的适用金融分布式架构云原生控制器的设计方法，其特征在于，所述步骤S2.4创建InplaceSet资源包括：通过获取CibDeployment配置中的发布策略配置spec.strategy.rolloutStrategy，为Beta和Group，分别表示Beta发布和分组发布...

【专利技术属性】
技术研发人员：王浩文，詹赵林，王畅，郭进，孙佳明，王鑫，黄小，刘清，
申请(专利权)人：兴业数字金融服务上海股份有限公司，
类型：发明
国别省市：