基于Kubernetes的PaaS平台域名配置方法及装置和电子设备与流程

本申请涉及计算技术领域，尤其涉及一种基于kubernetes的paas平台域名配置方法及装置和电子设备。

背景技术：

一般的，开发者开发了一款应用后，需要将其部署在容器中，并需要对外提供服务，针对该服务需要配置一个域名，使得外部可以利用该域名访问应用获取服务。

技术实现要素：

本申请提供的一种基于kubernetes的paas平台域名配置方法及装置，以解决现有技术中自动配置域名的问题。

根据本申请实施例提供的一种基于kubernetes的paas平台域名配置方法，所述方法包括：

接收客户端提交的应用名、端口并根据所述应用名生成的域名；

根据所述应用名和端口、以及所述域名后缀创建ingress对象；

监听是否创建新的ingress对象；

在监听到创建新的ingress对象的情况下，根据所述应用名、对应的namespace以及域名后缀生成新的域名；

将所述新的域名配置到nginx服务器的配置文件。

优选地，在所述根据所述应用名和端口、以及所述域名后缀创建ingress对象之前，所述方法还包括：

判断所述域名是否冲突；

所述根据所述应用名和端口、以及所述域名后缀创建ingress对象，具体包括：

在所述域名不冲突的情况下，根据所述应用名和端口、以及所述域名后缀创建ingress对象。

优选地，判断所述域名是否冲突，具体包括：

获取所述应用对应的第一namespace；

与已部署的其它应用对应的第二namespace进行比对；

在所述第一namespace与第二namespace相同的情况下，确定所述域名冲突。

根据本申请实施例提供的一种应用访问方法，所述方法包括：

在对用户访问的域名进行域名解析失败的情况下，对该域名进行域名泛解析；

判断是否包含特定域名后缀；

在包含特定域名后缀的情况下，将所述域名解析到所述特定域名后缀对应的nginx服务器；

将所述nginx服务器根据所述域名代理到对应的应用服务结果返回给所述用户。

根据本申请实施例提供的一种基于kubernetes的paas平台域名配置装置，所述装置包括：

接收单元，接收客户端提交的应用名、端口并根据所述应用名生成的域名；

创建单元，根据所述应用名和端口、以及所述域名后缀创建ingress对象；

监听单元，监听是否创建新的ingress对象；

生成单元，在监听到创建新的ingress对象的情况下，根据所述应用名、对应的namespace以及域名后缀生成新的域名；

配置单元，将所述新的域名配置到nginx服务器的配置文件。

优选地，在所述创建单元之前，所述装置还包括：

判断单元，判断所述域名是否冲突；

所述创建单元，具体包括：

在所述域名不冲突的情况下，根据所述应用名和端口、以及所述域名后缀创建ingress对象。

优选地，所述判断单元，具体包括：

获取子单元，获取所述应用对应的第一namespace；

比对子单元，与已部署的其它应用对应的第二namespace进行比对；

确定子单元，在所述第一namespace与第二namespace相同的情况下，确定所述域名冲突。

根据本申请实施例提供的一种应用访问装置，所述装置包括：

解析单元，在对用户访问的域名进行域名解析失败的情况下，对该域名进行域名泛解析；

判断单元，判断是否包含特定域名后缀；

转发单元，在包含特定域名后缀的情况下，将所述域名转发到所述特定域名后缀对应的nginx服务器；

返回单元，将所述nginx服务器根据所述域名代理到对应的应用服务结果返回给所述用户。

根据本申请实施例提供的一种电子设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为：

接收客户端提交的应用名、端口并根据所述应用名生成的域名；

根据所述应用名和端口、以及所述域名后缀创建ingress对象；

监听是否创建新的ingress对象；

在监听到创建新的ingress对象的情况下，根据所述应用名、对应的namespace以及域名后缀生成新的域名；

将所述新的域名配置到nginx服务器的配置文件。

根据本申请实施例提供的一种电子设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为：

在对用户访问的域名进行域名解析失败的情况下，对该域名进行域名泛解析；

判断是否包含特定域名后缀；

在包含特定域名后缀的情况下，将所述域名解析到所述特定域名后缀对应的nginx服务器；

将所述nginx服务器根据所述域名代理到对应的应用服务结果返回给所述用户。

本申请实施例中，可以利用kubernetes，在paas平台上创建应用实例，开发中仅需提交应用名、端口就可以实现自动配置对外提供服务的域名，并自动处理域名冲突问题；具体地，在监听到新创建的ingress对象之后，自动根据应用名、对应的namespace命名空间以及域名后缀生成新的域名，从而避免域名冲突。另一方面的，由于nginx还可以作为负载均衡服务器，所以通过nainx可以实现容器内应用服务施力的负载均衡。

附图说明

图1是本申请一实施例提供的基于kubernetes的paas平台域名配置方法的流程图；

图2是本申请一实施例提供的应用访问方法的流程图；

图3是本申请一实施例提供的基于kubernetes的paas平台域名配置装置的模块示意图；

图4是本申请一实施例提供的应用访问装置的模块示意图；

图5是本申请一实施例提供的一种服务器的硬件结构的示意图；

图6是本申请一实施例提供的一种服务器的示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

本申请适用于基于kubernetes容器集群管理系统的paas平台。

所述kubernetes是一种开源的容器集群管理系统，其提供应用部署、维护、高可用管理，弹性伸缩扩展机制等功能，并封装成为一套完整、简单易用的api对外提供服务。一般的，利用kubernetes可以方便地管理跨机器运行容器化的应用。

所述paas(platformasaservice，平台即服务)，是一种把应用服务的运行和开发环境作为一种服务，以saas的模式提交给用户。因此，paas也是saas模式的一种应用。paas可以提高在web平台上利用的资源数量。例如，可通过远程web服务使用数据即服务(data-as-a-service：数据即服务)，还可以使用可视化的api。用户或者厂商基于paas平台可以快速开发自己所需要的应用和产品。

基于kubernetes创建的容器，存在以下问题：

1.容器所获取的ip地址一般为容器的内部ip地址，无法被外部直接访问。

2.若容器内的应用对外暴露服务时存在域名冲突问题。

3.容器内的应用若部署在多台容器实例时，需要实现服务的负载均衡。

为了解决上述问题，请参见图2，为本申请一实施例提供的基于kubernetes的paas平台域名配置方法的流程图，包括以下步骤：

步骤110：接收客户端提交的应用名、端口并根据所述应用名生成的域名。

一般的，当开发中在基于kubernetes的paas平台(以下称为服务端)上部署某个应用的多个容器实例后，通常还需要对外暴露服务，并需要配置对应该应用的域名，从而可以使得外部用户可以通过所述域名访问部署的应用。开发者可以在服务端上创建应用的实例。而kubernetes可以自动地将该应用的实例部署到容器中。

在首次部署应用时，服务端可以自动生成该应用的域名。通常，可以根据一定预设的规则，例如根据应用名的全拼、或者英文翻译等方式，生成该应用对应的域名。例如，某个应用的中文应用名为“挖财”，则可以自动将“挖财”对应的拼音“wacai”作为应用的域名。

一般的，应用的实例部署在容器后，开发者还需完成容器内应用对外访问暴露，过程如步骤110所示：

开发者可以通过客户端向服务端提交应用的应用名、端口以及域名。

而服务端就可以接收到所述客户端提交的应用名、端口并根据所述应用名生成的域名。

步骤120：根据所述应用名和端口、以及所述域名后缀创建ingress对象。

由于基于kubernetes创建的容器存在如下问题：

容器所获取的ip地址一般为容器的内容ip地址，这样的ip地址只能在容器集群内容网路中路由，而无法被外部(公网)直接访问。因此，服务端还需要对部署在容器中的应用对应的ip进行一定的处理，使得其可以被外部访问。

本实施例中，通过创建ingress对象的方式解决了容器中应用ip无法被外部直接访问的问题。

这里的ingress是一种对外服务到容器集群内service(kubernetes的服务)之间规则的集合，可以允许进入集容器群的访问请求被转发至容器集群内的service。

具体地，ingress能把service配置成外网能够访问的url后缀(即域名后缀)；并且可以实现流量负载均衡，终止ssl，提供于域名访问的虚拟主机等。如此，用户只需通过访问url(api资源服务的形式，例如：caas.one/kibana)进入和请求service。通常，一个ingress控制器可以负责处理所有ingress对象的请求流量；所述ingress控制器通常还可以是一个负载均衡器；所述ingress控制器可以设置在边界路由器上，或者由额外的前端来帮助处理ha方式的流量。

步骤130：监听是否创建新的ingress对象。

步骤140：在监听到创建新的ingress对象的情况下，根据所述应用名、对应的namespace命名空间以及域名后缀生成新的域名。

所述namespace即命名空间，所述namespace主要用于组合和重用代码。其主要是为了解决变量的重名导致的冲突问题。以应用为例，通过引入namespace，就可以在namespace中定义本应用，避免例如同一应用不同版本之间应用名冲突的情况。一般来说，每一个应用都会对应有一个唯一的namespace。

本实施例中，根据所述应用名、对应的namespace命名空间以及域名后缀生成新的域名，可以体现为新的域名：“应用名.name-space.url后缀”。

步骤150：将所述新的域名配置到nginx服务器的配置文件。

所述nginx时一个高性能的http和反向代理服务器。在所述nginx作为web服务器时，具有占用内存少，并发能力强的特定。在所述nginx作为负载均衡服务器时，既可以在内部直接支持rails和php，也可以支持作为http代理服务器对外进行服务。

通过将所述新的域名配置到nginx服务器的配置文件，从而完成服务代理注册。

所述新的域名，即“应用名.name-space.url后缀”最终指向的是应用对应容器内的应用实例。

通过本实施例，开发中仅需提交应用名、端口就可以实现自动配置对外提供服务的域名，并自动处理域名冲突问题；具体地，在监听到新创建的ingress对象之后，自动根据应用名、对应的namespace命名空间以及域名后缀生成新的域名，从而避免域名冲突。另一方面的，由于nginx还可以作为负载均衡服务器，所以通过nainx可以实现容器内应用服务施力的负载均衡。

在上述图1所示实施例的基础上，在所述步骤120之前，所述方法还可以包括：

判断所述域名是否冲突；

所述步骤120，具体包括：

在所述域名不冲突的情况下，根据所述应用名和端口、以及所述域名后缀创建ingress对象。

本实施例中，所述判断所述域名是否冲突，可以是通过判定应用的namespace的方式实现的。

如前所述，每一个应用都会对应有一个唯一的namespace。因此，可以根据查询namespace表，判断是否存在该应用对应的namespace。所述namespace表是已经部署的其它应用对应的namespace集合。一般，服务端中会记录每一个部署应用对应的namespace，从而形成namespace表。

如果namespace表中存在该应用对应的namespace，则说明域名冲突；

如果namespace表中不存在该应用对应的namespace，则说明域名不冲突。在域名冲突的情况下，服务端可以向客户端发送通知，从而提示开发者重新申请域名。

请参见图2，为本申请一实施例提供的应用访问方法的流程图，包括以下步骤：

步骤210：在对用户访问的域名进行域名解析失败的情况下，对该域名进行域名泛解析。

步骤220：判断是否包含特定域名后缀。

步骤230：在包含特定域名后缀的情况下，将所述域名解析到所述特定域名后缀对应的nginx服务器。

步骤240：将所述nginx服务器根据所述域名代理到对应的应用服务结果返回给所述用户。

在实际应用中，用户使用客户端(如电脑)访问应用时，填写的访问地址通常是域名。而为了识别域名具体是指向哪一个应用，需要对域名进行域名解析，得到指向目标地址的ip。具体地，通过dns服务器实现，可以理解的，在客户端与应用服务器之间，会设置有一个用于进行dns解析的dns服务器。所述dns(domainnamesystem，域名系统)是因特网上作为域名和ip地址相互映射的一个分布式数据库，能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的ip。

所述域名泛解析(dns泛解析)是指在域名前添加任何子域名，均可以访问到指向的web地址。通过这种方式可以将“*.域名”解析到同一ip。域名解析的优点是可以通过类似于模糊匹配的方式将用户需要访问的应用解析到正确的服务器上。

依然以“*.name-space.url后缀”为例，在用户访问应用后，即使dns服务器对域名进行nds解析后得出该域名不存在对应的ip的情况下，还可以通过dns泛解析发现特定域名后缀(“url后缀”)，从而用户需要访问的应用解析到“*.name-space.url后缀”对应的服务器上。这里的“*.name-space.url后缀”所对应的服务器即为上述实施例步骤150中所示的服务代理注册的nginx服务器。该nginx服务会对完整的域名，即“应用名.name-space.url后缀”进行匹配，从而跳转到真正的应用服务地址，从而访问实际的容器地址。

与前述图1所述的基于kubernetes的paas平台域名配置方法实施例相对应，本申请还提供了一种基于kubernetes的paas平台域名配置装置的实施例。所述装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，本申请基于kubernetes的paas平台域名配置装置所在设备的一种硬件结构可以包括处理器、网络接口、内存以及非易失性存储器之外，实施例中装置所在的设备通常根据该基于kubernetes的paas平台域名配置实际功能，还可以包括其他硬件，对此不再赘述。

参见图3，为本申请一实施例提供的基于kubernetes的paas平台域名配置装置的模块图，所述装置包括：

接收单元310，接收客户端提交的应用名、端口并根据所述应用名生成的域名；

创建单元320，根据所述应用名和端口、以及所述域名后缀创建ingress对象；

监听单元330，监听是否创建新的ingress对象；

生成单元340，在监听到创建新的ingress对象的情况下，根据所述应用名、对应的namespace以及域名后缀生成新的域名；

配置单元350，将所述新的域名配置到nginx服务器的配置文件。

在一个可选的实施方式中：

在所述创建单元320之前，所述装置还包括：

判断单元，判断所述域名是否冲突；

所述创建单元320，具体包括：

在所述域名不冲突的情况下，根据所述应用名和端口、以及所述域名后缀创建ingress对象。

在一个可选的实施方式中：

所述判断单元，具体包括：

获取子单元，获取所述应用对应的第一namespace；

比对子单元，与已部署的其它应用对应的第二namespace进行比对；

确定子单元，在所述第一namespace与第二namespace相同的情况下，确定所述域名冲突。

与前述图2所述的应用访问方法实施例相对应，本申请还提供了一种应用访问装置的实施例。所述装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，本申请应用访问装置所在设备的一种硬件结构可以包括处理器、网络接口、内存以及非易失性存储器之外，实施例中装置所在的设备通常根据该应用访问实际功能，还可以包括其他硬件，对此不再赘述。

参见图4，为本申请一实施例提供的应用访问装置的模块图，所述装置包括：

解析单元410，在对用户访问的域名进行域名解析失败的情况下，对该域名进行域名泛解析；

判断单元420，判断是否包含特定域名后缀；

转发单元430，在包含特定域名后缀的情况下，将所述域名转发到所述特定域名后缀对应的nginx服务器；

返回单元440，将所述nginx服务器根据所述域名代理到对应的应用服务结果返回给所述用户。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上图3描述了基于kubernetes的paas平台域名配置装置的内部功能模块和结构示意，其实质上的执行主体可以为一种电子设备，例如服务器，图5是根据一示例性实施例示出的一种服务器的硬件结构的示意图，参照图5该服务器包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为：

接收客户端提交的应用名、端口并根据所述应用名生成的域名；

根据所述应用名和端口、以及所述域名后缀创建ingress对象；

监听是否创建新的ingress对象；

在监听到创建新的ingress对象的情况下，根据所述应用名、对应的namespace以及域名后缀生成新的域名；

将所述新的域名配置到nginx服务器的配置文件。

类似的，以上图4描述了应用访问装置的内部功能模块和结构示意，其实质上的执行主体可以为一种电子设备，例如服务器，图5是根据一示例性实施例示出的一种服务器的硬件结构的示意图，参照图5该服务器包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为：

在对用户访问的域名进行域名解析失败的情况下，对该域名进行域名泛解析；

判断是否包含特定域名后缀；

在包含特定域名后缀的情况下，将所述域名解析到所述特定域名后缀对应的nginx服务器；

将所述nginx服务器根据所述域名代理到对应的应用服务结果返回给所述用户。

在上述电子设备的实施例中，应理解，该处理器可以是中央处理单元(英文：centralprocessingunit，简称：cpu)，还可以是其他通用处理器、数字信号处理器(英文：digitalsignalprocessor，简称：dsp)、专用集成电路(英文：applicationspecificintegratedcircuit，简称：asic)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等，而前述的存储器可以是只读存储器(英文：read-onlymemory，缩写：rom)、随机存取存储器(英文：randomaccessmemory，简称：ram)、快闪存储器、硬盘或者固态硬盘。结合本发明实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

图6是根据一示例性实施例示出的一种服务器1000的示意图。参照图6，服务器1000包括处理组件1022，其进一步包括一个或多个处理器，以及由存储器1032所代表的存储器资源，用于存储可由处理组件1022的执行的指令，例如应用程序。存储器1032中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件1022被配置为执行指令，以执行上述基于卷积神经网络的图片检索方法的全部或部分步骤。

服务器1000还可以包括一个电源组件1026被配置为执行服务器1000的电源管理，一个有线或无线网络接口1050被配置为将服务器1000连接到网络，和一个输入输出(i/o)接口1058。服务器1000可以操作基于存储在存储器1032的操作系统，例如windowsservertm，macosxtm，unixtm,linuxtm，freebsdtm或类似。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于电子设备实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。