CN115941320A - 一种Kubernetes集群拟态防护方法和系统 - Google Patents

Abstract

本发明公开一种Kubernetes集群拟态防护方法和系统，方法包括：构建基于拟态防御技术的Kubernetes集群防护系统，系统包括：动态异构冗余执行体单元，其支持服务Service的所有容器集Pod的集合，集合中所有容器集Pod的标签一致且是异构和冗余的；动态异构执行体选择器单元，其用于生成异构冗余执行体；动态控制器单元，其用于实现异构冗余执行体的更新与发布；设置更新与发布参数，通过更新与发布参数以及基于拟态防御技术的Kubernetes集群防护系统实现应用发布。利用本发明的方法和系统，动态异构冗余执行体可以在时间和空间两个维度上实现结构上的相异性和冗余性的改变，包括对未知漏洞、后门等的改变，最大程度降低攻击者经验的可复现性和传播价值。

Description

一种Kubernetes集群拟态防护方法和系统

5技术领域

本发明涉及一种Kubernetes集群拟态防护方法和系统。

背景技术

拟态防御的工作原理是：一个功能等价的异构执行体的集合F，0在t1时刻随机从F中选取k个执行体提供带有裁决机制的输入输出服务，在t2时刻作类似动作，在后续的时刻依次类推。在功能等价条件下，动态异构冗余构造的防御界内，在时空维度上具有多维动态重构机制，未知漏洞后门或者病毒木马及攻击链会随着防御场景作不确定性的改变。图1示出拟态防御的核心框架，即动态异构冗余架构5(Dynamic Heterogeneous Redundancy，DHR)。

为便于理解本架构的工作原理与机制，在此以熟知的银行信贷系统来作类比，将动态异构冗余的思想与信贷业务做结合，通过建立

“拟态银行信贷系统”模型来了解拟态防御技术是如何实现“动态、异构、冗余”的机制。

0客户小明想要向银行申请贷款，需要经历贷款申请、受理调查、风险评估、贷款审批、合同签订、贷款发放的环节。

图2示出该贷款审批过程。在我们构造的“拟态银行信贷系统”

中，小明提交了贷款申请之后，一线人员会将贷款申请同时交给三个客户经理进行尽职调查，三个人的调查结果会同时交给业务管理部进5行风险评估。假如客户经理3业务不熟练，在调查过程中没有发现小明的材料有问题，客户经理1和客户经理2分别发现了问题，业务管理部会将三者的调查结果做比对进行风险评估。进一步地，根据风险评估的结果认定小明不符合贷款条件，信贷委员会不予审批。

与此同时，银行主管也得到了这个裁定结果，认为客户经理30有业务能力漏洞。接下来银行主管会责令他下岗重新培训，其位置由作为备份的客户经理M替代。

最终，一线人员会告知小明，其材料没有经过审批，无法贷款。

在图2所示模型中，一线人员对应DHR架构中的输入/输出代理，主要与外部做交互；三个不同的客户经理对应的是DHR架构中的异构执行体，是业务系统的核心处理模块；业务管理部和信贷委员会对应DHR架构中的多模裁决模块，用作处理结果的裁决；银行主管对应DHR架构中的负反馈控制器，用来对异构执行体，即客户经理进行上下线“清洗”，即业务培训调度。

其中，设置三个不同的客户经理同时处理一个业务，这体现了拟态防御中的异构与冗余思想。异构化要求功能等价，例如处理同一业务，但执行条件不同，例如人员自身的背景不同，但是由于人自身可能存在业务不精、工作时粗心马虎的情况，同一个业务被三个人同时处理可能有不同的结果，系统基于此来感知威胁，即风险。例如，本案例中小明材料造假，但是客户经理3没有审查出来，其实类似于网络安全中的漏洞利用攻击。客户经理3的业务不精即系统漏洞，没有审查出材料问题即漏洞被利用成功。

另外，银行主管在接收到裁决，即风险评估结果之后，会动态地调整客户经理3的岗位，这体现了拟态防御具备动态收敛的特性，确保系统安全性不随着时间的推移而降低。

因此，拟态防御的核心其实是一种闭环的安全框架，通过重构目标系统，实现从系统结构上确保业务处理安全的机制。

下面将描述Kubernetes Service服务与发布。首先描述Kubernetes Service与Pod。

Kubernetes通过服务Service的形式向外部提供服务，当客户端Client连接到Kubernetes的Service时，该连接被转发到支持该服务的容器集Pod上。由于Pod是有生命周期的，可以被创建，也可以被销毁，且Pod在创建时，它的IP地址也是不稳定的。Service的作用就在于通过标签来映射到对应的Pod上，这样客户端就可以通过Service提供的统一的入口地址，来访问后端具有相同标签的Pod，Service通过选择器selector参数来筛选拥有对应标签的Pod。

图3示出Service通过标签选择器将流量转发到对应的Pod上的示意图。如图3所示，若干个Pod上都被标识了不同的标签。此处用正方形和三角形代替。例如，带有正方形标签的Pod数量为5个，带有三角形标签的Pod数量为1个。当然，这里的数量是示例性的，带有正方形标签和三角形标签的Pod可以为任意数量。

如图3所示，Service标签选择器所选择的标签为正方形，所以Client访问流量最终转发到5个带有正方形标签的Pod上。

我们可以将Pod看成能够提供服务的独立计算单元，它具有如下的特点：

1)每个Pod都拥有自己的IP地址；

2)在Pod中的所有容器共享相同的IP地址，彼此之间可以自由通信；

3)一个Pod可以通过IP地址与集群内部的其他所有的Pod进行通信，而不需要NAT转换。

接下来描述Kubernetes Deployment，即部署。

容器的状态是不稳定的，并且容器的生命周期通常比较短暂，所以Kubernetes在编排容器的过程中常常不直接使用Pod，而是使用其他功能更加强大的组件。我们以最为常见的两类功能组件Replication Controller，即RC和Deployment为例，来介绍他们的使用方法。RC和Deployment主要是为了解决以下问题而存在的：

1)RC定义了一个期望的场景，及某种Pod的副本数量replicas在任意时刻都符合某个预期值；

2)Deployment是RC的升级，Deployment除了能够实现RC功能以外，还包括对Pod进行更新、回滚等操作。

图4示出Service、Pod、ReplicaSet、Deployment之间的关系图。如图4所示，标签选择器Selector所选择的标签为正方形，ReplicaSet通过标签选择器Selector，控制带有该标签的Pod的副本数量为5。当然，这里的数量是示例性的，带有正方形标签的Pod可以为任意数量。Deployment对Pod进行更新、回滚等操作。

通过上面的介绍，我们就可以通过Deployment来实现多种方式的发布，在此，我们介绍一种常用的滚动部署。应用的新版本逐步替换旧版本。实际的部署发生在一段时间内。在此期间，新旧版本会共存，而不会影响功能和用户体验。这个过程可以更轻易的回滚与旧组件不兼容的任何新组件。

图5示出Deployment滚动更新发布的示意图。如图5所示，提供服务的Pod副本数为3，通过滚动部署的更新，服务逐步由V1.0版本升级到V2.0版本。具体地说，在阶段1，V1.0的Pod数量为3个；在阶段2，V1.0的Pod数量为2个，V2.0的Pod数量为1个；在阶段3，V1.0的Pod数量为1个，V2.0的Pod数量为2个；在阶段4，V2.0的Pod数量为3个。在更新过程中，服务保持持续不中断。当然，这里的数量是示例性的。

除了滚动发布以外，常用于Deployment的发布方式还包括：蓝绿部署和金丝雀部署。蓝绿部署指的是，应用的新版本部署在绿色版本环境中，进行功能和性能测试。一旦测试通过，应用的流量从蓝色版本路由到绿色版本。然后绿色版本变成新的生产环境。在这个方法中，两个相同的生产环境并行工作。

金丝雀部署指的是，首先在生产环境的基础设施中小范围的部署新的应用代码。一旦应用签署发布，只有少数用户被路由到它。最大限度的降低影响。如果没有错误发生，新版本可以逐渐推广到整个基础设施。

接下来描述容器行为建模与异常行为检测。

将通过图6来简要介绍容器行为建模与异常行为检测的工作原理。

在测试环境下，用户可以保证容器没有被攻击，即容器内部的应用程序行为是正常的。在测试环境下收集容器行为信息，并基于该信息创建容器行为模型。

在生产环境下，容器中的程序行为是未知的，有可能受到攻击，此时记录生产环境下的容器行为，并将该行为与容器的行为模型进行对比，判断其行为是否是异常行为。如果该异常行为属于误判，则需要修改完善行为模型。如果异常行为不是误判，我们就可以认为容器遭受到了攻击，由此产生告警，并通知运维人员进行处理。

发明内容

借助于容器轻量化、易于移植、弹性伸缩等特点，容器集群编排工具Kubernetes能够更加系统的编排和发布容器，同时支持一键化的滚动部署以及回滚操作。从提供容器编排服务的角度来看，Kubernetes是一个非常好工具。

但是缺点是，Kubernete在提供容器编排服务的同时，并未考虑容器的安全服务，对于容器运行过程中存在的安全风险，例如特权容器、容器逃逸、反弹shell操作、暴力破解等安全风险无能为力。

就现有的容器异常行为检测技术而言，一方面是容器行为模型学习不够准确，需要大量的学习数据才能够建立容器模型，且模型不一定是十分准确的，在异常行为检测时可能会出现误判的情况。另一方面，当产生异常行为结果的时候，需要有丰富运维经验的工程师来人为处理告警，无法进行有效的自动化处理。

针对上述问题，本发明提出一种主动发布式的Kubernetes集群拟态防护方法，这是一种利用系统自身架构进行防御的安全解决方案，不需要额外的资源消耗就可以实现的内生安全机制。

一种Kubernetes集群拟态防护方法，所述方法包括：

构建基于拟态防御技术的Kubernetes集群防护系统，所述系统包括：动态异构冗余执行体单元、动态异构执行体选择器单元和动态控制器单元，其中，所述动态异构冗余执行体单元支持服务Service的所有容器集Pod的集合，所述集合中所有容器集Pod的标签一致且是异构和冗余的，所述动态异构执行体选择器单元用于生成异构冗余执行体，所述动态控制器单元用于实现所述异构冗余执行体的更新与发布；

设置更新与发布参数，通过所述更新与发布参数以及所述基于拟态防御技术的Kubernetes集群防护系统实现应用发布。

在所述方法中，所述更新与发布参数可以包括异构体个数、更新周期、同构体副本数和更新方式。

在所述方法中，所述异构冗余执行体内部的容器集Pod可以是按照规律动态变化的，所述动态控制器单元通过包括更新周期和动态发布算法在内的参数来设定所述规律。

在所述方法中，应用发布的方式可以是滚动部署、蓝绿部署或金丝雀部署。

一种Kubernetes集群拟态防护系统，所述系统包括：

动态异构冗余执行体单元，其支持服务Service的所有容器集Pod的集合，所述集合中所有容器集Pod的标签一致且是异构和冗余的；

动态异构执行体选择器单元，其用于生成异构冗余执行体；以及

动态控制器单元，其用于实现所述异构冗余执行体的更新与发布；

所述系统设置更新与发布参数，通过所述更新与发布参数以及基于拟态防御技术的Kubernetes集群防护系统实现应用发布。

在所述系统中，所述更新与发布参数可以包括异构体个数、更新周期、同构体副本数和更新方式。

在所述系统中，所述异构冗余执行体内部的容器集Pod可以是按照规律动态变化的，所述动态控制器单元通过包括更新周期和动态发布算法在内的参数来设定所述规律。

在所述系统中，应用发布的方式可以是滚动部署、蓝绿部署或金丝雀部署。

利用本发明的方法，动态异构冗余执行体可以在时间和空间两个维度上实现结构上的相异性和冗余性的改变，包括对未知漏洞、后门等的改变，最大程度降低攻击者经验的可复现性和传播价值。这样，将攻击难度提升了三个层次，即从基于静态空间的单一确定目标攻击难度，增强为静态异构空间的多目标协同一致攻击难度，再增强为“动态异构空间、多元目标协同一致攻击”难度，难度等级呈非线性提升，即使攻击成功，也只是一次的，攻击成功的经验无法继承和复制。

此外，本发明相比于现有技术还具有如下优点。

1)现有Service-Pod架构采用同构的容器集Pod集合来实现服务Service功能。而本发明的容器集Pod集合为异构执行体，且异构体的数量是可以选择设定的。

2)异构体容器集Pod集合是主动更新的，动态更新周期T可以自由设定，同构的容器集Pod副本数也是可以自由设定的。

3)本发明安全防御能力是基于Kubernetes自身架构的，不需要额外引入安全能力，是一种内生的安全。

4)防御过程可以做到完全的自动化，设定好相关参数后，系统就可以实现自动的防御，不需要人为的参与。

附图说明

下面将参考附图描述本发明的具体实施方式，这些实施方式是示例性的，而非限制性的。

图1示出动态异构冗余架构图，即DHR图；

图2示出拟态银行信贷系统的流程图；

图3示出Service通过标签选择器将流量转发到对应的Pod上的示意图；

图4示出Service、Pod、ReplicaSet、Deployment之间的关系图；

图5示出Deployment滚动更新发布的示意图；

图6示出容器行为建模与异常行为检测的原理图；

图7示出根据本发明实施例构造的基于拟态防御技术的Kubernetes集群防护架构图；

图8示出现有Kubernete部署下的Pod分布的过程图；

图9示出根据本发明实施例构造的主动发布式的Kubernetes集群拟态防护方法下的Pod分布的过程图；

图10示出根据本发明实施例的方法的流程图；

图11示出蓝绿部署的示意图；以及

图12示出金丝雀部署的示意图。

具体实施方式

本发明基于拟态防御技术特点，利用Kubernetes易于部署容器服务的特点，设计了一套Kubernetes集群服务的防护方法。

图7示出了根据本发明实施例构造的基于拟态防御技术的Kubernetes集群防护架构图。

在该基于拟态防御技术的Kubernetes集群防护方法和系统中，主要包括有三个模块单元，分别是动态异构冗余执行体单元1、动态异构执行体选择器单元2和动态控制器单元3。下面分别阐述各部分的作用。

1、动态异构冗余执行体单元1

该单元是支持服务Service的所有Pod的集合，该Pod集合有4个特点。

特点1)所有Pod的标签是一致的，这样服务Service的流量可以转发到任一Pod上，这个特点和Kubernetes集群中Pod的特点是一致的。

特点2)Pod是异构的，Pod彼此之间的架构、组件是不尽相同的，但是完全能够提供相同的服务。例如Pod 1是基于CentOS系统提供的Web服务，而Pod 2是基于Ubuntu系统提供的Web服务，虽然他们的操作系统是不一致的，但是他们提供的服务是一致的。

特点3)Pod是冗余的，它包括同构Pod的冗余和异构Pod的冗余。异构冗余特点保证了执行体整体的安全性最大化，因为执行体异构的特点，导致不同执行体之间存在相同漏洞的可能性很低，所以同一类型的攻击是很难攻破所有的异构体的。

特点4)执行体内部的Pod是按照一定规律动态变化的，动态变化规律由动态控制器单元进行设定，包括更新周期、动态发布算法等。2、动态异构执行体选择器单元2

该单元主要功能是生成异构冗余执行体，其中可以通过设定异构体的数量参数来选择生成异构体的种类。通过同构体副本数，可以设定同一结构体Pod的副本数。

3、动态控制器单元3

该单元主要功能是通过不同的更新方式来实现异构体的更新与发布。动态控制器单元最重要的两个参数是更新周期和动态发布算法。可以选择上文中所描述的滚动部署、蓝绿部署、金丝雀部署等算法来进行发布。更新周期指的是相邻两次发布之间的时间间隔，通过设定异构体的更新方式和更新周期，可以保证异构执行体在时空维度上是多维变化的，使系统可能存在的未知漏洞后门或者病毒木马及攻击链会随着时间不断重构。

下面将通过一个例子来对比形象的展示本发明的方法在抵御攻击的特性。假设一个服务Service下，通过标签选择器筛选的Pod副本数为6，并且假设在该架构下的Pod存在一类可以被黑客利用的漏洞。现有Kubernete下的Pod变化如图8所示。根据本发明实施例构造的主动发布式的Kubernetes集群拟态防护方法下的Pod分布如图9所示，其中相同图案的圆圈表示同构Pod，不同图案的圆圈表示异构Pod。当采用本发明的主动发布式的Kubernetes集群拟态防护方法时，异构体个数为3，同构体副本数为2，更新周期为T，更新方式为滚动发布。

在图8中，所有的Pod是同构的，所以虽然系统可能会有滚动更新，但是其漏洞信息保持一致，这样在遭受到黑客攻击的过程中，攻击者对于漏洞的学习利用是可以继承，当黑客发现了该漏洞之后，就可以利用漏洞去攻击任意一个Pod。尽管随着新发布的产生，沦陷的Pod会被新的Pod所取代，但是这并不影响攻击者持续利用该漏洞去攻击新的Pod。

在图9中，存在同构的Pod和异构的Pod，我们设定了更新周期T，采用的是滚动更新的方式进行发布，异构体个数是3，同构体的副本数是2。我们可以从图中看出，Pod 1-1从阶段1到阶段2状态没有发生变化，到阶段3时更新为异构体。针对单个Pod来说，当它的副本数为2时，它更新为异构体的周期为2T。在这个2T周期内，虽然攻击者可能利用已知漏洞来完成对Pod的攻击，但在这个周期结束之后，随着被攻击的Pod的消亡，取而代之的是其他的异构Pod，针对原来Pod的漏洞学习知识，无法用来攻击新的异构Pod，所以攻击是不可持续的。除此之外，在主动发布式的Kubernetes集群拟态防护方法下，异构体越多，更新周期越小，给攻击者带来的难5度就会越大。

通过上述的举例，假设一个服务Service下，通过标签选择器筛选所有Pod，采用本发明提出的防御方法，更新周期为T，异构体个数为k，同构体副本数为n，采用滚动更新的方式进行发布，则可以计算出：

0 1)Pod更新为异构体的最大时间为nT；

2)一个Pod在t时刻与t+knT时刻是同构体；

3)攻击者对于该Pod集合攻击的难度与k/nT成正比，即异构体个数k越多，攻击难度越大，滚动更新T越小，攻击难度越大，同构体副本数n越小，攻击难度越大。

5图10示出根据本发明实施例的方法的流程图，该方法包括如下步骤：

S1：构建基于拟态防御技术的Kubernetes集群防护系统，系统包括：动态异构冗余执行体单元、动态异构执行体选择器单元和动态控制器单元，其中，动态异构冗余执行体单元支持服务Service的所0有Pod的集合，集合中所有Pod的标签一致且是异构和冗余的，动态异构执行体选择器单元用于生成异构冗余执行体，动态控制器单元用于实现异构冗余执行体的更新与发布。

对于动态异构冗余执行体单元、动态异构执行体选择器单元和动态控制器单元，可以参考上面结合图7所作的详细描述。此外，上5文对于动态异构冗余执行体单元、动态异构执行体选择器单元和动态控制器单元的描述是示例性的，而非限制性的，本领域技术人员可以想到其它变形或等同实施方式。

本发明通过动态异构冗余体执行单元，可以在时间和空间两个维度上实现结构上的相异性和冗余性的改变，包括对未知漏洞、后门0等的改变，最大程度降低攻击者经验的可复现性和传播价值。将攻击难度提升了三个层次，即从基于静态空间的单一确定目标攻击难度，增强为静态异构空间的多目标协同一致攻击难度，再增强为“动态异构空间，多元目标协同一致攻击”难度，难度等级呈非线性提升，即使攻击成功，也只是一次的，攻击成功的经验无法继承和复制。

S2：设置更新与发布参数，通过更新与发布参数以及基于拟态防御技术的Kubernetes集群防护系统实现应用发布。

通过该方式，本发明的安全防御能力是基于Kubernetes自身架构的，不需要额外引入安全能力，是一种内生的安全。此外，防御过程可以做到完全的自动化，设定好相关参数后，系统就可以实现自动的防御，不需要人为的参与。

Pod从一个结构到另一个结构的更新方式可以是滚动更新发布，除此之外，也可以采用蓝绿部署和金丝雀部署方式。

1.蓝绿部署

图11示出蓝绿部署的示意图。

应用的新版本部署在绿色版本环境中，进行功能和性能测试。一旦测试通过，应用的流量从蓝色版本路由到绿色版本。然后绿色版本变成新的生产环境。在这个方法中，两个相同的生产环境并行工作。

在图11中，代码版本1代表蓝色版本，代码版本2代表绿色版本。

2.金丝雀部署

图12示出金丝雀部署的示意图。

采用金丝雀部署，你可以在生产环境的基础设施中小范围的部署新的应用代码。一旦应用签署发布，只有少数用户被路由到它。最大限度的降低影响。如果没有错误发生，新版本可以逐渐推广到整个基础设施。以前旷工开矿下矿洞前，先会放一只金丝雀进去探是否有有毒气体，看金丝雀能否活下来，金丝雀发布由此得名。

在图12中，代码版本1代表蓝色版本，代码版本2代表绿色版本。初始只有少数用户被路由至代码版本2，然后推广至全部设施。

金丝雀部署包括将生产流量从版本A逐渐转移到版本B。通常，流量是根据权重分配的。例如，90％的请求发送到版本A，10％的请求发送到版本B。

无论是滚动更新发布，还是蓝绿部署和金丝雀部署，他们都是一种主动式的发布，不需要感知外部状态，系统通过主动更新Pod来达到内容结构的目的，增加系统被攻破的难度。

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (8)

1.一种Kubernetes集群拟态防护方法，所述方法包括：

构建基于拟态防御技术的Kubernetes集群防护系统，所述系统包括：动态异构冗余执行体单元、动态异构执行体选择器单元和动态控制器单元，其中，所述动态异构冗余执行体单元支持服务Service的所有容器集Pod的集合，所述集合中所有容器集Pod的标签一致且是异构和冗余的，所述动态异构执行体选择器单元用于生成异构冗余执行体，所述动态控制器单元用于实现所述异构冗余执行体的更新与发布；

设置更新与发布参数，通过所述更新与发布参数以及所述基于拟态防御技术的Kubernetes集群防护系统实现应用发布。

2.根据权利要求1所述的方法，其中，

所述更新与发布参数包括异构体个数、更新周期、同构体副本数和更新方式。

3.根据权利要求1或2所述的方法，其中，

所述异构冗余执行体内部的容器集Pod是按照规律动态变化的，所述动态控制器单元通过包括更新周期和动态发布算法在内的参数来设定所述规律。

4.根据权利要求3所述的方法，其中，

应用发布的方式是滚动部署、蓝绿部署或金丝雀部署。

5.一种Kubernetes集群拟态防护系统，所述系统包括：

动态异构冗余执行体单元，其支持服务Service的所有容器集Pod的集合，所述集合中所有容器集Pod的标签一致且是异构和冗余的；

动态异构执行体选择器单元，其用于生成异构冗余执行体；以及

动态控制器单元，其用于实现所述异构冗余执行体的更新与发布；

所述系统设置更新与发布参数，通过所述更新与发布参数以及基于拟态防御技术的Kubernetes集群防护系统实现应用发布。

6.根据权利要求5所述的系统，其中，

所述更新与发布参数包括异构体个数、更新周期、同构体副本数和更新方式。

7.根据权利要求5或6所述的系统，其中，

所述异构冗余执行体内部的容器集Pod是按照规律动态变化的，所述动态控制器单元通过包括更新周期和动态发布算法在内的参数来设定所述规律。

8.根据权利要求7所述的系统，其中，

应用发布的方式是滚动部署、蓝绿部署或金丝雀部署。

Images