CN111464648B - 一种分布式本地dns系统及域名查询方法 - Google Patents

Abstract

本申请提供一种分布式本地DNS系统及域名查询方法，所述系统包括被部署在多个节点上的本地DNS服务和中心DNS服务。其中，本地DNS服务对应的服务器节点可以向各自节点上的容器提供域名解析服务，在接收到DNS查询请求后，先在节点缓存中查询应答结果，如果查询到应答结果，直接向客户端返回应答结果；如果未查询到应答结果再向中心DNS服务进行查询，以通过中心DNS服务获得DNS查询请求对应的IP地址并发送给客户端，从而减轻云平台上各业务对平台中心化DNS系统的依赖性。避免上层业务跨服务器访问基础DNS服务，同时，本地DNS服务还支持自动配置，并在出现故障时自动切换，缓解DNS系统故障对业务造成的影响。

Description

一种分布式本地DNS系统及域名查询方法

技术领域

本申请涉及云计算技术领域，尤其涉及一种分布式本地DNS系统及域名查询方法。

背景技术

DNS(Domain Name System，域名系统)是一种分布式网络目录服务，主要用于域名与IP地址的相互转换，以使客户端可以通过域名查询并访问指定的服务器。通用的DNS查询方式为：客户端向网络运营商提供的(或其他公共的)DNS递归服务器发起域名查询；DNS递归服务器先查询自身缓存，如缓存中有域名对应的IP地址，则告知客户端缓存的结果。如果缓存中没有域名对应的IP地址，则根据配置查询其他递归服务器或迭代查询根域名服务器至各级权威服务器获得IP地址，进行缓存后告知客户端查询的结果。

在容器云平台集群系统中，有许多微服务的容器实例分散部署在多个物理或虚拟的服务器，即节点上。各个微服务实例的IP地址是动态分配的，微服务之间的互相访问需要由集群系统提供一套集群中心DNS服务系统。容器云集群系统中的各服务实例之间可使用此DNS服务系统解析内部域名，并使用内部域名互相访问。

通常，可在容器云平台内部署一个集群中心化DNS服务，其服务内部记录有平台内部域名与IP的注册关系。平台内各个计算节点上的各个业务服务客户端都将其DNS服务器设置为此中心DNS服务的IP，即向此服务发送DNS查询请求。中心化DNS服务对于平台内部的域名可根据其维护的注册关系，缓存并告知客户端查询的结果；而对于平台以外的域名，则采用前述通用的方式，向互联网络上其他的DNS服务器进行查询，缓存并告知客户端查询的结果。

但是在大规模的容器云平台集群中，来自容器内的大量客户端，尤其是自身没有缓存的客户端，会对集群中心DNS服务造成了比较大并发服务的压力。使得传统DNS系统在应对突发流量时存在资源不足的风险。另外，当集群中心DNS服务出现故障时，各个节点上的服务都会受其影响，引发大量的业务失败。

发明内容

本申请提供了一种分布式本地DNS系统及域名查询方法，以解决传统DNS系统应对突发流量时，存在资源不足的问题。

一方面，本申请提供一种分布式本地DNS系统，包括多个节点；多个节点被分别配置作为客户端和/或服务器，以组成容器云平台；所述容器云平台中每个容器的宿主服务器节点上部署有本地DNS服务；所述容器云平台中的至少一个服务器节点还部署有中心DNS服务，作为本地DNS服务的上级递归DNS服务；

部署有本地DNS服务的节点被配置为：

接收所述客户端发送DNS查询请求；

在缓存中查询第一应答结果；所述第一应答结果包括在本节点缓存中存储的，所述DNS查询请求对应的IP地址；

如果在缓存中查询到所述第一应答结果，将所述第一应答结果发送至所述客户端；

如果在缓存中未查询到所述第一应答结果，将所述DNS查询请求发送至部署有中心DNS服务的节点；

接收第二应答结果；所述第二应答结果包括在署有中心DNS服务的节点缓存中存储的，所述DNS查询请求对应的IP地址；

缓存所述第二应答结果，以及将所述第二应答结果发送至所述客户端。

由以上技术方案可知，本申请提供一种分布式本地DNS系统，包括被部署在多个节点上的本地DNS服务和中心DNS服务。其中，本地DNS服务对应的服务器节点可以向各自节点上的容器提供域名解析服务，从而大幅度地减轻云平台上各业务对平台中心化DNS系统的依赖性。同时，避免上层业务跨服务器访问基础DNS服务，提高容器云平台DNS服务的可用性和平台上业务的服务性能与稳定性，减少平台DNS系统故障对业务造成的影响。

另一方面，本申请提供一种域名查询方法，应用于容器云平台；所述容器云平台中每个容器的宿主服务器节点上部署有本地DNS服务；所述容器云平台中的至少一个服务器节点还部署有中心DNS服务，作为本地DNS服务的上级递归DNS服务；

所述域名查询方法包括：

接收客户端发送DNS查询请求；

在缓存中查询第一应答结果；所述第一应答结果包括在本节点缓存中存储的，所述DNS查询请求对应的IP地址；

如果在缓存中查询到所述第一应答结果，将所述第一应答结果发送至所述客户端；

如果在缓存中未查询到所述第一应答结果，将所述DNS查询请求发送至部署有中心DNS服务的节点；

接收第二应答结果；所述第二应答结果包括在署有中心DNS服务的节点缓存中存储的，所述DNS查询请求对应的IP地址；

缓存所述第二应答结果，以及将所述第二应答结果发送至所述客户端。

由以上技术方案可知，本申请提供一种域名查询方法，所述方法可应用于容器云平台。所述方法在接收到DNS查询请求后，先在节点缓存中查询应答结果，如果查询到应答结果，直接向客户端返回应答结果；如果未查询到应答结果再向中心DNS服务进行查询，以通过中心DNS服务获得DNS查询请求对应的IP地址并发送给客户端。所述方法可以减轻云平台上各业务对平台中心化DNS系统的依赖性，解决传统DNS系统应对突发流量时，存在资源不足的问题。

附图说明

为了更清楚地说明本申请的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种容器云平台的结构示意图；

图2为本申请实施例提供的DNS系统结构示意图；

图3为本申请实施例提供的一种DNS域名查询方法流程示意图；

图4为本申请实施例提供的DNS交互流程示意图；

图5为本申请实施例提供的查询第二应答结果的流程示意图；

图6为本申请实施例提供的缓存外部IP地址的流程示意图；

图7为本申请实施例提供的探测切换装置处理流程示意图；

图8为本申请实施例提供的获取故障探测结果流程示意图；

图9为本申请实施例提供的判断本地DNS服务故障信息流程示意图；

图10为本申请实施例提供的切换DNS服务流程示意图。

具体实施方式

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

本申请提供的技术方案中，所述容器云平台是一种容器调度平台，例如Kubernetes等。通过容器云平台，可以构建企业级的分布式多租户容器管理平台，实现对软件的开发、集成、管理和运维。容器云平台具有大规模、高可靠性和高性能的特点。其中，容器，也称业务容器，是指能够操作多种数据结构和算法的模板类和函数库，可以在分布式网络平台中被任意节点调用，并通过与其他容器相互之间具有协同作用，以实现某一个总的功能。

参见图1，为本申请实施例一种容器云平台的结构示意图。由图1可知，在容器云平台中，可以包括多个节点，每个节点上设有特定的网络设备，如服务器等。这些节点可被分别配置，以作为客户端向发起与其他节点的协同作用，实现特定的功能。同时也可以作为服务器应邀与其他节点实现特定的功能。

不同的节点上可以对应配置有不同的容器，每个容器具有特定的数据处理功能，以便与其他节点进行连接而实现相应的功能。容器可以部署在节点的网络设备中，其中节点对应的网络设备即作为容器的宿主服务器。显然，容器与宿主服务器之间可以为一对一的关系，也可以是多对一的关系。即在一个宿主服务器上可以部署有多个业务容器。

实际应用中，当一个客户端想要调用容器云平台中的部分容器时，需要通过容器云平台提供的网络与容器对应的宿主服务器建立连接，以传输要处理的数据。由于容器云平台所包含的节点众多，因此，客户端需要准确地发现容器所在的宿主服务器，即对应的节点IP地址，才能够与宿主服务器建立连接。但由于IP地址是由数字构成的地址信息，例如192.0.2.123，并且相邻两个节点的IP地址差别很小，但所部署的容器功能可能差别很大，因此用户很容易因无法准确记住节点的IP地址，而无法调用相应的容器业务。

为了便于记录节点的IP地址，在容器云平台中可以使用域名系统(DNS)。域名系统可以通过字符串构成的域名，将IP地址与特定的字符串相关联，代替IP地址使用，以便于记住地址信息。例如，域名www.example.com代表IP地址192.0.2.123。通过域名系统，客户端在想与某一容器对应的宿主服务器节点建立连接时，只需要指定对应的域名，就可以通过DNS服务获取对应节点的IP地址，进而建立连接。

由于容器云平台内部具有众多节点，这些节点可以根据容器云平台的部署方式具有一定的规律性和层级关系。因此容器云平台内部可以拥有自己独立的域名系统，即部署独立的DNS服务。而当客户端发起访问时，可以根据连接目标节点的不同，分别发起与容器云平台内部节点的连接或与容器云平台以外的节点的连接。对于容器云平台内部的节点，可以使用部署在容器云平台的DNS服务实现域名查询及连接功能；对于容器云平台以外的节点，可以使用全网DNS系统实现域名查询及连接功能。

通常，对于容器云平台内的微服务间访问，可以引入容器云平台内部的域名及配套的平台中心化DNS服务，此时的域名查询流程如下：容器云平台提供集群中心化DNS服务；中心化DNS服务内部记录有平台内部域名与IP地址的注册关系。容器云平台内各个计算节点上的各个业务服务客户端都将其DNS服务器设置为此中心化DNS服务节点的IP地址。在需要访问时，客户端可以先向中心化DNS服务发送DNS查询请求。中心化DNS服务对于平台内部域名，根据其维护的注册关系向客户端应答IP地址；对于平台外的域名，可采用通用的公共DNS查询方法，向互联网络上的DNS服务器进行查询，缓存并告知客户端查询的结果。

以Kubernetes容器云平台为例：Kubernetes平台提供了一个集群插件kube-dns，在集群内使用Deployment部署多个同样配置的kube-dns实例，分散在不确定的多个节点上，并对客户端提供一个虚拟IP地址，各个节点上的业务容器，均配置其对应的DNS服务器IP为此虚拟IP地址。

当任意一个客户端发起DNS查询请求时，可以直接将DNS查询请求转向此虚拟IP地址，并由集群插件kube-dns完成DNS查询回应。如果DNS查询请求查询的域名对应节点在Kubernetes平台内部，则可以直接通过内部域名与IP地址的注册关系，向客户端反馈DNS查询的回应结果；如果DNS查询请求查询的域名对应节点不在Kubernetes平台内部，可以直接将DNS查询请求转发给互联网中的DNS服务器，实现通过公共网络服务器IP地址的查询。

由于容器云平台内部的节点具有相互关联和层级关系，因此可以由容器云平台集中在多个kube-dns实例间对客户端请求进行负载均衡。即通过负载均衡器实现部分客户端或服务器发起的DNS查询请求由部分中心化DNS服务的节点处理，从而分担中心化DNS服务的节点负荷，综合利用算力资源。

为了提高容器云平台DNS服务处理效率，减少业务受损情况，本申请提供一种分布式本地DNS系统。如图1所示，所述分布式本地DNS系统包括多个节点；多个节点被分别配置作为客户端和/或服务器，以组成容器云平台，适应总体的业务功能需要。

其中，所述容器云平台中每个容器的宿主服务器节点上部署有本地DNS服务。由于容器云平台包括多个节点，并且多个节点上都部署有容器对应的业务实例，因此本申请中容器云平台的多个节点都被配置有所述本地DNS服务，即实现分布式部署，通过多个节点共同完成针对容器云平台内部的DNS服务。所述本地DNS服务包括与域名系统相关的查询、解析、缓存、连接等功能。

所述本地DNS服务同样可以集群插件的形式部署在多个服务器节点中。并且，部署有本地DNS服务的节点，应包含缓存装置以及具有足够的数据处理能力和数据缓存能力，以便及时处理客户端发送的DNS查询请求，并将常用的域名信息与IP地址存储在缓存装置中，实现快速回应。

同时，针对本地DNS服务无法得到回应结果的DNS查询请求，例如针对容器云平台以外DNS查询请求，以及针对本地DNS服务无法缓存的DNS查询请求。本申请中所述容器云平台中的至少一个服务器节点还部署有中心DNS服务。中心DNS服务可以直接面向业务容器的客户端提供服务，还被本地DNS服务配置为上级递归DNS服务。其中，部署有中心DNS服务的节点可以对本地DNS服务节点中未缓存的DNS访问请求进行DNS查询回应，因此中心DNS服务作为本地DNS服务的上级递归DNS服务。

需要说明的是，上述中心DNS服务作为本地DNS服务的上级递归DNS服务仅仅针对DNS服务本身，并不对节点或容器业务的层级关系构成限定。实际应用中，部署有本地DNS服务的节点和部署有中心DNS服务的节点可以是父子关系也可以是兄弟关系，实现真正的分布式部署关系。

为了实现容器云平台内部的DNS查询及缓存服务，如图2、图3、图4所示，部署有本地DNS服务的节点被配置为：

S1：接收所述客户端发送DNS查询请求。

客户端需要访问某个容器业务实例时，需要首先发起DNS查询请求。在DNS查询请求中，可以包括指定容器业务实例的节点域名，如在平台开发程序中指定目标业务容器的域名为www.example.com；在计算节点在运行相应的开发程序后，可以向部署有本地DNS服务的发送一个包含该域名的DNS查询请求。

S2：在缓存中查询第一应答结果。

部署有本地DNS服务的节点在接收到DNS查询请求后，可以对DNS查询请求进行解析，确定客户端需要访问的域名地址，并在缓存中查询针对所查询域名信息的第一应答结果。通常，作为DNS服务的节点中，可以根据所查询过的域名信息状况，缓存一部分域名信息对应的IP地址数据，以便下一次查询域名信息时，可以直接从缓存中调用，而不必再向上级递归DNS服务器进行查询，以节省查询消耗的时间。其中，所述第一应答结果包括在本节点缓存中存储的，所述DNS查询请求对应的IP地址数据。例如，从DNS查询请求中解析获得所查询的域名为www.example.com，则部署有本地DNS服务的节点可以www.example.com作为索引值，在缓存中查询与之具有注册关系的IP地址数据。

S3：如果在缓存中查询到所述第一应答结果，将所述第一应答结果发送至所述客户端。

实际应用中，根据节点的缓存容量和设定的更新频率，部署有本地DNS服务的节点缓存装置中存储的域名信息是实时更新的。例如，对于客户端不经常访问的节点IP地址，会在存活一定时长后，自动从缓存中删除，以便节点能够缓存更多的域名信息。

因此，部署有本地DNS服务的节点在解析DNS查询请求后，会在缓存中查询相对应的IP地址，以作为第一应答结果。如果在缓存中查询到IP地址，则将对应的IP地址数据提取并作为第一应答结果发送至客户端。例如，以www.example.com作为索引值，在缓存中查询到与之对应的IP地址为192.0.2.123，则将IP地址进行提取，并作为第一应答结果发送给客户端节点。

S4：如果在缓存中未查询到所述第一应答结果，将所述DNS查询请求发送至部署有中心DNS服务的节点。

在部署有本地DNS服务的节点缓存中没有存储某一DNS查询请求对应的IP地址数据，或者节点中缓存的IP地址数据已到期失效时，在缓存中将不能查询到第一应答结果。因此，在本地DNS服务节点的缓存中未查询到DNS查询请求对应的IP地址时，本地DNS服务可以继续向上级递归DNS服务，即中心DNS服务，进行查询，以在上级递归DNS服务查询到DNS查询请求对应的IP地址。因此，如果在缓存中未查询到第一应答结果，部署有本地DNS服务的节点可以将DNS查询请求转发至部署有中心DNS服务的节点。

S5：接收第二应答结果。

其中，所述第二应答结果包括在署有中心DNS服务的节点缓存中存储的，所述DNS查询请求对应的IP地址。接收到DNS查询请求的中心DNS服务节点，可以针对DNS查询请求在缓存中查询与之对应的IP地址。并且，如果在节点缓存中查询到对应的IP地址，则提取IP地址并将IP地址作为第二应答结果反馈给本地DNS服务节点。

例如，在本地DNS服务节点中未查询到第一应答结果时，中心DNS服务节点将从DNS查询请求中解析获得所查询的域名为www.example.com。同时，以www.example.com作为索引值，在中心DNS服务节点缓存中查询与之对应的IP地址，如192.0.2.123，则将IP地址进行提取，并作为第二应答结果发送给本地DNS服务节点。

S6：缓存所述第二应答结果，以及将所述第二应答结果发送至所述客户端。

部署有本地DNS服务的节点在接收到中心DNS服务节点反馈的第二应答结果后，一方面可以将第二应答结果中的IP地址信息进行缓存，以便下一次查询相同域名时，能够直接从缓存中获取对应的IP地址，即缓存后的IP地址信息可以在后续查询服务中，以第一应答结果的形式反馈给客户端。部署有本地DNS服务的节点另一方面还将第二应答结果直接转发给客户端，使客户端可以按照接收到的第二应答结果，确定目标服务器IP地址，从而实现与目标服务器的连接。

基于上述方案，在本申请提供的分布式本地DNS系统中，在容器云平台的每个服务器节点上部署一套本地DNS服务，并且部分节点配置有容器云平台集群中心化DNS服务，作为本地DNS服务的上级递归DNS服务器。其中，配置各节点上的业务容器所对应DNS服务器IP，可以设置为其所在节点对应的本地DNS服务的IP地址，在需要DNS服务时，直接访问本地DNS服务对应的IP地址。

实际应用时，容器内的某个业务客户端会将DNS查询请求发送到本节点上的本地DNS服务。在本节点已有缓存的情况下，会直接响应客户端的DNS查询请求，而不必再向集群中心DNS服务发起查询。仅在本节点未缓存或缓存已到期失效的情况下，才向集群中心DNS服务转发该DNS查询请求，并缓存响应结果以备后续使用。

相对于仅使用集群中心DNS系统的传统方案，本申请可将来自各客户端，尤其是自身没有DNS缓存功能的客户端，的大部分DNS查询请求导向本节点上的本地DNS服务进行缓存查询。仅在本节点DNS缓存未覆盖或是已到期时才向集群中心DNS服务发起DNS查询请求，从而由分布在各节点的本地DNS服务分担处理DNS处理工作，避免大规模集群中，突增的流量、高并发地集中到集群中心DNS服务，缓解形成的性能瓶颈。

同时，由于采用分布式部署，不必再为原来中心化DNS服务预留太多缓存资源和计算资源，可以充分应对访问压力。分散在各节点上的本地DNS服务，也不占用平台节点太多的缓存资源和计算资源，即可分担主要的DNS服务压力，避免预留资源浪费的同时，提高平台DNS系统的可用性。此外，由于本地DNS服务在存储有DNS缓存时，本节点上的业务容器不再实时依赖平台中心DNS服务，可大幅缩减中心DNS系统出现故障或亚健康状况时受影响的节点波及范围。

对于本地DNS服务节点缓存中未查询到第一应答结果时，本地DNS服务节点会将DNS查询请求转发给部署有中心DNS服务的节点，中心DNS服务节点可以针对DNS查询请求在缓存中查询IP地址，并作为第二应答结果反馈给本地DNS服务节点。其中，第二应答结果可以根据中心DNS服务的查询结果包括两种形式，即在一种实现方式中，所述第二应答结果包括在中心DNS服务节点缓存中存储的，所述DNS查询请求对应的IP地址；或者，由中心DNS服务上级递归DNS服务系统反馈的，所述DNS查询请求对应的IP地址。

相应的，如图5所示，部署有中心DNS服务的节点还被进一步配置为：

S401：接收所述DNS查询请求；

S402：在缓存中查询所述第二应答结果；

S403：如果在缓存中查询到所述第二应答结果，将所述第二应答结果发送至部署有本地DNS服务的节点；

S404：如果在缓存中未查询到所述第二应答结果，向所述中心DNS服务的上级递归DNS服务系统发送所述DNS查询请求。

部署有中心DNS服务的节点可以在接收到DNS查询请求后，先在节点的缓存中查询IP地址，如果在缓存中查询到对应的IP地址，则将IP地址作为第二应答结果反馈给本地DNS服务节点。如果在缓存中未查询到对应的IP地址，则向中心DNS服务的上级递归DNS服务系统进行查询，如互联网公共DNS服务器、其他递归服务器、根域名服务器以及各级权威服务器。

对于向所述中心DNS服务的上级递归DNS服务系统发送DNS查询请求的情况，如图6所示，部署有中心DNS服务的节点被进一步配置为：

S4041：接收外部IP地址；

S4042：向部署有本地DNS服务的节点发送所述外部IP地址；

S4043：缓存所述外部IP地址。

中心DNS服务的上级递归DNS服务系统在接收到DNS查询请求后，可以针对DNS查询请求执行域名查询服务，获得外部IP地址。即，所述外部IP地址为由上级递归DNS服务系统反馈的，所述DNS查询请求对应的IP地址。例如，公共DNS递归服务器先查询自身缓存，如缓存中有域名对应的IP地址，则在缓存中提取对应的IP地址，并作为第二应答结果反馈给中心DNS服务节点。如果缓存中没有该域名对应的IP地址，则根据配置查询其他递归服务器或迭代查询根域名服务器至各级权威服务器获得IP地址，并将获得的IP地址作为第二应答结果反馈给中心DNS服务节点。

部署有中心DNS服务的节点在接收到外部IP地址后，可以向部署有本地DNS服务的节点发送所述外部IP地址，以便本地DNS服务节点将反馈的IP地址发送给客户端，完成DNS查询服务。

可见，在本实施例中，如果在中心DNS服务节点的缓存中未查询到所述第二应答结果，中心DNS服务节点可以相对作为客户端向公用DNS递归服务器发起DNS查询请求，从而获得在公网中该域名与IP地址的对应关系。因此，在本实施例中，可以在保证域名查询准确率的前提下，仅在中心DNS服务节点缓存中未查询到第二应答结果时，向公共DNS服务器查询域名，减少中心DNS服务节点的工作负荷，提高查询效率。

为了实现DNS服务，本申请提供的DNS系统可以自动设置规则，为使用本地DNS服务的容器自动进行DNS客户端的配置。自动的规则设置可以充分发挥容器云平台的运维优势，使得上层业务系统无需感知和适配平台底层服务形式的变化，即可在需要时自动使用本地DNS服务。

因此，在一种实现方式中，部署有本地DNS服务的节点具有固定的虚拟IP地址。可以通过设置基于虚拟IP地址的转发规则，从而可以使用自动切换装置将DNS查询请求切换至本地DNS服务。虚拟IP地址，可以更方便地对本地DNS服务进行自动调整，来进一步提升DNS系统的可用性，优化系统的服务性能，同时不对使用了本系统的上层业务产生明显的影响。相应的，部署有本地DNS服务的节点还被配置为：

通过IP地址转换，将访问所述虚拟IP地址的所述DNS查询请求转向期望的DNS服务。为了确定转发规则，本实施例可以设置容器使用的DNS服务器为固定的虚拟IP地址，再使用IP地址转换方式(NAT，Network Address Translation，网络地址转换)将访问此虚拟IP地址的请求，自动转向期望的DNS服务，即转向本地DNS服务。

部署有本地DNS服务的节点还被配置为：通过自动调整路由规则，将访问所述虚拟IP地址的所述DNS查询请求转向期望的DNS服务。即设置容器使用的DNS服务器为固定的虚拟IP地址，通过自动调整路由规则，当客户端发出的访问请求为DNS服务请求时，可以使请求转向期望的DNS服务，即转向本地DNS服务。

显然，DNS服务转发规则的设定，可以包括但不限于上述两种方式，在一种实现方式中，还可以直接设置容器的DNS服务器为期望的IP地址，同样能够实现将访问请求转向期望的DNS服务，但这种方式需要配合支持自动检测配置变更的客户端使用。

实际应用中，在集群中心DNS服务实例或者网络发生故障时，容器云平台的通用健康检查需要一定时间才能发现故障，并停止向故障实例转发请求，这期间从多个节点上访问到故障实例的业务系统DNS请求均会失败，导致较大范围的业务受损。同时，随着集群业务规模的不断扩大，集群中心化DNS服务的访问压力也比较大，尤其是在一部分业务流量突增时，集群中心DNS实例扩容及故障修复的速度可能不及业务流量增长速度，因此，中心DNS服务的高负载会对所有使用DNS系统的业务都造成一定风险。

为解决上述问题，可以为容器里的客户端配置主/备多个DNS服务器IP，但这受限于客户端的实现方式，不能有效的避免DNS对业务的影响。例如，一些客户端会顺序尝试各个IP，但业务可接受的超时时间(一般1至2秒)远低于主DNS解析失败后再尝试其他DNS服务器所需的时间，不能在DNS故障时避免大范围业务受损；另一些客户端会并行使用多个IP进行DNS解析，则会进一步加重集群中心化DNS服务的压力。

因此，在一种实现方式中，所述本地DNS服务设有检查接口。检查接口允许平台更准确地确定其状态并采取措施纠正异常状态。检查接口可以采用多种方式，例如：DNS协议接口，解析指定域名可以获得节点本地DNS服务的运行状态，可以更准确地反映DNS服务的可用性。或者，采用HTTP协议接口，访问指定URL可以获得节点本地DNS服务的运行状态，方便与既有的监控系统对接。检查接口可以反映服务运行或崩溃之外更为详细的运行状况。例如，能否响应DNS查询，资源是否充足，是否将要有计划地重启或升级维护等。

相应的，所述容器云平台中的节点上还部署有探测切换装置。如图7、图8所示，部署有所述探测切换装置的节点被配置为：

S71：通过所述检查接口获取当前本地DNS服务的故障探测结果；

S72：根据所述故障探测结果，将所述DNS查询请求发送至目标服务。

实际应用中，还可以在容器云平台的每个节点上部署微型的DNS缓存服务进行故障探测和切换的装置，从而根据探测结果进行规则的自动切换。提高平台在DNS服务异常时的可用性，降低新引入的本地DNS服务对平台可用性的潜在影响。

探测切换装置可根据自动探测的结果，或者运维人员的操作指令，自动将容器的DNS查询请求流量转向目标服务，即转向部署有本地DNS服务的节点、部署有中心DNS服务的节点、备用服务节点中的一种节点。

为了实现通过所述检查接口获取当前本地DNS服务的故障探测结果，如图9所示，部署有所述探测切换装置的节点还被配置为：

S711：定时向部署有本地DNS服务的节点发送DNS解析请求；

S712：获取部署有本地DNS服务的节点反馈的检查结果；

S713：根据所述检查结果的中解析成败次数，判断本地DNS服务的故障信息。

部署有所述探测切换装置的节点可以通过检查接口，定时向部署有本地DNS服务的节点发送DNS解析请求，从而获取反馈的检查结果。其中，定时发送的时长可以按照实际测试条件、系统响应速度以及云平台的活跃情况进行设定，例如每间隔1s或3s向本地DNS服务节点发送一次DNS解析请求。所发送的DNS解析请求是用于测试DNS解析过程的一种DNS查询请求，其DNS解析请求中可以指定测试的域名，以获得对应的测试IP地址。所述检查结果包括多次发送的所述DNS解析请求对应的IP地址。再根据检查结果中的解析成败次数，判断本地DNS服务的故障信息。

所述探测切换装置可以包括探测装置和自动切换装置。探测装置和自动切换装置可以协同工作，由探测装置定时向本节点的本地DNS服务发起DNS解析请求；由自动切换装置根据检查结果自动控制转发规则，将请求转向本地DNS服务还是中心DNS服务。

此外，探测装置和自动切换装置定时发起的DNS探测请求可以使用本地DNS服务提供的DNS协议的检查接口，提前知晓其即将进行的升级维护等有计划的变更，提前控制转发规则切换。因此，可以在更合适的时机进行切换，而不必在DNS彻底失效后才进行切换，进一步提高本系统的可用性，避免DNS服务不稳定对业务造成的影响。

因此，如图10所示，部署有所述探测切换装置的节点还被配置为：

S7131：获取所述检查结果中的连续成功次数和连续失败次数；

S7132：如果所述连续成功次数大于预设判断阈值，确定本地DNS服务正常运行，所述目标服务为本地DNS服务；

S7133：将所述DNS查询请求发送至本地DNS服务；

S7134：如果所述连续失败次数大于预设判断阈值，确定本地DNS服务出现异常，所述目标服务为中心DNS服务；

S7135：将所述DNS查询请求发送至中心DNS服务。

本实施例中，若DNS解析连续成功次数达到阈值，即解析结果为“NO ERROR”，且有效记录数大于0，则修改规则，使DNS请求转向节点本地DNS服务。若DNS解析连续失败次数达到阈值，则修改规则，使DNS请求转向集群中心DNS服务。

具体在实际运行中，探测过程可以如下：先检查系统配置，初始化系统，将DNS正常、异常计数均置零，并初始化转发规则；探测切换装置再向本地DNS服务节点发出探测请求，即发起一个用于测试的DNS查询指令，等待响应。如果DNS解析成功则在DNS正常计数+1，DNS异常计数清零；当DNS正常计数＜设定的正常阈值时，循环开始下一次探测；当DNS正常计数＞设定的正常阈值时，调整规则使用本地DNS服务。

如果DNS解析失败或者解析超时，则DNS异常计数+1，DNS正常计数清零；当DNS异常计数＜设定的异常阈值时，循环开始下一次探测；当DNS异常计数＞设定的异常阈值时，调整规则为使用中心DNS服务。

通过上述规则修改方式，可以实现在本地DNS服务节点可用时，使用本节点的本地DNS服务，以此来提高容器内业务的性能和稳定性，避免完全依赖于跨节点的集群中心DNS访问，减小因节点间网络或集群中心DNS服务波动的影响范围和严重性。而在本节点的本地DNS服务出现故障时，可以迅速、便捷地将DNS服务切换至中心DNS服务，避免因本地DNS服务的引入对业务稳定性造成影响，提高服务的可用性。

在一种实现方式中，部署有本地DNS服务的节点上还部署有多个微型DNS服务实例；部署有探测切换装置的节点还被配置为：如果所述DNS查询请求对应的节点本地DNS服务出现异常，将所述DNS查询请求发送至与异常节点的所述微型DNS服务实例相同的备用服务节点。

本实施例可以在每个节点上部署多个微型DNS服务实例，故障探测和自动切换装置可以分别进行探测，在其中部分DNS服务故障时将容器DNS请求切换到本节点上其他正常的DNS服务，而不必直接切换到中心DNS服务。进一步提高本系统的可用性，同时降低中心DNS系统的服务压力。

另外，本系统还可以部署一个控制使用本地DNS服务的开关，以便启用或关闭本地DNS服务功能。还可以为每个业务容器单独启用或关闭本地DNS功能，以根据实际需要选择DNS服务方式。

由以上技术方案可知，本申请提供一种分布式本地DNS系统，包括被部署在多个节点上的本地DNS服务和中心DNS服务。其中，本地DNS服务对应的服务器节点可以向各自节点上的容器提供域名解析服务，从而大幅度地减轻云平台上各业务对平台中心化DNS系统的依赖性。同时，避免上层业务跨服务器访问基础DNS服务，提高容器云平台DNS服务的可用性和平台上业务的服务性能与稳定性，减少平台DNS系统故障对业务造成的影响。

基于上述分布式本地DNS系统，本申请还提供一种域名查询方法，所述方法应用于容器云平台；所述容器云平台中每个容器的宿主服务器节点上部署有本地DNS服务；所述容器云平台中的至少一个服务器节点还部署有中心DNS服务，作为本地DNS服务的上级递归DNS服务。

所述域名查询方法包括：

S1：接收客户端发送DNS查询请求；

S2：在缓存中查询第一应答结果；所述第一应答结果包括在本节点缓存中存储的，所述DNS查询请求对应的IP地址；

S3：如果在缓存中查询到所述第一应答结果，将所述第一应答结果发送至所述客户端；

S4：如果在缓存中未查询到所述第一应答结果，将所述DNS查询请求发送至部署有中心DNS服务的节点；

S5：接收第二应答结果；所述第二应答结果包括在署有中心DNS服务的节点缓存中存储的，所述DNS查询请求对应的IP地址；

S6：缓存所述第二应答结果，以及将所述第二应答结果发送至所述客户端。

以容器云平台Kubernetes为例，所述域名查询方法可以通过如下方式实施：

通过在容器云平台内部署两个DaemonSets，即：dns-cache服务和dns-check服务。其中，dns-cache服务可以使用现有转发和缓存功能的成熟通用的DNS服务器软件，进行定制配置或二次开发。dns-cache服务可以监听配置于节点本地的一个IP地址，向中心DNS服务转发查询请求，并缓存结果，稳定高效地提供基础DNS服务，即实现在容器云平台的每个容器的宿主服务器节点上分布式地部署一套本地DNS服务。

dns-cache服务可以向kubelet提供http协议检查接口(http://IP:8000/ready)，用于在故障时自动重启,实现与既有的监控系统对接。dns-cache服务向dns-check提供DNS协议检查接口(ready.dns-check.local.IN CH)，用于在故障或升级时实现自动流量切换，从而解析指定域名可以获得节点本地DNS服务的运行状态，更准确地反映DNS服务的可用性。

dns-check服务可作为新开发的一个微服务，实现基于虚拟IP地址的转发规则，在必要时可以使用自动切换装置切换转发到的目标DNS服务。再设置iptables和路由规则，允许访问本地DNS服务的虚拟IP地址的流量发送至dns-cache服务。使用dns-cache提供的接口检查其可用性，控制iptables规则，将往来于本地DNS服务的虚拟IP地址的流量在本地DNS服务不正常时，重定向到集群级中心DNS服务监听的远程IP端口上；在本地DNS服务功能正常时，恢复发送到本地DNS服务监听的IP端口上，而实现自动化的故障探测和切换。

在当前提供服务的本地DNS实例不正常时，修改路由规则，将访问本地DNS服务的虚拟IP地址的流量重定向到正常的业务实例上。在所有本地实例均不正常时，重定向到集群级DNS服务监听的远程IP端口上，进一步提高系统的可用性。

再通过修改Kubernetes的kubelet组件，使其可以根据运维人员给出的pod对象信息(.spec.DNSType值是否为Local)，控制将容器的/etc/resolv.conf中的DNS服务器地址自动设置为本地DNS服务还是中心DNS服务。

由以上技术方案可知，本申请提供一种域名查询方法，所述方法可应用于容器云平台。所述方法在接收到DNS查询请求后，先在节点缓存中查询应答结果，如果查询到应答结果，直接向客户端返回应答结果；如果未查询到应答结果再向中心DNS服务进行查询，以通过中心DNS服务获得DNS查询请求对应的IP地址并发送给客户端。所述方法可以减轻云平台上各业务对平台中心化DNS系统的依赖性，解决传统DNS系统应对突发流量时，存在资源不足的问题。

本申请提供的实施例之间的相似部分相互参见即可，以上提供的具体实施方式只是本申请总的构思下的几个示例，并不构成本申请保护范围的限定。对于本领域的技术人员而言，在不付出创造性劳动的前提下依据本申请方案所扩展出的任何其他实施方式都属于本申请的保护范围。

Claims (9)

1.一种分布式本地DNS系统，其特征在于，包括多个节点；多个节点被分别配置作为客户端和/或服务器，以组成容器云平台；所述容器云平台中每个容器的宿主服务器节点上部署有本地DNS服务；部署有本地DNS服务的节点具有固定的虚拟IP地址；所述容器云平台中的至少一个服务器节点还部署有中心DNS服务，作为本地DNS服务的上级递归DNS服务；

部署有本地DNS服务的节点被配置为：

接收所述客户端发送DNS查询请求；

在缓存中查询第一应答结果；所述第一应答结果包括在本节点缓存中存储的，所述DNS查询请求对应的IP地址；

如果在缓存中查询到所述第一应答结果，将所述第一应答结果发送至所述客户端；

如果在缓存中未查询到所述第一应答结果，将所述DNS查询请求发送至部署有中心DNS服务的节点；

接收第二应答结果；所述第二应答结果包括在部署有中心DNS服务的节点缓存中存储的，所述DNS查询请求对应的IP地址；

缓存所述第二应答结果，以及将所述第二应答结果发送至所述客户端；

部署有本地DNS服务的节点还被配置为：

通过IP地址转换，将访问所述虚拟IP地址的所述DNS查询请求转向期望的DNS服务；或者，通过自动调整路由规则，将访问所述虚拟IP地址的所述DNS查询请求转向期望的DNS服务。

2.根据权利要求1所述的分布式本地DNS系统，其特征在于，所述第二应答结果包括在中心DNS服务节点缓存中存储的，所述DNS查询请求对应的IP地址；

或者，由中心DNS服务上级递归DNS服务系统反馈的，所述DNS查询请求对应的IP地址。

3.根据权利要求2所述的分布式本地DNS系统，其特征在于，部署有中心DNS服务的节点被进一步配置为：

接收所述DNS查询请求；

在缓存中查询所述第二应答结果；

如果在缓存中查询到所述第二应答结果，将所述第二应答结果发送至部署有本地DNS服务的节点；

如果在缓存中未查询到所述第二应答结果，向所述中心DNS服务的上级递归DNS服务系统发送所述DNS查询请求。

4.根据权利要求3所述的分布式本地DNS系统，其特征在于，部署有中心DNS服务的节点被进一步配置为：

接收外部IP地址；所述外部IP地址为由上级递归DNS服务系统反馈的，所述DNS查询请求对应的IP地址；

向部署有本地DNS服务的节点发送所述外部IP地址；

缓存所述外部IP地址。

5.根据权利要求1所述的分布式本地DNS系统，其特征在于，所述本地DNS服务设有检查接口；所述容器云平台中的节点上还部署有探测切换装置；部署有所述探测切换装置的节点被配置为：

通过所述检查接口获取当前本地DNS服务的故障探测结果；

根据所述故障探测结果，将所述DNS查询请求发送至目标服务；所述目标服务为本地DNS服务、中心DNS服务、备用服务中的一种。

6.根据权利要求5所述的分布式本地DNS系统，其特征在于，部署有所述探测切换装置的节点还被配置为：

定时向部署有本地DNS服务的节点发送DNS解析请求；

获取部署有本地DNS服务的节点反馈的检查结果；所述检查结果包括多次发送的所述DNS解析请求对应的IP地址；

根据所述检查结果的中解析成败次数，判断本地DNS服务的故障信息。

7.根据权利要求6所述的分布式本地DNS系统，其特征在于，部署有所述探测切换装置的节点还被配置为：

获取所述检查结果中的连续成功次数和连续失败次数；

如果所述连续成功次数大于预设判断阈值，确定本地DNS服务正常运行，所述目标服务为本地DNS服务；

将所述DNS查询请求发送至本地DNS服务；

如果所述连续失败次数大于预设判断阈值，确定本地DNS服务出现异常，所述目标服务为中心DNS服务；

将所述DNS查询请求发送至中心DNS服务。

8.根据权利要求5所述的分布式本地DNS系统，其特征在于，部署有本地DNS服务的节点上还部署有多个微型DNS服务实例；部署有探测切换装置的节点还被配置为：

如果所述DNS查询请求对应的节点本地DNS服务出现异常，将所述DNS查询请求发送至与异常节点的所述微型DNS服务实例相同的备用服务节点。

9.一种域名查询方法，其特征在于，应用于容器云平台；所述容器云平台中每个容器的宿主服务器节点上部署有本地DNS服务；部署有本地DNS服务的节点具有固定的虚拟IP地址；所述容器云平台中的至少一个服务器节点还部署有中心DNS服务，作为本地DNS服务的上级递归DNS服务；

所述域名查询方法包括：

接收客户端发送DNS查询请求；

在缓存中查询第一应答结果；所述第一应答结果包括在本节点缓存中存储的，所述DNS查询请求对应的IP地址；

如果在缓存中查询到所述第一应答结果，将所述第一应答结果发送至所述客户端；

如果在缓存中未查询到所述第一应答结果，将所述DNS查询请求发送至部署有中心DNS服务的节点；

接收第二应答结果；所述第二应答结果包括在部署有中心DNS服务的节点缓存中存储的，所述DNS查询请求对应的IP地址；

缓存所述第二应答结果，以及将所述第二应答结果发送至所述客户端；

通过IP地址转换，将访问所述虚拟IP地址的所述DNS查询请求转向期望的DNS服务；或者，通过自动调整路由规则，将访问所述虚拟IP地址的所述DNS查询请求转向期望的DNS服务。

Images