High availability system based on container platform, container scheduling method and electronic equipment

Abstract

The invention provides a high-availability system based on a container platform, a container calling method and electronic equipment, and the method comprises the steps: pre-creating and activating a container copy through a container scheduling module according to the resource state of each container node and a priority constraint condition in the early stage of fault occurrence, and then when a fault event occurs, calling the container copy in advance; and in response to the fault event reminding message, calling an interface of the container scheduling module to create a new service instance in the container copy, carrying out synchronous processing on the container state based on the new service instance, and migrating the flow on the fault container instance to the new container instance. Therefore, in a high-concurrency scene, by selecting the embodiment of the invention, the flow is immediately taken over through the pre-activated standby container copy when a fault occurs, so that zero-shutdown container switching is realized, the high availability of a container platform is remarkably improved, and smooth operation of services is ensured.

Description

Technical Field

[0001] This application relates to the field of data operation and maintenance technology, and in particular to a high-availability system based on a container platform, a container scheduling method, and an electronic device. Background Technology

[0002] A container is a software unit that encapsulates an application and its dependencies together and runs independently in a host environment. The lifecycle of each container is usually managed by a container orchestration system, which schedules and manages the scaling of containers. The high availability of a container refers to the characteristic that it can still provide services when a single container node fails.

[0003] Currently, high availability solutions in the container ecosystem mainly fall into two categories: container orchestration systems and service mesh-based solutions. Common container orchestration systems include Kubernetes and Docker Swarm. Service mesh-based high availability solutions include Istio. While traditional high availability solutions can improve availability to some extent, performance bottlenecks and availability risks still exist when dealing with high-concurrency failure scenarios. Summary of the Invention

[0004] In view of this, embodiments of this application provide a high-availability system, container scheduling method, and electronic device based on a container platform to solve the problem that traditional container management solutions cannot guarantee service continuity in high-concurrency failure scenarios.

[0005] In a first aspect, embodiments of this application provide a high-availability system based on a container platform, the system comprising: a high-availability proxy module, a dynamic recovery module, and a container scheduling module, wherein: The container scheduling module is used to pre-create and activate container replicas based on the resource status and priority constraints of each container node. The high availability proxy module is used to call the container scheduling module interface to create a new container instance in response to a fault event alert message, so that the container scheduling module creates a new service instance in the container replica; The dynamic recovery module is used to respond to the fault event alert message, synchronize the container status based on the new service instance, and migrate traffic on the faulty container instance to the new container instance.

[0006] Secondly, embodiments of this application provide a container scheduling method, wherein the method is applied to the high-availability system based on the container platform described in the first aspect, wherein the method includes: Based on the resource status and priority constraints of each container node, container replicas are pre-created and activated; In response to a fault event alert message, a new container instance is created, and a new service instance is created within the new container instance; The new service instance is used to synchronize the container state and migrate traffic from the faulty container instance to the new container instance.

[0007] Thirdly, embodiments of this application provide an electronic device, wherein the electronic device includes: a processor; and a memory storing a program; wherein the program includes instructions, which, when executed by the processor, cause the processor to perform the container scheduling method described in the second aspect.

[0008] Fourthly, embodiments of this application provide a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to execute the container scheduling method described in the second aspect.

[0009] The beneficial effects of this application are: This application provides a high-availability system, container invocation method, and electronic device based on a container platform. By utilizing a container scheduling module to pre-create and activate container replicas based on the resource status and priority constraints of each container node in the early stages of a failure, and then, in response to a failure event alert message, calling the container scheduling module's interface to create a new service instance within the container replicas, synchronizing the container status based on the new service instance, and migrating traffic from the failed container instance to the new container instance, this application's embodiment, in high-concurrency scenarios, enables zero-downtime container switching by immediately taking over traffic in the event of a failure through pre-activated backup container replicas, significantly improving the high availability of the container platform and ensuring smooth business operation. Attached Figure Description

[0010] Further details, features, and advantages of this application are disclosed in the following description of exemplary embodiments in conjunction with the accompanying drawings, in which: Figure 1 This application illustrates an exemplary system architecture diagram of a container-based high-availability system provided in this application. Figure 2 This application illustrates another exemplary system architecture diagram of a container-based high-availability system. Figure 3 This invention illustrates a schematic diagram of the working principle of a container-based high-availability system provided in this application. Figure 4 This illustration shows another working principle diagram of the high availability system based on the container platform provided in this application; Figure 5A flowchart of the container scheduling method provided in this application is shown; Figure 6 A structural block diagram of an exemplary electronic device that can be used to implement embodiments of this application is shown. Detailed Implementation

[0011] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While some embodiments of this application are shown in the drawings, it should be understood that this application can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this application. It should be understood that the drawings and embodiments of this application are for illustrative purposes only and are not intended to limit the scope of protection of this application.

[0012] It should be understood that the steps described in the method embodiments of this application may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this application is not limited in this respect.

[0013] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the following description. It should be noted that the concepts of "first", "second", etc., mentioned in this application are used only to distinguish different devices, modules, or units, and are not intended to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0014] It should be noted that the terms "a" and "a plurality of" used in this application are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0015] Before describing the high-availability system, container scheduling method, and electronic device based on the container platform provided in this application, the following explanations are provided for the technical terms that may appear in this document: A container is a software unit that encapsulates an application and its dependencies together and runs independently in a host environment.

[0016] Container orchestration: Systems that manage the lifecycle, scheduling, scaling, and service discovery of containers, such as Kubernetes and Docker Swarm.

[0017] Scheduler: The module responsible for allocating container instances to appropriate nodes for execution, making decisions based on resource availability and policies.

[0018] High Availability (HA): The ability to continue providing services even when a single point of failure occurs, typically achieved through redundant deployment and failover.

[0019] Control Plane: The core component cluster of the container orchestration system (such as Kubernetes API Server, etcd, scheduler, etc.), responsible for managing and monitoring the cluster status.

[0020] Worker Node: A compute node that runs container applications, typically containing container runtimes (such as Docker and containerd) and node agents (such as kubelet).

[0021] Service Mesh: An infrastructure layer that provides governance and management of inter-service communication in a microservice architecture; it is typically injected transparently into each service instance through a Sidecar proxy (such as Envoy).

[0022] Sidecar Pattern: Deploy auxiliary containers (such as proxies) outside the business containers in the same Pod / container group to handle functions such as log collection, network communication, and security, and run them decoupled from the business logic.

[0023] Load balancing is a technique that distributes requests or traffic to multiple service instances or nodes to improve throughput and reliability.

[0024] State synchronization: In a distributed system, the process of keeping the state of an application or service consistent across multiple nodes to prevent data loss due to single-node failure.

[0025] Cold start: When a service or container instance starts for the first time, it has not yet loaded runtime data or cache, and the initialization time is relatively long.

[0026] Hot Swap: A mechanism that pre-starts or reserves a backup instance to quickly switch to the backup instance in the event of a primary instance failure, thereby ensuring service continuity.

[0027] Stateless Service: A service that does not store persistent state locally. Instances can be interchanged and data is usually shared through external storage. Stateful Service: A service that maintains local state or data requires special mechanisms to ensure state consistency.

[0028] Replica: A running instance of the same service. Multiple replicas can provide load balancing and fault redundancy.

[0029] Rolling Update: The process of gradually replacing old application instances with new ones. Generally, the old instance is shut down only after the new instance is ready, in order to minimize service interruption.

[0030] As described in the background section, high availability solutions in the current container ecosystem are mainly divided into two categories: high availability solutions based on container orchestration systems and high availability solutions based on service meshes. Among them: High availability solutions based on container orchestration systems are specifically manifested as follows: Container orchestration platforms, represented by Kubernetes, achieve fault recovery and load balancing through a distributed control plane and replication mechanism. Systems such as Kubernetes use clusters of multiple master nodes (multiple API Server instances) and the distributed database etcd (usually deployed across availability zones with an odd number of nodes) to ensure high availability of the control plane; the scheduler and controller manager maintain a master instance through a master-slave backup election method to ensure continuous execution of control commands.

[0031] When a node or container instance fails, Kubernetes uses the ReplicaSet / Deployment controller to launch new Pod replicas on other healthy nodes and routes traffic to available replicas via the Service's virtual IP or a load balancer to ensure service continuity. Meanwhile, Kubernetes provides mechanisms such as readiness probes and liveness probes to automatically detect container health and trigger restarts or rescheduling.

[0032] High-availability solutions based on service meshes are essentially transparent network proxy layers, exemplified by Istio, providing advanced governance capabilities for microservice communication. In Istio, each application Pod is automatically injected with a lightweight proxy (based on Envoy), forming a data plane (Sidecar). Istio's control plane (including components like Pilot and Mixer) is responsible for distributing configurations, enabling the Sidecar proxy to perform functions such as traffic management, load balancing, circuit breaking, rate limiting, canary deployment, and A / B testing. Through two-way TLS (Two-Way Transport Layer Security), security policies, and access control, Istio provides zero-trust security; and by generating metrics and logs, it integrates with Prometheus, Jaeger, and other protocols to achieve observability.

[0033] Overall, service mesh allows developers to obtain reliable traffic control and fault recovery capabilities without modifying application code. In addition, some container platforms (such as Docker Swarm and Apache Mesos) also have high availability features, but with the popularity of Kubernetes, it has become the de facto standard.

[0034] While the aforementioned mainstream solutions can improve availability to some extent, performance bottlenecks and availability risks still exist in high-concurrency failure scenarios, mainly manifested in the following ways: 1) Node failure recovery delay: When a worker node fails, Kubernetes needs to reschedule and start a new container replica. This process includes scheduling decisions, image pulling, container startup, and initialization, which can be time-consuming. If a large number of nodes fail simultaneously, the remaining node resources may be insufficient, leading to scheduling delays, image pulling timeouts, and other problems, thus causing service interruptions.

[0035] 2) Data and configuration loss due to container migration: As mentioned earlier, when a node fails, the Pod will be rescheduled to another node. While this "container migration" helps with application high availability, it can also lead to issues with data persistence and network configuration consistency. For example, if persistent storage or data synchronization is not configured correctly, temporary data on the original node may be lost; changes in network IP or configuration may also affect client connectivity. Even with StatefulSet and PVC (Persistent Volume Claim) for storage protection, cross-node state synchronization itself is a complex overhead.

[0036] 3) Untimely state synchronization: For stateful services, current solutions often rely on external databases or distributed caches for synchronization, but synchronization is often delayed. In the event of a multi-node failure, inconsistencies may occur between different replicas, and the synchronization network load increases, thus affecting performance and recovery speed.

[0037] 4) Rolling upgrades interrupting persistent connections: Kubernetes' rolling upgrade mechanism deletes old Pods only after new Pods are ready, thus minimizing the risk of new connection interruptions. However, old persistent connections are terminated, causing incomplete sessions to fail. Furthermore, if the new version of the container starts slowly, service readiness may be briefly affected. For example, the statement "If the old Pod is deleted only after the new Pod is Ready... new connections won't have problems, but old connections are prone to issues" illustrates that rolling upgrades cannot guarantee uninterrupted sessions.

[0038] In summary, traditional container high availability solutions face challenges such as insufficient fault detection and recovery speed, inadequate state protection, and prominent resource bottlenecks in scenarios involving large-scale node failures, service migration, state synchronization, and upgrade processes, making it difficult to achieve true business continuity assurance.

[0039] In view of this, this application provides a high-availability system, container scheduling method, and electronic device based on a container platform to solve the problem that traditional container platforms struggle to guarantee service continuity under high-concurrency failure scenarios. Specifically, in its first aspect, this application provides a high-availability system based on a container platform. For example... Figure 1 As shown, the system 10 includes: The system includes a container scheduling module 101, a high-availability proxy module 102, and a dynamic recovery module 103. Among these: The container scheduling module is used to pre-create and activate container replicas based on the resource status and priority constraints of each container node. The high availability proxy module is used to call the container scheduling module interface to create a new container instance in response to a fault event alert message, so that the container scheduling module creates a new service instance in the container replica; The dynamic recovery module is used to respond to the fault event alert message, synchronize the container status based on the new service instance, and migrate traffic on the faulty container instance to the new container instance.

[0040] This embodiment of the application utilizes a container scheduling module to pre-create and activate container replicas based on the resource status and priority constraints of each container node in the early stages of a failure. Then, in response to a failure event alert message, it calls the container scheduling module's interface to create a new service instance within the container replicas. Based on the new service instance, it synchronizes the container status and migrates traffic from the failed container instance to the new instance. Thus, in high-concurrency scenarios, this embodiment of the application achieves zero-downtime container failover by immediately taking over traffic in the event of a failure through pre-activated backup container replicas, significantly improving the high availability of the container platform and ensuring smooth business operation.

[0041] The following section will provide a detailed description of the container-based high-availability system provided in this application, using specific examples: In this application, the container platform can be understood as a container management platform, which is a complete toolchain and management system built around containers, and can be used for the full lifecycle management of containers, including creating, deploying, running, and maintaining them. The container scheduling module can also be understood as a container scheduler, which is responsible for deploying and scheduling container replicas based on resource availability and priority requirements, and can dynamically adjust container scheduling strategies in real time.

[0042] In this application, the container-based high-availability system may also include, for example... Figure 2 As shown, it also includes: a container status monitoring module 104 and a load balancing module 105. The container status monitoring module monitors the resource status of each container in real time. In this application, the resource status of a container is defined as a health indicator of the container.

[0043] As one implementation method, this container-based high-availability system can be as follows: Figure 3 As shown, it is specifically divided into: infrastructure layer, container orchestration layer, load balancing layer, high availability detection layer, and fast recovery layer. The infrastructure layer consists of multiple physical / virtual machines and supports deployment across availability zones (availability domains). The network employs multi-path redundant connections, and nodes share distributed storage and cache (such as a cross-zone distributed database or Redis cluster), providing a foundation for state synchronization.

[0044] The container orchestration layer enhances container replica management by using enhanced Kubernetes or a self-developed scheduling system. The scheduler supports resource allocation based on service level and load conditions, prioritizing the creation of replicas for critical services in the event of a failure. For example, scheduling priorities and warm-up metrics can be set for different replicas to prioritize the reconstruction of important services when resources are scarce.

[0045] The load balancing layer is used to deploy the load balancing module mentioned later.

[0046] The high availability detection layer is used to deploy node health probes, service attitudes, and monitoring and alarm systems. Each node periodically sends heartbeats to the status monitor. Container applications work with ready / live probes. Monitoring systems (such as Prometheus + Alertmanager) collect performance metrics in real time and generate fault events to assist the high availability agent module in making agent decisions.

[0047] The fast recovery layer is used to deploy dynamic recovery modules.

[0048] As one implementation, the container scheduling module can create, deploy, and schedule container replicas based on health indicators monitored by the container status monitoring module. Specifically, in this application, the container monitoring module is used for: According to a preset period, the health indicators of each working container node collected by the monitoring agent unit on each working container node are obtained, or the key container is actively probed and detected according to the preset period to obtain the health indicators of the key container. The health indicators include: CPU load, network latency and container liveness status. Based on the health indicators, it is determined whether a fault event exists. If a fault event exists, a fault event reminder message is output to the high availability proxy module, the dynamic recovery module, and the container scheduling module.

[0049] The preset period can be flexibly set according to actual needs. When the preset period is 0, it indicates that the container monitoring module continuously acquires the health indicators of each working container node or key container in real time. The monitoring agent unit can refer to a status monitor, which is used to collect the running status and performance indicators of each working container node, container, and service instance, and provide the collected data to the high availability agent module.

[0050] In one implementation, this status monitor can monitor the fault status of each container through monitoring mechanisms such as heartbeat monitoring and node health probes. Critical containers refer to those within the working container nodes that require close monitoring; the classification of critical containers depends on actual needs and can be flexibly selected accordingly, without strict limitations in this application. Working container nodes refer to containers that are already activated and running. Service instances refer to services that need to be deployed and run in containers due to business requirements. The concept of container instances is similar to that of service instances; container instances refer to service instances that have been deployed in containers but are not yet running. In one implementation, the status monitor can determine whether there are any anomalies in container nodes or service instances based on the monitored health indicators. If an anomaly is found, a fault event alert message is output.

[0051] As one implementation method, in this application, a lightweight monitoring agent is deployed on each working container node. This agent can determine the health of the node through heartbeat reports and node metric collection (such as CPU, memory, disk, and network latency). At the same time, it performs active probe detection (liveness / readiness) on critical containers. If the status monitor collects abnormal signals (such as no heartbeat for a long time or continuous probe failures), it immediately generates a fault event alert message to notify the high availability agent module.

[0052] In this application, the high-availability proxy module is connected to the status monitor and is deployed in the control plane, specifically within the core component cluster of the container orchestration system, such as the Kubernetes API Server, etcd, or the scheduler. It acquires real-time health status data of the cluster and services collected by the status monitor. If an anomaly is detected in a container node or service instance, a fault event alert message is sent to the container scheduler and the dynamic recovery module. As one implementation, a monitoring system (such as Prometheus + Alertmanager) can collect performance metrics in real-time and generate fault events, then send fault event alert messages to each module.

[0053] Based on this, in some possible embodiments, the high-availability proxy module is also used for: Call the container scheduling module interface to check if there are any remaining resources that meet the preset calling conditions for the target container replica; If the target container copy exists, perform state synchronization and container image reconstruction, and enable the target container copy. The dynamic recovery module will then migrate the traffic on the faulty container instance to the target container copy.

[0054] In one implementation, the high-availability proxy module and the container scheduling module can interact via API calls. If the high-availability proxy module receives a fault event alert, it can create a new container instance by calling the container scheduling module's API. In a preferred implementation, the container scheduling module's API can be: `CreatePod(serviceName, replicas=1, priority=high))`. Here, `Priority` represents the priority of the created container instance. In response to this API call, the container scheduling module selects a container node with a normal health metric (serviceName, replicas, priority) for deployment.

[0055] Normal health indicators can be determined by remaining resources. If the remaining resources meet the preset call conditions, it indicates that the container node's health indicators are normal; otherwise, the container node is abnormal. Container replicas whose health indicators are normal, and whose replica count and priority meet the call request sent by the high-availability proxy module, are identified as target container replicas.

[0056] As one implementation method, this high-availability proxy module can also be used for: Based on the comparison between health indicators and preset health indicator thresholds, it is determined whether a fault event exists. The preset health indicator thresholds can vary depending on the type of health indicator; for example, the health indicator thresholds for CPU resources and memory resources are different. Specific health indicator thresholds can be flexibly set according to actual needs, and this application does not impose strict limitations on them.

[0057] Furthermore, this container scheduling module is also used to pre-cachate the container image of the faulty container corresponding to the fault event alert message to the hot node, that is, to the target container replica, which can effectively shorten the image pull time. During this process, if the container scheduling module has already created and activated the container replica, it can be considered a pre-warmed container replica and can be directly added to the load pool to facilitate rapid failover. Throughout the process, it is necessary to ensure that critical containers have the highest scheduling priority to guarantee that critical services can be rebuilt first, avoiding resource consumption by low-priority services.

[0058] As one implementation method, before migrating service traffic, the dynamic recovery module can identify the service's state, determining whether it is stateful or stateless. For stateful services, critical information can be periodically written to a distributed cache (such as a Redis cluster or object storage based on multiple availability zones) during normal operation. Simultaneously, the container internally takes periodic state snapshots (Hot Cache). When a new instance starts, the dynamic recovery module first reads the most recent snapshot from the cache for state initialization, thus avoiding full recalculation or long waits for backend recovery, improving cold start speed and consistency. For stateless services, they can be started directly using an image without additional synchronization.

[0059] As one implementation method, this high-availability proxy module is also used for: If no copy of the target container exists, an alarm message will be output.

[0060] If no target container replica exists, it means that the current cluster resources are insufficient to support the maintenance of the faulty container. In this case, an alarm message can be output, and the corresponding cause of the fault can be carried in the alarm message, which helps the operation and maintenance personnel to perform manual container maintenance.

[0061] In some possible embodiments, the high-availability system based on a container platform provided in this application further includes a load balancing module. This load balancing module is used for: Provide a unified service domain name or virtual IP address to the outside world, respond to the fault event alert message, and dynamically update the load balancing rules between each container according to the health status of each container fed back by the high availability proxy module. The load balancing rules constrain each container and each container replica to be located in different container regions.

[0062] The load balancing module provides a unified access point for external requests and distributes access traffic based on the real-time status of service instances. In the event of a failure, the high-availability proxy module can adjust the load balancing configuration, switching traffic to available container replicas or backup container nodes.

[0063] As one implementation, this load balancing module is deployed at the load balancing layer, specifically as a software or hardware load balancer, such as one based on Keepalived+HAProxy / VIP or a cloud provider's multi-AZ LB, providing a unified service domain name or virtual IP address. When a failure occurs in a certain region, it can automatically switch to container instances in the backup container region. Simultaneously, the internal load balancer can dynamically update its load balancing rules based on the container health metrics reported by the high-availability proxy module, ensuring that containers and container replicas are evenly distributed across different container regions.

[0064] In this embodiment, modules collaborate through predefined interfaces. For example, the high-availability proxy module provides a fault reporting interface, namely the `ReportFailure(serviceID, reason)` interface, where `ServiceID` identifies the corresponding service and `reason` identifies the cause of the fault. The container scheduling module provides Pod instance operation interfaces, such as `CreatePod(serviceID, options)` and `DeletePod(podID)`, where `option` identifies available container options and `podID` identifies the created Pod. The dynamic recovery module provides a service operation interface, namely the `SyncState(serviceID, podID)` interface. The load balancing module provides a load update interface, namely the `UpdateEndpoints(serviceID, podList)` interface, where `podlist` represents the current list of pods.

[0065] In this embodiment, the dynamic recovery module can be triggered by a fault event, and then execute a specific container recovery process. This dynamic recovery module can utilize pre-warmed container instances (active, resident, but not processing traffic standby containers) to accelerate fault recovery. If a container node fails, the dynamic recovery module immediately switches traffic to the corresponding pre-warmed container instance for seamless takeover and switching. For stateful services, the dynamic recovery module can coordinate the synchronization of the latest state from distributed cache or persistent storage to the new service instance to ensure data continuity.

[0066] Specifically, if a container node fails, the high-availability proxy module can sequentially call the preset interfaces of each module. First, it triggers the container scheduling module to create a new container replica. Then, it calls the dynamic recovery module to synchronize the container instance's state. Finally, it calls the load balancing module to balance the configurations among the containers. Throughout this process, the status monitor records and provides feedback to form a closed loop.

[0067] The high-availability proxy module features a multi-layered fault diagnosis mechanism. If a single container node becomes isolated or network partitions change, the specific scope of the fault can be determined through various monitoring methods such as network probing, log analysis, and heartbeat monitoring. After confirming a container node failure, the dynamic recovery module quickly performs container recovery and can also trigger isolation operations for the entire failed container node, such as automatically isolating the faulty container node and notifying the operations and maintenance system. At this point, the dynamic recovery module can automatically switch traffic, or manual confirmation can be required before switching traffic. Finally, the entire recovery process is visualized, ensuring that operations and maintenance personnel can see the progress of the container recovery throughout.

[0068] In some possible embodiments, the working principle of the container-based high-availability system provided in this application can be as follows: Figure 4 As shown, the system periodically performs health checks on the health status of containers and nodes to determine if any anomalies exist. If no anomalies are found, the system returns to performing the periodic health check. If anomalies are found, the specific anomaly is determined based on health indicator thresholds to confirm that the health indicators have reached the fault determination threshold. Further, the container scheduler is notified, and the replica recovery process is triggered. During this process, the system checks if any replica nodes are available. If not, the scheduling has failed, and an alarm message is issued. If any replica nodes are available, state synchronization and container image reconstruction are performed, the container is started, and service traffic is connected to complete traffic recovery and record the corresponding log information.

[0069] The high-availability system based on the container platform provided in this application can quickly detect and recover from container node failures. Container replica preheating and scheduling priority shorten recovery time, while distributed caching and cold start ensure continuous state synchronization. Furthermore, the high-availability proxy module and dynamic recovery module work together to automatically reroute traffic to healthy service instances, achieving continuous service availability.

[0070] Secondly, this application provides a container scheduling method, which is applied to the system provided in the first aspect. Furthermore, this method can be applied to any electronic device with container scheduling functionality, including but not limited to personal mobile terminals, computers, or servers. Figure 5 As shown, the method includes the following steps: S51. Based on the resource status and priority constraints of each container node, pre-create and activate container replicas; S52. In response to the fault event alert message, create a new container instance and create a new service instance in the new container instance; S53. Based on the new service instance, synchronize the container state and migrate traffic on the faulty container instance to the new container instance.

[0071] In some possible embodiments, the method further includes: According to a preset period, the health indicators of each working container node collected by the monitoring agent unit on each working container node are obtained, or the key container is actively probed and detected according to the preset period to obtain the health indicators of the key container. The health indicators include: CPU load, network latency and container liveness status. Based on the health indicators, determine whether there is a fault event. If a fault event exists, output the fault event reminder message.

[0072] In some possible embodiments, the method further includes: Based on the comparison between the health indicators and preset health indicator thresholds, it is determined whether a fault event exists.

[0073] In some possible embodiments, the method further includes: Check if there are any remaining target container copies that meet the preset call conditions; If the target container copy exists, perform state synchronization and container image reconstruction, and enable the target container copy. The dynamic recovery module will then migrate the traffic on the faulty container instance to the target container copy.

[0074] In some possible embodiments, the method further includes: If no copy of the target container exists, an alarm message will be output.

[0075] In some possible embodiments, the method further includes: Provide a unified service domain name or virtual IP address to the outside world, respond to the fault event alert message, and dynamically update the load balancing rules between each container according to the health status of each container fed back by the high availability proxy module. The load balancing rules constrain each container and each container replica to be located in different container regions.

[0076] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in this application comply with relevant laws and regulations and do not violate public order and good morals.

[0077] The names of the messages or information exchanged between multiple devices in the embodiments of this application are for illustrative purposes only and are not intended to limit the scope of these messages or information.

[0078] Thirdly, exemplary embodiments of this application also provide an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to cause the electronic device to perform a method according to an embodiment of this application.

[0079] An exemplary embodiment of this application also provides a non-transitory computer-readable storage medium storing a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a method according to an embodiment of this application.

[0080] An exemplary embodiment of this application also provides a computer program product, including a computer program, wherein, when executed by a computer's processor, the computer program is used to cause the computer to perform a method according to an embodiment of this application.

[0081] refer to Figure 6The present invention describes a structural block diagram of an electronic device 600 that can serve as a server or client of this application, which is an example of a hardware device that can be applied to various aspects of this application. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the application described and / or claimed herein.

[0082] like Figure 6 As shown, the electronic device 600 includes a computing unit 601, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM 602) or a computer program loaded from a storage unit 608 into a random access memory (RAM 603). The RAM 603 may also store various programs and data required for the operation of the electronic device 600. The computing unit 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output interface (I / O interface 605) is also connected to the bus 604.

[0083] Multiple components in electronic device 600 are connected to I / O interface 605, including: input unit 606, output unit 607, storage unit 608, and communication unit 609. Input unit 606 can be any type of device capable of inputting information to electronic device 600. Input unit 606 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of electronic device. Output unit 607 can be any type of device capable of presenting information and may include, but is not limited to, a display, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 608 may include, but is not limited to, disks and optical discs. Communication unit 609 allows electronic device 600 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers, and / or chipsets, such as Bluetooth™ devices, WiFi devices, WiMax devices, cellular communication devices, and / or the like.

[0084] The computing unit 601 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 601 performs the various methods and processes described above. For example, in some embodiments, the aforementioned container scheduling method can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 600 via ROM 602 and / or communication unit 609. In some embodiments, the computing unit 601 can be configured to perform the aforementioned container scheduling method by any other suitable means (e.g., by means of firmware).

[0085] The program code used to implement the methods of this application may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0086] In the context of this application, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0087] As used in this application, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, device, and / or apparatus (e.g., disk, optical disk, memory, programmable logic device (PLD)) for providing machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term "machine-readable signal" refers to any signal for providing machine instructions and / or data to a programmable processor.

[0088] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0089] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0090] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other.

Claims

1. A highly available system based on a container platform, characterized in that, The system includes: a high-availability proxy module, a dynamic recovery module, and a container scheduling module, wherein: The container scheduling module is used to pre-create and activate container replicas based on the resource status and priority constraints of each container node. The high availability proxy module is used to call the container scheduling module interface to create a new container instance in response to a fault event alert message, so that the container scheduling module creates a new service instance in the container replica; The dynamic recovery module is used to respond to the fault event alert message, synchronize the container status based on the new service instance, and migrate traffic on the faulty container instance to the new container instance.

2. The system according to claim 1, characterized in that, The system further includes: a container status monitoring module, the container status monitoring module being used for: According to a preset period, the health indicators of each working container node collected by the monitoring agent unit on each working container node are obtained, or the key container is actively probed and detected according to the preset period to obtain the health indicators of the key container. The health indicators include: CPU load, network latency and container liveness status. Based on the health indicators, it is determined whether a fault event exists. If a fault event exists, a fault event reminder message is output to the high availability proxy module, the dynamic recovery module, and the container scheduling module.

3. The system according to claim 2, characterized in that, The determination of whether a fault event exists based on the health indicators includes: Based on the comparison between the health indicators and preset health indicator thresholds, it is determined whether a fault event exists.

4. The system according to claim 1, characterized in that, The high-availability proxy module is also used for: Call the container scheduling module interface to check if there are any remaining resources that meet the preset calling conditions for the target container replica; If the target container copy exists, perform state synchronization and container image reconstruction, and enable the target container copy. The dynamic recovery module will then migrate the traffic on the faulty container instance to the target container copy.

5. The system according to claim 4, characterized in that, The high-availability proxy module is also used for: If no copy of the target container exists, an alarm message will be output.

6. The system according to claim 1, characterized in that, The system further includes a load balancing module, the load balancing module being used for: Provide a unified service domain name or virtual IP address to the outside world, respond to the fault event alert message, and dynamically update the load balancing rules between each container according to the health status of each container fed back by the high availability proxy module. The load balancing rules constrain each container and each container replica to be located in different container regions.

7. A container scheduling method, characterized in that, The method is applied to a container-based high-availability system as described in any one of claims 1-6, wherein the method comprises: Based on the resource status and priority constraints of each container node, container replicas are pre-created and activated; In response to a fault event alert message, a new container instance is created, and a new service instance is created within the new container instance; The new service instance is used to synchronize the container state and migrate traffic from the faulty container instance to the new container instance.

8. The container scheduling method according to claim 7, characterized in that, The method further includes: According to a preset period, the health indicators of each working container node collected by the monitoring agent unit on each working container node are obtained, or the key container is actively probed and detected according to the preset period to obtain the health indicators of the key container. The health indicators include: CPU load, network latency and container liveness status. Based on the health indicators, determine whether there is a fault event. If a fault event exists, output the fault event reminder message.

9. An electronic device, characterized in that, The electronic device includes: a processor and a memory storing a program; wherein the program includes instructions that, when executed by the processor, cause the processor to perform the method according to any one of claims 7-8.

10. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 7-8.

Images