Domain name resolution method and device, electronic equipment and storage medium

Abstract

The invention provides a domain name resolution method and device, electronic equipment and a storage medium, and the method comprises the steps: deploying a NodelocalDNS application at each node of a Kubernetes cluster, and distributing a virtual IP address; in response to the fact that Pod is dispatched to a node and requests for an IP address, a virtual Ethernet pair is created through a CNI network plug-in, an eBPF program is dynamically generated at the same time, and the program is mounted to virtual network equipment on the host side; the eBPF program monitors the network traffic sent from the Pod, and judges and processes the network traffic according to the destination address of the traffic; and after the Nodelocal DNS receives the DNS request of the Pod, performing cache check, and forwarding the request to an upstream CoreDNS for domain name resolution in response to a cache miss. According to the invention, the domain name resolution efficiency is improved, tenant isolation is realized, and the difficulty of managing the VPC network is reduced.

Description

Technical Field

[0001] The present application belongs to the technical field of domain name resolution, and in particular, relates to a domain name resolution method, device, electronic device and storage medium. Background Art

[0002] CoreDNS is used as the cluster's domain name server to resolve the cluster's Service and Pod domain names. Under the same VPC, Pods between clusters can access each other without additional operations. For Pods in different VPCs, you need to create a peer connection to ensure that the VPC where the Pod is located and the default VPC of the cluster can access each other.

[0003] When a Pod needs to resolve a domain name, it will initiate a domain name resolution request to CoreDNS. If it is not in the same VPC network as the cluster, the request will be directly forwarded to the SDN network (a peer connection must be established first, otherwise the request will be rejected). The request will be forwarded to the node where CoreDNS is located, and forwarded to the CoreDNS Pod through NAT, regardless of whether the Pod and CoreDNS are on the same node at this time. If the Pod uses the cluster's default VPC and is on the same node as CoreDNS, it will directly request CoreDNS without going through the SDN network.

[0004] In the above solution, if the VPC used by the Pod is not the default VPC network of the cluster, when resolving the Service and Pod domain names, CoreDNS needs to be accessed, and CoreDNS is in the default VPC and cannot be directly accessed. A peer connection needs to be created, but this does not make use of the network isolation capability of the VPC. At the same time, the need to create a peer connection will increase the difficulty of managing the VPC.

[0005] In addition, in order to implement network traffic restrictions between Pods, additional configuration of NetworkPolicy or security groups is required, which increases the difficulty of management. At the same time, since it is cross-VPC access, each access to CoreDNS needs to bypass the SDN network. Even if the Pod and CoreDNS are on the same node, under high concurrency, it will increase the burden on the SDN network and affect efficiency. This solution also cannot use NodelocalDNS to improve the efficiency of domain name resolution. Summary of the invention

[0006] In view of this, the present application aims to propose a domain name resolution method, device, electronic device and storage medium to solve the problem of accessing CorenDNS across VPCs and resolving Pod and Service DNS records, thereby improving the efficiency of resolving domain names, achieving tenant isolation and reducing the difficulty of managing VPC networks.

[0007] To achieve the above purpose, the technical solution of this application is implemented as follows: In a first aspect, the present application provides a domain name resolution method, comprising: Deploy the NodelocalDNS application on each node in the Kubernetes cluster and assign a virtual IP address; In response to the Pod being scheduled to the node and requesting an IP address, a virtual Ethernet pair is created through the CNI network plug-in, and an eBPF program is dynamically generated and mounted to the virtual network device on the host side, where one side of the virtual Ethernet pair is connected to the container network namespace of the Pod, and the other side is connected to the host network namespace; The eBPF program monitors the network traffic sent from the Pod and makes judgments and processes it based on the destination address of the traffic; After receiving the DNS request from the Pod, NodelocalDNS performs a cache check. In response to a cache hit, it directly returns the cache result to the container. In response to a cache miss, it forwards the request to the upstream CoreDNS for domain name resolution.

[0008] In a second aspect, based on the same inventive concept, the present application also provides a domain name resolution device, including: The deployment configuration module is configured to deploy the NodelocalDNS application on each node of the Kubernetes cluster and assign a virtual IP address; A program generation module is configured to, in response to a Pod being scheduled to a node and requesting an IP address, create a virtual Ethernet pair through a CNI network plug-in, dynamically generate an eBPF program, and mount the program to a virtual network device on the host side, wherein one side of the virtual Ethernet pair is connected to a container network namespace of the Pod, and the other side is connected to a host network namespace; The traffic processing module is configured as an eBPF program to monitor the network traffic sent from the Pod and make judgments and processes based on the destination address of the traffic; In the domain name resolution module, NodelocalDNS performs a cache check after receiving the DNS request from the Pod. In response to a cache hit, the cache result is directly returned to the container. In response to a cache miss, the request is forwarded to the upstream CoreDNS for domain name resolution.

[0009] In a third aspect, based on the same inventive concept, the present application also provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the method described in the first aspect is implemented.

[0010] In a fourth aspect, based on the same inventive concept, the present application also provides a non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium stores computer instructions, and the computer instructions are used to enable the computer to execute the method described in the first aspect.

[0011] Compared with the prior art, the domain name resolution method, device, electronic device and storage medium described in this application have the following beneficial effects: The domain name resolution method, device, electronic device and storage medium described in this application solve the problem of accessing CorenDNS to resolve Pod and Service DNS records across VPCs without creating a peer connection, greatly improving the efficiency and response time of domain name resolution, while achieving tenant isolation and reducing the difficulty of managing VPC networks. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The drawings constituting a part of the present application are used to provide a further understanding of the present application. The illustrative embodiments and descriptions of the present application are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings: Figure 1 A flow chart of a domain name resolution method described in an embodiment of the present application; Figure 2 A schematic diagram of a domain name resolution method processing process described in an embodiment of the present application; Figure 3 A schematic diagram of the structure of a domain name resolution device according to an embodiment of the present application; Figure 4 This is a schematic diagram of the hardware structure of the electronic device described in the embodiment of the present application. DETAILED DESCRIPTION

[0013] In order to make the objectives, technical solutions and advantages of the present application more clearly understood, the present application is further described in detail below in combination with specific embodiments and with reference to the accompanying drawings.

[0014] It should be noted that, unless otherwise defined, the technical terms or scientific terms used in the embodiments of the present application should be the usual meanings understood by people with ordinary skills in the field to which the present application belongs. The "first", "second" and similar words used in the embodiments of the present application do not represent any order, quantity or importance, but are only used to distinguish different components. "Including" or "comprising" and similar words mean that the elements or objects appearing in front of the word cover the elements or objects listed after the word and their equivalents, without excluding other elements or objects. "Connect" or "connected" and similar words are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. "Up", "down", "left", "right" and the like are only used to indicate relative positional relationships. When the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0015] Glossary: 1. Kubernetes Kubernetes is a portable and extensible open source container orchestration platform for managing containerized workloads and services, supporting automated deployment, large-scale scalability, and application containerization management.

[0016] 2. Pod Pod is a concept abstracted by Kubernetes, representing a group of application containers (such as Docker) and some shared resources of these containers (such as networks). It is the smallest deployable computing unit that can be created and managed in Kubernetes.

[0017] In Kubernetes, Service is an abstract object used to define a logical collection of Pods. It provides these Pods with a stable virtual IP address and an externally exposed DNS name, and load balances requests between these Pods.

[0018] 3. Service A Service defines a group of Pods through a label selector. When a group of Pods is defined as the backend of a Service, they share the same Service's network identifier and stable virtual IP address. In this way, other services or external clients can communicate with these Pods by accessing the Service's virtual IP address without having to worry about the specific address or changes of the Pod.

[0019] 4. DNS records In Kubernetes, the IP addresses of Pods and Services can be changed at any time, especially Pods. Therefore, when Pods are accessed from each other, they can be accessed through the Service domain name to avoid application unavailability due to IP changes.

[0020] Kubernetes creates DNS records for Services and Pods; within the cluster, Pods can directly access Services using consistent DNS names instead of IP addresses.

[0021] Generally, Kubernetes uses CoreDNS as the domain name server to provide domain name resolution for all services in the cluster.

[0022] Service A / AAAA Record Except for headless type services, ordinary services will be assigned a DNS A record in the form of my-svc.my-namespace.svc.cluster-domain.example. If the dual stack function is enabled, a DNS AAAA record will also be recorded, where my-svc is the service name, my-namespace is the namespace where the service is located, and cluster-domain.example is the cluster domain name suffix. Resolving the domain name will return the ClusterIP of the service.

[0023] For a Headless Service, a DNS record of the form my-svc.my-namespace.svc.cluster-domain.example is also generated. The difference from a normal Service is that when resolving the domain name, a collection of Pod IPs associated with the Service is returned.

[0024] Service SRV Record Kubernetes creates SRV records based on the named ports in a normal Service or Headless Service. For each named port, the SRV record format is: _port-name.port-protocol.my-svc.my-namespace.svc.cluster-domain.example.

[0025] Among them, port_name is the port name, port-protocol is the port protocol, for a normal Service, the record will be parsed into the port number and domain name: my-svc.my-namespace.svc.cluster-domain.example. For a headless Service, the record will be parsed into multiple results, the SRV record of each Pod associated with the Service, which contains the Pod port number and the domain name in the format of hostname.my-svc.my-namespace.svc.cluster-domain.example.

[0026] A / AAAA records for Pods Generally, Kubernetes generates a domain name for the Pod in the form of pod-ip-address.my-namespace.pod.cluster-domain.example, where pod-ip-address is the IP address of the Pod, my-namespace is the Namespace where the Pod is located, and cluster-domain.example is the suffix of the cluster domain name.

[0027] 5. Multiple VPCs and domain name resolution By default, Pods in a Kubernetes cluster are in the same VPC network. Pods can communicate with each other, and NetworkPolicy can be used to control traffic between networks.

[0028] In order to achieve isolation between tenants and more refined network control, the cluster introduces multiple VPC networks. When creating a Pod, you can specify which VPC the Pod belongs to, and the Pod will be assigned an IP under the VPC. If no peer connection is created, Pods in different VPCs cannot access each other. If not specified, the cluster's default VPC is used.

[0029] Access between Pods is mainly carried out using the Service domain name. In order to resolve the Service domain name, Pod needs to access CoreDNS, which belongs to the default VPC of the cluster.

[0030] The cluster's domain name server must allow Pods in different VPCs to access it and correctly resolve the A / AAAA DNS records of Services and Pods in the cluster.

[0031] The purpose of this application is to solve the problem of accessing CorenDNS across VPCs and resolving Pod and Service DNS records without creating a peer connection, improve the efficiency of resolving domain names, achieve tenant isolation, and reduce the difficulty of managing VPC networks.

[0032] The embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0033] See also Figure 1 As shown, this embodiment provides a domain name resolution method, which specifically includes the following steps: Step S101: deploy the NodelocalDNS application on each node of the Kubernetes cluster and assign a virtual IP address.

[0034] Specifically, in this embodiment, each node of the Kubernetes cluster deploys a NodelocalDNS application and allocates a virtual IP address to provide DNS services for all Pods on the node; the default domain name server address of the Pod points to the IP, and the upstream domain name server of NodelocalDNS is CoreDNS.

[0035] Step S102: In response to the Pod being scheduled to the node and requesting an IP address, a virtual Ethernet pair is created through the CNI network plug-in, and an eBPF program is dynamically generated and mounted to the virtual network device on the host side, wherein one side of the virtual Ethernet pair is connected to the container network namespace of the Pod, and the other side is connected to the host network namespace.

[0036] Specifically, in this embodiment, Figure 2 As shown in the figure, the network initialization of the Pod: When the Pod is scheduled to a node and requests an IP address, the CNI network plug-in creates a veth pair (virtual Ethernet pair), where one side (one end of the veth pair) is connected to the container network namespace of the Pod, and the other side (the other end of the veth pair) is connected to the host's network namespace as a virtual network device on the host.

[0037] Mounting of eBPF program: On the host-side virtual network device of the veth pair, an eBPF program is dynamically generated and mounted. This program is responsible for handling traffic interception and forwarding between the host and the container.

[0038] Step S103: The eBPF program monitors the network traffic sent from the Pod, and makes judgments and processes the traffic according to the destination address of the traffic.

[0039] Specifically, in this embodiment, the eBPF program is mounted on the host network device to judge the traffic entering the node. If the destination address of the traffic is the container (the IP address of the Pod), the eBPF program will forward the traffic to the host-side virtual network device of the container's veth pair.

[0040] For the container's export traffic, the eBPF program will intercept it and determine the destination address.

[0041] If the destination address is the virtual IP address of NodelocalDNS, the traffic will be forwarded to NodelocalDNS of the host network; if the destination address is any other address, the traffic will be processed according to normal network forwarding rules.

[0042] In this step, the eBPF program is mounted on the network devices of the container and the host to intercept and process the traffic. When it is found that the destination address of the access is the address of NodelocalDNS, regardless of whether the Pod is in the default VPC, it can access NodelocalDNS without detouring the SDN network, reducing the complexity of cluster VPC network management. In addition, the eBPF program directly intercepts and forwards the Pod traffic under the same VPC of the same node. It will not pass through the complete network stack and will not detour the SDN network, reducing unnecessary network overhead. This application uses the eBPF program. For Pods in different VPCs to access the domain name server, there is no need to create a peer connection to access the domain name server of the Kubernetes cluster.

[0043] Step S104, after receiving the DNS request from the Pod, NodelocalDNS performs a cache check. In response to a cache hit, the cache result is directly returned to the container. In response to a cache miss, the request is forwarded to the upstream CoreDNS for domain name resolution.

[0044] Specifically, in this embodiment, NodelocalDNS checks the cache: if the cache already has the resolution result of the corresponding domain name, it is directly returned to the container. If there is no cached result, NodelocalDNS will initiate a query request to CoreDNS through the host network.

[0045] NodelocalDNS's cache mechanism reduces requests to CoreDNS and improves resolution efficiency.

[0046] Upstream query of CoreDNS: If NodelocalDNS and CoreDNS are deployed on the same node, the query traffic will not enter the SDN (Software Defined Network) network and will be completed directly through local communication. If NodelocalDNS and CoreDNS are not on the same node, the query traffic will enter the SDN network through the host network to complete cross-node communication.

[0047] When querying across nodes, SDN is used to ensure that traffic is transmitted within the same VPC, optimizing network performance. eBPF technology reduces the overhead of traditional network processing methods and ensures fast forwarding of DNS traffic.

[0048] This embodiment greatly improves the efficiency and response time of domain name resolution by using NodelocalDNS to cache the domain names of Service and Pod. At the same time, it effectively improves the response speed of domain name resolution and reduces network load.

[0049] It should be noted that the above describes some embodiments of the present application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the above embodiments and still achieve the desired results. In addition, the processes depicted in the accompanying drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0050] Based on the same inventive concept, corresponding to any of the above-mentioned embodiment methods, the embodiment of the present application also provides a domain name resolution device.

[0051] like Figure 3 As shown, the domain name resolution device includes: The deployment configuration module 11 is configured to deploy a NodelocalDNS application on each node of the Kubernetes cluster and allocate a virtual IP address; The program generation module 12 is configured to create a virtual Ethernet pair through the CNI network plug-in in response to the Pod being scheduled to the node and requesting an IP address, and dynamically generate an eBPF program, and mount the program to the virtual network device on the host side, wherein one side of the virtual Ethernet pair is connected to the container network namespace of the Pod, and the other side is connected to the host network namespace; The traffic processing module 13 is configured as an eBPF program to monitor the network traffic sent from the Pod, and to judge and process the traffic according to the destination address of the traffic; Domain name resolution module 14, NodelocalDNS performs a cache check after receiving the DNS request from the Pod. If the cache hits, it directly returns the cache result to the container. If the cache misses, it forwards the request to the upstream CoreDNS for domain name resolution. For the convenience of description, the above devices are described in terms of functions and are divided into various modules. Of course, when implementing the embodiments of the present application, the functions of each module can be implemented in the same or multiple software and / or hardware.

[0052] The device of the above embodiment is used to implement the corresponding method in any of the above embodiments, and has the beneficial effects of the corresponding method embodiment, which will not be described in detail here.

[0053] Based on the same inventive concept, corresponding to any of the above-mentioned embodiments and methods, an embodiment of the present application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the method described in any of the above embodiments is implemented.

[0054] Figure 4 A more specific schematic diagram of the hardware structure of an electronic device provided in this embodiment is shown, and the device may include: a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, the memory 1020, the input / output interface 1030, and the communication interface 1040 are connected to each other through the bus 1050 in the device.

[0055] The processor 1010 can be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0056] The memory 1020 may be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 may store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented by software or firmware, the relevant program codes are stored in the memory 1020 and are called and executed by the processor 1010.

[0057] The input / output interface 1030 is used to connect the input / output module to realize information input and output. The input / output module can be configured in the device as a component (not shown in the figure), or it can be externally connected to the device to provide corresponding functions. The input device may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output device may include a display, a speaker, a vibrator, an indicator light, etc.

[0058] The communication interface 1040 is used to connect a communication module (not shown) to realize communication interaction between the device and other devices. The communication module can realize communication through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0059] The bus 1050 includes a path that transmits information between the various components of the device (eg, the processor 1010 , the memory 1020 , the input / output interface 1030 , and the communication interface 1040 ).

[0060] It should be noted that, although the above device only shows the processor 1010, the memory 1020, the input / output interface 1030, the communication interface 1040 and the bus 1050, in the specific implementation process, the device may also include other components necessary for normal operation. In addition, it can be understood by those skilled in the art that the above device may also only include the components necessary for implementing the embodiments of the present specification, and does not necessarily include all the components shown in the figure.

[0061] The electronic device of the above embodiment is used to implement the corresponding method in any of the above embodiments, and has the beneficial effects of the corresponding method embodiment, which will not be described in detail here.

[0062] Based on the same inventive concept, corresponding to any of the above-mentioned embodiments, the present application also provides a non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium stores computer instructions, and the computer instructions are used to enable the computer to execute the method described in any of the above embodiments.

[0063] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, read-only compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, tape disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device.

[0064] The computer instructions stored in the storage medium of the above embodiments are used to enable the computer to execute the method described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0065] A person skilled in the art should understand that the discussion of any of the above embodiments is merely illustrative and is not intended to imply that the scope of the present application (including the claims) is limited to these examples. In line with the concept of the present application, the technical features in the above embodiments or different embodiments may be combined, the steps may be implemented in any order, and there are many other variations of the different aspects of the embodiments of the present application as described above, which are not provided in detail for the sake of simplicity.

[0066] In addition, to simplify the description and discussion, and in order not to make the embodiments of the present application difficult to understand, the known power / ground connections to the integrated circuit (IC) chip and other components may or may not be shown in the provided drawings. In addition, the device may be shown in the form of a block diagram to avoid making the embodiments of the present application difficult to understand, and this also takes into account the fact that the details of the implementation of these block diagram devices are highly dependent on the platform on which the embodiments of the present application are to be implemented (that is, these details should be fully within the scope of understanding of those skilled in the art). Where specific details (e.g., circuits) are set forth to describe exemplary embodiments of the present application, it is obvious to those skilled in the art that the embodiments of the present application can be implemented without these specific details or with changes in these specific details. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0067] Although the present application has been described in conjunction with specific embodiments of the present application, many alternatives, modifications and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may use the discussed embodiments.

[0068] The embodiments of the present application are intended to cover all such substitutions, modifications and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the embodiments of the present application should be included in the scope of protection of the present application.

Claims

1. A domain name resolution method, characterized in that: include: Deploy the NodelocalDNS application on each node in the Kubernetes cluster and assign a virtual IP address; In response to the Pod being scheduled to the node and requesting an IP address, a virtual Ethernet pair is created through the CNI network plug-in, and an eBPF program is dynamically generated and mounted to the virtual network device on the host side, where one side of the virtual Ethernet pair is connected to the container network namespace of the Pod, and the other side is connected to the host network namespace; The eBPF program monitors the network traffic sent from the Pod and makes judgments and processes it based on the destination address of the traffic; After receiving the DNS request from the Pod, NodelocalDNS performs a cache check. In response to a cache hit, it directly returns the cache result to the container. In response to a cache miss, it forwards the request to the upstream CoreDNS for domain name resolution.

2. The method according to claim 1, characterized in that: The default DNS configuration for the Pod is set to the virtual IP address of NodelocalDNS, and NodelocalDNS forwards requests upstream to CoreDNS.

3. The method according to claim 1, characterized in that The eBPF program monitors the network traffic sent from the Pod and makes judgments and processes based on the destination address of the traffic, including: The eBPF program judges the traffic entering the node, and if the destination address is a container, it forwards the traffic to the virtual network device on the host side; For the container's export traffic, the eBPF program intercepts it and determines the destination address.

4. The method according to claim 3, characterized in that The eBPF program intercepts the container's export traffic and determines the destination address, including: In response to the virtual IP address of NodelocalDNS being the destination address, the traffic is intercepted and forwarded to NodelocalDNS on the host network.

5. The method according to claim 1, characterized in that If the response does not hit the cache, the request is forwarded to the upstream CoreDNS for domain name resolution, including: In response to a cache miss, NodelocalDNS initiates a query request to CoreDNS through the host network; Since NodelocalDNS and CoreDNS are deployed on the same node, query traffic will not enter the SDN network and will be completed directly through local communication; In response to the deployment of NodelocalDNS and CoreDNS on different nodes, the query traffic enters the SDN network through the host network to complete cross-node communication.

6. A domain name resolution device, characterized in that: include: The deployment configuration module is configured to deploy the NodelocalDNS application on each node of the Kubernetes cluster and assign a virtual IP address; A program generation module is configured to, in response to a Pod being scheduled to a node and requesting an IP address, create a virtual Ethernet pair through a CNI network plug-in, dynamically generate an eBPF program, and mount the program to a virtual network device on the host side, wherein one side of the virtual Ethernet pair is connected to a container network namespace of the Pod, and the other side is connected to a host network namespace; The traffic processing module is configured as an eBPF program to monitor the network traffic sent from the Pod and make judgments and processes it according to the destination address of the traffic; In the domain name resolution module, NodelocalDNS performs a cache check after receiving the DNS request from the Pod. In response to a cache hit, the cache result is directly returned to the container. In response to a cache miss, the request is forwarded to the upstream CoreDNS for domain name resolution.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the method according to any one of claims 1 to 5 is implemented.

8. A non-transitory computer-readable storage medium, characterized in that: in, The non-transitory computer-readable storage medium stores computer instructions, and the computer instructions are used to cause a computer to execute the method according to any one of claims 1 to 5.

Images