一种容器云平台的域名解析方法、系统、介质和电子设备

技术领域

本申请涉及云原生技术领域，特别涉及一种容器云平台的域名解析方法、系统、计算机可读存储介质和电子设备。

背景技术

在容器云平台中，不同容器组(Pod)之间通过IP地址进行相互访问。在访问容器组之前，通常只知道要访问的容器组的域名，因而，需要经由域名解析服务对要访问的容器组的域名进行解析，获取要访问的容器组的IP地址，然后再向要访问的容器组发出访问请求数据包。

目前，通常在容器云平台中使用相应的域名解析服务组件提供域名解析服务，但是，当出现访问流量过高的情况时，域名解析服务组件经常会出现域名解析负担过重而导致崩溃，无法正常工作，使得发出访问请求的容器组无法正常获取要访问的容器组的IP地址，致使访问流量无法到达要访问的容器组。

因而，亟需提供一种针对上述现有技术不足的技术方案。

发明内容

本申请的目的在于提供一种容器云平台的域名解析方法、系统、计算机可读存储介质和电子设备，以解决或缓解上述现有技术中存在的问题。

为了实现上述目的，本申请提供如下技术方案：

本申请提供一种容器云平台的域名解析方法，用于源容器组向目的容器组的访问，其中，所述源容器组为发出访问请求的容器组，所述目的容器组为所述访问请求要访问的容器组；所述源容器组、所述目的容器组均位于所述容器云平台，所述容器云平台的域名解析方法包括：检测到源容器组生成域名解析需求；响应于预先写入的内核域名映射表中包含所述目的容器组的域名，所述源容器组使用操作系统内核访问所述内核域名映射表，以获取所述目的容器组的IP地址；其中，所述内核域名映射表中包含所述目的容器组的域名和所述目的容器组的IP地址的映射关系；响应于所述内核域名映射表中未包含所述目的容器组的域名，所述源容器组向域名解析服务组件发出域名解析请求，以获取所述目的容器组的IP地址；其中，所述域名解析服务组件部署于所述容器云平台。

优选的，在所述检测到源容器组生成域名解析需求之前，还包括：对所述域名解析服务组件进行监控，以基于所述域名解析请求指向的容器组的频次，确定所述容器云平台中的高频目的容器组；向指定容器组的内核域名映射表中写入所述高频目的容器组的域名和IP地址的映射关系。

优选的，所述向指定容器组的内核域名映射表中写入高频目的容器组的域名和IP地址的映射关系，包括：基于发出指向所述高频目的容器组的域名解析请求的容器组的频次，确定所述高频目的容器组对应的高频源容器组；向所述高频源容器组的内核域名映射表中写入所述高频目的容器组的域名和IP地址的映射关系。

优选的，所述向所述高频源容器组的内核域名映射表中写入所述高频目的容器组的域名和IP地址的映射关系，包括：通过容器操作指令向所述高频源容器组的内核域名映射表中写入所述高频目的容器组的域名和IP地址的映射关系。

优选的，所述向所述高频源容器组的内核域名映射表中写入所述高频目的容器组的域名和IP地址，包括：创建或修改容器组控制器的配置文件，并将所述高频目的容器组的域名和IP地址的映射关系写入所述配置文件中的指定字段；对所述配置文件在所述高频源容器组中进行部署或更新，以将所述高频目的容器组的域名和IP地址的映射关系写入所述高频源容器组的内核域名映射表。

优选的，所述容器云平台的域名解析方法还包括：对所述域名解析服务组件进行监控，以基于发出所述域名解析请求的容器组的频次，确定所述容器云平台中的异常源容器组。

优选的，所述域名解析服务组件包括节点DNS缓存和DNS组件，对应的，所述源容器组向域名解析服务组件发出域名解析请求，以获取所述目的容器组的IP地址，包括：响应于所述节点DNS缓存中存储有所述目的容器组的域名和IP地址的映射关系，则所述节点DNS缓存将所述目的容器组的IP地址反馈至所述源容器组；否则，将所述域名解析请求发送至所述DNS组件，以由所述DNS组件对所述目的容器组的域名进行解析，以获取所述目的容器组的IP地址。

本申请实施例还提供一种容器云平台的域名解析系统，用于源容器组向目的容器组的访问，其中，所述源容器组为发出访问请求的容器组，所述目的容器组为所述访问请求要访问的容器组，所述源容器组、所述目的容器组均位于所述容器云平台，所述容器云平台的域名解析系统包括：需求监控单元，配置为检测到源容器组生成域名解析需求；第一获取单元，配置为响应于预先写入的内核域名映射表中包含所述目的容器组的域名，所述源容器组使用操作系统内核访问所述内核域名映射表，以获取所述目的容器组的IP地址；其中，所述内核域名映射表中包含所述目的容器组的域名和所述目的容器组的IP地址的映射关系；第二获取单元，配置为响应于所述内核域名映射表中未包含所述目的容器组的域名，所述源容器组向域名解析服务组件发出域名解析请求，以获取所述目的容器组的IP地址；其中，所述域名解析服务组件部署于所述容器云平台。

本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，所述程序为如上任一所述的容器云平台的域名解析方法。

本申请实施例还提供一种电子设备，包括：处理器、存储器、以及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上任一所述的容器云平台的域名解析方法。

有益效果：

本申请提供的容器云平台的域名解析技术，用于源容器组向目的容器组的访问，其中，定义发出访问请求的容器组为源容器组，访问请求要访问的容器组为目的容器组；在源容器组向目的容器组访问前，检测到源容器组生成域名解析请求时，如果预先写入的内核域名映射表中包含目的容器组的域名，那么，源容器组使用操作系统内核访问内核域名映射表，获取目的容器组的IP地址；如果预先写入的内核域名映射表中不包含目的容器组的域名，那么，由源容器组向域名解析服务组件发出域名解析请求，获取目的容器组的IP地址。籍此，对指向预先存储在内核域名映射表中的目的容器组的域名解析需求，无需发起域名解析请求，使用操作系统内核访问内核域名映射表即可获知要访问的目的容器组的IP地址，使得大量的域名解析工作直接在源容器组中由操作系统内核完成，减轻了域名解析服务组件的工作负担，降低了域名解析的硬件资源使用，不同源容器组之间的域名解析工作不会相互影响，有效提升了域名解析效率。

附图说明

构成本申请的一部分的说明书附图用来提供对本申请的进一步理解，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。其中：

图1为现有技术中域名解析服务组件在容器云平台中的部署示意图；

图2为现有技术中域名解析服务组件提供域名解析服务的技术框架图；

图3为现有技术中域名解析服务组件提供域名解析服务的逻辑示意图；

图4为根据本申请的一些实施例提供的一种容器云平台的域名解析方法的流程示意图；

图5为根据本申请的一些实施例提供的源容器组对目标容器组的域名进行解析的逻辑示意图；

图6为根据本申请的一些实施例提供的监控组件和内核域名映射表注入组件的技术逻辑图；

图7为根据本申请的一些实施例提供的指定容器组的内核域名映射表的内容的截图；

图8为根据本申请的一些实施例提供的容器云平台的监控界面的截图；

图9为根据本申请的一些实施例提供的容器云平台的监控界面中对热点源容器组进行展示的截图；

图10为根据本申请的一些实施例提供的一种容器云平台的域名解析系统的结构示意图；

图11为根据本申请的一些实施例提供的电子设备的结构示意图；

图12为根据本申请的一些实施例提供的电子设备的硬件结构图。

具体实施方式

下面将参考附图并结合实施例来详细说明本申请。各个示例通过本申请的解释的方式提供而非限制本申请。实际上，本领域的技术人员将清楚，在不脱离本申请的范围或精神的情况下，可在本申请中进行修改和变型。例如，示为或描述为一个实施例的一部分的特征可用于另一个实施例，以产生又一个实施例。因此，所期望的是，本申请包含归入所附权利要求及其等同物的范围内的此类修改和变型。

首先，需要说明的是，本申请中，将发出访问请求的容器组定义为源容器组，访问请求要访问的容器组定义为目的容器组，源容器组、目的容器组均位于容器云平台。

在目前的容器云平台中，不同IP地址的容器组之间的相互访问，通常使用域名解析服务组件为容器组提供域名解析服务。比如，DNS组件、节点DNS缓存等。

具体来说，在容器云平台(比如Kubernetes系统)中创建容器组后，由容器组所在节点的容器组管理组件(比如Kukelet组件)对该容器组进行管理，并为该容器组分配唯一的域名和IP地址。DNS组件(比如CoreDNS组件)通过访问容器云平台中的相关组件，即可获取该容器组的域名和IP地址，生成DNS记录并进行存储。

当源容器组要访问目的容器组时，如果源容器组知道该容器组的IP地址，则只需直接向目的容器组的IP地址发送访问请求数据包，如果源容器组只知道目的容器组的域名，则需要先向DNS组件发送域名解析请求，由DNS组件提供域名解析服务，对源容器组发送的目的容器组的域名进行解析后，得到目的容器组的IP地址，返回给源容器组，再由源容器组向目的容器组的IP地址发送访问请求数据包。

由于容器云平台通常包括多个节点，每个节点中又部署有大量的容器组，当多个源容器组同时向DNS组件发送域名解析请求时，一方面，DNS组件需要处理并发的域名解析请求，使得DNS组件的负担加重，甚至出现崩溃；另一方面，域名解析的效率降低，源容器组需要等待DNS组件处理域名解析请求，才能获得目的容器组的IP地址，严重影响容器云平台中的容器组之间的相互访问。

基于此，还可以在容器云平台中的每个节点中部署节点DNS缓存(比如NodeLocalDNS组件)，通过节点DNS缓存对所在节点中的源容器组发出的域名解析请求和收到的域名解析结果进行临时存储，在此之后如果该节点上的容器组要访问相同的域名，则可以直接在节点DNS缓存中查询对应的IP地址，并返回给源容器组即可。如果容器组要访问的域名未在所在节点的节点DNS缓存中进行存储，再由源容器组向DNS组件发送域名解析请求，由DNS组件提供域名解析服务。

简单来说，目前在容器云平台中部署域名解析服务组件，既可以仅部署DNS组件，由DNS组件直接处理全部的域名解析请求，也可以同时部署DNS组件和节点DNS缓存，由节点DNS缓存优先对域名解析请求进行处理，对于节点DNS缓存中已经存储的目的容器组的域名，直接向源容器组反馈对应的IP地址，对于节点DNS缓存中未存储的目的容器组的域名，再由源容器组向DNS组件发送域名解析请求。下面对同时部署DNS组件和节点DNS缓存的情况进行详细说明。

如图1-图3所示，以Kubernetes集群为例，在Kubernetes集群的某个节点中部署DNS插件，DNS插件通过API-Server组件以Damonset的形式在Kubernetes集群的每个节点中部署节点DNS缓存，以及在其中至少一个节点中部署DNS组件。

在将DNS组件部署在Kubernetes集群后，DNS组件通过API-Server组件遍历查询Kubernetes集群中的全部容器组的域名和IP地址，且进行解析，生成DNS记录并存储在DNS组件中。

在源容器组对目的容器组进行访问前，如果只知道目的容器组的域名，则需要通过节点DNS缓存和DNS组件提供的域名解析服务来获知目的容器组的IP地址。具体地，源容器组将要访问的目的容器组的域名发送给所在节点的节点DNS缓存，如果节点DNS缓存临时存储有该目的容器组的DNS数据(包含目的容器组的域名和IP地址)，那么节点DNS缓存通过查询本地临时存储的DNS数据即可获得该目的容器组的IP地址，并反馈给源容器组，使得源容器组能够根据IP地址对目的容器组进行访问。

如果源容器组或者该节点上的其它容器组从未访问过该目的容器组，使得节点DNS缓存从未存储该目的容器组的DNS数据，或者源容器组或者该节点上的其它容器组近期没有访问过该目的容器组，使得节点DNS缓存已经将该目的容器组的DNS数据清除，那么节点DNS缓存无法从本地查询到该目的容器组的DNS数据，则将未命中的结果(节点DNS缓存中未查询到该目的容器组的IP地址)反馈给源容器组，源容器组在收到未命中的结果后向DNS组件再次发出域名解析请求，由DNS组件对目的容器组的域名进行解析后将目的容器组的IP地址反馈给源容器组，使得源容器组能够根据IP地址对目的容器组进行访问。

此外，该源容器组所在节点的节点DNS缓存将对该目的容器组的DNS数据进行临时存储。在一段时间内，如果节点DNS缓存再次收到该容器组或者该节点上的其它容器组发送的该目的容器组的域名，那么节点DNS缓存直接查询本地临时存储的DNS数据即可获得该目的容器组的IP地址，将结果反馈给发送方，无需DNS组件再对该目的容器组的域名进行重复解析。

但是，无论是采用单独部署DNS组件的方式，还是采用同时部署DNS组件和节点DNS缓存的方式，在面对访问流量过高的情况时，都会使得域名解析服务组件的域名解析负担过重，出现崩溃、无法正常工作的问题，使得源容器组无法获取目的容器组的IP地址，访问流量无法到达目的容器组。

具体来说，每个节点DNS缓存需要同时为同一节点中的多个源容器组提供域名解析服务，在访问流量过高时，节点DNS缓存需要同时对多个源容器组发出的域名解析请求进行响应，这同样会使节点DNS缓存的负担过重，无法正常反馈域名解析结果，源容器组无法从节点DNS缓存获得目的容器组的IP地址，节点DNS缓存失去为源容器组提供域名解析服务的能力。

为了减轻容器云平台中域名解析服务组件的负担，申请人提出了一种容器云平台的域名解析技术，在源容器组的内核域名映射表中预先存储目的容器组的域名和IP地址的对应关系，当源容器组要访问目的容器组时，使用操作系统内核访问内核域名映射表，获取要访问的目的容器组的IP地址，使得大量的域名解析工作直接在源容器组中由操作系统内核完成，减轻了域名解析服务组件的工作负担，降低了域名解析的硬件资源使用，不同源容器组之间的域名解析工作不会相互影响，有效提升了域名解析效率。

如图4所示，源容器组为发出访问请求的容器组，目的容器组为访问请求要访问的容器组，源容器组、目的容器组均位于容器云平台，该容器云平台的域名解析方法包括：

步骤S401、检测到源容器组生成域名解析需求。

基于前述说明可知，在源容器组要访问目的容器组时，如果源容器组知道该容器组的IP地址，则只需直接向目的容器组的IP地址发送访问请求数据包，如果源容器组只知道目的容器组的域名，则需要进行域名解析，由此即产生域名解析需求。

简单来说，如果源容器组要访问目的容器组，且不知道目的容器组的IP地址，只知道目的容器组的域名，那么源容器组就产生了相应的域名解析需求。从细节上说，在源容器组生成数据访问请求包时，需要将目的容器组的IP地址封装在数据访问请求包的报头中，因此在创建数据访问请求包时检测到缺少目的容器组的IP地址，即检测到源容器组生成域名解析需求。

步骤S402、响应于预先写入的内核域名映射表中包含目的容器组的域名，源容器组使用操作系统内核访问内核域名映射表，以获取目的容器组的IP地址。

其中，内核域名映射表中包含目的容器组的域名和目的容器组的IP地址的映射关系。

目前，通过域名解析服务组件提供域名解析服务时，共用相同域名解析服务组件的多个源容器组在进行域名解析时会相互影响。具体的，当域名解析服务组件对某个源容器组发送的域名解析请求进行处理时，无法同时处理其它源容器组发出的域名解析请求，从而对其它源容器组的域名解析性能造成影响。而本申请中，对于内核域名映射表中包含的目的容器组的域名，由源容器组使用操作系统内核在源容器组内进行域名解析，无需向域名解析服务组件发送域名解析请求，有效解决了多个源容器组同时进行域名解析时存在的相互干扰问题。

具体地，如图5所示，在源容器组的内核域名映射表中预先写入了目的容器组的域名和IP地址的映射关系后，一旦检测到源容器组生成了域名解析需求，源容器组将优先使用操作系统内核访问内核域名映射表，查询要访问的目的容器组的域名，通过内核域名映射表中域名和IP地址的映射关系获知要访问的目的容器组的IP地址，而无需向域名解析服务组件发起域名解析请求，使得大量的域名解析工作转由操作系统内核在源容器组内直接完成，减轻了域名解析服务组件的工作负担，降低了域名解析的硬件资源使用，不同源容器组之间的域名解析工作不会相互影响，有效提升了域名解析效率。

在此，通过内核域名映射表来对域名进行处理，实际上是由操作系统内核直接读取内核域名映射表的内容，将目的容器组的域名转换为对应的IP地址，而无需发送域名解析请求，也没有经过网卡，减轻了网卡、域名解析服务组件等网络相关组件的压力。

步骤S403、响应于内核域名映射表中未包含目的容器组的域名，源容器组向域名解析服务组件发出域名解析请求，以获取目的容器组的IP地址。

其中，域名解析服务组件部署于容器云平台。

基于前述说明可知，如果未在源容器组的内核域名映射表中预先写入目的容器组的域名和IP地址的映射关系，那么源容器组使用操作系统内核访问内核域名映射表，查询要访问的目的容器组的域名，无法获知要访问的目的容器组的IP地址。源容器组将向域名解析服务组件发出域名解析请求，由域名解析服务组件提供域名解析服务，返回目的容器组的IP地址。

基于前述说明可知，在容器云平台中部署域名解析服务组件可以采用单独部署DNS组件的方式，还可以采用同时部署DNS组件和节点DNS缓存的方式。

在此，以同时部署DNS组件和节点DNS缓存的情况为例进行说明，即域名解析服务组件包括节点DNS缓存和DNS组件，相应地，源容器组向域名解析服务组件发出域名解析请求，以获取目的容器组的IP地址，具体为，响应于节点DNS缓存中存储有目的容器组的域名和IP地址的映射关系，则节点DNS缓存将目的容器组的IP地址反馈至源容器组；否则，将域名解析请求发送至DNS组件，以由DNS组件对目的容器组的域名进行解析，以获取目的容器组的IP地址。

如图5所示，如果在源容器组使用操作系统内核访问内核域名映射表后，无法获知要访问的目的容器组的IP地址，那么源容器组首先向节点DNS缓存发出域名解析请求。

进一步地，如果节点DNS缓存对该目的容器组的DNS数据进行了临时存储，那么，节点DNS缓存通过查询本地临时存储的DNS数据即可获得该目的容器组的IP地址，并反馈给源容器组。如果在节点DNS缓存中未能查询到该目的容器组的DNS数据，则节点DNS缓存将未命中的结果反馈给源容器组；源容器组在收到未命中的结果后向DNS组件再次发出域名解析请求，在DNS组件对目的容器组的域名进行解析后，将目的容器组的IP地址反馈给源容器组。

本申请中，在部署域名解析服务组件的基础上，让源容器组优先使用操作系统内核在源容器组中完成域名解析，一方面，减少域名解析请求的发起量，降低网络开销和相关网络组件的负担；另一方面，不同容器组之间的域名解析工作不会相互影响，提升了域名解析的效率，可以有效满足访问流量过高时的域名解析需求。

应当理解，在不同应用场景下，可以采用多种方式将目的容器组的域名和IP地址写入源容器组的内核域名映射表中，下面进行具体说明。

一具体的应用场景中，在向源容器组的内核域名映射表中写入目的容器组的域名和IP地址的映射关系时，可以通过容器操作指令向源容器组的内核域名映射表中写入目的容器组的域名和IP地址的映射关系。

比如，通过exec指令修改源容器组的内核域名映射表，将目的容器组的域名和对应的IP地址写入源容器组的内核域名映射表中。具体的，首先，执行ps指令：docker ps-aqf"name＝<源容器组的名称>"，即可获取源容器组的唯一标识(比如源容器组的id)；然后，再执行exec指令：docker exec<源容器组的id>/bin/sh-c"echo<对应的IP地址><域名>>>/etc/hosts"，即可将目的容器组的域名和IP地址写入源容器组的内核域名映射表(/etc/hosts)中。

另一具体的应用场景中，在向源容器组的内核域名映射表中写入目的容器组的域名和IP地址的映射关系时，可以通过创建或修改容器组控制器的配置文件，并将目的容器组的域名和IP地址的映射关系写入配置文件中的指定字段；然后，对配置文件在源容器组中进行部署或更新，以将目的容器组的域名和IP地址的映射关系写入源容器组的内核域名映射表。

比如，通过创建或修改容器组控制器的yaml文件方式在容器组的内核域名映射表中添加额外条目，以将目的容器组的域名和对应的IP地址写入容器组内的内核域名映射表。具体的，首先，为容器组控制器创建包含HostAlias字段的yaml文件，或者，在容器组控制器的yaml文件中添加HostAlias字段，将目的容器组的域名和对应的IP地址写入该yaml文件中的HostAlias字段。其中，yaml文件的内容如下：

然后，对容器组控制器的yaml文件进行部署或者更新，容器组控制器的yaml文件中的HostAlias字段的域名和对应的IP地址被写入该容器组的内核域名映射表中。其中，部署或更新指令如下：kubectl apply-f busybox.yaml。

又一具体的应用场景中，在向源容器组的内核域名映射表中写入目的容器组的域名和IP地址的映射关系时，可以通过建立节点的内核域名映射表与源容器组的内核域名映射表之间的映射关系，以将目的容器组的域名和IP地址的映射关系写入源容器组的内核域名映射表。

比如，预先建立源容器组的内核域名映射表(/etc/hosts)与所在节点的内核域名映射表(/etc/hosts)之间的映射关系，并将目的容器组的域名和IP地址的映射关系写入所在节点的内核域名映射表中，根据预先建立的映射关系，目的容器组的域名和IP地址的映射关系将被自动同步至源容器组的内核域名映射表中。

需要说明的是，通过容器操作指令的方式和建立映射关系的方式向源容器组的内核域名映射表中写入域名和IP地址的映射关系时，无需重启容器组即可让写入的域名和对应的IP地址对该容器组生效；而通过配置文件的方式向源容器组的内核域名映射表中写入域名和IP地址的映射关系时，则需要重启该容器组才能让写入的域名和IP地址对该容器组生效。也就是说，通过配置文件向源容器组的内核域名映射表中写入域名和IP地址的映射关系的方式只适用于允许重启的容器组，并且在写入完成后需要及时重启该容器组。

此外，无论是通过容器操作指令的方式，还是通过配置文件的方式，又或者是通过建立映射关系的方式向源容器组的内核域名映射表中写入域名和IP地址的映射关系，既可以手动操作完成，即手动输入容器操作指令，手动创建、修改、部署、更新配置文件，以及手动建立映射关系和修改节点的内核域名映射表，还可以在容器云平台中部署内核域名映射表注入组件，由内核域名映射表注入组件自动输入容器操作指令，自动创建、修改、部署、更新配置文件，以及自动建立映射关系和修改节点的内核域名映射表，以将目的容器组的域名和IP地址写入源容器组的内核域名映射表中。

可以理解的是，除了上述方式以外，还可以通过其它可能的实现方式将目的容器组的域名和IP地址写入源容器组的内核域名映射表中，在此，并不对此进行限定。

基于前述说明可知，本申请实施例将发出访问请求的容器组定义为源容器组，访问请求要访问的容器组定义为目的容器组，因此对于容器云平台中的每个容器组来说，既可能是某个目的容器组的源容器组，又可能是某个源容器组的目的容器组。

为了能够将目的容器组的域名和IP地址预先写入源容器组的内核域名映射表中，一种可能的实现方式是，在每个容器组的内核域名映射表中预先写入同一容器云平台中其他所有容器组的域名和IP地址，从而让每个源容器组在产生域名解析需求时，全部使用操作系统内核在源容器组中完成域名解析，无需发出任何域名解析请求，但该方式需要在每个容器组的内核域名映射表中预先写入同一容器云平台中其他所有容器组的域名和IP地址，前期工作量浩大，且会造成操作系统内核负担过重。

基于此，如图6所示，在本申请中，还可以在容器云平台中部署监控组件(比如Prometheus组件)，来对容器云平台中容器组的域名解析服务组件进行监控，并对相应的历史数据进行收集和分析，进而获知被访问频次较高的目的容器组，即在单位时间内被访问请求次数较高的目的容器组。并且通过向应用管理员进行展示，由应用管理员手动操作，或者通过内核域名注入组件，将访问频次较高的目的容器组的域名和IP地址的映射关系写入指定容器组的内核域名映射表中，以此，仅将容器云平台中被访问频次较高的目的容器组的域名和IP地址的映射关系预先写入指定容器组的内核域名映射表中，极大地减轻了前期工作量。

在一具体应用场景中，在检测到源容器组生成域名解析需求之前，可以通过监控组件对域名解析服务组件进行监控，获取域名解析请求的历史数据，基于域名解析请求历史数据中，域名解析请求指向的容器组的频次，确定容器云平台中的高频目的容器组，并向指定容器组的内核域名映射表中写入高频目的容器组的域名和IP地址的映射关系。

本申请中，监控组件对域名解析服务组件进行监控，具体是对DNS插件在实例化DNS组件、节点DNS缓存时提供的对外暴露指标监控数据(metrics)的端口进行实时、动态监控，从DNS组件、节点DNS缓存获取指标监控数据。

从域名解析请求的历史数据中找到被访问频次较高的容器组(高频目的容器组)，在部署于容器云平台的所有容器组中确定出指定容器组，在指定容器组的内核域名映射表中写入高频目的容器组的域名和IP地址的映射关系。具体的，可以向应用管理员展示高频目的容器组，由应用管理员手动将高频目的容器组的域名和IP地址写入指定容器组的内核域名映射表中，也可以通过在容器云平台中部署内核域名映射表注入组件，由内核域名映射表注入组件接收监控组件发送的高频目的容器组的域名和IP地址，由内核域名映射表注入组件将高频目的容器组的域名和IP地址写入指定容器组的内核域名映射表中。

一旦检测到指定容器组生成了指向高频目的容器组的域名解析需求，指定容器组将优先使用操作系统内核访问内核域名映射表，查询要访问的高频目的容器组的域名，通过内核域名映射表中域名和IP地址的映射关系获知要访问的高频目的容器组的IP地址。

举例来说，监控组件通过对DNS组件和节点DNS缓存组件的指标监控数据进行分析，确定出高频目的容器组的域名：aa.bb、cc.dd、dao-204aaa-dao-2048,以及对应的高频目的容器组的IP地址：127.0.0.1、127.0.0.1、172.31.15.43，并由内核域名映射表注入组件将高频目的容器组的域名和IP地址写入指定容器组的内核域名映射表中，则指定容器组的内核域名映射表的内容如图7所示。当指定容器组请求对dao-204aaa-dao-2048进行访问时，该容器组即可通过操作系统内核直接将域名dao-204aaa-dao-2048转换为对应的IP地址：172.31.15.43，进而直接对172.31.15.43发送访问请求数据包。

籍此，在指定容器组的内核域名映射表中写入高频目的容器组的域名和对应的IP地址，将指向高频目的容器组的域名解析工作从节点分散到容器组，而无需向域名解析服务组件发起域名解析请求，而指向高频目的容器组的域名解析工作占据着整个容器云平台中域名解析工作的较高比例，使得大量的域名解析工作转由操作系统内核在指定容器组内直接完成，剩余少量的域名解析工作仍由域名解析服务组件完成，减轻了域名解析服务组件的工作负担，降低了域名解析的硬件资源使用，有效提升了域名解析效率。也就是说，当指定容器组要访问高频目的容器组时，可直接由该容器组使用操作系统内核访问内核域名映射表完成域名解析(从内核户名映射表中获取高频目的容器组的域名对应的IP地址)，无需再向DNS组件、节点DNS缓存组件发送域名解析服务请求，减轻了DNS组件、节点DNS缓存组件的工作负担，降低了域名解析的硬件资源使用，有效提升了域名解析效率。

进一步地，在部署于容器云平台的所有容器组中确定出指定容器组，具体可以是在容器云平台中的所有容器组中选出若干个容器组作为指定容器组，又可以将容器云平台中的所有容器组作为指定容器组，还可以将指向高频目的容器组的频次较高的域名解析请求对应的源容器组作为指定容器组。

对于将指向高频目的容器组的频次较高的域名解析请求对应的源容器组作为指定容器组的情况，向指定容器组的内核域名映射表中写入高频目的容器组的域名和IP地址的映射关系包括：基于发出指向高频目的容器组的域名解析请求的容器组的频次，确定高频目的容器组对应的高频源容器组；然后，向高频源容器组的内核域名映射表中写入高频目的容器组的域名和IP地址的映射关系。

应当理解，在监控组件对域名解析请求进行监控，并对相应的历史数据进行收集和分析时，既可以获知访问频次较高的目的容器组，又可以进一步获知指向高频目的容器组的所有域名解析请求的发出方。对发出这些域名解析请求的源容器组进行统计和分析，从中筛选出访问频次较高的源容器组作为高频源容器组。

也就是说，高频源容器组是通过监控组件对域名解析请求的历史数据进行收集和分析，通过向应用管理员展示发出指向高频目的容器组的域名解析请求的源容器组的访问频次，由应用管理员人工确定出高频源容器组，或者由监控组件按照预设阈值将指向高频目的容器组的频次较高的域名解析请求对应的源容器组确定为高频源容器组。在确定了高频源容器组后，再由应用管理员手动操作，或者由内核域名映射表注入组件向高频源容器组中写入高频目的容器组的域名和IP地址的映射关系。

可以理解，本申请通过监控组件对节点DNS缓存和DNS组件的指标监控数据进行实时监控，动态地确定出高频源容器组，并在高频源容器组的内核域名映射表中写入该容器组对应的高频目的容器组的域名和IP地址的映射关系，既减小了在源容器组的内核域名映射表中预先写入目的容器组的域名和IP地址的映射关系的工作量，又能够在访问流量发生变化时，根据高频源容器组和高频目的容器组的变化，动态调整高频源容器组的内核域名映射表的内容。

相应地，在向高频源容器组的内核域名映射表中写入高频目的容器组的域名和IP地址的映射关系时，一种可能的实现方式是，通过容器操作指令向高频源容器组的内核域名映射表中写入高频目的容器组的域名和IP地址的映射关系。另一种可能的实现方式是，创建或修改容器组控制器的配置文件，并将高频目的容器组的域名和IP地址的映射关系写入配置文件中的指定字段，然后对配置文件在高频源容器组中进行部署或更新，以将高频目的容器组的域名和IP地址的映射关系写入高频源容器组的内核域名映射表。又一种可能的实现方式是，通过建立高频源容器组的内核域名映射表与所在节点的内核域名映射表之间的映射关系，以将高频目的容器组的域名和IP地址的映射关系写入高频源容器组的内核域名映射表。

如图8和图9所示，通过监控组件对节点DNS缓存和DNS组件的指标监控数据进行实时监控分析，一方面可以确定出被访问频次较高的目的容器组的域名，另一方面还可以确定发起访问的源容器组的域名、IP地址以及访问次数，进而从中确定出发起访问次数较多的热点源容器组，并进行展示，以防止应用恶意发起对其它应用的恶意访问，造成系统崩溃，及时对异常应用进行处理。也就是说，通过对域名解析服务组件进行监控，可以根据发出域名解析请求的容器组的频次，确定容器云平台中的异常源容器组(频次超过预设阈值)，并在容器云平台的监控界面中对异常源容器组进行标注，和/或指示容器云平台中的相关管理组件禁止异常源容器组发出访问请求。

图10为根据本申请的一些实施例提供的一种容器云平台的域名解析系统的结构示意图；如图10所示，该容器云平台的域名解析系统用于源容器组向目的容器组的访问，其中，源容器组为发出访问请求的容器组，目的容器组为访问请求要访问的容器组，源容器组、目的容器组均位于容器云平台；该容器云平台的域名解析系统包括：

需求监控单元1001，配置为检测到源容器组生成域名解析需求；第一获取单元1002，配置为响应于预先写入的内核域名映射表中包含目的容器组的域名，源容器组使用操作系统内核访问内核域名映射表，以获取目的容器组的IP地址；其中，内核域名映射表中包含目的容器组的域名和目的容器组的IP地址的映射关系；第二获取单元1003，配置为响应于内核域名映射表中未包含目的容器组的域名，源容器组向域名解析服务组件发出域名解析请求，以获取目的容器组的IP地址；其中，域名解析服务组件部署于容器云平台。

本申请实施例提供的容器云平台的域名解析系统能够实现上述任一容器云平台的域名解析方法实施例的步骤、流程，并达到相同的技术效果，在此不再一一赘述。

图11为根据本申请的一些实施例提供的电子设备的结构示意图；如图11所示，该电子设备包括：

一个或多个处理器1101；

计算机可读介质，可以配置为存储一个或多个程序1102，一个或多个处理器1101执行一个或多个程序1102时，实现如下步骤：检测到源容器组生成域名解析需求；响应于预先写入的内核域名映射表中包含目的容器组的域名，源容器组使用操作系统内核访问内核域名映射表，以获取目的容器组的IP地址；其中，内核域名映射表中包含目的容器组的域名和目的容器组的IP地址的映射关系；响应于内核域名映射表中未包含目的容器组的域名，源容器组向域名解析服务组件发出域名解析请求，以获取目的容器组的IP地址；其中，域名解析服务组件部署于容器云平台。

图12为根据本申请的一些实施例提供的电子设备的硬件结构；如图12所示，该电子设备的硬件结构可以包括：处理器1201、通信接口1202、计算机可读介质1203和通信总线1204。

其中，处理器1201、通信接口1202、计算机可读存储介质1203通过通信总线1204完成相互间的通信。

可选地，通信接口1202可以为通信模块的接口，如GSM模块的接口。

其中，处理器1201具体可以配置为：检测到源容器组生成域名解析需求；响应于预先写入的内核域名映射表中包含目的容器组的域名，源容器组使用操作系统内核访问内核域名映射表，以获取目的容器组的IP地址；其中，内核域名映射表中包含目的容器组的域名和目的容器组的IP地址的映射关系；响应于内核域名映射表中未包含目的容器组的域名，源容器组向域名解析服务组件发出域名解析请求，以获取目的容器组的IP地址；其中，域名解析服务组件部署于容器云平台。

处理器1201可以是通用处理器，包括中央处理器(central processing unit，简称CPU)、网络处理器(Network Processor，简称NP)等，还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

本申请实施例的电子设备以多种形式存在，包括但不限于：

(1)移动通信设备：这类设备的特点是具备移动通信功能，并且以提供话音、数据通信为主要目标。这类终端包括：智能手机(例如：iPhone)、多媒体手机、功能性手机，以及低端手机等。

(2)超移动个人计算机设备：这类设备属于个人计算机的范畴，有计算和处理功能，一般也具备移动上网特性。这类终端包括：PDA、MID和UMPC设备等，例如iPad。

(3)便携式娱乐设备：这类设备可以显示和播放多媒体内容。该类设备包括：音频、视频播放器(例如：iPod)，掌上游戏机，电子书，以及智能玩具和便携式车载导航设备。

(4)服务器：提供计算服务的设备，服务器的构成包括处理器、硬盘、内存、系统总线等，服务器和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。

(5)其它具有数据交互功能的电子装置。

需要指出，根据实施的需要，可将本申请实施例中描述的各个部件/步骤拆分为更多部件/步骤，也可以将两个或多个部件/步骤或者部件/步骤的部分操作组合成新的部件/步骤，以实现本申请实施例的目的。

上述根据本申请实施例的方法可在硬件、固件中实现，或者被实现为可存储在记录介质(诸如CD ROM、RAM、软盘、硬盘或磁光盘)中的软件或计算机代码，或者被实现通过网络下载的原始存储在远程记录介质或非暂时机器存储介质中并将被存储在本地记录介质中的计算机代码，从而在此描述的方法可被存储在使用通用计算机、专用处理器或者可编程或专用硬件(诸如ASIC或FPGA)的记录介质上的这样的软件处理。可以理解，计算机、处理器、微处理器控制器或可编程硬件包括可存储或接收软件或计算机代码的存储组件(例如，RAM、ROM、闪存等)，当软件或计算机代码被计算机、处理器或硬件访问且执行时，实现在此描述的容器云平台的域名解析方法。此外，当通用计算机访问用于实现在此示出的方法的代码时，代码的执行将通用计算机转换为用于执行在此示出的方法的专用计算机。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及方法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和涉及约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请实施例的范围。

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

以上所描述得设备及系统实施例仅仅是示意性的，其中作为分离不见说明的单元可以使或者也可以不是物理上分开的，作为单元提示的不见可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上仅为本申请的优选实施例，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。