CN115065729B - 一种基于Kubernetes的边缘应用沙盒移植方法 - Google Patents

Abstract

本发明提供了一种基于Kubernetes的边缘应用沙盒移植方法，涉及互联网技术领域；该方法包括以下的步骤：S10、对边缘服务器进行配置后，外部沙盒请求转发至沙盒内的nginx服务器；S20、nginx服务器对请求进行识别；S30、应用网关gateway对请求的处理，应用网关gateway根据自身的路由配置，按照各应用的路径前缀，将请求转发至对应的边缘应用；S40、当边缘应用需要下载资源时，调用下载器downloader的接口，使用其下载能力；当边缘应用需要获取底层信息时，则调用通用支撑服务端common的接口；S50、下载器downloader将下载后的资源保存到对应边缘应用的volume中；本发明的有益效果是：有效避免配置界面随应用的迭代而进行变更，能够支持所见即所得的展示要求。

Description

一种基于Kubernetes的边缘应用沙盒移植方法

技术领域

本发明涉及互联网技术领域，更具体的说，本发明涉及一种基于Kubernetes的边缘应用沙盒移植方法。

背景技术

与传统流媒体平台不同，现有的边缘网关娱乐系统(以IFE即“机上娱乐系统”为例)是一个分布式系统(C端用户不能直接访问中心端)，对C端用户展示的娱乐内容需要从中心端分发到边缘端。

每个边缘网关娱乐系统作为server对C端用户(比如乘客)进行娱乐内容的服务(比如电影、音乐、电子书等)。随之而来的刚性需求就是运营人员需要在中心端快速高效的对配置的娱乐信息进行查看。

传统的方式是，在中心的配置端，制作一个与边缘界面相同的孪生界面(即所见即所得)。这种方案直接导致配置界面与边缘服务界面高度耦合，机上娱乐系统需要改版时，中心端的配置界面也要随之改变，成本极高，无法满足现今“版本快速迭代”的要求。另一种方案是在中心端运行一个边缘的实例，进行观看。此种方案，一方面配置界面单调，配置人员需要“脑补”配置后的样子，另外一方面，中心端的同步并不是“所见即所得”，效率低下。两种传统方案，要么开发成本高昂，要么用户体验很差，需要有创新的方案进行优化。

发明内容

为了克服现有技术的不足，本发明提供一种基于Kubernetes的边缘应用沙盒移植方法。

本发明解决其技术问题所采用的技术方案是：一种基于Kubernetes的边缘应用沙盒移植方法，其改进之处在于，该方法包括以下的步骤：

S10、对边缘服务器进行配置后，外部沙盒请求转发至沙盒内的nginx服务器；

S20、nginx服务器对请求进行识别，当属于静态资源类请求时，nginx服务器负责在对应的volume中查找资源；当属于非静态资源类请求时，则统一转发至应用网关gateway处理；

S30、应用网关gateway对请求的处理，应用网关gateway根据自身的路由配置，按照各应用的路径前缀，将请求转发至对应的边缘应用；

S40、当边缘应用需要下载资源时，调用下载器downloader的接口，使用其下载能力；当边缘应用需要获取底层信息时，则调用通用支撑服务端common的接口；

S50、下载器downloader将下载后的资源保存到对应边缘应用的volume中。

进一步的，步骤S10中，当对边缘服务器的配置由多人同时进行时，为每个操作者分配一个KubernetesPOD；

外部沙盒请求由ingress按照路径前缀转发的方式转入对应沙盒的KubernetesService，Kubernetes Service按照端口转发的方式转发给沙盒内的nginx服务器。

进一步的，所述步骤S10之前，还包括对沙盒进行创建的过程，包括以下步骤：

S101、根据运营人员提供的边缘应用配置信息生成相应的KubernetesConfigMap，将沙盒内基础服务和边缘应用作为整体生成Kubernetes POD的资源描述文件，并将生成的Kubernetes ConfigMap通过文件挂载的方式，挂载入POD中各边缘应用的对应目录，各个边缘应用根据自身的配置来提供服务；

S102、为每个沙盒的POD生成Kubernetes Service，该Kubernetes Service的端口转发目标为该沙盒内nginx服务器的工作端口；

S103、为每个沙盒生成Kubernetes Volume，用于存放边缘应用的资源文件；将整个沙盒Volume的各个子目录分别挂载入各个边缘应用的资源目录，并将整个volume挂载到nginx服务器的数据目录；

S104、根据POD描述文件中的特定信息，建立运营人员与沙盒的对应关系。

进一步的，步骤S104中，将运营人员id存入POD的annotation，以根据运营人员ID查找到指定的沙盒；

该步骤中，利用运营人员与沙盒的对应关系，使用Kubernetes的API对相关的POD进行删除。

进一步的，步骤S104之后还具有以下步骤：

S105、当更新沙盒失败时，捕捉对应的异常，在删除POD后重新提交POD的描述文件。

进一步的，对沙盒进行创建后，还包括以下步骤：

向Ingress中增加对应沙盒服务的路由信息，由Ingress按照前缀匹配的方式完成对沙盒请求的转发；

Ingress对沙盒内边缘应用的前端页面跳转进行处理，根据请求发起时所在的页面强制对资源和API请求重定向，使得边缘应用前端页面不感知沙盒环境的url变化。

进一步的，步骤S20中，nginx服务器绑定整个沙盒volume，能够访问所有应用的资源目录。

进一步的，步骤S30中，应用网关gateway按照各应用的alias组成的路径前缀，将请求转发至对应的边缘应用；

当请求url中不包括alias，则根据http请求头中reference字段的路径前缀来进行转发。

进一步的，步骤S50中，每个边缘应用只绑定沙盒volume的一个子目录，边缘应用只能访问属于其自身的目录。

进一步的，步骤S40中，所述通用支撑服务端common为沙盒内运行的边缘应用提供基础的能力支撑，通用支撑服务端common感知自身运行在沙盒中，通过模拟底层数据，使边缘应用对是否运行在沙盒内无感；

所述common通用支撑服务端会感知应用配置变化，适时触发应用的配置重载接口，使边缘应用有机会完成配置的更新。

本发明的有益效果是：将边缘端应用置于以Kubernetes的POD为边界的沙盒中，可以有效避免配置界面随应用的迭代而进行变更，能够支持所见即所得的展示要求，在降低开发成本的同时保持了较高的用户体验。

附图说明

图1为本发明的一种基于Kubernetes的边缘应用沙盒移植方法的运行环境示意图。图2为本发明的一种基于Kubernetes的边缘应用沙盒移植方法中沙盒创建及更新流程的示意图。

具体实施方式

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

以下将结合实施例和附图对本发明的构思、具体结构及产生的技术效果进行清楚、完整地描述，以充分地理解本发明的目的、特征和效果。显然，所描述的实施例只是本发明的一部分实施例，而不是全部实施例，基于本发明的实施例，本领域的技术人员在不付出创造性劳动的前提下所获得的其他实施例，均属于本发明保护的范围。另外，专利中涉及到的所有联接/连接关系，并非单指构件直接相接，而是指可根据具体实施情况，通过添加或减少联接辅件，来组成更优的联接结构。本发明创造中的各个技术特征，在不互相矛盾冲突的前提下可以交互组合。

本发明揭示了一种基于Kubernetes的边缘应用沙盒移植方法，该方法将边缘端应用置于以Kubernetes的POD为边界的沙盒中，可以有效避免配置界面随应用的迭代而进行变更，能够支持所见即所得的展示要求，在降低开发成本的同时保持了较高的用户体验。

具体的，参照图1所示，为边缘应用在边缘服务器的运行环境示意图；用户通过浏览器访问边缘服务器内的nginx服务器，nginx服务器将请求转发给应用网关gateway，应用网关gateway再按照路径匹配的方式将请求转发给特定的边缘应用；下载器downloader响应边缘应用的资源下载需求，将资源由中心端拉取到边缘本地磁盘；通用支撑服务端common向边缘应用提供业务接口，并与中心端通过MQTT协议进行通讯；所有的边缘应用都是以docker镜像的方式运行并提供服务。

沙盒环境需要保证边缘服务在不经过任何修改的情况下，能够运行在中心端的系统中，即沙盒之所以称之为沙盒，就是将原本运行在边缘的服务移植到沙盒中，而边缘服务而不自知。中心端需要能够支持不同的运营人员对多个沙盒的独立控制，结合边缘应用的docker镜像分发方式，顺理成章地采用了Kubernetes作为沙盒环境的调度编排框架。使用Kubernetes而不是直接使用原生docker来实现沙盒，一方面增加了配置的便利性，另一方面提高了服务端的服务器使用效率，可以节省更多的服务器资源。

本实施例中，对于所述的一种基于Kubernetes的边缘应用沙盒移植方法，包括步骤S10-S50：

S10、对边缘服务器进行配置后，外部沙盒请求转发至沙盒内的nginx服务器；

步骤S10中，当对边缘服务器的配置由多人同时进行时，为每个操作者分配一个KubernetesPOD；

外部沙盒请求由ingress按照路径前缀转发的方式转入对应沙盒的KubernetesService，KubernetesService按照端口转发的方式转发给沙盒内的nginx服务器；该转发步骤是为了在中心端区分可能同时存在的多个沙盒同时访问，边缘端不会有该转发步骤。

S20、nginx服务器对请求进行识别，当属于静态资源类请求时，nginx服务器负责在对应的volume中查找资源，nginx服务器绑定整个沙盒volume，能够访问所有应用的资源目录；当属于非静态资源类请求时，则统一转发至应用网关gateway处理；nginx服务器的转发逻辑在沙盒和边缘环境完全相同；

S30、应用网关gateway对请求的处理，应用网关gateway根据自身的路由配置，按照各应用的路径前缀，将请求转发至对应的边缘应用；应用网关gateway的转发逻辑在沙盒和边缘环境完全相同；

步骤S30中，应用网关gateway按照各应用的alias组成的路径前缀，将请求转发至对应的边缘应用；当请求url中不包括alias，则根据http请求头中reference字段的路径前缀来进行转发。

S40、当边缘应用需要下载资源时，调用下载器downloader的接口，使用其下载能力；当边缘应用需要获取底层信息时，则调用通用支撑服务端common的接口；

步骤S40中，所述通用支撑服务端common为沙盒内运行的边缘应用提供基础的能力支撑，通用支撑服务端common感知自身运行在沙盒中，通过模拟底层数据，使边缘应用对是否运行在沙盒内无感；

所述common通用支撑服务端会感知应用配置变化，适时触发应用的配置重载接口，使边缘应用有机会完成配置的更新。

S50、下载器downloader将下载后的资源保存到对应边缘应用的volume中；步骤S50中，每个边缘应用只绑定沙盒volume的一个子目录，边缘应用只能访问属于其自身的目录。

通过上述的步骤，实现一层层的转发，能够保证特定沙盒中应用提供的服务接口及页面能够被外部访问到，提供所见即所得的编辑能力，满足中心端面向不同运营人员提供多个沙盒的要求。

在上述的实施例中，需要进一步阐述的是，基于Kubernetes的边缘应用沙盒移植方法主要包括三个主要组成部分：沙盒内基础服务、中心端沙盒管理服务、中心端应用路由(Ingress)，下文将会对这三个组成部分进行详细说明。

其中，沙盒内基础服务主要职责是对沙盒内运行的边缘应用提供支撑，实际上是将边缘环境的nginx服务器、应用网关gateway、下载器downloader、通用支撑服务端common等服务植入沙盒，并且其中的少部分服务需要感知自身是运行在边缘环境还是沙盒环境(沙盒环境提供特殊的环境变量标识)，在沙盒环境中运行需要作出一些调整，主要涉及接口行为方式及底层数据模拟；在沙盒环境中数据流向也更加复杂。

沙盒内基础服务包括以下几个方面：

一、nginx服务器、应用网关gateway根据配置实现对应用及数据请求的转发；请求进入沙盒后，如果是数据请求(图片、文件等)则由nginx服务器本身进行处理，nginx服务器会从volume里找寻对应资源进行应答；如果是应用请求则nginx服务器将其转发给应用网关gateway，应用网关gateway根据自身的路由配置将请求分发给对应的边缘应用处理。

二、通用支撑服务端common为沙盒内运行的边缘应用提供基础的能力支撑；通用支撑服务端common感知自身运行在沙盒中，会模拟底层数据，让应用对是否运行在沙盒内无感；通用支撑服务端common会感知应用配置变化，适时触发应用的配置重载接口，让边缘应用有机会完成配置的更新(与边缘环境功能相同)；通用支撑服务端common在边缘环境中提供的类似指标采集或上报等与边缘环境紧密相关的功能在沙盒内不再执行。

三、下载器downloader提供资源动态下载能力；由各个边缘应用调用下载器downloader的下载接口，下载的资源会保存在volume里每个边缘应用专属的目录中；下载器downloader无需感知自身是否运行在沙盒中，下载资源都是从同源OSS服务中下载。

四、边缘应用；边缘应用可由运营人员选择性加入、删除或更改相关配置，其共享沙盒内所有基础服务提供的能力；在配置完成并验证后，运营人员可以选择将该套配置推送到指定的边缘节点。

以上所有沙盒内服务都会放入一个KubernetesPOD中，并且系统会为该POD绑定KubernetesService，Service的转发入口即为nginx服务器的工作端口；即每个KubernetesPOD等价于一个完整的边缘实例。

对于上述的中心端沙盒管理服务，负责对沙盒整个生命周期的管理，提供沙盒创建、更新、查询、销毁的能力。在本实施例中，即在步骤S10之前，具有对沙盒进行创建的过程，结合图2所示，包括以下步骤：

S101、根据运营人员提供的边缘应用配置信息生成相应的KubernetesConfigMap，将沙盒内基础服务和边缘应用作为整体生成KubernetesPOD的资源描述文件，并将生成的KubernetesConfigMap通过文件挂载的方式，挂载入POD中各边缘应用的对应目录，各个边缘应用根据自身的配置来提供服务；

S102、为每个沙盒的POD生成KubernetesService，该KubernetesService的端口转发目标为该沙盒内nginx服务器的工作端口；

S103、为每个沙盒生成KubernetesVolume，用于存放边缘应用的资源文件例如图片、音视频等)；将整个沙盒Volume的各个子目录分别挂载入各个边缘应用的资源目录，并将整个volume挂载到nginx服务器的数据目录；

S104、根据POD描述文件中的特定信息，建立运营人员与沙盒的对应关系；

步骤S104中，将运营人员id存入POD的annotation，以根据运营人员ID查找到指定的沙盒；

该步骤中，利用运营人员与沙盒的对应关系，使用Kubernetes的API对相关的POD进行删除。

本实施例中，运营人员在操作沙盒时，有可能只更新了沙盒内相关应用的配置，也有可能增加了新的应用及配置，由于POD只能接受有限的更新要求，所以在更新沙盒失败时捕捉对应的异常，在删除POD后重新提交POD的描述文件

更进一步的，对于上述的中心应用路由(Ingress)，本发明提供了一具体实施例，包括以下内容：

一、中心沙盒管理服务成功创建沙盒POD后，会向Ingress中增加对应沙盒服务的路由信息，形式类似/sandbox/xxxx(xxxx为沙盒id)，由Ingress按照前缀匹配的方式完成对沙盒请求的转发；Ingress只提供请求转发功能(转发到沙盒对应的KubernetesService)，后续处理过程由沙盒内服务接管；

二、Ingress对沙盒内边缘应用的前端页面跳转进行特殊处理，根据请求发起时所在的页面强制对资源和API请求重定向，使得边缘应用前端页面不感知沙盒环境的url变化(沙盒内应用url增加了沙盒前缀)。

基于上述内容，本发明提供了一种基于Kubernetes的边缘应用沙盒移植方法，该方法能够在不修改边缘应用的前提下，将其直接放入沙盒并使其能对外正确展示自身内容，提供完整的边缘应用功能；在边缘应用改版时，无需对中心配置端做任何修改，将对应版本的应用放入沙盒即能实现“所见即所得”的配置编辑功能，在保证用户体验的前提下，极大地降低了研发成本。

以上是对本发明的较佳实施进行了具体说明，但本发明创造并不限于所述实施例，熟悉本领域的技术人员在不违背本发明精神的前提下还可做出种种的等同变形或替换，这些等同的变形或替换均包含在本申请权利要求所限定的范围内。

Claims (8)

1.一种基于Kubernetes的边缘应用沙盒移植方法，其特征在于，该方法包括以下的步骤：

S10、对边缘服务器进行配置后，外部沙盒请求转发至沙盒内的nginx服务器；

步骤S10中，当对边缘服务器的配置由多人同时进行时，为每个操作者分配一个Kubernetes POD；外部沙盒请求由ingress按照路径前缀转发的方式转入对应沙盒的Kubernetes Service，Kubernetes Service按照端口转发的方式转发给沙盒内的nginx服务器；

所述步骤S10之前，还包括对沙盒进行创建的过程，包括以下步骤：S101、根据运营人员提供的边缘应用配置信息生成相应的Kubernetes ConfigMap，将沙盒内基础服务和边缘应用作为整体生成Kubernetes POD的资源描述文件，并将生成的Kubernetes ConfigMap通过文件挂载的方式，挂载入POD中各边缘应用的对应目录，各个边缘应用根据自身的配置来提供服务；S102、为每个沙盒的POD生成Kubernetes Service，该Kubernetes Service的端口转发目标为该沙盒内nginx服务器的工作端口；S103、为每个沙盒生成Kubernetes Volume，用于存放边缘应用的资源文件；将整个沙盒Volume的各个子目录分别挂载入各个边缘应用的资源目录，并将整个volume挂载到nginx服务器的数据目录；S104、根据POD描述文件中的信息，建立运营人员与沙盒的对应关系；在边缘应用改版时，无需对中心配置端做任何修改，将对应版本的应用放入沙盒中；

S20、nginx服务器对请求进行识别，当属于静态资源类请求时，nginx服务器负责在对应的volume中查找资源；当属于非静态资源类请求时，则统一转发至应用网关gateway处理；

S30、应用网关gateway对请求的处理，应用网关gateway根据自身的路由配置，按照各应用的路径前缀，将请求转发至对应的边缘应用；

S40、当边缘应用需要下载资源时，调用下载器downloader的接口，使用其下载能力；当边缘应用需要获取底层信息时，则调用通用支撑服务端common的接口；

S50、下载器downloader将下载后的资源保存到对应边缘应用的volume中。

2.根据权利要求1所述的一种基于Kubernetes的边缘应用沙盒移植方法，其特征在于，步骤S104中，将运营人员id存入POD的annotation，以根据运营人员ID查找到指定的沙盒；

该步骤中，利用运营人员与沙盒的对应关系，使用Kubernetes的API对相关的POD进行删除。

3.根据权利要求1所述的一种基于Kubernetes的边缘应用沙盒移植方法，其特征在于，步骤S104之后还具有以下步骤：

S105、当更新沙盒失败时，捕捉对应的异常，在删除POD后重新提交POD的描述文件。

4.根据权利要求1所述的一种基于Kubernetes的边缘应用沙盒移植方法，其特征在于，对沙盒进行创建后，还包括以下步骤：

向Ingress中增加对应沙盒服务的路由信息，由Ingress按照前缀匹配的方式完成对沙盒请求的转发；

Ingress对沙盒内边缘应用的前端页面跳转进行处理，根据请求发起时所在的页面强制对资源和API请求重定向，使得边缘应用前端页面不感知沙盒环境的url变化。

5.根据权利要求1所述的一种基于Kubernetes的边缘应用沙盒移植方法，其特征在于，步骤S20中，nginx服务器绑定整个沙盒volume，能够访问所有应用的资源目录。

6.根据权利要求1所述的一种基于Kubernetes的边缘应用沙盒移植方法，其特征在于，步骤S30中，应用网关gateway按照各应用的alias组成的路径前缀，将请求转发至对应的边缘应用；

当请求url中不包括alias，则根据http请求头中reference字段的路径前缀来进行转发。

7.根据权利要求1所述的一种基于Kubernetes的边缘应用沙盒移植方法，其特征在于，步骤S50中，每个边缘应用只绑定沙盒volume的一个子目录，边缘应用只能访问属于其自身的目录。

8.根据权利要求1所述的一种基于Kubernetes的边缘应用沙盒移植方法，其特征在于，步骤S40中，所述通用支撑服务端common为沙盒内运行的边缘应用提供基础的能力支撑，通用支撑服务端common感知自身运行在沙盒中，通过模拟底层数据，使边缘应用对是否运行在沙盒内无感；

所述common通用支撑服务端会感知应用配置变化，适时触发应用的配置重载接口，使边缘应用有机会完成配置的更新。