一种基于云原生的云边协同数据交换服务实现方法及系统

摘要

本发明公开了一种基于云原生的云边协同数据交换服务实现方法及系统，属于云计算与边缘计算的云边协同技术领域，用Kubernetes扩展技术中的CRD的方式定义云边协同数据交换资源CECO，CECO统一了不同数据类型的云边数据交换，使用者可以用统一的方式通过提交YAML文件声明式的申请各种云边数据交换服务；利用operator模式实现CRD控制器，负责根据CRD CECO的对象期望状态，在云端与边缘端部署容器化的相应数据同步组件，所述CRD控制器可以根据不同类型数据同步需求，自动化部署相应的数据同步组件。本发明既方便用户统一申请和使用云边数据交换服务，又方便云服务商提供和运维云边数据交换服务。

说明书

技术领域

本发明涉及云计算与边缘计算的云边协同技术领域，具体地说是一种基于云原生的云边协同数据交换服务实现方法及系统。

背景技术

云边协同是边缘计算领域的重要组成部分，可分为资源协同、数据协同、服务协同等层次。数据协同是云边协同的基础能力，指数据在边缘与云之间可控有序流动，形成完整的数据流转路径，高效低成本对数据进行生命周期管理。目前在解决云边之间的数据交换的问题时，都是根据不同数据类型独立处理的，且使用方式也不相同，如云边间消息型数据的交换，使用者通常需要通过软件包SDK，以编写代码的方式在云端和边缘端的两个应用中实现消息传递；又如云边间文件型数据的交换，需要在云端和边缘端安装或者部署相应的同步服务组件，才能实现文件同步；流数据交换则更为复杂，需要部署多个组件完成。这种分离的数据交换的实现方式，使得用户使用起来很不方便，代码侵入性高，部署方式复杂且不易维护，弹性伸缩困难，不利于发挥云计算能力，不利于云厂商为用户提供服务。

发明内容

本发明的技术任务是针对以上不足之处，提供一种基于云原生的云边协同数据交换服务实现方法及系统，既方便用户统一申请和使用云边数据交换服务，又方便云服务商提供和运维云边数据交换服务。

本发明解决其技术问题所采用的技术方案是：

一种基于云原生的云边协同数据交换服务实现方法，用云原生标准化的方式统一定义了不同种类的云边数据交换的需求,用Kubernetes扩展技术中的CRD(CustomResource Definition)的方式定义云边协同数据交换资源CECO，CECO统一了不同数据类型的云边数据交换，使用者可以用统一的方式通过提交YAML文件声明式的申请各种云边数据交换服务；

利用operator模式实现CRD控制器ceco controller，负责根据CRD CECO的对象期望状态，在云端与边缘端部署容器化的相应数据同步组件，所述CRD控制器可以根据不同类型数据同步需求，自动化部署相应的数据同步组件，并持续的维护各数据同步组件以达到CECO的对象的期望状态。

本方法使云边数据交换形成一个统一的云原生化的服务，云厂商可以方便的提供云边数据交换服务，用户在申请云边数据交换服务时，只需按照云原生的方式，用Yaml格式声明式的提交服务请求，而不必关心所需数据同步组件的部署细节，可以用统一的方式申请云边消息、云边文件、流数据等各种数据交换服务。这种方法能够充分发挥Kubernetes的容器编排调度能力，非常方便的在大量边缘端(边缘节点)上部署服务，特别适合边缘计算场景，并能充分发挥云计算的弹性伸缩能力，是一个既方便用户使用，又方便云服务商提供和运维云边数据交换服务产品的实现方法。

优选的，所述不同数据类型包括消息协同、文件协同、流数据协同、数据库协同数据类型。

优选的，声明式的数据交换服务的定义方式如下：

通过CRD技术把云边数据交换定义成客户资源，以相同模板形式定义不同的数据交换类型的CRD资源；

创建好定制资源CRD后，将CRD注册到kubernetes系统中，Kubernetes API服务器会为所指定的CRD生成一个RESTful的资源路径，此端点URL可以用来创建和管理定制资源对象，Kubernetes API负责为定制资源提供存储和访问服务。

进一步的，消息协同服务的定义，通过deployType定义部署方式，采用DaemonSet的方式部署消息同步组件到各个节点，便于以订阅-分发的形式，发送和接收消息；通过mqType选择支持数据交换服务的消息队列类型；

文件协同的服务定义，通过deployType定义部署方式，通过Reader定义文件的同步源路径；通过Writer定义文件的同步目的路径；通过dataSliceSize定义采集文件源时的分片大小，通过threadNum定义并发任务数。

使用云原生消息中间件NATS作为传输载体，也可以根据需求使用Kafka，RocketMQ消息中间件。

优选的，所述ceco controller基于kubebuilder框架实现，实现逻辑包括：

1)、ceco controller通过API Server获取云边协同数据交换资源；

2)、将不同种类的数据协同服务请求分发到相应的处理模块，由专用模块完成相应数据交换组件的云原生化部署工作；

3)、对于不同类型数据交换请求通过不同模块进行处理，通过CECO CRD自定义资源和ceco controller资源控制器实现对数据交换服务的统一的云原生形式的访问和使用方式，统一的云原生形式的运维管理方式；

4)、云原生的方式实现配置变更：对数据交换服务的配置变更请求也是通过声明式的Yaml文件方式实现，通过API server对数据交换资源对象的属性进行变更，利用kubebuilder的reflector机制，ceco controller可以获知资源对象的属性变化，然后执行相应的部署变更操作，直到工作负载到达期望的状态；

5)、云原生的方式实现滚动升级：通过ceco controller根据服务版本的变化信息，平稳有序的完成新版本负载(数据交换服务组件)的创建和旧版本负载(数据交换服务组件)的终止，无论是云端节点还是边缘端节点都可以通过ceco controller进行更新升级，实现云边协同的管控。

进一步的，所述对于不同类型数据交换请求通过不同模块进行处理，

对于消息协同类数据交换请求，由MessageSync模块处理，用户申请消息协同类的数据交换服务请求时，对应创建MessageSync资源对象，模块会解析MessageSync资源对象的各个属性值及服务请求的配置，然后根据配置信息自动的通过APIserver完成在相应数据交换组件的部署，具体部署何种形式的工作负载资源由deployType指定，从而实现云原生方式的部署与管控；

文件协同类数据交换请求由FileSync模块处理，可采用相同的方式实现，给使用者统一的访问体验；

流数据类型数据交换请求由StreamSync模块处理，能完成对接RTSP/RTMP协议的数据交换组件的部署需求；

数据库同步类型的服务由DB Sync模块完成必要组件的部署。

优选的，云边协同的消息型数据交换服务，ceco controller根据服务请求采用DaemonSet方式在所有的边缘节点上部署所需的Leaf Node消息组件(NATS消息系统)和消息服务代理组件，Leaf Node消息组件通过云端的ceco controller以DaemonSet的方式在所有边缘节点上部署。ceco controller可以在云上的集群节点部署消息服务相关组件，方便的完成云端分发，海量边缘端订阅的消息型数据交换场景。

优选的，云边协同的文件型数据交换服务，ceco controller通过API server收到FileSync资源对象的变化，由File Sync模块负责在所对应节点上以Deployment方式部署；

在需要发送文件的节点(文件同步源节点)，ceco controller会向指定节点部署文件采集deployment，包括File Sync Agent文件同步服务代理，Split Worker文件切分器，Adapter Shim消息队列适配器，NATS client消息系统客户端；

在需要接收文件的节点(文件同步目的节点)，ceco controller会向指定节点部署文件接收的deployment，包括File Sync Agent文件同步服务代理，Combine Worker文件组合器，Adapter Shim消息队列适配器，NATS client消息系统客户端；

云端ceco controller可以根据当前文件同步deployment的CPU利用率，动态的调整在工作节点的文件同步工作pod的副本数量，当CPU的压力过大时，可以相应增加worker的副本数。

优选的，适配层Adapter Shim，用于适配对接各种消息队列，包括Kafka，RocketMQ消息队列，采用NATS消息系统作为基础消息队列实现云边协同的数据交换；采用StatefulSet形式将NATS部署在Kubernetes集群中。

本方法利用Kubernetes技术的extensions扩展能力，通过自定义资源CRD的方式，定义了一个新的资源组CECO负责描述云边协同的数据交换服务，用CECO将各种需要在云边间传输与同步的数据类型统一起来，在CECO组中，分别定义了消息协同、文件协同、流数据协同、数据库协同等资源类型。实现一个统一的kubernetes控制器ceco controller，通过API server监听各数据交换资源的变化，根据不同的数据交换类型，自动化的部署或调整相应的数据交换组件，以达到资源实例期望的状态，并通过HPA(Horizontal PodAutoscaler)实现对负载实例的弹性伸缩，满足用户对云边数据协同的性能要求。对于消息类型的数据交换服务采用DaemondSet的方式，将数据交换消息组件统一下发到每一个节点中，实现高性能的消息分发；对于文件类型的数据交互服务采用部署Deployment的方式，实现点到点的文件同步能力。

本方法还要求保护一种基于云原生的云边协同数据交换服务系统，用Kubernetes扩展技术中的CRD的方式定义云边协同数据交换资源CECO，CECO统一了不同数据类型的云边数据交换，使用者可以用统一的方式通过提交YAML文件声明式的申请各种云边数据交换服务；

利用operator模式实现CRD控制器，负责根据CRD CECO的对象期望状态，在云端与边缘端部署容器化的相应数据同步组件，所述CRD控制器可以根据不同类型数据同步需求，自动化部署相应的数据同步组件，并持续的维护各数据同步组件以达到CECO的对象的期望状态；

该系统实现上述的基于云原生的云边协同数据交换服务实现方法。

本发明的一种基于云原生的云边协同数据交换服务实现方法及系统与现有技术相比，具有以下有益效果：

本方法及系统从云服务的角度提出了一种以云原生方式实现云边协同数据交换的方法，使云边数据交换成为一个统一的云原生化的服务，用户可以使用相同的方式申请消息传输服务、文件同步、流数据协同、数据库协同等不同数据类型的云边数据交换服务，体验一致，使用方便；

以云服务的形式提供消息传输服务，解决了传统消息队列代码侵入性高，不易运维的问题；以云服务的形式提供文件同步服务或者流数据同步服务，解决了传统数据同步服务部署复杂的问题，用户仅需以Yaml的形式声明式使用数据交换服务，不必关心所需数据同步组件的部署细节，一切的部署问题由云服务厂商负责；

同时这种云原生化的实现方法能够充分发挥Kubernetes的容器编排调度能力，非常方便的在大量边缘端(边缘节点)上部署服务，特别适合边缘计算云边协同场景，并能充分发挥云计算的弹性伸缩能力，使得云服务商能够更方便的向用户提供云边协同的数据交换服务，更高效的负责云边数据交换服务的自动化部署、弹性伸缩、滚动更新、统一运维。

本方法及系统是一个既方便用户，简化了用户的部署和使用方式，又方便云服务商提供和运维统一的云边协同数据交换服务产品的实现方法。

附图说明

图1是本发明实施例提供的实现云管平台高可用的方法中Mariadb主从实现流程图。

具体实施方式

下面结合附图和具体实施例对本发明作进一步说明。

本发明实施例提供了一种基于云原生的云边协同数据交换服务实现方法，用云原生标准化的方式统一定义了不同种类的云边数据交换的需求,用Kubernetes扩展技术中的CRD(Custom Resource Definition)的方式定义云边协同数据交换资源CECO，CECO统一了消息协同、文件协同、流数据协同、数据库协同等不同数据类型的云边数据交换，使用者可以用统一的方式通过提交YAML文件声明式的申请各种云边数据交换服务；像使用云服务一样开发各种基于云边数据交换的应用。

本方法利用operator模式实现CRD控制器ceco controller，负责根据CRD CECO的对象期望状态，在云端与边缘端部署容器化的相应数据同步组件，所述CRD控制器可以根据不同类型数据同步需求，自动化部署相应的数据同步组件，并持续的维护各数据同步组件以达到CECO的对象的期望状态。

支持根据CPU使用率对数据交换服务进行弹性伸缩，支持对数据交换服务进行平滑的升级与变更。

本方法用CRD(Custom Resource Definition)的方式定义了一种云边协同数据交换资源，统一了消息协同、文件协同、流数据协同、数据库协同等不同数据类型的云边数据交换，一个统一的数据交换服务，可以方便用户的使用。利用operator模式实现了CRD控制器ceco controller，统一处理各种数据类型的数据交换服务请求，自动化的部署相应的数据同步组件到对应的集群节点或者边缘节点，简化了用户的各种云边数据交换的部署复杂度，方便云服务商提供统一的数据交换服务。通过利用Kubernetes的DaemondSet,Deployment等多种工作负载资源方式部署容器化的数据采集、数据同步等组件，提供云原生的数据交换服务，使得数据交换服务适应海量边缘节点，云边协同的动态负载均衡，平稳滚动升级等边缘计算场景要求。通过提供部署服务代理agent的方式，将各种数据交换(消息队列，文件协同等)以云原生服务的形式提供给使用者，使用者可以通过REST API的方式，像访问微服务一样，使用消息队列，文件协同等，避免了应用开发的代码侵入问题，也方面了云服务商进行升级和变配。

本方法的具体技术方案详述如下：

一、声明式的数据交换服务的定义：

通过CRD技术把云边数据交换定义成一种客户资源，其中包括消息协同，文件协同，流数据协同等以相同模板形式定义的几个不同的数据交换类型的CRD资源，如附图1中标号①②③所示，它们都属于一个group定义为ceco.io，提供多类型一致的数据交换访问体验，如附图1中标号④所示。

其中消息协同服务请求的定义如下：(只列出主要的数据项定义)

使用者可以通过提交Yaml文件声明式的申请服务，以上是一个消息协同式的数据交换服务。deployType定义了部署方式，方法中采用DaemonSet的方式部署消息同步组件到各个节点，便于以订阅-分发的形式，发送和接收消息。mqType用于选择支持数据交换服务的消息队列类型，本发明中使用云原生消息中间件NATS作为传输载体，也可以根据需求使用Kafka，RocketMQ等消息中间件。

文件协同的服务申请采用同样模板的Yaml CRD方式定义，以达到对不同数据类型一致管理与使用体验，方便用户申请使用不同类型的数据交换服务。

文件协同的服务申请定义如下：(只列出主要的数据项定义)

文件协同的服务定义中，deployType和mqType等数据项的定义都与消息协同一致，Reader用于定义文件的同步源路径，Writer用于定义文件的同步目的路径。dataSliceSize用于定义采集文件源时的分片大小，threadNum用于定义并发任务数。

其他数据协同类型，如流数据或者数据库，都采用相同的模板定义。使得用户可以采用统一的方式申请不同数据类型的云边数据交换服务。

创建好定制资源CRD后，可以将CRD注册到kubernetes系统中，如附图1中标号⑤所示，Kubernetes API服务器会为所指定的CRD生成一个RESTful的资源路径，此端点URL可以用来创建和管理定制资源对象，如：/apis/ceco.io/v1/namespaces/*/messagesyncs；或者/apis/ceco.io/v1/namespaces/*/filesyncs。Kubernetes API负责为定制资源提供存储和访问服务。

二、统一的云边协同数据交换控制器：

云边协同数据交换控制器ceco controller是本方法的整个系统的核心，如附图1中标号⑥所示。根据kubernetes扩展功能的定义，定制资源本身只是用来存取结构化的数据，必须定制控制器(Custom Controller)与定制资源相对应结合后，才能够提供真正的声明式API(Declarative API)去设定资源的期望状态，并尝试让Kubernetes对象的当前状态同步到其期望状态。控制器负责将结构化的数据解释为用户所期望状态的记录，并持续地维护该状态。Kubernetes的Operator模式就是将定制资源与定制控制器相结合的，使得可以使用定制控制器来将特定于某应用的领域知识组织起来，以编码的形式构造对Kubernetes API的扩展。

Kuberbuilder是一个针对kubernetes的Operator模式实现的编程框架，框架中实现了informer，它会借助APIServer跟踪该扩展资源定义的变化，一旦被触发就会调用回调函数，并把变更的具体内容放到Workqueue中，定制控制器controller里面的worker会获取Workqueue里面内容，并进行相应的业务处理。

本方法中的云边协同数据交换控制器ceco controller就是基于kubebuilder框架实现的，主要实现逻辑如下：

1、通过API Server获取云边协同数据交换资源。将步骤(一)中自定义的协同资源CRD注册到kubernetes系统中的etcd后，kube-apiserver会去监督所有etcd中资源的创建、更新与删除，包括自定义资源。ceco controller通过API Server获取MessageSync，FileSync，StreamSync，DBSync等数据交换资源。

2、将不同种类的数据协同服务请求(对应数据交换资源对象的创建、删除、更新变化)分发到相应的处理模块，消息协同模块MessageSync,文件协同模块FileSync,流数据协同模块StreamSync,数据库协同模块DBSync，由这些专用模块完成相应数据交换组件的云原生化部署工作。

3、对于消息协同类数据交换请求，由MessageSync模块处理，如附图1中标号⑦所示。用户申请消息协同类的数据交换服务请求时，对应创建MessageSync资源对象，模块会解析MessageSync资源对象的各个属性值(及服务请求的配置)，然后根据配置信息自动的通过APIserver完成在相应数据交换组件的部署，具体部署何种形式的工作负载资源由deployType指定，从而实现云原生方式的部署与管控。云边消息的数据交换服务的云原生实现在下文步骤(三)中定义。

4、对于文件协同类型的数据交换请求，则可以采用相同的方式实现，给使用者统一的访问体验。文件协同类数据交换请求由FileSync模块处理，如附图1中标号⑧所示。云边文件协同数据交换服务的云原生实现在下文步骤(四)中定义。

5、ceco controller还可以实现其他种类更复杂类型的数据交换服务，如流数据类型StreamSync,能完成对接RTSP/RTMP协议的数据交换组件的部署需求。如数据库同步类型的服务则由DB Sync模块完成对表发现组件等必要组件的部署。通过CECO CRD自定义资源和ceco controller资源控制器实现了对数据交换服务的统一的云原生形式的访问和使用方式，统一的云原生形式的运维管理方式。

6、云原生的方式实现配置变更。对数据交换服务的配置变更请求也是通过声明式的Yaml文件方式实现。通过API server对数据交换资源对象的属性进行变更，利用kubebuilder的reflector机制，ceco controller可以获知资源对象的属性变化，然后执行相应的部署变更操作，直到工作负载到达期望的状态。

7、云原生的方式实现滚动升级。通过本方法可以帮助云服务商实现对数据交换服务的滚动升级。具体也是通过ceco controller根据服务版本的变化信息，平稳有序的完成新版本负载(数据交换服务组件)的创建和旧版本负载(数据交换服务组件)的终止。无论是云端节点还是边缘端节点都可以通过ceco controller进行更新升级，实现云边协同的管控。

三、云边协同的消息型数据交换服务：

云边协同的消息型数据交换服务是一种典型的边缘计算场景的应用。本方法既可以使云服务厂商按照云原生的方式提供云边协同消息服务，方便进行弹性伸缩，滚动升级等运维服务，又可以使用户采用体验一致的声明式方式申请云边消息服务。

在云边协同场景中的消息同步服务要求在边缘节点的消息服务组件具备低延迟性，高安全性，和轻量性。ceco controller根据服务请求采用DaemonSet方式在所有的边缘节点(Edge Node)上部署所需的Leaf Node消息组件(NATS消息系统)和消息服务代理组件，如附图1中标号⑨所示。

本方法在边缘节点上采用Leaf Node消息组件，能够支持桥接安全域从本地客户端透明地路由到一个或多个远程消息系统，使用本地策略对客户端进行身份验证和授权，及低延时响应处理等边缘计算特有的场景需求。Leaf Node消息组件通过云端的cecocontroller以DaemonSet的方式在所有边缘节点上部署。ceco controller可以在云上的集群节点部署消息服务相关组件，方便的完成云端分发，海量边缘端订阅的消息型数据交换场景，如附图1中标号⑩所示。

传统的通常需要通过软件包SDK，以编写代码的方式在云端和边缘端的两个应用中实现消息传递，代码侵入性高，使用不方便，不利于云端运维。本方法中的实现了MessageServer Agent模块，当提交消息协同服务请求时，通过ceco controller向各节点部署，如附图1中标号⑾所示。Message Server Agent模块，以容器的方式实现了消息访问传输的代理，对外提供URL的服务访问接口，应用程序通过REST API使用消息服务，没有代码侵入，可以像使用云原生服务一样的方式进行消息的发送与接收，如附图1中标号⑿所示。既方便用户使用，有方便云端统一运维，如进行消息组件的升级。

四、云边协同的文件型数据交换服务：

文件同步是另一种常用的云边数据交换服务，通过数据交换服务模板，用户可以用与消息服务体验一致的方式申请云边文件同步服务，如CRD FileSync中定义的类型与属性。ceco controller会通过API server收到FileSync资源对象的变化(创建，修改，删除)，由File Sync模块(如附图1中标号⑧所示)负责在所对应节点上以Deployment方式部署。

在需要发送文件的节点(文件同步源节点)，ceco controller会向指定节点部署文件采集deployment，包括File Sync Agent文件同步服务代理，Split Worker文件切分器，Adapter Shim消息队列适配器，NATS client消息系统客户端，如附图1中标号⒀所示。

在需要接收文件的节点(文件同步目的节点)，ceco controller会向指定节点部署文件接收的deployment，包括File Sync Agent文件同步服务代理，Combine Worker文件组合器，Adapter Shim消息队列适配器，NATS client消息系统客户端,如附图1中标号⒁所示。

云端ceco controller可以根据当前文件同步deployment的CPU利用率，动态的调整在工作节点的文件同步工作pod的副本数量，当CPU的压力过大时，可以相应增加worker的副本数。

五、适配层与消息队列系统：

适配层Adapter Shim，如附图1中标号⒂所示，用于适配对接各种消息队列，如第2部分中介绍的Kafka，RocketMQ等消息队列。

本方法中采用NATS消息系统作为基础消息队列实现云边协同的数据交换，NATS是一个开源的、高性能的、简洁的、灵活的，云原生的分布式消息队列系统，非常适合云基础设施的消息通信系统、IoT设备消息通信。本方法的实现中采用StatefulSet形式将NATS部署在Kubernetes集群中，如附图1中标号⒃所示。

边缘计算是指在靠近物或数据源头的一侧，就近提供计算服务。其应用程序在边缘侧发起，产生更快的网络服务响应，满足行业在实时业务、应用智能、安全与隐私保护等方面的基本需求。边缘计算与云计算之间不是替代关系，而是互补协同关系。边缘计算与云计算需要通过紧密协同才能更好的满足各种需求场景的匹配，从而放大边缘计算和云计算的应用价值。边云协同的能力与内涵，涉及IaaS、PaaS、SaaS各层面的全面协同，包括资源协同、数据协同、服务协同等。数据协同是指边缘节点主要负责现场/终端数据的采集，按照规则或数据模型对数据进行初步处理与分析，并将处理结果以及相关数据上传给云端；云端提供海量数据的存储、分析与价值挖掘。边缘与云的数据协同，支持数据在边缘与云之间可控有序流动，形成完整的数据流转路径，高效低成本对数据进行生命周期管理与价值挖掘。如何实现数据在云端与边缘端的传输与同步，如何用云原生服务化的形式实现数据在云端与边缘端的交换是本发明要解决的问题。

消息队列中间件是分布式系统中重要的组件，主要解决应用解耦，异步消息，流量削锋等问题，实现高性能，高可用，可伸缩和最终一致性架构。目前使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ。NATS是一个开源的、高性能的、简洁的分布式的消息队列系统，适合云基础设施的消息通信系统、IoT设备消息通信和微服务架构。

流媒体是指在internet中使用流媒体技术的连续时基媒体，例如视频、音频或多媒体文件。流式传输方式是将音视频、动画等多媒体文件经过压缩后分成一个个小数据包，当用户端发出请求时，由服务器端向用户端实时、连续传送这些小数据包。RTSP是应用级协议，控制实时数据的发送。RTSP提供了一个可扩展框架，使实时数据，如音频与视频的受控点播成为可能。RTMP协议从属于应用层，被设计用来在适合的传输协议(如TCP)上复用和打包多媒体传输流(如音频、视频和互动内容)。

容器是一种轻量级操作系统层面的虚拟机，它为应用软件及其依赖组件提供了一个资源独立的运行环境。应用软件所依赖的组件会被打包成一个可重用的镜像，镜像可以方便的分发到各种运行宿主机上，镜像运行环境可以独立于宿浓度主操作系统，这样应用程序可以以容器的方式在不同计算环境下快速启动运行。

Kubernetes(简称k8s)是一个开源的容器编排和管理引擎，支持大规模容器部署。应用以容器的方式在Kubernetes中运行，可以方便的实现负载均衡，应用软件的版本的滚动升级等需求。它整合了网络，存储，安全性，监控及其他服务，提供全面的容器基础架构。已成为云原生应用的运行环境的编排管理的事实标准。kubernetes集群中的两种管理角色为Master和Node，Master节点负责整个集群的管理和控制，应用容器的调度，node节点负责工作负载以容器的方式运行，node与master间需要保持稳定的网络连接，以汇报node状态。在边缘计算场景中，当node与master不能保持网络连接时，集群无法正常工作。

定制资源(Custom Resource)是对Kubernetes API的扩展,定制资源可以通过动态注册的方式在运行中的集群内或出现或消失，集群管理员可以独立于集群更新定制资源。一旦某定制资源被安装，用户可以使用kubectl来创建和访问其中的对象，就像pod等内置资源所做的一样。通过CustomResourceDefinition API资源定义定制资源。定义CRD对象的操作会使用所设定的名字和模式定义(Schema)创建一个新的定制资源，Kubernetes API负责定制资源提供存储和访问服务。Kubernetes中的很多行为都是通过称为控制器(Controllers)的程序来实现的,控制器常常与自定义资源结合使用,控制器会读取某个资源对象的spec，会执行相应操作，更新资源对象的status。Operator模式就是将定制资源与定制控制器相结合的

使用声明式API，可以声明或者设定资源的期望状态，并尝试让Kubernetes对象的当前状态同步到其期望状态。控制器负责将结构化的数据解释为用户所期望状态的记录，并持续地维护该状态。

本方法解决的主要问题就是如何利用kubernetes技术实现云边协同的数据交换服务，如何提供一种云原生服务的方法实现数据在云端与边缘端的传输与同步，既方便云服务商提供和运维云边数据交换服务，又方便用户申请和使用云边数据交换服务。

本发明实施例还提供了一种基于云原生的云边协同数据交换服务系统，用Kubernetes扩展技术中的CRD的方式定义云边协同数据交换资源CECO，CECO统一了不同数据类型的云边数据交换，使用者可以用统一的方式通过提交YAML文件声明式的申请各种云边数据交换服务；

利用operator模式实现CRD控制器，负责根据CRD CECO的对象期望状态，在云端与边缘端部署容器化的相应数据同步组件，所述CRD控制器可以根据不同类型数据同步需求，自动化部署相应的数据同步组件，并持续的维护各数据同步组件以达到CECO的对象的期望状态；

该系统实现上述实施例中所述的基于云原生的云边协同数据交换服务实现方法。

通过上面具体实施方式，所述技术领域的技术人员可容易的实现本发明。但是应当理解，本发明并不限于上述的具体实施方式。在公开的实施方式的基础上，所述技术领域的技术人员可任意组合不同的技术特征，从而实现不同的技术方案。

除说明书所述的技术特征外，均为本专业技术人员的已知技术。