CN111866206A - 分布式域名解析方法、装置及设备 - Google Patents

Abstract

本申请公开了一种分布式域名解析方法，涉及云计算领域。该方法应用于Kubernetes集群中，包括：节点的第一域名服务器接收所述节点的本地对象发送的域名解析请求，其中，所述节点为所述Kubernetes集群中的任意一个节点，所述本地对象为所述节点内的应用对象，所述域名解析请求中包括待解析的域名；在所述第一域名服务器的本地缓存数据中查询与所述待解析的域名匹配的地址数据；将所述地址数据提供给所述本地对象。该方法针对节点中的本地对象发出的域名解析请求，可以由该节点的第一域名服务器在本地缓存数据中查询与待解析的域名匹配的地址数据，并将该地址数据提供给该本地对象即可，可以提升Kubernetes集群对域名解析请求的处理速度。

Description

分布式域名解析方法、装置及设备

技术领域

本公开涉及云计算技术领域，更具体地，涉及一种分布式域名解析方法、装置、节点及计算机可读存储介质。

背景技术

Kubernetes，简称K8S，是一种基于容器的集群管理平台，Kubernetes集群一般包括主节点(Master)，以及分别与主节点通信连接的多个计算节点(Node)，其中，主节点一般用于管理和控制多个计算节点，计算节点作为工作负载节点，其包含直接部署在节点中的原应用程序和多个容器组(Pod)，每个容器组中封装有一个或多个用于承载应用程序的容器(Container)，Pod是Kubernetes的基本操作单元，是最小的可创建、调试和管理的部署单元。

域名解析(DomainNameResolution)，是指将域名(DomainName)解析为对应的网络协议地址(IP，InternetProtocolAddress)，在实际中，一般使用域名服务器(DNS，DomainNameService)进行域名解析处理。

目前，在Kubernetes集群中，常用的域名解析方法一般是在容器组中的容器需要访问内部域名时，该容器直接发送域名解析请求到Kubernetes集群的中心域名服务器；之后，中心域名服务器响应于该域名解析请求，到接口服务器，即apiserver中查询与待解析的域名相匹配的地址数据，并将该地址数据返回给中心域名服务器；之后，再由中心域名服务器将该地址数据提供给该容器。

然而，随着Kubernetes集群中节点数以及Pod数的不断增加，中心域名服务器在单位时间内需要处理的域名解析请求的数量也在不断增加，因此，在使用上述方法处理Kubernetes集群中的域名解析请求时，存在处理速度慢的技术问题。

发明内容

本公开实施例的一个目的是提供一种用于域名解析的新技术方案。

根据本公开的第一方面，提供了一种分布式域名解析方法，应用于Kubernetes集群中，包括：

节点的第一域名服务器接收所述节点的本地对象发送的域名解析请求，其中，所述节点为所述Kubernetes集群中的任意一个节点，所述本地对象为所述节点内的应用对象，所述域名解析请求中包括待解析的域名；

在所述第一域名服务器的本地缓存数据中查询与所述待解析的域名匹配的地址数据；

将所述地址数据提供给所述本地对象。

可选地，在所述查询之前，所述方法还包括：

从所述待解析的域名中解析出域名类型；

若所述域名类型表征所述待解析的域名为所述Kubernetes集群的内部域名，执行所述在所述第一域名服务器的本地缓存数据中查询与所述待解析的域名匹配的地址数据步骤。

可选地，所述方法还包括：若所述域名类型表征所述待解析的域名为外部域名，将所述域名解析请求发送给第二域名服务器，以获取与所述待解析的域名相匹配的地址数据。

可选地，所述方法还包括：若所述本地缓存数据中不存在与所述待解析的域名匹配的地址数据，在所述Kubernetes集群的集群配置数据中，获取与所述待解析的域名相匹配的地址数据。

可选地，所述在所述Kubernetes集群的集群数据中，获取与所述待解析的域名相匹配的地址数据，包括：

向所述Kubernetes集群的接口服务器发送数据请求，其中，所述数据请求中包括所述待解析的域名；

接收所述接口服务器返回的对所述数据请求的响应消息；

从所述响应消息中，获得所述地址数据。

可选地，所述本地缓存数据通过以下步骤获得：

按照预设时间间隔向所述Kubernetes集群的接口服务器发送获取集群配置数据的请求；

接收所述接口服务器返回的所述集群配置数据；

将所述集群配置数据缓存到本地缓存区。

可选地，所述本地对象包括以下至少一种对象：容器组、原应用程序，其中，所述原应用程序是所述节点内除所述容器组以外的应用程序。

根据本公开的第二方面，本公开还提供了一种分布式域名解析装置，应用于Kubernetes集群中的任意一个节点的第一域名服务器，包括：

请求接收模块，用于接收所述节点的本地对象发送的域名解析请求，其中，所述域名解析请求中包括待解析的域名，所述本地对象为所述节点内的应用对象；

地址数据查询模块，用于在所述第一域名服务器的本地缓存数据中查询与所述待解析的域名匹配的地址数据；

地址数据提供模块，用于将所述地址数据提供给所述本地对象。

可选地，所述请求分发模块还用于：

若所述域名类型表征所述待解析的域名为外部域名，将所述域名解析请求发送给第二域名服务器，以获取与所述待解析的域名相匹配的地址数据。

可选地，若所述本地缓存数据中不存在与所述待解析的域名匹配的地址数据，所述地址数据查询模块还用于：

在所述Kubernetes集群的集群配置数据中，获取与所述待解析的域名相匹配的地址数据。

可选地，所述地址数据查询模块在用于在所述Kubernetes集群的集群配置数据中，获取与所述待解析的域名相匹配的地址数据时，用于：

向所述Kubernetes集群的接口服务器发送数据请求，其中，所述数据请求中包括所述待解析的域名；

接收所述接口服务器返回的对所述数据请求的响应消息；

从所述响应消息中，获得所述地址数据。

可选地，所述地址数据查询模块包括：

本地缓冲数据获得子模块，用于按照预设时间间隔向所述Kubernetes集群的接口服务器发送获取集群配置数据的请求；接收所述接口服务器返回的所述集群配置数据；将所述集群配置数据缓存到本地缓存区。

根据本公开的第三方面，还提供一种Kubernetes集群中的节点，包括第二方面所述的装置；或者，

所述节点包括：

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

处理器，用于根据所述指令的控制运行所述节点执行如第一方面任意一项所述的方法。

根据本公开的第四方面，还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有可被计算机读取执行的计算机程序，所述计算机程序用于在被所述计算机读取运行时，执行如第一方面任意一项所述的方法。

根据本公开的实施例，针对Kubernetes集群中的任意一个节点中的本地对象发出的域名解析请求，可以先不到Kubernetes集群的中心域名服务器中进行域名解析，而是由该节点的第一域名服务器在本地缓存数据中查询与待解析的域名匹配的地址数据，并将该地址数据提供给该本地对象即可。该方法可以提升Kubernetes集群针对域名解析请求的处理速度。

通过以下参照附图对本公开的示例性实施例的详细描述，本公开的其它特征及其优点将会变得清楚。

附图说明

被结合在说明书中并构成说明书的一部分的附图示出了本公开的实施例，并且连同其说明一起用于解释本公开的原理。

图1是Kubernetes集群中现有的域名解析处理的示意图。

图2是根据一个实施例的分布式域名解析处理的示意图。

图3是显示可用于实现一个实施例的分布式域名解析方法的服务器的硬件配置的原理框图。

图4是根据一个实施例的分布式域名解析方法的流程示意图。

图5是根据一个实施例的分布式域名解析装置的原理框图。

图6是根据一个实施例的Kubernetes集群中的节点的硬件结构示意图。

具体实施方式

现在将参照附图来详细描述本公开的各种示例性实施例。应注意到：除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本公开的范围。

以下对至少一个示例性实施例的描述实际上仅仅是说明性的，决不作为对本公开及其应用或使用的任何限制。

对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为说明书的一部分。

在这里示出和讨论的所有例子中，任何具体值应被解释为仅仅是示例性的，而不是作为限制。因此，示例性实施例的其它例子可以具有不同的值。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。

平台即服务(PaaS，Platform as a Service)是云计算的重要组成部分，其用于提供运算平台与解决方案服务。目前的PaaS平台，一般可以基于Kubernetes集群搭建。请参看图1，其是Kubernetes集群中现有的域名解析处理的示意图。如图1所示，在现有的PaaS平台，即，基于Kubernetes集群搭建的云平台中，在主节点(Master)或者计算节点(Node)的容器组(Pod)中的容器需要访问Kubernetes集群中的内部域名时，一般是执行步骤S1100，即，由该容器发送域名解析请求到中心域名服务器，其中，该中心域名服务器部署在主节点中，一般可以使用coreDNS应用程序来进行域名解析处理。在中心域名服务器接收到域名解析请求后，执行步骤S1200，由中心域名服务器向Kubernetes集群的接口服务器，即apiserver发送查询请求，以获取该待解析的域名对应的地址数据。apiserver接收到中心域名服务器发送的查询请求后，执行步骤S1300，响应于该查询请求，到Kubernetes集群的etcd数据库中查询，获得对应的地址数据。之后，由apiserver将获取到的该地址数据返回给中心域名服务器，再由中心域名服务器提供给该容器。

另外，针对计算节点中的原应用程序，即，直接部署在节点中的除容器组以外的应用程序，在其需要访问外部域名时，一般是执行步骤S1400，直接发送域名解析请求到外部域名服务器进行域名解析，其中，所述外部域名服务器用于解析外部域名。需要说明的是，apiserver为Kubernetes集群的一个系统组件，其提供了Kubernetes集群中各类资源对象的增加、删除、修改、查询以及监控服务的http rest接口，是Kubernetes集群的数据总线和数据中心，而etcd是一个高可用的分布式键值(key-value)数据库，用于保存Kubernetes集群所有的网络配置和对象的集群配置数据。

由于Kubernetes集群中所有节点的内部域名的域名解析请求都需要中心域名服务器进行解析处理，因此，随着Kubernetes集群中节点数以及Pod数的不断增加，其可能存在针对请求的解析处理出现数据延迟，处理速度慢的问题。

请参看图2，其是根据一个实施例的分布式域名解析处理的示意图。如图2所示，为了解决现有技术的域名解析方法在处理Kubernetes集群中的域名解析请求时，存在的处理速度慢的问题，本实施例为Kubernetes集群的每一个节点均设置对应的第一域名服务器，在节点的第一域名服务器接收到本节点中的本地对象，例如，容器组中的容器或者原应用程序发送的域名解析请求时，可以先由该第一域名服务器直接对待解析的域名进行解析，并返回匹配的地址数据，而不需要集中的向中心化的域名服务器发送域名解析请求，进而避免中心域名服务器进行集中域名解析处理时所带来的数据延迟问题，可以提升域名解析处理的处理速度。

<硬件配置>

图3是显示可用于实现一个实施例的分布式域名解析方法的服务器3000的硬件配置的原理框图。

服务器300例如可以是刀片服务器、机架式服务器等，在本实施例中，服务器3000可以直接为本公开任意实施例的Kubernetes集群中的节点，在此不做限定。

如图3所示，服务器3000可以包括处理器3100、存储器3200、接口装置3300、通信装置3400、显示装置3500和输入装置3600。处理器3100例如可以是中央处理器CPU等。存储器3200例如包括ROM(只读存储器)、RAM(随机存取存储器)、诸如硬盘的非易失性存储器等。接口装置3300例如包括USB接口、串行接口等。通信装置3400例如能够进行有线或无线通信。显示装置3500例如是液晶显示屏。输入装置3600例如可以包括触摸屏、键盘等。

本实施例中，服务器3100可用于参与实现根据本公开任意实施例的分布式域名解析方法。

应用于本公开实施例中，服务器3000的存储器3200用于存储指令，所述指令用于控制所述处理器3100进行操作以支持实现根据本公开任意实施例的分布式域名解析方法。技术人员可以根据本公开所公开方案设计指令。指令如何控制处理器进行操作，这是本领域公知，故在此不再详细描述。

本领域技术人员应当理解，尽管在图3中示出了服务器3000的多个装置，但是，本公开实施例的服务器3000可以仅涉及其中的部分装置，例如，只涉及处理器3100和存储器3200。这是本领域公知，此处不再赘述。

<方法实施例>

请参看图4，其是根据一个实施例的分布式域名解析方法的流程示意图。本实施例提供的分布式域名解析方法可以应用于Kubernetes集群中，如图4所示，该方法可以包括如下步骤S4100-S4300，以下予以详细说明。

步骤S4100，节点的第一域名服务器接收所述节点的本地对象发送的域名解析请求，其中，所述节点为所述Kubernetes集群中的任意一个节点，所述本地对象为所述节点内的应用对象，所述域名解析请求中包括待解析的域名。

在本实施例中，所述节点，可以是Kubernetes集群中的主节点，也可以是计算节点。

本地对象，可以是Kubernetes集群的节点内的应用对象，例如，本地对象可以是部署在该节点中的容器组。另外，针对计算节点，本地对象也可以为该计算节点中的原应用程序，例如，本地对象可以为直接部署在计算节点中的即时通信应用程序。

在本实施例中，用于接收本地对象发送的域名解析请求的第一域名服务器可以是Kubernetes集群中的当前节点，即，可以将提供域名解析服务的应用程序部署在Kubernetes集群的每一节点中，该应用程序监听并处理本节点中的本地对象发送的域名解析请求。另外，在本实施例中，第一域名服务器中的“第一”是用于与第二域名服务器进行区分，而非特指某一域名服务器，其中，在本实施例中，第二域名服务器可以是用于对外部域名进行解析处理的服务器。

域名(DomainName)，又称网域，是由一串用点分隔的名字组成的Internet上某一台计算设备或计算设备组的名称，用于在数据传输时对计算机的定位标识(有时也指地理位置)，例如，域名可以为“baidu.com”、“sina.com”或者“cluster.local”等。在实际中，由于IP地址具有不方便记忆并且不能显示地址组织的名称和性质等缺点，因此，可以通过域名来方便的对计算设备进行标识，并在用户通过域名访问计算设备时，通过域名服务器来对域名进行解析，以获取计算设备对应的IP地址，使用户可以更方便的访问网络。

如图2所示，在本实施例中，为了提升域名解析处理的处理速度，针对Kubernetes集群的节点中的本地对象发出的域名解析请求，可以先不到Kubernetes集群的中心域名服务器进行处理，而是由每一节点的第一域名服务器进行处理，即，所述节点的第一域名服务器接收所述节点的本地对象发送的域名解析请求，可以为部署在节点中的域名服务器或者域名解析服务接收节点中的本地对象发送的域名解析请求。

需要说明的是，由于计算节点中的原应用程序发送的域名解析请求一般是针对外部域名，即，针对的是Kubernetes集群以外的域名的解析请求，而计算节点或者主节点的容器组发送的域名解析请求通常是针对内部域名，即，针对的是Kubernetes集群内部的其它容器组或者服务的解析请求，因此，为了提升域名解析处理的处理速度，在Kubernetes集群的每一个节点中，可以将第一域名服务器或者直接部署在节点中的域名解析服务拆分为第一解析服务和第二解析服务，以根据待解析的域名的域名类型进行有针对性的解析处理，以下予以详细说明。

在本实施例中，第一解析服务可以是轻量级的、用于提供域名解析请求的分发处理的应用程序。

具体来讲，第一解析服务可以接收本节点中的本地对象发送的域名解析请求，通过对待解析的域名进行初步解析，获得其对应的域名类型，并根据该域名类型确定将该域名解析请求分发给第二域名解析服务或第二域名服务器进行解析处理，其中，所述第二域名服务器是用于对外部域名进行解析处理的服务器，在具体实施时，第二域名服务器可以根据需要进行设置，此处不做特殊限定。

在具体实施时，第一域名解析服务可以通过在Kubernetes集群的节点中部署dnsmasq应用程序来实现，其中，dnsmasq是一个小巧且方便地用于配置域名解析服务的应用程序。例如，可以在dnsmasq应用程序的配置文件中配置内容“server＝/cluster.local/127.0.0.1”来实现域名解析请求的分发处理，即，在dnsmasq应用程序接收到节点中的本地对象发送的域名解析请求之后，将待解析的域名中包含内部域名，即，“cluster.local”的域名解析请求转发到监听“127.0.0.1:53”的第二域名解析服务中进行动态解析处理，而将“cluster.local”以外的域名解析请求转发给第二域名服务器进行动态解析处理。需要说明的是，“cluster.local”是kubernetes集群内部的默认域，在具体实施时，内部域名可以根据需要进行设置，例如，内部域名也可以是用户在kubernetes集群内的自定义域，此处不再赘述。另外，“127.0.0.1”是回送地址，用于表示当前节点；在具体实施时，也可以将其设置为节点的实际IP地址；而“53”是用于监听域名解析请求的默认端口，在具体实施时，该端口也可以根据需要进行设置，此处不做特殊限定。

与第一域名服务相对应，第二域名解析服务可以是用于对Kubernetes集群中的内部域名进行动态解析处理的应用程序。第二域名解析服务根据接收到的域名解析请求，通过在本地缓存数据中查询与待解析的域名匹配的地址数据，以进行解析处理。

在步骤S4100之后，执行步骤S4200，在所述第一域名服务器的本地缓存数据中查询与所述待解析的域名匹配的地址数据。

地址数据，是指与待解析的域名匹配的IP地址，在本实施例中，可以是在第一域名服务器中的第二域名解析服务接收到节点中的本地对象发送的域名解析请求之后，在本地缓存数据缓存的域名数据记录中查询，以获取与待解析的域名相匹配的地址数据。如图2所示，本地缓存数据中缓存的域名数据记录可为“记录1”，“记录2”等，其中，每条域名数据记录的内容可以为<域名，IP地址>的形式，此处不做特殊限定。

在具体实施时，所述本地缓存数据可以通过以下步骤获得：按照预设时间间隔向所述Kubernetes集群的接口服务器发送获取集群配置数据的请求；接收所述接口服务器返回的所述集群配置数据；将所述集群配置数据缓存到本地缓存区。

即，可以由第二域名解析服务以监听的方式，在预设的时间间隔内缓存Kubernetes集群的etcd中的集群配置数据到本地缓存区中，以获得相对实时的集群配置数据。

例如，可以将第二域名解析服务定义为“KceDnsDriver”，在KceDnsDriver运行的过程中，可以每隔十秒，向接口服务器，即，apiserver发送获取etcd中的集群配置数据的数据请求，并将apiserver返回的集群配置数据缓存到本地缓存区中，以获得相对实时的本地缓存数据。需要说明的是，在具体实施时，预设时间间隔可以根据需要进行设置，例如，也可以将预设的时间间隔设置为20秒、10分钟等，此处不做特殊限定。

根据上述描述可知，为了提升域名解析处理的处理速度，在执行上述查询之前，本实施例提供的该方法还包括：从所述待解析的域名中解析出域名类型；在所述域名类型表征所述待解析的域名为所述Kubernetes集群的内部域名的情况下，执行所述在所述第一域名服务器的本地缓存数据中查询与所述待解析的域名匹配的地址数据步骤；以及，在所述域名类型表征所述待解析的域名为外部域名的情况下，将所述域名解析请求发送给第二域名服务器，以获取与所述待解析的域名相匹配的地址数据。

在具体实施时，由于第一域名服务器所使用的本地缓存数据是按照预设时间间隔将集群的etcd中的集群配置数据缓存到本地缓存区中的，因此，可能存在本地缓存数据中不存在与待解析的域名相匹配的地址数据的情况，如图2所示，针对该情况，若第一域名解析服务器的本地缓存数据中不存在与待解析的域名匹配的地址数据，本实施例提供的该方法还可以在所述Kubernetes集群的集群配置数据中，获取与所述待解析的域名相匹配的地址数据。

具体来讲，所述在所述Kubernetes集群的集群配置数据中，获取与所述待解析的域名相匹配的地址数据，包括：向所述Kubernetes集群的接口服务器发送数据请求，其中，所述数据请求中包括所述待解析的域名；接收所述接口服务器返回的对所述数据请求的响应消息；从所述响应消息中，获得所述地址数据。

即，当第二域名服务在本地缓存数据中查询不到与待解析的域名相匹配的IP地址时，可以由第二域名服务通过对应的域名查询接口函数向Kubernetes集群的接口服务器，即，apiserver发送数据请求；apiserver在接收到该数据请求之后，可以根据该待解析的域名，在Kubernetes集群的集群配置数据，即，在etcd中查询获得与待解析的域名匹配的IP地址，并将该IP地址返回给第二域名服务。

在步骤S4200之后，执行步骤S4300，将所述地址数据提供给所述本地对象。

在第一域名服务器获取到与待解析的域名匹配的地址数据，即，IP地址之后，可以将该IP地址提供给本地对象，本地对象即可根据该IP地址访问对应的计算设备或者服务，此处不再赘述。

根据以上步骤S2100-S2300可知，本实施例的方法针对Kubernetes集群中的任意一个节点中的本地对象发出的域名解析请求，可以先不到Kubernetes集群的中心域名服务器中进行域名解析，而是由该节点的第一域名服务器在本地缓存数据中查询与待解析的域名匹配的地址数据，并将该地址数据提供给该本地对象即可。该方法可以提升Kubernetes集群中的域名解析处理的处理速度。

<装置实施例>

在本实施例中，还提供一种分布式域名解析装置，其可以应用于Kubernetes集群中的任意一个节点的第一域名服务器中，如图5所示，该装置5000可以包括请求接收模块5100、地址数据查询模块5200和地址数据提供模块5300。

该请求接收模块5100，用于接收所述节点的本地对象发送的域名解析请求，其中，所述域名解析请求中包括待解析的域名，所述本地对象为所述节点内的应用对象。

该地址数据查询模块5200，用于在所述第一域名服务器的本地缓存数据中查询与所述待解析的域名匹配的地址数据。

在一个实施例中，该装置5000还包括请求分发模块，用于在所述地址数据查询模块执行所述查询之前，从所述待解析的域名中解析出域名类型；若所述域名类型表征所述待解析的域名为所述Kubernetes集群的内部域名，将所述域名解析请求发送给所述地址数据查询模块。

在该实施例中，所述请求分发模块还用于：若所述域名类型表征所述待解析的域名为外部域名，将所述域名解析请求发送给第二域名服务器，以获取与所述待解析的域名相匹配的地址数据。

在一个实施例中，若所述本地缓存数据中不存在与所述待解析的域名匹配的地址数据，该地址数据查询模块5200还可以用于：在所述Kubernetes集群的集群配置数据中，获取与所述待解析的域名相匹配的地址数据。

在该实施例中，该地址数据查询模块5200在用于在所述Kubernetes集群的集群配置数据中，获取与所述待解析的域名相匹配的地址数据时，可以用于：向所述Kubernetes集群的接口服务器发送数据请求，其中，所述数据请求中包括所述待解析的域名；接收所述接口服务器返回的对所述数据请求的响应消息；从所述响应消息中，获得所述地址数据。

在一个实施例中，该地址数据查询模块5200包括本地缓冲数据获得子模块，用于按照预设时间间隔向所述Kubernetes集群的接口服务器发送获取集群配置数据的请求；接收所述接口服务器返回的所述集群配置数据；将所述集群配置数据缓存到本地缓存区。

该地址数据提供模块5300，用于将所述地址数据提供给所述本地对象。

<设备实施例>

在本实施例中，还提供一种Kubernetes集群中的节点，其可以包括根据本公开任意实施例的分布式域名解析装置5000，用于实施本公开任意实施例的分布式域名解析方法。

如图6所示，该电子设备6000还可以包括处理器6200和存储器6100，该存储器6100用于存储可执行的指令；该处理器6200用于根据指令的控制运行电子设备以执行根据本公开任意实施例的分布式域名解析方法。

以上装置5000的各个模块可以由处理器6200运行该指令以执行根据本公开任意实施例的分布式域名解析方法来实现。

<介质实施例>

在本实施例中，还提供一种计算机可读存储介质，该计算机可读存储介质存储有可被计算机读取并运行的计算机程序，所述计算机程序用于在被所述计算机读取运行时，执行如本公开以上任意实施例所述的方法。

本公开可以是系统、方法和/或计算机程序产品。计算机程序产品可以包括计算机可读存储介质，其上载有用于使处理器实现本公开的各个方面的计算机可读程序指令。

计算机可读存储介质可以是可以保持和存储由指令执行设备使用的指令的有形设备。计算机可读存储介质例如可以是――但不限于――电存储设备、磁存储设备、光存储设备、电磁存储设备、半导体存储设备或者上述的任意合适的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、静态随机存取存储器(SRAM)、便携式压缩盘只读存储器(CD-ROM)、数字多功能盘(DVD)、记忆棒、软盘、机械编码设备、例如其上存储有指令的打孔卡或凹槽内凸起结构、以及上述的任意合适的组合。这里所使用的计算机可读存储介质不被解释为瞬时信号本身，诸如无线电波或者其他自由传播的电磁波、通过波导或其他传输媒介传播的电磁波(例如，通过光纤电缆的光脉冲)、或者通过电线传输的电信号。

这里所描述的计算机可读程序指令可以从计算机可读存储介质下载到各个计算/处理设备，或者通过网络、例如因特网、局域网、广域网和/或无线网下载到外部计算机或外部存储设备。网络可以包括铜传输电缆、光纤传输、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。每个计算/处理设备中的网络适配卡或者网络接口从网络接收计算机可读程序指令，并转发该计算机可读程序指令，以供存储在各个计算/处理设备中的计算机可读存储介质中。

用于执行本公开操作的计算机程序指令可以是汇编指令、指令集架构(ISA)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据、或者以一种或多种编程语言的任意组合编写的源代码或目标代码，所述编程语言包括面向对象的编程语言—诸如Smalltalk、C++等，以及常规的过程式编程语言—诸如“C”语言或类似的编程语言。计算机可读程序指令可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络—包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。在一些实施例中，通过利用计算机可读程序指令的状态信息来个性化定制电子电路，例如可编程逻辑电路、现场可编程门阵列(FPGA)或可编程逻辑阵列(PLA)，该电子电路可以执行计算机可读程序指令，从而实现本公开的各个方面。

这里参照根据本公开实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本公开的各个方面。应当理解，流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合，都可以由计算机可读程序指令实现。

这些计算机可读程序指令可以提供给通用计算机、专用计算机或其它可编程数据处理装置的处理器，从而生产出一种机器，使得这些指令在通过计算机或其它可编程数据处理装置的处理器执行时，产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机可读程序指令存储在计算机可读存储介质中，这些指令使得计算机、可编程数据处理装置和/或其他设备以特定方式工作，从而，存储有指令的计算机可读介质则包括一个制造品，其包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各个方面的指令。

也可以把计算机可读程序指令加载到计算机、其它可编程数据处理装置、或其它设备上，使得在计算机、其它可编程数据处理装置或其它设备上执行一系列操作步骤，以产生计算机实现的过程，从而使得在计算机、其它可编程数据处理装置、或其它设备上执行的指令实现流程图和/或框图中的一个或多个方框中规定的功能/动作。

附图中的流程图和框图显示了根据本公开的多个实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或指令的一部分，所述模块、程序段或指令的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。对于本领域技术人员来说公知的是，通过硬件方式实现、通过软件方式实现以及通过软件和硬件结合的方式实现都是等价的。

以上已经描述了本公开的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。本公开的范围由所附权利要求来限定。

Claims (15)

1.一种分布式域名解析方法，其特征在于，应用于Kubernetes集群中，包括：

节点的第一域名服务器接收所述节点的本地对象发送的域名解析请求，其中，所述节点为所述Kubernetes集群中的任意一个节点，所述本地对象为所述节点内的应用对象，所述域名解析请求中包括待解析的域名；

在所述第一域名服务器的本地缓存数据中查询与所述待解析的域名匹配的地址数据；

将所述地址数据提供给所述本地对象。

2.根据权利要求1所述的方法，其特征在于，在所述查询之前，所述方法还包括：

从所述待解析的域名中解析出域名类型；

若所述域名类型表征所述待解析的域名为所述Kubernetes集群的内部域名，执行所述在所述第一域名服务器的本地缓存数据中查询与所述待解析的域名匹配的地址数据步骤。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

若所述域名类型表征所述待解析的域名为外部域名，将所述域名解析请求发送给第二域名服务器，以获取与所述待解析的域名相匹配的地址数据。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

若所述本地缓存数据中不存在与所述待解析的域名匹配的地址数据，在所述Kubernetes集群的集群配置数据中，获取与所述待解析的域名相匹配的地址数据。

5.根据权利要求4所述的方法，其特征在于，所述在所述Kubernetes集群的集群配置数据中，获取与所述待解析的域名相匹配的地址数据，包括：

向所述Kubernetes集群的接口服务器发送数据请求，其中，所述数据请求中包括所述待解析的域名；

接收所述接口服务器返回的对所述数据请求的响应消息；

从所述响应消息中，获得所述地址数据。

6.根据权利要求1所述的方法，其特征在于，所述本地缓存数据通过以下步骤获得：

按照预设时间间隔向所述Kubernetes集群的接口服务器发送获取集群配置数据的请求；

接收所述接口服务器返回的所述集群配置数据；

将所述集群配置数据缓存到本地缓存区。

7.根据权利要求1所述的方法，其特征在于，所述本地对象包括以下至少一种对象：容器组、原应用程序，其中，所述原应用程序是所述节点内除所述容器组以外的应用程序。

8.一种分布式域名解析装置，应用于Kubernetes集群中的任意一个节点的第一域名服务器中，包括：

请求接收模块，用于接收所述节点的本地对象发送的域名解析请求，其中，所述域名解析请求中包括待解析的域名，所述本地对象为所述节点内的应用对象；

地址数据查询模块，用于在所述第一域名服务器的本地缓存数据中查询与所述待解析的域名匹配的地址数据；

地址数据提供模块，用于将所述地址数据提供给所述本地对象。

9.根据权利要求8所述的装置，其特征在于，所述装置还包括：

请求分发模块，用于在所述地址数据查询模块执行所述查询之前，从所述待解析的域名中解析出域名类型；若所述域名类型表征所述待解析的域名为所述Kubernetes集群的内部域名，将所述域名解析请求发送给所述地址数据查询模块。

10.根据权利要求9所述的装置，其特征在于，所述请求分发模块还用于：

若所述域名类型表征所述待解析的域名为外部域名，将所述域名解析请求发送给第二域名服务器，以获取与所述待解析的域名相匹配的地址数据。

11.根据权利要求8所述的装置，其特征在于，若所述本地缓存数据中不存在与所述待解析的域名匹配的地址数据，所述地址数据查询模块还用于：

在所述Kubernetes集群的集群配置数据中，获取与所述待解析的域名相匹配的地址数据。

12.根据权利要求11所述的方法，其特征在于，所述地址数据查询模块在用于在所述Kubernetes集群的集群配置数据中，获取与所述待解析的域名相匹配的地址数据时，用于：

向所述Kubernetes集群的接口服务器发送数据请求，其中，所述数据请求中包括所述待解析的域名；

接收所述接口服务器返回的对所述数据请求的响应消息；

从所述响应消息中，获得所述地址数据。

13.根据权利要求8所述的方法，其特征在于，所述地址数据查询模块包括：

本地缓冲数据获得子模块，用于按照预设时间间隔向所述Kubernetes集群的接口服务器发送获取集群配置数据的请求；接收所述接口服务器返回的所述集群配置数据；将所述集群配置数据缓存到本地缓存区。

14.一种Kubernetes集群中的节点，其特征在于，包括权利要求8所述的装置；或者，

所述节点包括：

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

处理器，用于根据所述指令的控制运行所述节点执行如权利要求1-7任意一项所述的方法。

15.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有可被计算机读取执行的计算机程序，所述计算机程序用于在被所述计算机读取运行时，执行根据权利要求1-7中任意一项所述的方法。

Images