Container application migration monitoring method and device based on K8s cluster

Abstract

The invention discloses a container application migration monitoring method and device based on a K8s cluster, and relates to the field of distributed systems.The method comprises the steps that a health check rule is configured for each server in a load balancing pool through a health check expression, flow distribution is dynamically adjusted based on the execution result of the health check rule, and a load balancing result is obtained. And gradually adjusting the configuration of each server of the load balancing pool, finishing container application transition from an old K8s cluster to a new K8s cluster, recording the health state and request flow of a network link defined by each server of the load balancing pool based on predefined log configuration information, obtaining a health check log, analyzing the data of the health check log, and sending the data to the server of the load balancing pool. And generating a target chart containing the health state and the request flow of the network link defined by each server of the load balancing pool. According to the method and the device, the technical problem of service interruption caused by improper manual operation when container application migration is carried out on the K8s cluster in the related technology is solved.

Description

Technical Field

[0001] The present invention relates to the technical field of distributed systems or other related fields, and in particular to a container application migration monitoring method and device based on a K8s cluster. Background Art

[0002] With the rise of cloud computing and microservices architecture, Kubernetes (K8s cluster) has become the industry standard for automating the deployment, scaling, and management of containerized applications. K8s provides powerful container orchestration capabilities, automatically managing and scheduling containers across distributed clusters, greatly simplifying application deployment and maintenance. However, as Kubernetes clusters grow in size and complexity, achieving smooth migration and fault recovery between clusters while ensuring high application availability and efficiency has become a pressing technical challenge.

[0003] Since most Kubernetes clusters are deployed within the enterprise intranet and not directly exposed to the public network, they often require a reverse proxy server on the external network to forward external requests to the internal Kubernetes services. For example, the Apache HTTP Server plays a key role in this role due to its high flexibility and configurability. Its mod_proxy module enables load balancing and forwarding of client requests. However, the default configuration lacks in-depth health monitoring of backend Kubernetes services. This can result in invalid or damaged services still receiving external requests during service upgrades or failures, impacting the overall system reliability and user experience.

[0004] In mission-critical business assurance scenarios, multi-cluster deployments have become the norm to mitigate the risks associated with single points of failure. However, when migrating container applications from an old Kubernetes cluster to a new one, traditional approaches often face numerous challenges. First, service continuity and stability are difficult to guarantee, especially during the migration process, where improper manual operations can lead to service interruptions. Second, locating the faulty link becomes difficult, especially in complex environments with high concurrency and multi-component interactions. Accurately determining the cause of the problem is challenging. Finally, traditional migration methods can involve significant downtime, which is unacceptable for both user perception and business continuity.

[0005] To address the above-mentioned problems, no effective solutions have been proposed so far. Summary of the Invention

[0006] An embodiment of the present invention provides a container application migration monitoring method and device based on a K8s cluster, so as to at least solve the technical problem in the related art that improper manual operation is prone to cause service interruption when the K8s cluster performs container application migration.

[0007] According to one aspect of an embodiment of the present invention, a container application migration monitoring method based on a K8s cluster is provided, including: using a predefined health check expression to configure health check rules for each server in a load balancing pool; based on the execution results of the health check rules, dynamically adjusting traffic distribution, gradually adjusting the configuration of each server in the load balancing pool, and completing the transition of container applications from the old K8s cluster to the new K8s cluster; based on predefined log configuration information, recording the health status and request traffic of the network links defined by each server in the load balancing pool to obtain a health check log; parsing the data in the health check log to generate a target chart containing the health status and request traffic of the network links defined by each server in the load balancing pool.

[0008] Optionally, before using a predefined health check expression to configure health check rules for each server in the load balancing pool, it also includes: obtaining a predefined health check expression set and a health check policy set, wherein the expressions of the health check expression set include at least one of the following: an expression for checking the response status code, an expression for checking whether the response body contains a specified instruction; obtaining a predefined load balancing policy combination, wherein the policies in the load balancing policy set include at least one of the following: a load balancing policy by the number of requests, a load balancing policy by traffic, a load balancing policy by busyness, and a load balancing policy by heartbeat detection; obtaining a predefined anomaly monitoring parameter set, wherein the parameters of the anomaly monitoring parameter set include at least one of the following: a unique identifier for identifying each backend node, the number of checks for identifying a server as healthy or unhealthy, the time interval for health checks, a uniform resource identifier URI for health checks, and a health check template.

[0009] Optionally, the step of configuring health check rules for each server in the load balancing pool using a predefined health check expression includes: adding the route forwarded by the container application deployed on the K8s cluster to the load balancing pool and setting session stickiness routing; configuring the health check rules of the load balancing pool according to the predefined health check policy and the health check expression.

[0010] Optionally, after configuring health check rules for each server in the load balancing pool using a predefined health check expression, it also includes: configuring forwarding requests to a designated server in the load balancing pool; configuring the uniform resource locator URI returned by the reverse request proxy to the client; and determining a strategy for forwarding requests based on the configuration of the server in the load balancing pool.

[0011] Optionally, based on the execution result of the health check rule, dynamically adjust the traffic distribution, gradually adjust the configuration of each server in the load balancing pool, and complete the steps of transitioning the container application from the old K8s cluster to the new K8s cluster, including: based on the execution result of the health check rule, dynamically adjust the traffic distribution, migrate one of the applications deployed on the old K8s cluster to the new K8s cluster; add a configuration health check rule to one of the applications deployed on the new K8s cluster; use the newly added health check rule to perform a health check on one of the applications to obtain a health check result; if the health check result indicates that one of the applications has an abnormality, stop allocating new traffic to the new K8s cluster; if the health check result indicates that one of the applications has no abnormality, migrate other applications in the old K8s cluster except one of the applications to the new K8s cluster.

[0012] Optionally, after completing the transition of container applications from the old K8s cluster to the new K8s cluster, it also includes: after all container applications are migrated to the new K8s cluster, monitoring the running status of all applications in the new K8s cluster; after the running status of all applications is in normal state for a preset stable time, disconnecting the network link of the old K8s cluster.

[0013] Optionally, the steps of parsing the data of the health check log and generating a target chart containing the health status and request traffic of the network links defined by each server in the load balancing pool include: adding a custom log format in the configuration file, wherein the custom log format is used to determine the output format of the health check log; parsing the data of the health check log to calculate the number of successful health checks and the number of failed health checks for each network link; calculating the normal link ratio and the abnormal link ratio based on the number of successful health checks and the number of failed health checks for each network link; determining the health status of the network links defined by each server in the load balancing pool based on the normal link ratio and the abnormal link ratio; parsing the data of the health check log to extract the minimum and maximum values ​​of the request traffic of the network links defined by each server in the load balancing pool within a predetermined time period; generating a target chart containing all network links based on the health status of the network links defined by each server in the load balancing pool and the minimum and maximum values ​​of the request traffic of the network links defined by each server in the load balancing pool.

[0014] According to another aspect of an embodiment of the present invention, a container application migration monitoring device based on a K8s cluster is also provided, including: a check rule configuration unit, used to configure health check rules for each server in the load balancing pool using a predefined health check expression; a migration unit, used to dynamically adjust traffic distribution based on the execution results of the health check rules, gradually adjust the configuration of each server in the load balancing pool, and complete the transition of container applications from the old K8s cluster to the new K8s cluster; a network link check unit, used to record the health status and request traffic of the network links defined by each server in the load balancing pool based on predefined log configuration information, and obtain a health check log; a chart generation unit, used to parse the data of the health check log and generate a target chart containing the health status and request traffic of the network links defined by each server in the load balancing pool.

[0015] Optionally, the container application migration monitoring device based on the K8s cluster also includes: a first acquisition unit, used to obtain a predefined health check expression set and a health check policy set before using a predefined health check expression to configure health check rules for each server in the load balancing pool, wherein the expression of the health check expression set includes at least one of the following: an expression for checking the response status code, an expression for checking whether the response body contains a specified instruction; a second acquisition unit, used to obtain a predefined load balancing policy combination, wherein the policies in the load balancing policy set include at least one of the following: load balancing policy by number of requests, load balancing policy by traffic, load balancing policy by busyness, and load balancing policy by heartbeat detection; a third acquisition unit, used to obtain a predefined anomaly monitoring parameter set, wherein the parameters of the anomaly monitoring parameter set include at least one of the following: a unique identifier for identifying each backend node, the number of checks for identifying a server as healthy or unhealthy, the time interval for health checks, a uniform resource identifier URI for health checks, and a health check template.

[0016] Optionally, the inspection rule configuration unit includes: a routing addition module, used to add the routes forwarded by the container application deployed on the K8s cluster to the load balancing pool and set the session stickiness routing; an inspection rule configuration module, used to configure the health check rules of the load balancing pool according to a predefined health check policy and the health check expression.

[0017] Optionally, the container application migration monitoring device based on the K8s cluster also includes: a request forwarding configuration unit, which is used to configure the forwarding request to the designated server of the load balancing pool after configuring the health check rules for each server in the load balancing pool using a pre-defined health check expression; a URI configuration unit, which is used to configure the uniform resource locator URI returned by the reverse request proxy to the client; and a forwarding request policy determination unit, which is used to determine the forwarding request policy based on the configuration of the server in the load balancing pool.

[0018] Optionally, the migration unit includes: an application migration module, which is used to dynamically adjust traffic allocation based on the execution result of the health check rule, and migrate one of the applications deployed on the old K8s cluster to the new K8s cluster; an application rule adding module, which is used to add a configuration health check rule to one of the applications deployed on the new K8s cluster; an application health check module, which is used to perform a health check on one of the applications using the newly added health check rule to obtain a health check result; a stop allocating traffic module, which is used to stop allocating new traffic to the new K8s cluster when the health check result indicates that one of the applications has an abnormality; and a remaining application migration module, which is used to migrate other applications in the old K8s cluster except one of the applications to the new K8s cluster when the health check result indicates that one of the applications has no abnormality.

[0019] Optionally, the container application migration monitoring device based on the K8s cluster also includes: an application status monitoring unit, which is used to monitor the running status of all applications in the new K8s cluster after completing the transition of container applications from the old K8s cluster to the new K8s cluster and migrating all container applications to the new K8s cluster; an old cluster link disconnection unit, which is used to disconnect the network link of the old K8s cluster after the running status of all applications is in normal state for a preset stable time.

[0020] Optionally, the chart generation unit includes: a log format adding module for adding a custom log format to a configuration file, wherein the custom log format is used to determine the output format of the health check log; a first log data parsing module for parsing the data of the health check log and calculating the number of health check successes and health check failures for each network link; a link ratio calculation module for calculating the normal link ratio and the abnormal link ratio based on the number of health check successes and health check failures for each network link; a link status determination module for determining the health status of the network links defined by each server in the load balancing pool based on the normal link ratio and the abnormal link ratio; a second log data parsing module for parsing the data of the health check log and extracting the minimum and maximum values ​​of the request traffic of the network links defined by each server in the load balancing pool within a predetermined time period; a chart generation module for generating a target chart containing all network links based on the health status of the network links defined by each server in the load balancing pool and the minimum and maximum values ​​of the request traffic of the network links defined by each server in the load balancing pool.

[0021] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is also provided, which includes a stored computer program, wherein when the computer program is running, the device where the computer-readable storage medium is located is controlled to execute any one of the above-mentioned container application migration monitoring methods based on the K8s cluster.

[0022] According to another aspect of an embodiment of the present invention, an electronic device is also provided, comprising one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement any one of the above-mentioned container application migration monitoring methods based on the K8s cluster.

[0023] According to another aspect of an embodiment of the present invention, a computer program product is also provided, including a computer program, which, when executed by a processor, implements the steps of any one of the above-mentioned methods for monitoring container application migration based on a K8s cluster.

[0024] In the present disclosure, a predefined health check expression is used to configure health check rules for each server in the load balancing pool; based on the execution results of the health check rules, traffic distribution is dynamically adjusted, the configuration of each server in the load balancing pool is gradually adjusted, and the transition of container applications from the old K8s cluster to the new K8s cluster is completed; based on the predefined log configuration information, the health status and request traffic of the network links defined by each server in the load balancing pool are recorded to obtain a health check log; the data in the health check log is parsed to generate a target chart containing the health status and request traffic of the network links defined by each server in the load balancing pool.

[0025] Based on the above disclosure, the present invention can use pre-configured health check rules to detect the health status of backend services, use load balancing strategies to change request scheduling algorithms, and thus decide whether to forward traffic to specific backend services, gradually adjust the configurations of each server in the load balancing pool, and complete the transition of container applications from the old K8s cluster to the new K8s cluster, and then record the health status and request traffic of the network links defined by each server in the load balancing pool, obtain health check logs, generate health check charts, and display the status of network links through charts to reduce the number of service interruptions, thereby solving the technical problem in the related technology that when the K8s cluster performs container application migration, improper manual operations are prone to cause service interruptions. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

[0027] Figure 1 This is a flowchart of an optional K8s cluster-based container application migration monitoring method according to an embodiment of the present invention;

[0028] Figure 2 This is a schematic diagram of an optional K8S cluster application automatic abnormality monitoring and smooth migration system according to an embodiment of the present invention;

[0029] Figure 3 is a timing diagram of an optional smooth migration process according to an embodiment of the present invention;

[0030] Figure 4 is a schematic diagram of an optional K8s cluster-based container application migration monitoring device according to an embodiment of the present invention;

[0031] Figure 5 This is a hardware structure block diagram of an electronic device (or mobile device) that executes a container application migration monitoring method based on a K8s cluster according to an embodiment of the present invention. DETAILED DESCRIPTION

[0032] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described 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 making creative efforts should fall within the scope of protection of the present invention.

[0033] It should be noted that the terms "first", "second", etc. in the description and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0034] To facilitate those skilled in the art to understand the present invention, some of the terms or nouns involved in the embodiments of the present invention are explained below:

[0035] Cluster, in this invention, refers to Kubernetes (abbreviated as K8s) cluster, which provides an efficient and scalable container orchestration solution, allowing users to automatically deploy, manage and scale containerized applications on cross-machine clusters.

[0036] Applications, as used in this article, refer to containerized applications deployed on a Kubernetes cluster. These applications are packaged and run in containers. These containers package applications and their runtime dependencies to ensure stable operation in various environments. In the Kubernetes ecosystem, containerized applications are the fundamental unit of deployment.

[0037] A reverse proxy server is a proxy server (such as NGINX or Apache) that is used to obtain resources from client requests and forward them to one or more backend servers. A reverse proxy server acts as an intermediary between the client and the backend servers and can provide a variety of functions, including load balancing, caching, SSL termination, security enhancement, and more.

[0038] Apache HTTP Server (Apache or httpd) is a free and open-source web server application that provides HTTP services, acting as a bridge between containerized applications and the outside world. It supports various modules, such as mod_proxy and mod_proxy_hcheck, for reverse proxy and health checking.

[0039] The proxy module, mod_proxy (NA for short), is an Apache HTTP Server module that implements proxy functionality. It allows the Apache server to act as an intermediary, forwarding requests to backend servers. It can be used in scenarios such as load balancing, caching, and content filtering.

[0040] The proxy health check module, mod_proxy_hcheck, is a module provided by httpd that implements health checks on backend servers. As an extension of mod_proxy, it is specifically designed to detect and monitor the health of backend servers and adjust load balancing decisions based on the results, significantly improving system reliability and availability.

[0041] A Uniform Resource Locator (URL) is used to identify the location and access method of a resource. It contains information such as the resource's access protocol, host name, port number, and path. URLs are commonly used to access network resources such as web pages, files, and databases.

[0042] A Uniform Resource Identifier (URI) is a universal address that uniquely identifies a resource. It can be absolute (for example, a URL) or relative. URIs are used on the Internet to locate and retrieve information, regardless of whether the resource exists or how it is accessed.

[0043] Proxy Health Check Expression (ProxyHCExpr), part of the mod_proxy_http module in the Apache HTTP Server, defines health check conditions. By setting specific expressions, such as checking the HTTP response status code, you can determine whether the backend server can correctly handle requests. This is a key configuration for implementing automatic health checks.

[0044] A load balancing member (Balancer Member, also known as BalancerMember) is a configuration parameter in the mod_proxy_balancer module of the Apache HTTP Server. It defines the backend servers in a load balancing pool. It specifies the server URL, session identifier, health check method, health check expression, and other parameters to control how requests are distributed across multiple backends.

[0045] It should be noted that the container application migration monitoring method and device based on K8s cluster in the present disclosure can be used in the field of distributed system technology. When realizing automatic application anomaly monitoring and smooth migration based on K8s cluster, it can also be used in any field other than the field of distributed system technology. When realizing automatic application anomaly monitoring and smooth migration based on K8s cluster, the application field of the container application migration monitoring method and device based on K8s cluster in the present disclosure is not limited.

[0046] It should be noted that the information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) collected by this disclosure are information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of relevant data comply with the relevant laws, regulations and standards of the relevant regions, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation portals for users to choose to authorize or refuse. For example, an interface is set up between this system and relevant users or institutions. Before obtaining relevant information, it is necessary to send an acquisition request to the aforementioned user or institution through the interface, and obtain relevant information after receiving the consent information fed back by the aforementioned user or institution.

[0047] It should be noted that in this disclosure, when collecting and analyzing customer information, the corresponding operation entrance is provided for users to choose to agree or reject the automated decision-making results; if the user chooses to reject, the expert decision-making process will be entered.

[0048] The following embodiments of the present invention can be applied to various systems / applications / devices for container application migration monitoring based on K8s clusters. The present invention can be applied to fields such as cloud computing, microservice architecture, and containerized application management, and particularly focuses on the advanced management and operation and maintenance of Kubernetes (K8s) clusters. For example, in a multi-data center operation and maintenance scenario: when operating an application of a microservice architecture across data centers in multiple geographical locations, the load balancing and health check mechanism of the present invention can ensure that traffic is always directed to the healthiest and most stable Kubernetes cluster, providing uninterrupted service even in the face of data center-level failures or maintenance. Or in an application smooth migration scenario, it is necessary to migrate the running application service from the old K8s cluster to the new cluster, whether for the purpose of infrastructure upgrade, expansion, or disaster recovery. The smooth migration strategy of the present invention can ensure that service continuity and user experience are not affected during the migration process, while avoiding the involvement of the fault link through health monitoring, thereby improving the security and efficiency of the migration. Furthermore, in the environment of large-scale containerized applications, the health check definition and abnormal monitoring parameters provided by the present invention can promptly identify and isolate faulty services, trigger an automatic fault recovery mechanism, reduce service interruption time and operation and maintenance burden, thereby improving the reliability and maintenance efficiency of the overall system.

[0049] This invention ensures that services are always running in a healthy state through automated health monitoring, avoiding the degradation of user experience caused by failed services receiving requests. At the same time, it proposes a progressive migration strategy, combining health checks with dynamic adjustment of traffic distribution to achieve seamless switching between old and new clusters, greatly reducing potential risks and downtime during service migration.

[0050] This invention goes beyond basic load balancing and integrates health status with traffic distribution. It intelligently adjusts traffic distribution strategies based on the health of backend services, improving resource utilization efficiency. Furthermore, it provides visualization of request link health and traffic flow, helping operations personnel quickly understand system status, perform fault diagnosis, and optimize resources, enabling more accurate operations decisions in complex environments.

[0051] The present invention will be described in detail below with reference to various embodiments.

[0052] Example 1

[0053] According to an embodiment of the present invention, an embodiment of a container application migration monitoring method based on a K8s cluster is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0054] Figure 1 This is a flowchart of an optional container application migration monitoring method based on a K8s cluster according to an embodiment of the present invention. Figure 1 As shown, the method includes the following steps:

[0055] Optionally, before using a predefined health check expression to configure health check rules for each server in the load balancing pool, it also includes: obtaining a predefined health check expression set and a health check policy set, wherein the expressions of the health check expression set include at least one of the following: an expression for checking the response status code, an expression for checking whether the response body contains a specified instruction; obtaining a predefined load balancing policy combination, wherein the policies in the load balancing policy set include at least one of the following: a load balancing policy by the number of requests, a load balancing policy by traffic, a load balancing policy by busyness, and a load balancing policy by heartbeat detection; obtaining a predefined anomaly monitoring parameter set, wherein the parameters of the anomaly monitoring parameter set include at least one of the following: a unique identifier for identifying each backend node, the number of checks for identifying a server as healthy or unhealthy, the time interval for health checks, a uniform resource identifier URI for health checks, and a health check template.

[0056] Before configuring the health check rules for each server in the load balancing pool, this embodiment needs to complete the selection and pre-definition of health check expressions. The health check expression set contains a series of preset formulas and standards. The purpose of designing these expressions is to automatically evaluate the running status of container applications in the backend Kubernetes cluster. The expression set covers at least the following two types of expressions: The first type is expressions that check the response status code, which focuses on the verification of the HTTP response status code to ensure that the backend service can return the expected status code indicating success or acceptable errors. The second type is expressions that check whether the response body contains specified instructions: In addition to the status code, this embodiment also provides the ability to check the content of the response body to ensure that the service response does not contain specific error messages or maintenance mode indications. For example, by detecting whether the response body contains the words "Under maintenance", it can be determined whether the service is in maintenance status, and then corresponding isolation measures can be taken.

[0057] This embodiment further completes the selection and configuration of the load balancing strategy to ensure that even during the health check process, traffic can be efficiently and evenly distributed to healthy back-end servers. The load balancing strategy set includes at least the following four strategies, and each strategy has its applicable scenario: The first is a load balancing strategy based on the number of requests: it is distributed according to the number of requests received by the back-end server, which is suitable for application scenarios with relatively uniform request patterns and can avoid overloading of a single server. The second is a load balancing strategy based on traffic volume: it performs load balancing based on the size of the traffic processed by the server, which is suitable for scenarios where the hardware configurations of different servers are significantly different, ensuring fairer resource occupancy. The third is a load balancing strategy based on busyness: taking into account the actual load situation of the server, it distributes requests according to busyness (CPU usage, memory usage, etc.), optimizes resource utilization efficiency, and avoids the formation of hotspot servers. The fourth is a load balancing strategy based on heartbeat detection: it monitors the survival status of the server through a regular heartbeat mechanism, and only sends requests to surviving and responsive servers, further enhancing the reliability and response speed of the system.

[0058] To achieve more accurate health checks and anomaly monitoring, this embodiment also predefines a set of anomaly monitoring parameter sets. These parameters not only refine the health check logic, but also adapt to different business needs and operating environments, ensuring system stability and service continuity. The anomaly monitoring parameter set includes at least the following five parameters: First, a unique identifier for identifying each backend node: By configuring the session identifier (route parameter), each backend server can be assigned a unique identifier, which helps track and manage sessions related to a specific server and ensure session continuity and consistency. Second, the number of checks used to mark a server as healthy or unhealthy: This embodiment uses the hcpasses and hcfails parameters to define the number of consecutive health or failure checks a server must undergo before being marked as healthy or unhealthy. This can avoid misjudgments caused by occasional network jitter or brief failures and improve the accuracy of health check judgments. Third, the health check interval: The hcinterval parameter specifies the health check cycle, that is, the minimum time interval between two health checks. A reasonable health check frequency can ensure monitoring sensitivity while avoiding excessive consumption of system resources, finding the optimal balance between monitoring efficiency and resource consumption. Fourth, the Uniform Resource Identifier (URI) for health checks: The hcuri parameter is used to specify the URL path for health checks. For example, it can be the health check endpoint ( / healthcheck) of the backend service. By customizing the URI, specific components or functions of the service can be monitored more carefully, improving the accuracy of fault location. Fifth, health check templates. For example, the hctemplate parameter allows the creation and reuse of health check configurations, reducing duplication of work when managing multiple similar services and improving configuration efficiency and consistency. Templates can contain multiple parameters mentioned above to facilitate rapid configuration and unified management.

[0059] When obtaining and defining the above-mentioned collections and parameters, this embodiment fully considers the particularity and complexity of container applications in the Kubernetes cluster. By flexibly using health check expressions, policies, and monitoring parameters, it is not only possible to effectively monitor the health status of backend services, but also to ensure the intelligence and efficiency of the load balancing mechanism, laying a solid foundation for the smooth operation of container applications and seamless migration between clusters. In addition, the predefined collections and parameters provide a set of standardized solutions, which facilitates operation and maintenance personnel to quickly configure and adjust according to actual needs, reduces the difficulty and error rate of system configuration, and enhances the maintainability and scalability of the system.

[0060] Step S101: configure health check rules for each server in the load balancing pool using a predefined health check expression.

[0061] In this embodiment, step S101 details the process of configuring health check rules for each server in the load balancing pool using predefined health check expressions, ensuring high service reliability and a smooth user experience when container applications migrate between Kubernetes clusters. The health check expressions are predefined, for example, in Apache HTTP Server, using the ProxyHCExpr directive, and are used to determine the health status of backend Kubernetes services. A load balancing pool is a collection of backend servers, as defined in the mod_proxy_balancer module, where each member corresponds to a container application in a Kubernetes cluster and is used to receive and distribute external requests.

[0062] Optionally, the steps of configuring health check rules for each server in the load balancing pool using a predefined health check expression include: adding the route forwarded by the container application deployed on the K8s cluster to the load balancing pool and setting session stickiness routing; configuring the health check rules of the load balancing pool according to the predefined health check policy and health check expression.

[0063] Among them, the route forwarded by the container application is added to the load balancing pool. For example, in the configuration of Apache HTTP Server, the BalancerMember instruction is used to add the URL pointing to the container application on the K8s cluster to a defined load balancing pool. This not only includes the address information of the service, but may also involve additional configurations such as the service weight and label to guide the formulation of the load balancing strategy.

[0064] Among them, setting session stickiness routing, for example, you can define a unique identifier for each container application through the route parameter, ensuring that requests in the same session are always forwarded to the server that originally responded to the request, even if there are multiple available members in the load balancing pool. This helps maintain the consistency of session state, which is especially important for applications that rely on session state (such as shopping carts and login status).

[0065] Finally, this embodiment configures health check rules based on predefined health check policies and health check expressions. For example, based on the expression defined by ProxyHCExpr, the appropriate health check method (such as GET or TCP) is selected through the hcmethod option in BalancerMember, and the health check URL is specified through hcuri. Furthermore, the hcpasses and hcfails parameters define the thresholds for consecutive successful or failed health checks to determine the health status of the service and adjust the request forwarding strategy.

[0066] Optionally, after configuring health check rules for each server in the load balancing pool using a predefined health check expression, it also includes: configuring forwarding requests to a designated server in the load balancing pool; configuring the uniform resource locator URI returned by the reverse request proxy to the client; and determining a strategy for forwarding requests based on the configuration of the server in the load balancing pool.

[0067] For example, the ProxyPass directive is used in the Apache configuration to explicitly indicate that requests should be forwarded to the backend servers defined in the load balancing pool. In addition, load balancing policies such as byrequests, bytraffic, or bybusyness can be specified through the ProxySet lbmethod to determine how to distribute requests among servers. As for the Uniform Resource Locator URI returned to the client by configuring a reverse request proxy, for example, the ProxyPassReverse directive is used to ensure that requests returned from the backend server can be correctly redirected back to the URI of the original client. This is the key to the reverse proxy function, ensuring the transparency and consistency of the interaction between the client and the server.

[0068] Finally, the strategy for forwarding requests is determined based on the configuration of the servers in the load balancing pool. It integrates the above configurations and dynamically adjusts traffic distribution by parsing BalancerMember parameters such as weight, health status, load, etc., to ensure that requests are efficiently and reasonably forwarded to the healthiest and least busy servers, thereby achieving high availability and performance optimization of the service.

[0069] Step S102: Based on the execution results of the health check rules, dynamically adjust the traffic distribution, gradually adjust the configuration of each server in the load balancing pool, and complete the transition of container applications from the old K8s cluster to the new K8s cluster.

[0070] In this embodiment, step S102 involves a core operation and maintenance process, namely, dynamically adjusting traffic distribution based on the execution results of health check rules, gradually adjusting the configuration of each server in the load balancing pool, and realizing a smooth transition from the old K8s cluster to the new K8s cluster, ensuring that service migration in a multi-cluster environment is both safe and efficient.

[0071] For example, this embodiment performs health checks through the mod_proxy_hcheck module to continuously monitor the health status of the backend service. Once the status of the backend service changes (whether it gets better or worse), the system will immediately recalculate the load balancing strategy and adjust the traffic distribution to ensure that the traffic is only directed to healthy service instances. This immediate traffic adjustment mechanism effectively avoids the propagation of faults and ensures the continuity and stability of the service. Afterwards, in order to complete the transition of container applications from the old K8s cluster to the new K8s cluster, this embodiment adopts a gradual configuration adjustment strategy. Initially, only a part of the applications are deployed and monitored on the new cluster to ensure that these applications can run stably in the new environment. Over time, by adding configurations, adjusting weights and redistributing traffic, more applications and services are gradually migrated to the new cluster until the entire migration process is finally completed.

[0072] Optionally, based on the execution results of the health check rules, dynamically adjust the traffic distribution, gradually adjust the configuration of each server in the load balancing pool, and complete the steps of transitioning the container application from the old K8s cluster to the new K8s cluster, including: based on the execution results of the health check rules, dynamically adjust the traffic distribution, migrate one of the applications deployed on the old K8s cluster to the new K8s cluster; add a configuration health check rule to one of the applications deployed on the new K8s cluster; use the newly added health check rule to perform a health check on one of the applications to obtain a health check result; if the health check result indicates that one of the applications has an abnormality, stop allocating new traffic to the new K8s cluster; if the health check result indicates that one of the applications has no abnormality, migrate all applications in the old K8s cluster except one of the applications to the new K8s cluster.

[0073] At the beginning of this embodiment, one of the applications deployed on the old K8s cluster is selected as a migration pilot and redeployed to the new K8s cluster. In order to ensure that the migrated application can run normally in the new environment without impacting existing services, only the single application is deployed on the new cluster in the initial stage. On the new K8s cluster, the health check rule configuration for the pilot application is added, such as through a combination of the BalancerMember directive and the ProxyHCExpr expression. This configuration includes but is not limited to selecting a health check method (such as a GET request), defining a health check expression (such as checking a 2xx status code), setting the check frequency and the threshold for continuous success or failure.

[0074] Once the health check rules are configured, this embodiment begins performing health checks. For example, it sends regular probe requests to the pilot application on the new cluster, determines the health status of backend services based on the rules defined by ProxyHCExpr, and collects and analyzes the health check results. The health check results directly influence the traffic distribution strategy. If the health check results indicate that the pilot application is running normally in the new cluster, with no exceptions or service interruptions, the system gradually increases the traffic weight of the new cluster to enable it to carry more user requests. Conversely, if the pilot application exhibits health issues, such as excessive response latency or unusually high status code rates, the system immediately stops allocating new traffic to the new cluster to prevent further escalation and protect the user experience. After the pilot application has successfully migrated and has run stably for a period of time, proving the feasibility of the new cluster environment, this embodiment continues to migrate the remaining applications on the old Kubernetes cluster, while simultaneously performing health checks and traffic adjustments on each newly deployed application. This gradual process ensures sufficient monitoring and adjustment time for each migration, thereby achieving a seamless transition from the old cluster to the new cluster.

[0075] Optionally, after completing the transition of container applications from the old K8s cluster to the new K8s cluster, it also includes: after all container applications are migrated to the new K8s cluster, monitoring the running status of all applications in the new K8s cluster; after the running status of all applications is in normal state for a preset stable time, disconnecting the network link of the old K8s cluster.

[0076] In this embodiment, after a smooth transition from an old Kubernetes (K8s) cluster to a new K8s cluster is achieved, a monitoring mechanism is provided to continuously monitor the running status of all container applications on the new cluster. This mechanism is not only based on static health check rules, but also combines dynamic application performance indicators, system log analysis, and real-time monitoring data to ensure that each application instance can run stably in the new environment. By working in conjunction with the mod_proxy_hcheck module of Apache HTTP Server and other monitoring tools, this embodiment can collect and analyze the application's response time, error rate, resource consumption (CPU, memory, etc.) and system logs to form a comprehensive application health status report.

[0077] This embodiment further disconnects the network link of the old K8s cluster after confirming that all applications on the new K8s cluster have reached a stable operating state and this state lasts for more than a preset stable time. It should be noted that the setting of the preset stable time is based on business needs, application properties and historical data. Its purpose is to verify the long-term reliability and performance stability of the application on the new cluster, ensuring that the new cluster can withstand the load in the actual production environment without causing instability or interruption of services due to migration. Only when all monitoring indicators continue to show normal operation and meet the definition criteria of stable operation, the network link of the old cluster will be disconnected, thereby formally ending the migration process.

[0078] In addition to basic response status code checks, this embodiment also considers dynamic indicators such as the application's response time, error rate, and resource utilization. These comprehensive indicators are used to determine whether the application is in a healthy state, rather than relying solely on static health check expressions, thereby improving the accuracy and comprehensiveness of monitoring. To ensure the effectiveness of monitoring, this embodiment integrates multiple data sources, including log files, system monitoring data, performance test results, etc., and uses big data analysis technologies such as machine learning models to conduct in-depth analysis of the collected information and identify potential service risk points.

[0079] Through the above implementation steps, the present invention ensures seamless service operation during the switchover between the old and new K8s clusters through strict application status monitoring, avoiding any service interruptions caused by the migration. After the new cluster reaches a stable state, the network link of the old cluster is disconnected, achieving efficient resource utilization and management, avoiding resource waste, ensuring a consistent and continuous user experience, and maintaining a high-quality service level even during the migration process.

[0080] Through automated monitoring and decision-making, this embodiment can significantly reduce the workload of operation and maintenance personnel during the migration process and the risk of human error, thereby improving operation and maintenance efficiency and overall system stability.

[0081] Step S103 , based on predefined log configuration information, records the health status and request flow of the network links defined by each server in the load balancing pool to obtain a health check log.

[0082] In this embodiment, the health check log is used to monitor and evaluate the health status and request traffic of servers in the load balancing pool. Specifically, this embodiment can capture detailed information related to health checks and request traffic by configuring the log format of the Apache HTTP Server. This information is then recorded in the health check log.

[0083] Optionally, this embodiment first defines a custom log format that can capture the detailed results of the health check, including but not limited to the request status code, response time, requested URI, and specific flags related to the health check, such as the value of hcexpr and the access status of hcuri. These parameters will be recorded in the health check log for subsequent analysis and monitoring. Through the health check mechanism of the mod_proxy_hcheck module, the results of each health check on the backend server will be recorded, including whether the check was successful (true or false), the check method (such as GET, HEAD, or TCP), and other parameters related to the health check, such as the checked URI and the check interval.

[0084] In addition to health status, this embodiment also records the actual request traffic for each link in the load balancing pool. This includes the number of requests per second, average request size, and response time. Logging allows tracking and analyzing traffic changes and trends on the link. This embodiment configures dedicated log output files, such as health_check.log and outbound.log, to store health check results and request traffic data. These files form the basis for data analysis and chart generation in subsequent step S104.

[0085] Optionally, recording health check logs and request traffic information is the key to achieving comprehensive system monitoring and maintenance. The log configuration of this embodiment is not limited to the collection of the above-mentioned basic information, but can also be expanded to record more relevant indicators, such as: error type. In this embodiment, the specific error type that caused the health check failure can be recorded by the error type, which helps operation and maintenance personnel to quickly locate the problem. Response time, record the response time of each health check, which is used to analyze the server's latency and whether there is a performance bottleneck. TLS handshake status, when an encrypted connection is used, record whether the TLS or SSL handshake is successful, and the handshake time, which is particularly important for security and efficiency assessments. Request type, distinguish between recording user requests and system health check requests, to facilitate filtering and classification analysis in log data.

[0086] Step S104 , parsing the data in the health check log, and generating a target graph including the health status and request traffic of the network links defined by each server in the load balancing pool.

[0087] In this embodiment, parsing health check logs and generating targeted charts are core steps to ensure the readability and usability of monitoring results. For example, this embodiment parses the health check data recorded in health_check.log and the request traffic information in outbound.log to generate a series of charts that visually display the health status and traffic distribution of network links. First, this embodiment uses appropriate parsing tools or scripts to read and understand the information in the health check logs. The parsing process involves identifying the health check result (true or false), the health check method, and related parameters such as hcuri, hcpasses, and hcfails. Simultaneously, this embodiment parses the request traffic logs to extract key data such as request frequency, response time, and traffic peaks. After parsing, the log data is statistically processed to calculate the health check success and failure rates for each backend server, as well as the minimum, maximum, and average request traffic. Finally, this embodiment uses chart generation tools or scripts to generate charts based on these statistical data. For example, a bar chart is generated to display the health check success and failure rates for each server, and a line chart is generated to show the trend of request traffic over time. Charts can be generated in real time or periodically to suit monitoring and maintenance needs.

[0088] Optionally, the steps of parsing the data of the health check log and generating a target chart containing the health status and request traffic of the network links defined by each server in the load balancing pool include: adding a custom log format in the configuration file, wherein the custom log format is used to determine the output format of the health check log; parsing the data of the health check log and calculating the number of health check successes and health check failures for each network link; calculating the normal link ratio and the abnormal link ratio based on the health check successes and health check failures for each network link; determining the health status of the network links defined by each server in the load balancing pool based on the normal link ratio and the abnormal link ratio; parsing the data of the health check log and extracting the minimum and maximum values ​​of the request traffic of the network links defined by each server in the load balancing pool within a predetermined time period; generating a target chart containing all network links based on the health status of the network links defined by each server in the load balancing pool and the minimum and maximum values ​​of the request traffic of the network links defined by each server in the load balancing pool.

[0089] In this embodiment, it is necessary to intuitively display the health status and request traffic of the network links defined by each server in the load balancing pool to achieve automated anomaly monitoring of Kubernetes applications. For example, this embodiment requires defining a specific custom log format in the configuration file of the Apache HTTP Server to capture detailed information related to health checks. The log format should include but is not limited to fields such as client IP, user name, timestamp, request method, response status code, response size, user agent, referrer, session identifier, health check method, health check expression result, etc. By configuring the log format (such as using the LogFormat directive, it can be ensured that the log file health_check.log accurately records key data in the health check process, which is convenient for subsequent data parsing and analysis.

[0090] Furthermore, this embodiment parses the health check log (such as health_check.log) to obtain detailed information on the health check results, identify the health check expression results (hcexpr), distinguish between true and false results, and further count the number of successes and failures of the health check for each network link. Based on the health check results of each network link, this embodiment calculates the ratio of normal links to abnormal links, including counting the total number of successes and failures of all health checks on the link, and then calculating the proportion of each in the total number of checks. By setting a threshold, such as a 90% success rate, the system can automatically determine which links are in a normal state and which links are abnormal, which helps to quickly locate potential fault points and take corresponding measures to ensure service continuity.

[0091] By analyzing the ratio of normal links and abnormal links, this embodiment can quantitatively evaluate the health status of all network links. For example, if the normal ratio of the link is lower than the preset threshold, the system may automatically trigger an alarm or adjust the traffic distribution strategy to isolate the abnormal link and ensure that the traffic is only directed to healthy service instances. This automated mechanism greatly enhances the stability and reliability of the system and reduces the burden on operation and maintenance personnel. In addition to the analysis of health status, this embodiment also focuses on real-time monitoring of request traffic. By parsing log files, the outbound request traffic of each network link within a preset time period (such as the past hour) can be extracted. Using regular expressions or other data extraction techniques, the system can identify and count the minimum and maximum values ​​of each link request. This data helps operation and maintenance personnel understand the fluctuations in network load and adjust resource allocation in a timely manner.

[0092] Finally, this example uses the previously collected data to generate a series of charts that visually display the health status of network links and request traffic trends. Charts may include bar charts, trend charts, or heat maps, allowing for analysis across different dimensions. For example, a bar chart can display the health check success rate for each network link, while a trend chart can reflect traffic fluctuations over time, helping operations personnel gain insight into system performance and stability.

[0093] Through the above steps, you can use pre-defined health check expressions to configure health check rules for each server in the load balancing pool; based on the execution results of the health check rules, dynamically adjust traffic distribution, gradually adjust the configuration of each server in the load balancing pool, and complete the transition of container applications from the old K8s cluster to the new K8s cluster; based on the pre-defined log configuration information, record the health status and request traffic of the network links defined by each server in the load balancing pool to obtain a health check log; parse the data in the health check log to generate a target chart containing the health status and request traffic of the network links defined by each server in the load balancing pool. In this embodiment, pre-configured health check rules can be used to detect the health status of backend services, and the load balancing strategy can be used to change the request scheduling algorithm to decide whether to forward traffic to a specific backend service. The configuration of each server in the load balancing pool can be gradually adjusted, and the transition of container applications from the old K8s cluster to the new K8s cluster can be completed. The health status and request traffic of the network links defined by each server in the load balancing pool can be recorded, and a health check log can be obtained. A health check chart is generated, and the status of the network link is displayed through the chart to reduce the number of service interruptions, thereby solving the technical problem in the related technology that when the K8s cluster is migrating container applications, improper manual operations may easily lead to service interruptions.

[0094] The following describes in detail another optional specific implementation.

[0095] In order to ensure that traffic can be correctly distributed to normal Kubernetes applications, the present invention provides a system for automated anomaly monitoring and smooth migration of Kubernetes applications based on Apache. By adding the health check strategy of the mod_proxy_hcheck module of Apache HTTPServer (httpd), the insufficiency of health status monitoring between Apache and K8s applications is supplemented. In an actual operating environment, when an application needs to be migrated from an old K8s cluster to a new K8s cluster, how to ensure the continuity and stability of the service is an important challenge. Traditional migration methods often involve downtime or complex manual operations, which may lead to service interruption and degradation of user experience. The present invention can distribute traffic through its reverse proxy function (mod_proxy), and combined with the health check function of the mod_proxy_hcheck module, it can realize dynamic allocation and health status monitoring of access traffic. At the same time, by parsing Apache logs, it realizes access request link health status monitoring, solves the problem of difficult location of faulty links during migration, and further supports the smooth migration of application systems.

[0096] The present invention provides a request status code anomaly monitoring model method based on Apache and a system for smoothly switching access traffic from an old K8s cluster to a new K8s cluster. Figure 2 Schematic diagram of an optional K8S cluster application automatic abnormality monitoring and smooth migration system according to an embodiment of the present invention. Figure 2 As shown, the system is divided into the following four modules: 1. Health check definition module; 2. Health check configuration module; 3. Migration strategy module; 4. Link request display module.

[0097] Among them, the health check definition module can define various forms of health check methods, the configuration module can select a combination of health check definitions according to actual needs, the migration strategy module can use the health check method in the mod_proxy_hcheck module to detect the health status of the backend service, and use the load balancing strategy in the mod_proxy_balancer module to change the request scheduling algorithm to decide whether to forward traffic to a specific backend service, and the link request display module can use log records to statistically organize requests and display them intuitively through charts.

[0098] The following is a detailed description of these modules.

[0099] 1. Health check definition module.

[0100] Generate the complete content of the health check definition by selecting from predefined health check methods, including common health check methods (such as GET, OPTIONS, HEAD, TCP, etc.), selecting different load balancing methods and configuring other parameters.

[0101] 1. Define the health check expression.

[0102] (1) Define ok234, for example, ProxyHCExpr ok234{%{REQUEST_STATUS}=- / ^

[234] / }.

[0103] Meaning: Checks whether the response status code is 2xx, 3xx, or 4xx. If it matches, it means it is healthy.

[0104] (2) Define gdown, for example, ProxyHCExpr gdown{%{REQUEST_STATUS}=- / ^[5] / }.

[0105] Meaning: Checks whether the response status code is 5xx. If it matches, it means it is unhealthy.

[0106] (3) Define in_maint, for example, ProxyHCExpr in_maint{hc('body')!- / Undermaintenance / }.

[0107] Meaning: Checks whether the response body contains "Under maintenance". If not, it means it is healthy.

[0108] 2. Define health check strategies.

[0109] (1) TCP: Check whether a socket to the backend can be created.

[0110] (2)OPTIONS: Send an OPTIONS request via HTTP / 1.0.

[0111] (3) HEAD: Send a HEAD request via HTTP / 1.0.

[0112] (4)GET: Send a GET request via HTTP / 1.0.

[0113] (5)OPTIONS11: Send an OPTIONS request via HTTP / 1.1.

[0114] (6) HEAD11: Sends a HEAD request via HTTP / 1.1.

[0115] (7)GET11: Send a GET request via HTTP / 1.1.

[0116] 3. Define the load balancing strategy.

[0117] (1) byrequests: load balancing strategy based on the number of requests.

[0118] (2) bytraffic: load balancing strategy based on traffic.

[0119] (3) bybusyness: load balancing strategy based on busyness.

[0120] (4) heartbeat: detect the load balancing strategy based on the heartbeat.

[0121] 4. Define other parameters.

[0122] (1)route.

[0123] Meaning: A unique identifier used to identify each backend node.

[0124] For example, route=node1 means that requests from the same user are routed to the same backend server node1 during the entire session.

[0125] (2)hcpasses.

[0126] Meaning: Indicates how many consecutive successful health checks are required to mark the server as healthy.

[0127] For example, if hcpasses=2, two consecutive health checks must be passed.

[0128] (3)hcfails.

[0129] Meaning: Indicates how many consecutive failed health checks are required before the server is marked as unhealthy.

[0130] For example, hcfails=3 means that three consecutive health check failures are required.

[0131] (4)hcinterval.

[0132] Meaning: Defines the time interval (in seconds) between health checks.

[0133] For example, hcinterval=10 means a health check is performed every 10 seconds.

[0134] (5)hcuri.

[0135] Meaning: Specifies the URI for health check.

[0136] For example, hcuri= / status.php means using / status.php for health check.

[0137] (6)hctemplate.

[0138] Define a health check template for reusing health check configurations.

[0139] For example, define multiple health check parameters in a template and then reference the template in BalancerMember.

[0140] 2. Health check configuration module.

[0141] Configure BalancerMember to define the route forwarded by the web application deployed on Kubernetes as a load balancing member and configure health check rules based on the health check definition. The following provides several common health check rules.

[0142] (1) GET example, for example, BalancerMember "http: / / 10.10.10.1" route=nodeXhcmethod=GET; hcexpr=in_maint hcuri= / service.

[0143] Meaning: Add http: / / 10.10.10.1 to the load balancing pool, set the session stickiness route to nodeX, and perform a health check by sending a GET request to the / service URI. If the health check expression in_maint returns false, the node is considered healthy and can receive requests.

[0144] (2) HEAD example, for example, BalancerMember "http: / / 10.10.10.2" route=nodeYhcmethod=HEAD;hcexpr=ok234 hcuri= / service.

[0145] Meaning: Add http: / / 10.10.10.2 to the load balancing pool, set the session stickiness route to nodeY, and perform a health check by sending a HEAD request to the / service URI. If the health check expression ok234 returns true, the node is considered healthy and can receive requests.

[0146] (3) TCP example, for example, BalancerMember "http: / / 10.10.10.3" route=nodeZhcmethod=TCP hcuri= / service;hcinterval=30hcpasses=1hcfails=1.

[0147] Add http: / / 10.10.10.3 to the load balancing pool, set the session stickiness route to nodeZ, and perform a health check every 30 seconds using TCP. If the health check fails once, the node is considered healthy; if it succeeds once, it is considered healthy. Although hcuri= / service is set, this URI is not actually used in the TCP health check.

[0148] 2. For the load balancing member, configure ProxyPass and ProxyPassReverse to mycluster and link to the BalancerMember content under mycluster.

[0149] 3. Migration strategy module.

[0150] To achieve a gradual migration from the old Kubernetes cluster to the new one, you can gradually adjust the weight of the BalancerMember or add new application health checks to achieve a smooth migration. This example uses two applications as an example to illustrate the gradual migration. In actual use, you can refer to this module configuration to horizontally expand the number of BalancerMembers according to the number of applications to achieve a smooth migration.

[0151] Figure 3 is a timing diagram of an optional smooth migration process according to an embodiment of the present invention, such as Figure 3 As shown in the figure, the migration process involves the Apache system, the old K8s cluster, and the new K8s cluster.

[0152] Configure BalancerMember. Initially, deploy service1 and service2 on the old Kubernetes cluster. During the migration phase, deploy service2 on the new Kubernetes cluster, making it the only service available. Service2 will be forwarded to both clusters, while other services will be forwarded only to the old Kubernetes cluster. After service2 has run without any issues for a while, add service1 to the new Kubernetes cluster. Upon completion, disconnect all connections to the old Kubernetes cluster.

[0153] 1. Initial stage: Deploy two applications (including service1 and service2) on the old Kubernetes cluster.

[0154] 2. Gradual migration phase: Deploy only one application (service2) on the new K8s cluster, and add health check configuration for the service2 application based on the initial phase.

[0155] Adding the service2 configuration to the new Kubernetes cluster will divert 50% of the traffic. Because of the added health checks and detection configurations, if the application in the new Kubernetes cluster experiences an anomaly, traffic will not be diverted to the new cluster, and the application will remain unaffected during the migration. After this configuration runs for a while and there are no anomalies, the service1 application is added to the new Kubernetes cluster, gradually migrating the business traffic.

[0156] 3. Complete the migration phase: After all applications on the new cluster have run smoothly for a period of time, disconnect the old cluster.

[0157] By monitoring the health check policies of backend web services and isolating access to abnormal requests, traffic is directed only to application nodes that can normally process requests. During the migration from the old system to the new one, different request links with health check policies were configured at different stages, gradually completing the deployment of all applications to the new system, achieving a smooth migration from the old to the new system.

[0158] By automatically detecting and disconnecting unhealthy backend service connections, traffic is prevented from being forwarded to unresponsive services, improving overall system reliability. The flexible configuration options provided by the mod_proxy_hcheck module allow the frequency and criteria of health checks to be adjusted according to specific needs, adapting to different application scenarios. Furthermore, this embodiment is based on the existing Apache httpd and mod_proxy_hcheck modules, eliminating the need for additional complex tools and making it easy to integrate into existing systems.

[0159] 4. Link request display module.

[0160] 1. Add a custom log format to the Apache configuration file to log health check results to the health_check.log file. Then, log information about outbound requests to the outbound.log file.

[0161] 2. Parse the health_check.log log file, extract the result data of the hcexpr expression, and calculate the success and failure ratios.

[0162] By analyzing the health check results, the normal and abnormal ratios for each link can be calculated and displayed. This data can be obtained by parsing the log files, and then the number of successes and failures can be calculated to determine the respective ratios.

[0163] Normal link ratio: the ratio of successful health checks to the total number of checks.

[0164] Abnormal link ratio: The ratio of health check failures to the total number of checks.

[0165] 3. Parse the health_check.log file to extract the lowest and highest values ​​of HTTP request traffic from a system or service within a certain time period. #The regular expression matches the timestamp and request processing time in the log line.

[0166] 4. Generate charts through HTML web pages.

[0167] Select a different link to view the key components included in the link. Whether the requested link is normal is marked with a color. If 100% of the request fails, no link is displayed.

[0168] By parsing the logs and regularly updating and generating a bar chart of health check results, as well as HTTP outbound request traffic and counting the minimum and maximum values ​​to generate a line chart, real-time monitoring of the server health status is achieved.

[0169] This embodiment of the present invention achieves a smooth migration from an old Kubernetes cluster to a new one by gradually adjusting the BalancerMember configuration, reducing migration risks and downtime. Appropriate health check methods and configuration parameters can be selected based on specific needs to accommodate different application scenarios and network environments. A visual interface eliminates the complexity of manual configuration and generates configuration content through simple interface operations, reducing the risk of configuration errors.

[0170] The embodiments of the present invention can use status monitoring charts to understand the current health status of the system in real time, discover and solve problems in a timely manner, and based on probabilistic data, users can make reasonable decisions, such as adjusting health check configurations, optimizing load balancing strategies, etc., to improve system availability and stability.

[0171] The following describes it in detail with reference to another embodiment.

[0172] Example 2

[0173] A container application migration monitoring device based on a K8s cluster provided in this embodiment includes multiple implementation units, each implementation unit corresponding to each implementation step in the above-mentioned embodiment one.

[0174] Figure 4 is a schematic diagram of an optional container application migration monitoring device based on a K8s cluster according to an embodiment of the present invention, such as Figure 4As shown, the container application migration monitoring device based on the K8s cluster may include: an inspection rule configuration unit 41, a migration unit 42, a network link inspection unit 43, and a chart generation unit 44.

[0175] The check rule configuration unit 41 is used to configure health check rules for each server in the load balancing pool using a predefined health check expression.

[0176] The migration unit 42 is used to dynamically adjust traffic distribution based on the execution results of the health check rules, gradually adjust the configuration of each server in the load balancing pool, and complete the transition of container applications from the old K8s cluster to the new K8s cluster.

[0177] The network link checking unit 43 is configured to record the health status and request flow of the network links defined by each server in the load balancing pool based on predefined log configuration information to obtain a health check log.

[0178] The chart generating unit 44 is configured to parse the data in the health check log and generate a target chart including the health status and request flow of the network links defined by each server in the load balancing pool.

[0179] The above-mentioned container application migration monitoring device based on K8s cluster can configure health check rules for each server in the load balancing pool by using a pre-defined health check expression through the inspection rule configuration unit 41, and dynamically adjust the traffic distribution based on the execution results of the health check rules through the migration unit 42, gradually adjust the configuration of each server in the load balancing pool, and complete the transition of the container application from the old K8s cluster to the new K8s cluster. The network link inspection unit 43 records the health status and request traffic of the network links defined by each server in the load balancing pool based on the pre-defined log configuration information to obtain a health check log, and the chart generation unit 44 parses the data of the health check log to generate a target chart containing the health status and request traffic of the network links defined by each server in the load balancing pool. In this embodiment, pre-configured health check rules can be used to detect the health status of backend services, and the load balancing strategy can be used to change the request scheduling algorithm to decide whether to forward traffic to a specific backend service. The configuration of each server in the load balancing pool can be gradually adjusted, and the transition of container applications from the old K8s cluster to the new K8s cluster can be completed. The health status and request traffic of the network links defined by each server in the load balancing pool can be recorded, and a health check log can be obtained. A health check chart is generated, and the status of the network link is displayed through the chart to reduce the number of service interruptions, thereby solving the technical problem in the related technology that when the K8s cluster is migrating container applications, improper manual operations may easily lead to service interruptions.

[0180] Optionally, the container application migration monitoring device based on the K8s cluster also includes: a first acquisition unit, used to obtain a predefined health check expression set and a health check policy set before using a predefined health check expression to configure health check rules for each server in the load balancing pool, wherein the expression of the health check expression set includes at least one of the following: an expression for checking the response status code, an expression for checking whether the response body contains a specified instruction; a second acquisition unit, used to obtain a predefined load balancing policy combination, wherein the policy in the load balancing policy set includes at least one of the following: a load balancing policy by the number of requests, a load balancing policy by traffic, a load balancing policy by busyness, and a load balancing policy by heartbeat detection; a third acquisition unit, used to obtain a predefined anomaly monitoring parameter set, wherein the parameters of the anomaly monitoring parameter set include at least one of the following: a unique identifier for identifying each backend node, the number of checks for identifying a server as healthy or unhealthy, the time interval for health checks, a uniform resource identifier URI for health checks, and a health check template.

[0181] Optionally, the inspection rule configuration unit includes: a routing addition module, which is used to add the routes forwarded by the container application deployed on the K8s cluster to the load balancing pool and set the session stickiness routing; and a inspection rule configuration module, which is used to configure the health check rules of the load balancing pool according to pre-defined health check policies and health check expressions.

[0182] Optionally, the container application migration monitoring device based on the K8s cluster also includes: a request forwarding configuration unit, which is used to configure the forwarding request to the designated server of the load balancing pool after configuring the health check rules for each server in the load balancing pool using a pre-defined health check expression; a URI configuration unit, which is used to configure the uniform resource locator URI returned by the reverse request proxy to the client; and a forwarding request policy determination unit, which is used to determine the forwarding request policy based on the configuration of the server in the load balancing pool.

[0183] Optionally, the migration unit includes: an application migration module, which is used to dynamically adjust traffic distribution based on the execution results of the health check rules, and migrate one of the applications deployed on the old K8s cluster to the new K8s cluster; an application rule adding module, which is used to add a configuration health check rule to one of the applications deployed on the new K8s cluster; an application health check module, which is used to perform a health check on one of the applications using the newly added health check rules to obtain a health check result; a stop allocating traffic module, which is used to stop allocating new traffic to the new K8s cluster when the health check result indicates that one of the applications has an abnormality; and a remaining application migration module, which is used to migrate other applications in the old K8s cluster except one of the applications to the new K8s cluster when the health check result indicates that one of the applications has no abnormality.

[0184] Optionally, the container application migration monitoring device based on the K8s cluster also includes: an application status monitoring unit, which is used to monitor the running status of all applications in the new K8s cluster after completing the transition of container applications from the old K8s cluster to the new K8s cluster and migrating all container applications to the new K8s cluster; an old cluster link disconnection unit, which is used to disconnect the network link of the old K8s cluster after the running status of all applications is in normal state for a preset stable period of time.

[0185] Optionally, the chart generation unit includes: a log format adding module for adding a custom log format to the configuration file, wherein the custom log format is used to determine the output format of the health check log; a first log data parsing module for parsing the data of the health check log and calculating the number of successful health checks and the number of failed health checks for each network link; a link ratio calculation module for calculating the normal link ratio and the abnormal link ratio based on the number of successful health checks and the number of failed health checks for each network link; a link status determination module for determining the health status of the network links defined by each server in the load balancing pool based on the normal link ratio and the abnormal link ratio; a second log data parsing module for parsing the data of the health check log and extracting the minimum and maximum values ​​of the request traffic of the network links defined by each server in the load balancing pool within a predetermined time period; a chart generation module for generating a target chart containing all network links based on the health status of the network links defined by each server in the load balancing pool and the minimum and maximum values ​​of the request traffic of the network links defined by each server in the load balancing pool.

[0186] The above-mentioned container application migration monitoring device based on K8s cluster can also include a processor and a memory. The above-mentioned inspection rule configuration unit 41, migration unit 42, network link inspection unit 43, chart generation unit 44, etc. are all stored in the memory as program units, and the processor executes the above-mentioned program units stored in the memory to realize the corresponding functions.

[0187] The processors mentioned above contain a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and kernel parameters can be adjusted to enable automated application anomaly monitoring and smooth application migration within a Kubernetes cluster.

[0188] The above-mentioned memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0189] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is further provided, which includes a stored computer program, wherein when the computer program is running, the device where the computer-readable storage medium is located is controlled to execute any one of the container application migration monitoring methods based on the K8s cluster in the above-mentioned embodiment 1.

[0190] According to another aspect of an embodiment of the present invention, an electronic device is also provided, comprising one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by one or more processors, the one or more processors implement the container application migration monitoring method based on the K8s cluster of any one of the above-mentioned embodiments.

[0191] The present application also provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of the container application migration monitoring method based on the K8s cluster described in each embodiment of the present application.

[0192] The present application also provides a computer program product, including a non-volatile computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the steps of the container application migration monitoring method based on the K8s cluster described in each embodiment of the present application.

[0193] Figure 5 This is a hardware structure diagram of an electronic device (or mobile device) that executes a container application migration monitoring method based on a K8s cluster according to an embodiment of the present invention. Figure 5 As shown, the electronic device may include one or more ( Figure 5 (As shown in the figure, 502a, 502b, ..., 502n are used) processor 502 (processor 502 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), memory 504 for storing data. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, a keyboard, a power supply and / or a camera. It will be understood by those skilled in the art that Figure 5 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 5 More or fewer components than shown, or with Figure 5 Different configurations shown.

[0194] The serial numbers of the above embodiments of the present invention are for description only and do not represent the advantages or disadvantages of the embodiments.

[0195] In the above embodiments of the present invention, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0196] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only exemplary. For example, the division of the units can be a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0197] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0198] In addition, the functional units in the various embodiments of the present invention may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0199] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable 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. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server or network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, magnetic disk or optical disk, etc. Various media that can store program codes.

[0200] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be regarded as within the scope of protection of the present invention.

Claims

1. A container application migration monitoring method based on K8s cluster, characterized in that: include: Use predefined health check expressions to configure health check rules for each server in the load balancing pool; Based on the execution results of the health check rules, dynamically adjust traffic distribution, gradually adjust the configuration of each server in the load balancing pool, and complete the transition of container applications from the old K8s cluster to the new K8s cluster; Based on predefined log configuration information, record the health status and request flow of the network links defined by each server in the load balancing pool to obtain a health check log; Parse the data in the health check log to generate a target graph containing the health status and request flow of the network links defined by each server in the load balancing pool.

2. The container application migration monitoring method according to claim 1, characterized in that: Before configuring health check rules for each server in the load balancing pool using pre-defined health check expressions, the following steps are also required: Obtain a predefined health check expression set and a health check policy set, wherein the expressions in the health check expression set include at least one of the following: an expression for checking a response status code, and an expression for checking whether a response body contains a specified instruction; Obtain a predefined load balancing strategy combination, wherein the strategies in the load balancing strategy set include at least one of the following: a load balancing strategy based on the number of requests, a load balancing strategy based on the flow rate, a load balancing strategy based on the busyness, and a load balancing strategy based on the heartbeat detection; Obtain a predefined set of anomaly monitoring parameters, wherein the parameters of the anomaly monitoring parameter set include at least one of the following: a unique identifier for identifying each backend node, the number of checks for identifying a server as healthy or unhealthy, a time interval for health checks, a uniform resource identifier (URI) for health checks, and a health check template.

3. The container application migration monitoring method according to claim 2, characterized in that: The steps to configure health check rules for each server in the load balancing pool using predefined health check expressions include: Add the routes forwarded by the container application deployed on the K8s cluster to the load balancing pool and set session stickiness routes; The health check rules of the load balancing pool are configured according to a predefined health check strategy and the health check expression.

4. The container application migration monitoring method according to claim 1, characterized in that: After configuring health check rules for each server in the load balancing pool using pre-defined health check expressions, it also includes: Configure forwarding requests to the specified server in the load balancing pool; Configure the Uniform Resource Locator (URI) that the reverse request proxy returns to the client; The strategy for forwarding requests is determined based on the configuration of the servers in the load balancing pool.

5. The container application migration monitoring method according to claim 1, characterized in that: Based on the execution results of the health check rules, dynamically adjust traffic distribution, gradually adjust the configuration of each server in the load balancing pool, and complete the steps of transitioning container applications from the old K8s cluster to the new K8s cluster, including: Based on the execution results of the health check rules, dynamically adjust traffic distribution and migrate one of the applications deployed on the old K8s cluster to the new K8s cluster; Add a health check rule to one of the applications deployed on the new K8s cluster; Performing a health check on one of the applications using the newly added health check rule to obtain a health check result; If the health check result indicates that one of the applications is abnormal, stop allocating new traffic to the new K8s cluster; When the health check result indicates that one of the applications is normal, migrate the other applications in the old K8s cluster except the one of the applications to the new K8s cluster.

6. The container application migration monitoring method according to claim 5, characterized in that: After completing the transition of container applications from the old K8s cluster to the new K8s cluster, the following steps are also required: After migrating all container applications to the new K8s cluster, monitor the running status of all applications in the new K8s cluster; After the running status of all the applications is in normal state for a preset stable duration, the network link of the old K8s cluster is disconnected.

7. The container application migration monitoring method according to claim 1, characterized in that: The step of parsing the data of the health check log to generate a target graph containing the health status of the network links defined by each server in the load balancing pool and the request flow includes: Add a custom log format to the configuration file, where the custom log format is used to determine the output format of the health check log; Parsing the data in the health check log to calculate the number of health check successes and health check failures for each network link; Based on the number of successful health checks and failed health checks for each network link, the normal link ratio and abnormal link ratio are calculated. Determining the health status of network links defined by each server in the load balancing pool based on the normal link ratio and the abnormal link ratio; Parsing the data in the health check log to extract the lowest and highest values ​​of the request traffic of the network links defined by each server in the load balancing pool within a predetermined time period; Based on the health status of the network links defined by each server in the load balancing pool and the lowest and highest values ​​of the request flows of the network links defined by each server in the load balancing pool, a target graph containing all network links is generated.

8. A container application migration monitoring device based on K8s cluster, characterized in that: include: The check rule configuration unit is used to configure health check rules for each server in the load balancing pool using pre-defined health check expressions; A migration unit, configured to dynamically adjust traffic distribution based on the execution results of the health check rules, gradually adjust the configuration of each server in the load balancing pool, and complete the transition of container applications from the old K8s cluster to the new K8s cluster; A network link checking unit, configured to record the health status and request flow of the network links defined by each server in the load balancing pool based on predefined log configuration information, and obtain a health check log; The chart generating unit is used to parse the data of the health check log and generate a target chart including the health status and request flow of the network links defined by each server in the load balancing pool.

9. An electronic device, characterized in that: It includes one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the container application migration monitoring method based on the K8s cluster as described in any one of claims 1 to 7.

10. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the container application migration monitoring method based on the K8s cluster are implemented.

Images