A domain name resolution management method, program product, device and medium

Abstract

The present invention discloses a domain name resolution management method, program product, device and medium, which relate to the field of container technology, and are used to realize the automatic update of DNS records in a cluster. In view of the current problem that the update of DNS records needs to be manually realized after the Ingress resources change, a domain name resolution management method is provided, which monitors whether the Ingress resources change, so as to be linked with the configuration file of the DNS server. When the Ingress resources change, the corresponding domain name information is obtained by parsing the changed Ingress resources, and updated to the DNS configuration file, thereby realizing automatic DNS resolution management. This method effectively avoids the inconvenience caused by manually updating DNS records, reduces the risks caused by manual operations, reduces the system operation and maintenance costs, and improves the availability of the system.

Description

Technical Field

[0001] The present invention relates to the field of container technology, and in particular to a domain name resolution management method, program product, device and medium. Background Art

[0002] Kubernetes (K8s) is a container orchestration platform that provides the ability to automatically deploy, scale, and manage applications. In a Kubernetes cluster, one of the key components is the seven-layer load balancing scheduler (Ingress-Controller). It is used to forward external requests to services within the cluster according to the rules of Ingress (a resource object that defines routing rules from outside the cluster to services within the cluster), that is, to control users to access application services in the cluster through specific domain names and paths. In order to enable external users to access services in a Kubernetes cluster through domain names, it is usually necessary to resolve the domain name defined in the Ingress resource to the external Internet Protocol (IP) address of the Ingress-Controller. Requests to access the domain name defined in the Ingress resource can reach the Ingress-Controller, and then the service container group (Pod) corresponding to the domain name can be resolved. This resolution usually depends on the configuration of an external Domain Name System (DNS) server.

[0003] Currently, every time an Ingress resource is created, updated, or deleted, operations personnel need to manually modify DNS records to reflect these changes. For frequently changing environments or large-scale multi-tenant systems, this manual management method is not only cumbersome and error-prone, but also causes service interruptions or access delays, and cannot meet the needs of dynamic and frequent business releases.

[0004] Therefore, technicians in this field are in urgent need of a domain name resolution management method to solve a series of problems caused by relying on manual updating of DNS configuration when Ingress resources change. Summary of the invention

[0005] The purpose of the present invention is to provide a domain name resolution management method, program product, device and medium to solve a series of problems caused by relying on manual updating of DNS configuration when Ingress resources change.

[0006] In order to solve the above technical problems, the present invention provides a domain name resolution management method, comprising:

[0007] Monitor whether there are any changes in the Ingress resources in the cluster;

[0008] When the Ingress resource changes, the changed Ingress resource is parsed to obtain the corresponding domain name information;

[0009] The domain name information is updated to a configuration file of a domain name system server in the cluster.

[0010] In a possible embodiment, updating the domain name information to a configuration file of a domain name system server in the cluster includes:

[0011] a first plug-in that updates the domain name information to the configuration file of the core domain name system server in the cluster;

[0012] The configuration file is mounted into the container group of the cluster in the form of configuration mapping;

[0013] The first plug-in is used to update the correspondence between the Ingress resource domain name and the seven-layer load balancing scheduler.

[0014] In a possible embodiment, the method further includes:

[0015] Direct all the resolution requests for accessing the domain name related to the Ingress resource outside the cluster to the core domain name system server in the cluster;

[0016] The core domain name system server is also used to: resolve the access request sent by the client to the corresponding Internet Protocol address of the seven-layer load balancing scheduler; and resolve the backend service corresponding to the domain name information in the corresponding Ingress resource through the seven-layer load balancing scheduler.

[0017] In a possible embodiment, directing all resolution requests for accessing domain names related to the Ingress resources outside the cluster to the core domain name system server in the cluster includes:

[0018] Add a name service record entry to the DNS server configuration file;

[0019] The name service record item is used to direct all resolution requests for accessing domain names related to the Ingress resources outside the cluster to the external access address of the core domain name system server.

[0020] In a possible embodiment, after all the resolution requests for accessing the domain name related to the Ingress resource outside the cluster are directed to the core domain name system server in the cluster, the method further includes:

[0021] When receiving an access request from outside the cluster to access the domain name related to the Ingress resource, parsing the access request to the corresponding Internet Protocol address of the seven-layer load balancing scheduler through the core domain name system server;

[0022] The backend service corresponding to the Ingress resource domain name is parsed by the seven-layer load balancing scheduler, and the parsing result is returned.

[0023] In a possible embodiment, resolving the access request to the corresponding Internet Protocol address of the seven-layer load balancing scheduler through the core domain name system server includes:

[0024] The core domain name system server resolves the domain name information of the access request through the second plug-in and corresponds to the Internet protocol address of the seven-layer load balancing scheduler;

[0025] The second plug-in is used to provide domain name resolution service.

[0026] In a possible embodiment, the method further includes:

[0027] The first plug-in and the second plug-in are configured in a configuration map of the core domain name system server.

[0028] In a possible embodiment, before configuring the first plug-in and the second plug-in in the configuration mapping of the core domain name system server, the method further includes:

[0029] The seven-layer load balancing scheduler and the core domain name system server are deployed in the cluster.

[0030] In a possible embodiment, the method further includes:

[0031] Design and deploy monitoring programs;

[0032] Among them, the monitoring program is used to execute the following steps when running: monitoring whether there is any change in the Ingress resources in the cluster; when the Ingress resources change, parsing the changed Ingress resources to obtain the corresponding domain name information; and updating the domain name information to the configuration file of the domain name system server in the cluster.

[0033] In a possible embodiment, monitoring whether the Ingress resource in the cluster changes includes:

[0034] The monitoring program captures the Ingress resource change event by monitoring the application programming interface service of the cluster, and when the Ingress resource change event is captured, it is determined that the Ingress resource has changed.

[0035] In a possible embodiment, when the Ingress resource changes, parsing the changed Ingress resource to obtain corresponding domain name information includes:

[0036] The Ingress resource change event is parsed to obtain the domain name information corresponding to the Ingress resource that has changed.

[0037] In a possible embodiment, the Ingress resource change event includes: an Ingress resource creation event, an Ingress resource update event, and an Ingress resource deletion event.

[0038] In order to solve the above technical problem, the present invention also provides a computer program product, including a computer program / instruction, which implements the steps of the domain name resolution management method described above when executed by a processor.

[0039] In order to solve the above technical problems, the present invention also provides a domain name resolution management device, comprising:

[0040] Memory for storing computer programs;

[0041] The processor is used to implement the steps of the domain name resolution management method as described above when executing the computer program.

[0042] In order to solve the above technical problem, the present invention also provides a non-volatile storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the domain name resolution management method described above are implemented.

[0043] The present invention provides a domain name resolution management method, which monitors whether the Ingress resource has changed, so as to be linked with the configuration file of the DNS server. When the Ingress resource changes, the corresponding domain name information is obtained by parsing the changed Ingress resource, and updated to the DNS configuration file, thereby realizing automatic DNS resolution management. This method effectively avoids the inconvenience caused by manual updating of DNS records, reduces the risks caused by manual operation, reduces the system operation and maintenance costs, and improves the availability of the system.

[0044] The domain name resolution management device and non-volatile storage medium provided by the present invention correspond to the above method and have the same effect as above. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] In order to more clearly illustrate the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0046] Figure 1 A flowchart of a domain name resolution management method provided by an embodiment of the present invention;

[0047] Figure 2 A diagram showing the architecture and process flow of a domain name resolution management method provided by an embodiment of the present invention;

[0048] Figure 3 A structural diagram of a domain name resolution management device provided by an embodiment of the present invention;

[0049] Figure 4 A structural diagram of another domain name resolution management device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0050] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0051] The core of the present invention is to provide a domain name resolution management method, program product, device and medium.

[0052] In order to enable those skilled in the art to better understand the scheme of the present invention, the present invention is further described in detail below in conjunction with the accompanying drawings and specific implementation methods.

[0053] In related technologies, whenever an Ingress resource (a resource object used to define routing rules from outside the cluster to services inside the cluster) is created, updated, or deleted in a Kubernetes (K8s, a container orchestration platform) cluster, the operation and maintenance personnel are required to manually modify the Domain Name System (DNS) records to reflect these changes, otherwise external users cannot access the application services at the backend of the cluster through the correct domain name and path. However, for application scenarios such as frequent environmental changes or large-scale multi-tenant systems, this manual management method is not only cumbersome and error-prone, but also causes service interruptions or access delays, and cannot meet the dynamic and frequent business release requirements.

[0054] Therefore, in order to solve the above problems, the present invention provides a domain name resolution management method such as Figure 1 As shown, including:

[0055] S11: Monitors whether there are any changes in the Ingress resources in the cluster.

[0056] S12: When the Ingress resource changes, the changed Ingress resource is parsed to obtain the corresponding domain name information.

[0057] S13: Update the domain name information to the configuration file of the domain name system server in the cluster.

[0058] Among them, in step S11, monitoring whether the Ingress resource has changed can be achieved by monitoring the Ingress resource change events in the Kubernetes cluster in a possible implementation. Specifically, the Ingress resource change events may include but are not limited to: Ingress resource creation events, Ingress resource update events, and Ingress resource deletion events, which correspond to the addition, update, and deletion of the domain name information corresponding to the Ingress resource, respectively.

[0059] Furthermore, the Ingress resource change event mentioned in the above embodiment will occur when the Ingress resource changes in the Kubernetes cluster. Therefore, in a possible embodiment, the above step S11 determines whether the Ingress resource changes in the Kubernetes cluster by monitoring whether the above Ingress resource change event occurs in the Kubernetes cluster, which can be specifically:

[0060] By monitoring the application programming interface service (K8s API Server) of the Kubernetes cluster, Ingress resource change events are captured. When Ingress resource change events are captured, it is determined that the Ingress resources have changed.

[0061] Similarly, in this implementation scheme, the parsing of the changed Ingress resource in step S12 is to parse the monitored Ingress resource change event, and obtain the domain name information corresponding to the Ingress resource targeted by the Ingress resource change event. Finally, in step S13, the domain name information corresponding to the Ingress resource parsed from the Ingress resource change event is updated to the configuration file of the DNS server, completing an automatic update of the DNS record of the Ingress resource change.

[0062] It should also be noted that the above process steps of the method are easy to implement and can be implemented by pre-written programs, script files or functional modules, and this embodiment does not limit this. In a possible embodiment, the method also includes:

[0063] S10: Design and deploy monitoring programs.

[0064] Among them, the monitoring program is used to execute the above steps S11~S13 when running. Specifically, how to implement S11~S13 for the monitoring program. Specifically, step S11 in a possible embodiment is to monitor the Ingress resource change event at the specified interface (K8s API Server). When the monitoring interface is known and the object to be monitored is known, there are currently many mature implementation plans for monitoring specific events, so this embodiment will not be repeated. Similarly, step S12 corresponds to parsing the event obtained by monitoring in step S11. When the Ingress resource change events to be monitored are all currently available and are common events in the cluster, it is not difficult to implement the parsing of the Ingress resource change event by writing a program script. Finally, step S13 requires updating specific information (domain name information obtained by parsing the Ingress resource change event) to the specified location (configuration file of the DNS server), which is also a common operation in the computer field. It can be achieved through the instructions for writing configurations to the configuration file supported by the Kubernetes cluster and the DNS server, and this embodiment will not be repeated.

[0065] In summary, the domain name resolution management method provided by the present invention realizes the linkage between the domain name information corresponding to the Ingress resource and the DNS server by monitoring the changes of the Ingress resource. By pre-writing monitoring programs, script files or deploying functional modules, the operation and maintenance personnel of the Kubernetes cluster do not need to frequently manually update the DNS records, and can also realize the dynamic update of the DNS configuration, thereby realizing automated DNS resolution management. This method effectively avoids the inconvenience caused by manual updates, reduces the risks caused by manual operations, reduces the operation and maintenance costs of the cluster, and improves the availability of the system.

[0066] On the other hand, regarding how to dynamically update the domain name information corresponding to the changed Ingress resource to the configuration file of the DNS server, this embodiment further provides a possible implementation scheme, and the above-mentioned step S13 is specifically as follows:

[0067] The first plugin that updates the CoreDNS server configuration files in the cluster with domain information.

[0068] The configuration file is mounted to the container group (pod) of the cluster in the form of configuration mapping (configmap). The first plug-in (hosts plug-in) is used to update the correspondence between the Ingress resource domain name and the seven-layer load balancing scheduler (Ingress-Controller).

[0069] Specifically, the above-mentioned Ingress-Controller is a seven-layer load balancing scheduler and a key component in the Kubernetes cluster. It is mainly responsible for implementing the routing rules defined in the Ingress resource object. Specifically, Ingress-Controller is used to manage the Hypertext Transfer Protocol (HTTP) / Hypertext Transfer Protocol Secure (HTTPS) traffic from outside the cluster to the services inside the cluster, and realize the function of external access to services within the cluster. That is, in the Kubernetes cluster, the Ingress-Controller component provides Ingress-related functions.

[0070] The above-mentioned CoreDNS is a flexible and scalable DNS server, mainly used for service discovery in Kubernetes clusters. Specifically, CoreDNS can monitor the creation and destruction events of services and pods in the cluster, record the corresponding resolution records, and provide a mutual positioning process for services in the cluster. When other pods access services or pods in the cluster through domain names, they will query the CoreDNS service for resolution records and then access the resolved Internet Protocol (IP) address.

[0071] In the application scenarios targeted by this method, this embodiment mainly uses the hosts plug-in among the many flexibly extensible plug-ins of CoreDNS. Among them, the hosts plug-in is the first plug-in mentioned above. The hosts plug-in is similar to the local hosts file, allowing users to customize domain name resolution records. Therefore, the record of the domain name corresponding to the Ingress resource in DNS in the above step S13 can be implemented through the hosts plug-in. It should be particularly noted that the configuration file in CoreDNS is mounted to the pod in the Kubernetes cluster through configmap. Therefore, when the hosts plug-in updates the domain name information in the configuration file, CoreDNS will automatically trigger subsequent updates, and no human intervention is required to achieve that the next time the user resolves the domain name through CoreDNS, it can be resolved to the backend service corresponding to the Kubernetes cluster through the correct domain name and path.

[0072] Based on this embodiment, in the above step S13, it is only necessary to write the domain name information obtained by parsing the changed Ingress resources into the hosts plug-in of CoreDNS to realize the automatic dynamic update of DNS records without human intervention. This can avoid the inconvenience caused by manual updates, reduce the risks caused by manual operations, reduce the operation and maintenance costs of the cluster, and improve the system availability.

[0073] In the above embodiment, it has been explained that CoreDNS, as a type of DNS server, can be used to implement service discovery of Kubernetes clusters. That is, when a user accesses a domain name, the access request can be resolved to the correct backend service and container group according to the DNS record. Based on this principle, this embodiment also provides a further implementation scheme, and the method also includes:

[0074] S21: Directs all domain name resolution requests from outside the cluster that access Ingress resources to the core domain name system server in the cluster.

[0075] The CoreDNS server is also used to resolve the access request sent by the client to the corresponding Internet Protocol address of the seven-layer load balancing scheduler. And resolve the backend service corresponding to the domain name information in the corresponding Ingress resource through the seven-layer load balancing scheduler.

[0076] As described in the above embodiment, CoreDNS has the functions of domain name resolution and service discovery in the Kubernetes cluster, and can resolve user access to specific domain names to the corresponding services and pods in the Kubernetes cluster through DNS records. Therefore, when the Ingress resources change based on the above method, the corresponding domain name can be automatically updated to the CoreDNS configuration file. Through the solution provided in this embodiment, all access requests for domain names related to Ingress resources are directed to CoreDNS, and automated DNS resolution management can be achieved.

[0077] Furthermore, this embodiment also provides a specific implementation plan for how to direct all access requests for Ingress resource domain names sent by the client to CoreDNS. The above step S21 is specifically as follows:

[0078] Add a name service record entry to the DNS server configuration file.

[0079] The name service record item is used to direct all the resolution requests for accessing the domain names related to the Ingress resources outside the cluster to the external access address of the core domain name system server.

[0080] For example, in Linux (an operating system kernel) systems, the DNS domain name service is generally configured through the / etc / resolv.conf file. Assuming that the external access address of CoreDNS is 192.168.2.3, you can add a configuration record of "nameserver 192.168.2.3" to the / etc / resolv.conf file, that is, use CoreDNS as the name service (nameserver) of the Kubernetes cluster. In this way, whenever an external client (client) accesses an Ingress-related domain name, the access request will be resolved through CoreDNS to the correct cluster backend service.

[0081] Afterwards, regarding how the CoreDNS resolves the access request to the correct cluster backend service, this embodiment also provides a specific implementation scheme. After step S21, the method further includes:

[0082] S22: When receiving an access request from outside the cluster to access a domain name related to an Ingress resource, the core domain name system server resolves the access request to the corresponding Internet protocol address of the seven-layer load balancing scheduler.

[0083] S23: The backend service corresponding to the Ingress resource domain name is resolved through the seven-layer load balancing scheduler, and the resolution result is returned.

[0084] That is, after this embodiment directs the external client's request to access the Ingress-related domain name to CoreDNS, CoreDNS can resolve the access request to the correct seven-layer load balancing scheduler (Ingress-Controller) IP address, and then resolve the backend service corresponding to the domain name in the Ingress resource through Ingress-Controller.

[0085] Furthermore, this embodiment further provides a specific implementation scheme for how to implement the domain name resolution function. The above step S22 is specifically as follows:

[0086] The core domain name system server resolves the domain name information of the access request through the second plug-in and corresponds it to the Internet Protocol address of the seven-layer load balancing scheduler.

[0087] The second plug-in is used to provide domain name resolution service.

[0088] As can be seen from the above embodiments, CoreDNS is a flexible and scalable DNS server, which includes multiple functional plug-ins including hosts plug-ins, such as kubernetes plug-ins, log plug-ins, cache plug-ins, etc. Among them, the kubernetes plug-in is a plug-in that can automatically parse the DNS records of services and pods, which can be used for service discovery in the Kubernetes cluster, thereby parsing the user's access request to the correct backend service. In other words, the kubernetes plug-in is the second plug-in mentioned above.

[0089] In summary, the above embodiment provides a specific linkage scheme between the Ingress domain name and CoreDNS. First, by using CoreDNS as the domain name resolution server of the Kubernetes cluster, all requests for external clients to access the domain name related to the Ingress resource received by the Kubernetes cluster are resolved by CoreDNS. Specifically, CoreDNS can be implemented through the kubernetes plug-in: the Ingress domain name is resolved to the correct Ingress-Controller IP address, and then the backend service corresponding to the domain name in the Ingress resource is resolved through the Ingress-Controller. Further, the implementation of the above domain name resolution function depends on the timely update of DNS records. The above method steps S11~S13 can monitor the changes of Ingress resources in the Kubernetes cluster, and update the changed Ingress domain name to the hosts plug-in of CoreDNS. Since the configuration file of CoreDNS is mounted in the pod in the form of configmap, the update will be automatically triggered after the configuration file changes, without human intervention. That is, when a subsequent external client has a request to access the changed Ingress domain name, CoreDNS can resolve the access request to the correct cluster backend service according to the updated DNS record.

[0090] It can be seen that the implementation scheme provided in the above embodiment can realize the linkage between the Ingress domain name and CoreDNS. Whenever the Ingress domain name changes, it can be monitored and automatically updated to the hosts plug-in of CoreDNS to realize the dynamic update of DNS records. When the user has a domain name access request for the cluster, the domain name request can be automatically resolved through CoreDNS, based on the previously dynamically updated DNS records, to ensure that the access request can be accurately resolved to the cluster backend service. The whole process is simple to implement. It only needs to use CoreDNS as the domain name resolution server of the Kubernetes cluster and monitor the Ingress resource change events in the Kubernetes cluster. After the Ingress resource changes, the corresponding domain name is updated to CoreDNS to complete the automated DNS resolution management. It avoids the inconvenience caused by manual updates, reduces the risks caused by human operations, reduces the system operation and maintenance costs, and improves the availability of the system.

[0091] On the other hand, regarding how to implement the linkage solution between the Ingress domain name and CoreDNS provided in the above embodiment, this embodiment also provides a corresponding deployment solution, and the above method also includes:

[0092] S31: Deploy a seven-layer load balancing scheduler and core domain name system server in the cluster.

[0093] S32: Configure the first plug-in and the second plug-in in the configuration map of the core domain name system server.

[0094] It should be noted that Ingress-Controller provides the above-mentioned Ingress-related functions, while CoreDNS is used to provide domain name resolution functions within the Kubernetes cluster. Ingress-Controller and CoreDNS are both existing components and servers. Their specific deployment schemes can be learned based on the corresponding operation manuals, and this embodiment will not be repeated here. The first plug-in deployed in CoreDNS is the hosts plug-in among the common plug-ins of CoreDNS, and the second plug-in deployed in CoreDNS is the kubernetes plug-in among the common plug-ins of CoreDNS. Its specific deployment scheme can be found in the operation manual of CoreDNS, and this embodiment will not be repeated here. After the deployment of Ingress-Controller and CoreDNS is completed in the Kubernetes cluster, the dynamic and fully automatic management of Ingress domain name resolution can be realized through the Ingress domain name and CoreDNS linkage scheme provided in the above embodiment. There is no need to manually configure the correspondence between DNS and Ingress domain names, which can significantly improve the degree of automation of domain name resolution and reduce the risks brought by human operation.

[0095] Finally, based on the implementation schemes provided in the above embodiments, this embodiment provides a complete and specific implementation process of the domain name resolution management method. Figure 2 As shown in the figure, the complete Ingress domain name access and dynamic management process includes the following stages.

[0096] 1. Deployment and initialization phase.

[0097] First, deploy Ingress-Controller and CoreDNS in the Kubernetes cluster. Ingress-Controller is used to provide Ingress related functions, while CoreDNS is used to provide domain name resolution functions in the Kubernetes cluster.

[0098] After that, you need to configure the kubernetes plug-in and hosts plug-in in the CoreDNS configmap to support DNS resolution and dynamic domain name updates for Ingress resources within the Kubernetes cluster. The kubernetes plug-in is used to enable CoreDNS to automatically resolve services and pods within the cluster, while the hosts plug-in is used to implement automatic and dynamic domain name resolution record updates when needed (i.e., when Ingress resources are created, updated, deleted, etc.).

[0099] Then, we need to design a monitoring program to monitor changes in Ingress resources in the Kubernetes cluster. Specifically, the monitoring program monitors the application programming interface service (K8s API Server) of the Kubernetes cluster. When there are changes in Ingress resources in the Kubernetes cluster, corresponding Ingress resource change events will be generated in the cluster, including Ingress resource creation events, Ingress resource update events, and Ingress resource deletion events. The monitoring program monitors the application programming interface service to capture these events, thereby determining that Ingress resource changes have occurred in the Kubernetes cluster. And by parsing these events to extract the corresponding domain name and the corresponding backend service information, the domain name resolution record is automatically generated and updated based on this, and written to the hosts plug-in of the CoreDNS configuration file.

[0100] For example, Figure 2 As shown in the figure, the monitoring program listens to an Ingress resource creation event at the application programming interface service, and parses this event to obtain the domain name resolution record of "1.2.3.4 app.example.com". After that, the monitoring program writes this domain name resolution record "1.2.3.4 app.example.com" to the hosts plug-in of the CoreDNS configuration file. Since the CoreDNS configuration file is mounted into the pod in the form of configmap, the update is automatically triggered when the configuration file changes.

[0101] Finally, configure a name service record item in the external DNS server to point all domain name resolution requests from external clients received by the Kubernetes cluster to the IP address or domain name of CoreDNS in the Kubernetes cluster, thereby providing domain name resolution services in the Kubernetes cluster through CoreDNS.

[0102] For example, Figure 2As shown in the figure, in Linux systems, DNS domain name services are generally configured through the / etc / resolv.conf file. If the external access address of CoreDNS is 192.168.2.3, the configuration file for configuring the DNS server can be: nameserver 192.168.2.3. After that, all access requests from external clients related to the Ingress domain name will be directed to the IP address 192.168.2.3, that is, to CoreDNS, which will implement the domain name resolution of the access request.

[0103] Based on the above configuration, when an external client accesses an Ingress-related domain name, it will resolve the correct Ingress-Controller IP address through CoreDNS, and then resolve the backend service corresponding to the domain name in Ingress through Ingress-Controller.

[0104] 2. External client access request processing phase.

[0105] When an external client sends a domain name-based service access request to the Kubernetes cluster, the access request is first directed to CoreDNS based on the configuration of the DNS server in the above deployment initialization phase. CoreDNS resolves the domain name to the correct Ingress-Controller IP address through the kubernetes plug-in deployed in it, and then the Ingress-Controller resolves the request to the correct backend service pod in the Kubernetes cluster based on the routing rules specified in the Ingress resource corresponding to the domain name.

[0106] 3. DNS resolution management stage of Ingress resource domain names.

[0107] In the above-mentioned stage 2, CoreDNS realizes the correct resolution of the domain name access request of the external user, which depends on the accurate recording and timely updating of the DNS record. Therefore, in this stage, the monitoring program monitors the application programming interface service of the Kubernetes cluster in real time to capture the Ingress resource change event that occurs with the change of the Ingress resource in the Kubernetes cluster. After capturing the change event, parse this event to obtain the domain name corresponding to the changed Ingress resource. Finally, based on the Ingress resource operation represented by the change event, the hosts plug-in in the CoreDNS configuration file is configured with the same domain name resolution record. For example, if the Ingress resource creation event is captured, the domain name resolution record obtained by parsing the Ingress resource creation event is added to the hosts plug-in of the CoreDNS configuration file; if the Ingress resource update event is captured, the corresponding original domain name resolution record in the hosts plug-in of the CoreDNS configuration file is updated according to the domain name resolution record obtained by parsing the Ingress resource update event; if the Ingress resource deletion event is captured, the corresponding original domain name resolution record in the hosts plug-in of the CoreDNS configuration file is deleted according to the domain name resolution record obtained by parsing the Ingress resource deletion event. This enables automated and dynamic configuration updates of DNS records without human intervention, ensuring that subsequent access resolution requests for the changed Ingress domain names in Phase 2 can be resolved to the correct service pod in the Kubernetes cluster backend.

[0108] In summary, the domain name resolution management method provided in this embodiment has the following three beneficial effects: 1) Fully automated management: The program monitors the changes of Ingress resources in the cluster and automatically updates the DNS records, without manual operation, which greatly reduces the complexity of operation and maintenance. 2) Efficient and reliable: Dynamically updating DNS records ensures the timeliness and accuracy of domain name resolution, avoids the potential risks caused by human errors, and achieves high availability of the system. 3) Adaptability to complex scenarios: Applicable to large-scale Kubernetes clusters, multi-tenant environments, and frequent service updates, improving the scalability and maintenance efficiency of the system.

[0109] In addition to the embodiment of a domain name resolution management method provided in the above embodiment, the present invention also provides an embodiment corresponding to a computer program product. A computer program product includes a computer program / instruction, and when the computer program / instruction is executed by a processor, the steps of the domain name resolution management method described in any of the above embodiments can be implemented.

[0110] Since the embodiments of the computer program product part correspond to the embodiments of the method part, please refer to the description of the embodiments of the method part for the embodiments of the computer program product part, which will not be repeated here.

[0111] A computer program product provided in this embodiment includes a computer program / instruction. When the computer program / instruction is executed by the processor, the steps of the domain name resolution management method described in any of the above embodiments can be implemented. Therefore, when the computer program product is deployed and the computer program / instruction therein is executed, it can be realized by monitoring whether the Ingress resource changes, so as to link with the configuration file of the DNS server. When the Ingress resource changes, the corresponding domain name information is obtained by parsing the changed Ingress resource, and updated to the DNS configuration file, thereby realizing automated DNS resolution management. This device effectively avoids the inconvenience caused by manual updating of DNS records and greatly reduces the complexity of operation and maintenance. In addition, this device reduces the risks brought by human operation, ensures the timeliness and accuracy of domain name resolution, and improves the availability of the system. In addition, this device can be applied to large-scale Kubernetes clusters, multi-tenant environments, and frequent service updates, improving the scalability and maintenance efficiency of the system.

[0112] In the above embodiment, a domain name resolution management method is described in detail, and the present invention also provides a corresponding embodiment of a domain name resolution management device. It should be noted that the present invention describes the embodiment of the device part from two perspectives, one is based on the functional module perspective, and the other is based on the hardware perspective.

[0113] Based on the functional module perspective, such as Figure 3 As shown, this embodiment provides a domain name resolution management device, including:

[0114] The monitoring module 11 is used to monitor whether there is any change in the Ingress resources in the cluster.

[0115] The parsing module 12 is used to parse the changed Ingress resources when the Ingress resources change, so as to obtain the corresponding domain name information.

[0116] The updating module 13 is used to update the domain name information to the configuration file of the domain name system server in the cluster.

[0117] Since the embodiments of the apparatus part correspond to the embodiments of the method part, please refer to the description of the embodiments of the method part for the embodiments of the apparatus part, which will not be repeated here.

[0118] A domain name resolution management device provided in this embodiment is linked with the configuration file of the DNS server by monitoring whether the Ingress resource has changed. When the Ingress resource changes, the corresponding domain name information is obtained by parsing the changed Ingress resource and updated to the DNS configuration file, thereby realizing automated DNS resolution management. This device effectively avoids the inconvenience caused by manual updating of DNS records and greatly reduces the complexity of operation and maintenance. In addition, this device reduces the risks brought by human operation, ensures the timeliness and accuracy of domain name resolution, and improves the availability of the system. In addition, this device can be applied to large-scale Kubernetes clusters, multi-tenant environments, and scenarios with frequent service updates, improving the scalability and maintenance efficiency of the system.

[0119] Figure 4 A structural diagram of a domain name resolution management device provided by another embodiment of the present invention, such as Figure 4 As shown, a domain name resolution management device includes: a memory 20, for storing a computer program;

[0120] The processor 21 is used to implement the steps of a domain name resolution management method in the above embodiment when executing a computer program.

[0121] The domain name resolution management device provided in this embodiment may include but is not limited to a mobile terminal, a personal computer, a workstation, etc.

[0122] Among them, the processor 21 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 21 can be implemented in at least one hardware form of a digital signal processor (DSP), a field-programmable gate array (FPGA), and a programmable logic array (PLA). The processor 21 may also include a main processor and a coprocessor. The main processor is a processor for processing data in the awake state, also known as a central processing unit (CPU); the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor 21 may be integrated with a graphics processing unit (GPU), which is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 21 may also include an artificial intelligence (AI) processor, which is used to process computing operations related to machine learning.

[0123] The memory 20 may include one or more computer-readable storage media, which may be non-transitory. The memory 20 may also include a high-speed random access memory, and a non-volatile memory, such as one or more disk storage devices, flash memory storage devices. In this embodiment, the memory 20 is at least used to store the following computer program 201, wherein, after the computer program is loaded and executed by the processor 21, it can implement the relevant steps of a domain name resolution management method disclosed in any of the aforementioned embodiments. In addition, the resources stored in the memory 20 may also include an operating system 202 and data 203, etc., and the storage method may be temporary storage or permanent storage. Among them, the operating system 202 may include Windows, Unix, Linux, etc. Data 203 may include, but is not limited to, a domain name resolution management method, etc.

[0124] In some embodiments, a domain name resolution management device may further include a display screen 22 , an input / output interface 23 , a communication interface 24 , a power supply 25 , and a communication bus 26 .

[0125] Those skilled in the art will understand that Figure 4 The structure shown in the figure does not constitute a limitation on a domain name resolution management device, and may include more or fewer components than those shown in the figure.

[0126] A domain name resolution management device provided by an embodiment of the present invention includes a memory and a processor. When the processor executes a program stored in the memory, it can implement the following method: a domain name resolution management method.

[0127] A domain name resolution management device provided in this embodiment executes a computer program stored in a memory through a processor to realize linkage with the configuration file of a DNS server by monitoring whether the Ingress resource has changed. When the Ingress resource changes, the corresponding domain name information is obtained by parsing the changed Ingress resource and updating it to the DNS configuration file, thereby realizing automated DNS resolution management. This device effectively avoids the inconvenience caused by manual updating of DNS records and greatly reduces the complexity of operation and maintenance. In addition, this device reduces the risks brought by human operation, ensures the timeliness and accuracy of domain name resolution, and improves the availability of the system. In addition, this device can be applied to large-scale Kubernetes clusters, multi-tenant environments, and scenarios with frequent service updates, improving the scalability and maintenance efficiency of the system.

[0128] Finally, the present invention also provides an embodiment corresponding to a non-volatile storage medium. The non-volatile storage medium stores a computer program, and when the computer program is executed by a processor, the steps recorded in the above method embodiment are implemented.

[0129] It is understandable that if the method in the above embodiment is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a non-volatile storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium to execute all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc. Various media that can store program codes.

[0130] A non-volatile storage medium provided in this embodiment, when the computer program stored therein is executed, can be linked with the configuration file of the DNS server by monitoring whether the Ingress resource has changed. When the Ingress resource changes, the corresponding domain name information is obtained by parsing the changed Ingress resource and updating it to the DNS configuration file, thereby realizing automated DNS resolution management. Based on the execution of the computer program stored in the non-volatile storage medium provided by this embodiment, the inconvenience caused by manual updating of DNS records can be effectively avoided, and the complexity of operation and maintenance is greatly reduced. In addition, the risks brought by manual operation can be reduced, the timeliness and accuracy of domain name resolution can be ensured, and the availability of the system can be improved. Finally, the computer program stored in the non-volatile storage medium provided by the execution of this embodiment can be applied to large-scale Kubernetes clusters, multi-tenant environments, and frequent service updates, which improves the scalability and maintenance efficiency of the system.

[0131] The above is a detailed introduction to a domain name resolution management method, program product, device and medium provided by the present invention. The various embodiments in the specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same and similar parts between the embodiments can be referenced to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part description. It should be pointed out that for ordinary technicians in this technical field, without departing from the principle of the present invention, several improvements and modifications can be made to the present invention, and these improvements and modifications also fall within the scope of protection of the present invention.

[0132] It should also be noted that, in this specification, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "comprise", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the statement "comprises a ..." does not exclude the presence of other identical elements in the process, method, article or device including the element.

Claims

1. A domain name resolution management method, characterized in that: include: Monitor whether there are any changes in the Ingress resources in the cluster; When the Ingress resource changes, the changed Ingress resource is parsed to obtain the corresponding domain name information; A first plug-in that updates the domain name information to a configuration file of a core domain name system server in the cluster; The configuration file is mounted in the container group of the cluster in the form of configuration mapping; the first plug-in is a hosts plug-in, and the first plug-in is used to update the correspondence between the Ingress resource domain name and the seven-layer load balancing scheduler; The method further comprises: Add a name service record item in the configuration file of the domain name system server; wherein the name service record item is used to point all the resolution requests for accessing the domain name related to the Ingress resource outside the cluster to the external access address of the core domain name system server; When receiving an access request from outside the cluster to access a domain name related to the Ingress resource, the core domain name system server resolves the domain name information of the access request through a second plug-in and corresponds it to the Internet Protocol address of the seven-layer load balancing scheduler; wherein the second plug-in is a kubernetes plug-in, and the second plug-in is used to provide a domain name resolution service; The backend service corresponding to the Ingress resource domain name is parsed by the seven-layer load balancing scheduler, and the parsing result is returned.

2. The domain name resolution management method according to claim 1, characterized in that: The method further comprises: The first plug-in and the second plug-in are configured in a configuration map of the core domain name system server.

3. The domain name resolution management method according to claim 2, characterized in that: Before configuring the first plug-in and the second plug-in in the configuration map of the core domain name system server, the method further includes: The seven-layer load balancing scheduler and the core domain name system server are deployed in the cluster.

4. The domain name resolution management method according to any one of claims 1 to 3, characterized in that: The method further comprises: Design and deploy monitoring programs; Among them, the monitoring program is used to execute the following steps when running: monitoring whether there is any change in the Ingress resources in the cluster; when the Ingress resources change, parsing the changed Ingress resources to obtain the corresponding domain name information; and updating the domain name information to the configuration file of the domain name system server in the cluster.

5. The domain name resolution management method according to claim 4, characterized in that: The monitoring of whether the Ingress resources in the cluster have changed includes: The monitoring program captures Ingress resource change events by monitoring the application programming interface service of the cluster, and when the Ingress resource change event is captured, it is determined that the Ingress resource has changed.

6. The domain name resolution management method according to claim 5, characterized in that: When the Ingress resource changes, parsing the changed Ingress resource to obtain the corresponding domain name information includes: The Ingress resource change event is parsed to obtain the domain name information corresponding to the Ingress resource that has changed.

7. The domain name resolution management method according to claim 6, characterized in that: The Ingress resource change event includes: an Ingress resource creation event, an Ingress resource update event, and an Ingress resource deletion event.

8. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the steps of the domain name resolution management method according to any one of claims 1 to 7 are implemented.

9. A domain name resolution management device, characterized in that: include: Memory for storing computer programs; A processor, configured to implement the steps of the domain name resolution management method as described in any one of claims 1 to 7 when executing the computer program.

10. A non-volatile storage medium, characterized in that: The non-volatile storage medium stores a computer program, and when the computer program is executed by the processor, the steps of the domain name resolution management method according to any one of claims 1 to 7 are implemented.

Images