DNS automatic scheduling method based on container automatic expansion and contraction

Abstract

The invention relates to the technical field of computer load balancing, and discloses a DNS automatic scheduling method based on container automatic expansion and contraction, and the method comprises the steps: S1, building an open source Nginx service in a Kubernetes container mode; s2, performing Kubernetes HPA automatic expansion and contraction on the Nginx service, and configuring an expansion and contraction threshold value; s3, deploying a self-developed CronDNS (Domain Name Server) service in a Kubernetes container mode; and S4, configuring the CronDNS. According to the DNS automatic scheduling method based on container automatic expansion and contraction, the design difficulty is small, services are completely decoupled, cloud dependence is reduced, the cloud cost can be reduced, and flexibility and controllability can be improved.

Description

Technical Field

[0001] The present application relates to the technical field of computer load balancing, and in particular to a DNS automatic scheduling method based on automatic expansion and contraction of containers. Background Art

[0002] In modern network architecture, load balancer (LB) is an important component for distributing network traffic and ensuring high availability and reliability of the system. With the popularity of cloud computing, many enterprises and developers choose to use load balancing services provided by cloud products (such as AWS Elastic Load Balancer, Azure Load Balancer, GCP LoadBalancing, etc.) to manage their network traffic. These cloud product LBs have the advantages of easy management, automatic expansion, and high security. However, with the development of business and the demand for cost optimization, the defects and shortcomings of existing cloud product LBs in some aspects have gradually emerged. These shortcomings are mainly: 1. High cost: The usage fee of cloud product LB is usually charged according to traffic and number of instances. In high concurrency and large traffic scenarios, the cost increases significantly, bringing a greater financial burden to enterprises; 2. Insufficient flexibility and controllability: The configuration and functions of cloud product LB are limited by the restrictions of cloud service providers. Users are subject to certain restrictions in terms of flexible customization and optimization, and cannot make fine adjustments based on their own business needs; 3. Dependence on a single supplier: LB that relies on a single cloud service provider has a certain risk of supplier lock-in. Once the supplier's service has problems or price adjustments, it is difficult for users to quickly migrate to other solutions; 4. Slow automatic expansion response speed: Although cloud product LB usually has automatic expansion function, the response speed sometimes cannot meet the real-time expansion requirements in high-concurrency scenarios, which may cause short-term performance bottlenecks or service interruptions.

[0003] Therefore, a better DNS automatic scheduling technology is urgently needed. Summary of the invention

[0004] The purpose of this application is to provide a DNS automatic scheduling method based on automatic expansion and contraction of containers to solve the technical problems raised in the above background.

[0005] To achieve the above purpose, the present application discloses the following technical solution: a DNS automatic scheduling method based on automatic expansion and contraction of containers, the method comprising the following steps: S1-Build an open source Nginx service in Kubernetes container mode, including: deploying the open source Nginx service in a containerized manner in the Kubernetes cluster, where the Nginx cluster acts as a reverse proxy server, responsible for receiving and distributing front-end requests to back-end services; S2-Automatically scale the Nginx service using Kubernetes HPA and configure the scaling threshold, including: configuring Kubernetes HPA to automatically manage the expansion and reduction of the Nginx service. The scaling threshold is the resource usage threshold. When the load increases, the number of instances of the Nginx cluster is automatically increased; when the load decreases, the number of instances of the Nginx cluster is automatically reduced. S3-Deploy the self-developed CronDNS service in Kubernetes container mode, including: deploying the CronDNS service, which actively obtains the IP changes of the Nginx cluster at regular intervals and automatically registers the latest IP address to the DNS service of the cloud product; S4-Configure CronDNS, including obtaining Nginx configuration and docking target DNS configuration; wherein, obtaining Nginx configuration specifically includes: configuring CronDNS to obtain relevant information of the Nginx cluster, and the relevant information includes the namespace and label tags where the Nginx cluster is located; the docking target DNS configuration specifically includes: configuring CronDNS to dock the target DNS service, and the target DNS service includes cloud information, access keys and DNS interface information.

[0006] Preferably, the receiving and distributing of front-end requests to back-end services specifically includes: The Nginx cluster receives requests from DNS resolution and forwards the requests to the backend application server; The Nginx cluster evenly distributes requests to each application server in the cluster according to the configured load balancing strategy.

[0007] Preferably, the load balancing strategy includes a preconfigured polling strategy and a least connection strategy.

[0008] Preferably, the resource usage threshold includes CPU usage and memory usage.

[0009] Preferably, the Nginx cluster uses each cloud DNS product service as a load balancer; wherein the DNS service provided by each cloud DNS product service is used to resolve domain names and distribute requests to each node of the Nginx cluster.

[0010] Preferably, the HPA is a native automatic scaling service for Kubernetes.

[0011] Preferably, the configured CronDNS is used to connect to the DNS API and has operable permissions; when CoreDNS finds that the number of copies of the Nginx cluster has increased, it obtains the public IP of the Nginx cluster instance; and adds the public IP to the record corresponding to its domain name through the cloud API of the cloud DNS product service, otherwise deletes the reduced public IP.

[0012] The DNS automatic scheduling method based on automatic expansion and contraction of containers in this application has the following technical effects: First: Reduce cloud costs: Self-built Nginx services do not need to rely on the LB services provided by cloud service providers. By self-building Nginx services, enterprises can use their own resources or choose more economical cloud solutions, thereby significantly reducing the cost of using load balancing. In addition, self-built solutions reduce the fees charged by cloud service providers based on usage, optimizing operating costs; Second: Improve flexibility and controllability: Self-built Nginx and CronDNS services allow users to flexibly configure and adjust according to specific business needs, improving the controllability of the system. Users can independently define expansion strategies, load balancing strategies, and DNS update frequencies to meet the needs of specific scenarios. In addition, using the HPA function of Kubernetes, the Nginx service can automatically expand and shrink according to actual load conditions, providing a high degree of flexibility and controllability. Enterprises can customize expansion strategies and load balancing strategies according to specific business needs to meet the needs of specific scenarios; Third: Complete decoupling of business: The independent operation of Nginx and CronDNS services decouples business logic from the underlying load balancer, enhancing the stability and maintainability of the system. No matter how the underlying load balancer changes, the business logic can remain unchanged, reducing the impact on the system; Fourth: High availability and scalability: Through the HPA function of Kubernetes, the Nginx service can automatically expand and shrink according to the load, ensuring the high availability of the system in high-concurrency scenarios. At the same time, the CronDNS service automatically updates the DNS record to ensure that the traffic can be correctly distributed to the latest Nginx cluster instance, improving the reliability of the system; Fifth: Reduce cloud dependence: The self-developed CronDNS service is compatible with the DNS interfaces of most cloud service providers, ensuring seamless integration of the system in a multi-cloud environment and reducing dependence on a single cloud service provider. Users can freely choose cloud service providers, which improves the compatibility and flexibility of the system; Sixth: Easy to integrate and maintain: Nginx and CronDNS services run in the Kubernetes environment, which has good integration and maintainability. Utilizing Kubernetes' container orchestration capabilities, the deployment and management process is simplified, reducing operation and maintenance costs and complexity; Seventh: Enhanced security: Self-built load balancers and DNS services allow sensitive data and configurations to be completely controlled by the enterprise itself, reducing potential security risks. Through reasonable permissions and access control, the security of the system is further improved; Eighth: Optimize performance: By customizing Nginx configuration and optimizing load balancing strategies, you can optimize performance for specific application scenarios and improve the system's response speed and processing capabilities. At the same time, the CronDNS service ensures real-time updates of DNS records, reduces DNS resolution delays, and optimizes overall performance; Ninth: Quickly respond to changes in demand: The system has the ability to quickly respond to changes in business needs. Through automatic expansion and contraction and dynamic DNS updates, it can quickly adapt to traffic fluctuations and business growth, maintaining system stability and efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without paying any creative work.

[0014] Figure 1 A schematic diagram of the principle of a DNS automatic scheduling method based on automatic expansion and contraction of containers provided in an embodiment of the present application; Figure 2 The figure is a schematic diagram of the working principle of a load balancer in the prior art. DETAILED DESCRIPTION

[0015] The technical solutions in the embodiments of the present application are described clearly and completely below. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present application.

[0016] In this article, the term "comprising" is intended to cover non-exclusive inclusion, so that a process, method, article or device that includes a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of more restrictions, the elements defined by the sentence "comprising..." do not exclude the presence of other identical elements in the process, method, article or device that includes the elements.

[0017] like Figure 2 As shown, the load balancer of the prior art works as follows: the client first accesses the DNS server, and then the DNS server forwards the request to the backend Nginx cluster according to the A record, and Nginx then reverse proxies to the application server.

[0018] Based on the technical issues raised in this article, in order to solve the corresponding problems, this embodiment is based on the following design ideas, namely: by using Nginx to replace the load balancing (LB) service of the cloud service provider, Nginx assumes the role of application layer proxy, and the DNS service is responsible for load balancing the Nginx cluster. The difficulty is that Nginx cannot achieve automatic expansion and contraction, and the Nginx IP address after expansion and contraction cannot be automatically updated to the DNS A record. A new CronDNS service is introduced, which can actively obtain the changes in the Nginx IP address and automatically register it in the DNS record.

[0019] Specifically, if Figure 1 As shown, a DNS automatic scheduling method based on automatic expansion and contraction of containers in this embodiment includes steps S1-S4, and the specific content of each step is detailed as follows.

[0020] S1-Build an open source Nginx service in Kubernetes container mode, including: deploying an open source Nginx service in a containerized manner in the Kubernetes cluster, where the Nginx cluster acts as a reverse proxy server, responsible for receiving and distributing front-end requests to back-end services. Here, the Nginx service is the native Ingress-Nginx function of K8S. Introduction to Ingress-Nginx: It is a resource object in the Kubernetes cluster used to implement external access to internal services. It usually acts as a reverse proxy, responsible for receiving requests from the outside and forwarding these requests to the corresponding services within the cluster. Ingress-Nginx has the following main functions and features: Load balancing: external requests can be evenly distributed to multiple backend service instances to improve system availability and scalability; Routing rules: Map different request paths to different backend services according to the defined rules; SSL termination: supports configuration of SSL certificates to achieve HTTPS access; Domain name management: can route and forward requests based on domain names; In short, Ingress-Nginx can parse the K8S Ingress yaml configuration into the Nginx.conf configuration in Nginx.

[0021] S2-Automatically scale the Nginx service with Kubernetes HPA (Horizontal Pod Autoscaler) and configure the scaling threshold, including: configuring Kubernetes' HPA to automatically manage the expansion and reduction of the Nginx service, the scaling threshold is the resource utilization threshold, according to the set CPU, memory and other resource utilization thresholds, when the load increases, the number of Nginx instances is automatically increased; when the load decreases, the number of Nginx instances is automatically reduced. This ensures the high availability of the system and the efficiency of resource utilization in high concurrency scenarios. In this step, the K8S native HPA is used here to automatically scale the number of copies of the Nginx cluster in step S1. Specific configuration: Get the Nginx CPU usage in real time, and set the threshold to 80%. When the current Nginx pod CPU usage value accounts for more than 80% of the Nginx pod request CPU ratio, the number of Nginx pod copies will be expanded and reduced in the opposite direction. The number of instances increased or reduced at one time depends on the calculation rules of the native HPA.

[0022] S3-deploys the self-developed CronDNS service in the form of Kubernetes containers, which is responsible for dynamically managing the IP address changes of the Nginx service. This includes: deploying the CronDNS service, which actively obtains the IP changes of the Nginx cluster at regular intervals and automatically registers the latest IP address to the DNS service of the cloud product; the CronDNS service is compatible with the DNS interfaces of most cloud service providers to ensure seamless connection.

[0023] S4-Configure CronDNS, including obtaining Nginx configuration and docking target DNS configuration.

[0024] The acquisition of Nginx configuration specifically includes: configuring CronDNS to obtain relevant information of the Nginx cluster, including the namespace and label of the Nginx cluster. Namespace and label are native concepts in K8S, that is, the current Nginx pod set can be queried through their combination results. Then, the instance where the pod is located can be found according to the pod information, and the public IP address of the cloud business API can be found according to the instance information.

[0025] The docking target DNS configuration specifically includes: configuring CronDNS to dock the target DNS service, including cloud information, access keys and DNS interface information. Through these configurations, CronDNS can automatically update cloud DNS records to ensure dynamic updates of Nginx IP addresses. According to the configuration defined above, its configuration is mainly used to connect to the DNS API and has operable permissions. When CoreDNS finds that the number of Nginx pod copies has increased, it obtains the public IP of its instance; and adds this public IP to the A record corresponding to its domain name through a cloud API, and reversely deletes the reduced public IP.

[0026] Based on the above-mentioned DNS automatic scheduling method based on container automatic expansion and contraction, the corresponding system architecture includes the following parts: 1. DNS products and services of each cloud Function: Acts as a load balancer for the Nginx cluster.

[0027] Details: DNS services provided by major cloud service providers (such as Amazon Route 53, Azure DNS, Alibaba Cloud DNS, etc.) are used to resolve domain names and distribute requests to each node of the Nginx cluster. These DNS services are usually highly available and have low latency, ensuring that requests reach the target server quickly and accurately.

[0028] 2. CronDNS module Function: Proactively obtain Nginx IP changes regularly and automatically register them in the cloud product DNS.

[0029] Details: CronDNS is a self-developed DNS update service, deployed as a Kubernetes container. It regularly scans the IP address changes of the Nginx cluster and automatically registers the updated IP address to the DNS service of the cloud product. CronDNS is compatible with most cloud DNS services, ensuring that the IP address of Nginx after expansion and contraction can be updated to the DNS record in time, thereby ensuring the accuracy and real-time performance of load balancing.

[0030] CronDNS involves two parts of configuration: Get the Nginx configuration: including the namespace and label where Nginx is located, to ensure that CronDNS can accurately identify and track changes in the Nginx instance.

[0031] Connect to the target DNS configuration: including cloud information, keys, and DNS interface information, to ensure that CronDNS can seamlessly connect to the target cloud's DNS service and automatically update DNS records.

[0032] 3. Nginx cluster proxy module Function: Load balance the application.

[0033] Details: As a reverse proxy server, the Nginx cluster receives requests from DNS resolution and forwards them to the backend application servers. Nginx can evenly distribute requests to each application server in the cluster according to the configured load balancing strategy (such as polling, least connection, etc.), improving the reliability and scalability of the application.

[0034] 4. HPA automatic expansion module Function: Provide automatic expansion and contraction services for Nginx clusters.

[0035] Details: HPA (Horizontal Pod Autoscaler) is a native automatic scaling service for Kubernetes. It dynamically adjusts the number of replicas of the Nginx cluster based on Nginx's resource usage (such as CPU, memory, etc.). When the number of requests increases, HPA automatically increases the number of Nginx instances; when the number of requests decreases, HPA automatically reduces the number of instances, thereby optimizing resource usage and costs.

[0036] In summary, this embodiment provides a flexible, efficient, and low-cost load balancing solution that is suitable for various complex and changing business scenarios, and provides strong support for the digital transformation of enterprises and cloud architecture optimization.

[0037] In the embodiments provided in the present application, it should be understood that the embodiments described herein can be implemented in hardware, software, firmware, middleware, code or any appropriate combination thereof. For hardware implementation, the processor can be implemented in one or more of the following units: application specific integrated circuit ASIC, digital signal processor DSP, digital signal processing device DSPD, programmable logic device PLD, field programmable gate array FPGA, processor, controller, microcontroller, microprocessor, other electronic units designed to implement the functions described herein or their combination. For software implementation, part or all of the flow of the embodiment can be completed by instructing the relevant hardware through a computer program. When implemented, the above program can be stored in a computer-readable storage medium or transmitted as one or more instructions or codes on a computer-readable storage medium. Computer-readable storage media include computer storage media and communication media, wherein the communication medium includes any medium that is convenient for transmitting a computer program from one place to another. The storage medium can be any available medium that a computer can access. The computer-readable storage medium can include, but is not limited to, RAM, ROM, EEPROM, CD-ROM or other optical disk storage, disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store the desired program code in the form of an instruction or data structure and can be accessed by a computer.

[0038] Finally, it should be noted that the above are only preferred embodiments of the present application and are not intended to limit the present application. Although the present application has been described in detail with reference to the aforementioned embodiments, it is still possible for those skilled in the art to modify the technical solutions described in the aforementioned embodiments, or to make equivalent substitutions for some of the technical features therein. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included in the protection scope of the present application.

Claims

1. A DNS automatic scheduling method based on automatic expansion and contraction of containers, characterized in that: The method comprises the following steps: S1-Build an open source Nginx service in Kubernetes container mode, including: deploying the open source Nginx service in a containerized manner in the Kubernetes cluster, where the Nginx cluster acts as a reverse proxy server, responsible for receiving and distributing front-end requests to back-end services; S2-Automatically scale the Nginx service using Kubernetes HPA and configure the scaling threshold, including: configuring Kubernetes HPA to automatically manage the expansion and reduction of the Nginx service. The scaling threshold is the resource usage threshold. When the load increases, the number of instances of the Nginx cluster is automatically increased; when the load decreases, the number of instances of the Nginx cluster is automatically reduced. S3-Deploy the self-developed CronDNS service in Kubernetes container mode, including: deploying the CronDNS service, which actively obtains the IP changes of the Nginx cluster at regular intervals and automatically registers the latest IP address to the DNS service of the cloud product; S4-Configure CronDNS, including obtaining Nginx configuration and docking target DNS configuration; wherein, obtaining Nginx configuration specifically includes: configuring CronDNS to obtain relevant information of the Nginx cluster, and the relevant information includes the namespace and label tags where the Nginx cluster is located; the docking target DNS configuration specifically includes: configuring CronDNS to dock the target DNS service, and the target DNS service includes cloud information, access keys and DNS interface information.

2. The DNS automatic scheduling method based on automatic expansion and contraction of containers according to claim 1 is characterized in that: The responsible for receiving and distributing front-end requests to back-end services includes: The Nginx cluster receives requests from DNS resolution and forwards the requests to the backend application server; The Nginx cluster evenly distributes requests to each application server in the cluster according to the configured load balancing strategy.

3. The DNS automatic scheduling method based on automatic expansion and contraction of containers according to claim 2 is characterized in that: The load balancing strategy includes a preconfigured polling strategy and a least connection strategy.

4. The DNS automatic scheduling method based on automatic expansion and contraction of containers according to claim 1 is characterized in that: The resource usage threshold includes CPU usage and memory usage.

5. The DNS automatic scheduling method based on automatic expansion and contraction of containers according to claim 1 is characterized in that: The Nginx cluster uses various cloud DNS product services as a load balancer; wherein the DNS service provided by the various cloud DNS product services is used to resolve domain names and distribute requests to each node of the Nginx cluster.

6. The DNS automatic scheduling method based on automatic expansion and contraction of containers according to claim 1 is characterized in that: The HPA is the native automatic scaling service of Kubernetes.

7. The DNS automatic scheduling method based on automatic expansion and contraction of containers according to claim 1 is characterized in that: The configuration CronDNS is used to connect to the DNS API and has operable permissions; when CoreDNS finds that the number of copies of the Nginx cluster has increased, it obtains the public IP of the Nginx cluster instance; And add the public IP to the record corresponding to its domain name through the cloud API of the cloud DNS product service, otherwise delete the reduced public IP.

Images