Virtual node state monitor deployment method and apparatus, storage medium, and device

Abstract

The application discloses a virtual node state monitor deployment method and device, a storage medium and equipment. The method comprises the following steps: providing a Kubernetes cluster, wherein the cluster comprises at least one subnet; deploying at least three replicas of a container group comprising a virtual node state monitor in each subnet; wherein at least one service container group is deployed in at least one subnet; the at least one service container group is monitored by at least one virtual node state monitor in the at least one subnet; and a headless service is used to expose the service container group in the at least one virtual node state monitor. The application can reduce the starting frequency of the second container group eviction strategy in Kubernetes, reduce the probability of eviction failure, and further reduce the reconstruction probability of the service container group in the virtual node state monitor by setting a deployment mode, thereby providing reliability guarantee for scheduling the service container group in the virtual node state monitor.

Description

Technical Field

[0001] This disclosure relates to the field of information technology, and in particular to methods, apparatus, storage media and devices for deploying virtual node status monitors. Background Technology

[0002] With the development of container technology, container technology and virtualization technology have become a widely accepted method for sharing container server resources. Container technology provides operators with great flexibility in the process of building container operating system instances on demand. Kubernetes (K8s) is an open-source platform created and managed by Google. The name Kubernetes comes from Greek and means "helmsman" or "navigator." K8s is a container cluster management system. K8s can realize automated deployment, automatic scaling, and maintenance of container clusters.

[0003] Virtual Kubelet is an implementation of the open-source Kubernetes kubelet. It disguises itself as a virtual kubelet to link Kubernetes clusters with APIs of other platforms, and can schedule containers in cloud serverless APIs. However, deployment schemes for Virtual Kubelet in related technologies may lead to problems such as frequent rebuilding and eviction failures of business container groups deployed in Virtual Kubelet. Summary of the Invention

[0004] To reduce the frequency of business container group rebuilding and the probability of eviction failure, embodiments of this disclosure provide a method, apparatus, storage medium, and device for deploying a virtual node status monitor.

[0005] On the one hand, this disclosure provides a method for deploying a virtual node status monitor, the method comprising:

[0006] Provide a Kubernetes cluster that contains at least one subnet;

[0007] Deploy at least three copies of container groups containing virtual node status monitors in each subnet; at least one service container group is deployed in at least one subnet; the at least one service container group is monitored by at least one virtual node status monitor in the at least one subnet.

[0008] The business container group in the at least one virtual node status monitor is exposed using a headless service.

[0009] On the other hand, this disclosure provides a virtual node status monitoring processing device, the device comprising:

[0010] a subnet determination module configured to provide a Kubernetes cluster comprising at least one subnet;

[0011] a deployment module configured to deploy at least three replicas of a container group comprising a virtual node state monitor in each subnet; wherein at least one service container group is deployed in at least one subnet; the at least one service container group is monitored by at least one virtual node state monitor in the at least one subnet;

[0012] a headless service module configured to expose the service container group in the at least one virtual node state monitor using a headless service.

[0013] In another aspect, the present disclosure provides a computer-readable storage medium, characterized in that the computer-readable storage medium stores at least one instruction or at least one program, the at least one instruction or at least one program is loaded and executed by a processor to implement the virtual node state monitor deployment method described above.

[0014] In another aspect, the present disclosure provides a virtual node state monitor processing device, characterized in that it comprises at least one processor and a memory in communication connection with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the at least one processor implements the virtual node state monitor deployment method described above by executing the instructions stored in the memory.

[0015] The present disclosure provides a virtual node state monitor deployment method, device, storage medium and equipment. The present disclosure reduces the frequency of starting the second container group eviction policy in Kubernetes by deploying at least three replicas of a container group comprising a virtual node state monitor in each subnet of the Kubernetes cluster, reduces the probability of eviction failure, and further reduces the reconstruction probability of the service container group in the virtual node state monitor by setting the deployment mode, thereby realizing a high-availability solution for virtual node state monitor management, providing protection for fault restart and upgrade reconstruction of the virtual node state monitor, and providing reliability protection for scheduling the service container group in the virtual node state monitor. BRIEF DESCRIPTION OF DRAWINGS

[0016] In order to more clearly illustrate the technical solutions and advantages in the embodiments of the present disclosure or related technologies, the drawings needed in the embodiment or related technology description will be briefly introduced as follows. Obviously, the drawings in the following description are only some embodiments of the present disclosure, and those skilled in the art can obtain other drawings according to these drawings without creative labor.

[0017] Figure 1This is a schematic diagram of the deployment of a virtual node status monitor in the relevant technology provided in this disclosure;

[0018] Figure 2 This is a schematic diagram of the framework of a virtual node status monitor deployment method provided in this disclosure;

[0019] Figure 3 This is a flowchart illustrating a method for deploying a virtual node status monitor according to an embodiment of this disclosure;

[0020] Figure 4 This is a schematic diagram of container deployment in subnet A provided in an embodiment of this disclosure;

[0021] Figure 5 This is a schematic diagram of the Kubernetes architecture in a scenario provided in this public disclosure;

[0022] Figure 6 This is a flowchart illustrating the method for restarting the status monitor of each virtual node provided in this disclosure;

[0023] Figure 7 This is a flowchart illustrating the method for upgrading the status monitor of each virtual node provided in this disclosure;

[0024] Figure 8 This is a block diagram of a virtual node status monitoring device provided in this disclosure;

[0025] Figure 9 This is a schematic diagram of the hardware structure of a device for implementing the method provided in the embodiments of this disclosure. Detailed Implementation

[0026] The technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0027] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0028] To make the objectives, technical solutions, and advantages of the embodiments disclosed herein clearer, the embodiments of this disclosure will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are merely illustrative of the embodiments of this disclosure and are not intended to limit the scope of this disclosure.

[0029] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "multiple" means two or more. To facilitate understanding of the above-described technical solutions and their resulting technical effects, this disclosure first explains the relevant technical terms:

[0030] Kubernetes: Kubernetes is an open-source container orchestration engine from Google. It supports automated deployment, massive scalability, and containerized application management, aiming to make deploying containerized applications simple and efficient. Kubernetes provides a mechanism for application deployment, planning, updating, and maintenance. Its design structure defines a series of building blocks designed to provide a mechanism for deploying, maintaining, and scaling applications. The components that make up Kubernetes are designed with loose coupling and scalability in mind, allowing them to meet a variety of different workloads. Scalability is largely provided by the Kubernetes API, which is primarily used as an internal component for scaling and as containers running on Kubernetes. Kubernetes can be deployed in distributed computer clusters, where each computer can form a node, each node can run one or more applications, and each container group can support one or more applications.

[0031] Pod: The basic unit of scheduling in Kubernetes is called a "pod," which is interpreted in this disclosure as a group of containers. This abstract category allows higher-level abstractions to be added to containerized components. A pod typically contains one or more containers, ensuring they remain on the host and can share resources. Each pod in Kubernetes is assigned a unique (within the cluster) IP address, allowing applications to use the same port without conflicts. A pod can define a volume, such as a local disk directory or network disk, and expose it within a container within the pod. Pods can be managed manually via the Kubernetes API or delegated to a controller for automated management.

[0032] Kubelet: The Kubelet is responsible for the running status of each node, ensuring that all containers on the node are running correctly. In this disclosure, it is interpreted as a node status monitor. It handles the starting, stopping, and maintenance of application containers according to the instructions of the control panel. If a pod is not in the required state, it will be redeployed to the same node. Node status messages are relayed to the relay host every few seconds. If the master detects a node failure, the pod can be started on another healthy node.

[0033] API server: The API server is a key component that provides internal and external interfaces to Kubernetes using the Kubernetes API and JSON over HTTP. It can be deployed on a node.

[0034] Vk: Short for Virtual Kubelet, which is explained in this disclosure as a virtual node status monitor. VirtualKubelet is an implementation of the open-source Kubernetes kubelet; it's an API disguised as a virtual kubelet that links Kubernetes clusters to other platforms. Vk's primary use case is supporting the extension of the Kubernetes API to serverless container platforms such as ACI and Fargate. From the perspective of the Kubernetes APIServer, Virtual Kubelets look like regular kubelets, but the key difference is that they schedule containers elsewhere, such as within a cloud serverless API, rather than on the nodes. Vk has a pluggable architecture and can directly use Kubernetes primitives.

[0035] A Service is a resource in Kubernetes that provides access to single or multiple containerized applications. Each service has a fixed IP address and port throughout its lifecycle. Each service corresponds to one or more backend Pods. In this way, clients don't need to know the location of the Pods, making it convenient for the backend to perform Pod scaling operations such as scaling up and down. Headless Services are a special type of Service that are not assigned a fixed IP address during runtime. When a client accesses a Headless Service, the DNS (Domain Name System) in the cluster returns a set of IP addresses of the service's Pods, allowing the client to define its own load balancing strategies.

[0036] Deployment: This disclosure interprets it as a stateless service deployment mode; StatefulSet: This disclosure interprets it as a stateful service deployment mode; Both StatefulSet and Deployment are load management controller APIs provided by Kubernetes for managing applications. StatefulSet, based on Pod group management, ensures the order and consistency of Pods within a Pod group. Unlike Deployment, Pods created by StatefulSet retain a persistent identifier (e.g., Pod Name) throughout their lifecycle.

[0037] pod-eviction-timeout: Container group eviction timeout.

[0038] node-eviction-rate: Eviction rate, defaults to 0.1 pod / second.

[0039] Kube-controller-manager: Container group controller.

[0040] The first container group eviction strategy: This is a pod eviction policy provided by Kubernetes for unhealthy nodes. The Kubernetes controller periodically checks the node status, and whenever a node's status is NotReady and the podEvictionTimeout period has expired, all pods on that node are evicted to other nodes. The specific eviction speed is also affected by eviction rate parameters, cluster size, etc. The two most commonly used parameters are pod-eviction-timeout and node-eviction-rate.

[0041] large-cluster-size-threshold: Large cluster capacity threshold. Determines whether a cluster is a large cluster. The default value is 50, meaning a cluster with more than 50 nodes is considered a large cluster.

[0042] unhealthy-zone-threshold: The threshold for the proportion of faulty nodes. The default value is 55%.

[0043] secondary-node-eviction-rate: the second eviction rate.

[0044] Second container group eviction policy: This is another pod eviction policy provided by Kubernetes to evict unhealthy nodes. This policy may be triggered when the number of faulty nodes in a subnet exceeds a certain threshold. In a large cluster, when the number of faulty nodes exceeds 55%, eviction is performed based on the second container group eviction policy, with a default eviction rate of 0.01 pods / second. In a small cluster, when the number of faulty nodes exceeds 55%, eviction is performed based on the second container group eviction policy, with a second eviction rate of 0 pods / second.

[0045] The technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0046] In related technologies, deployment schemes for virtual node status monitors (Virtual Kubelet) based on Kubernetes typically involve deploying a single virtual node status monitor within the Kubernetes cluster using a stateless service deployment model (Deployment). Please refer to... Figure 1The diagram illustrates the deployment of a virtual node status monitor in the context of related technologies. Clearly, the virtual node status monitor registers itself as a node within the Kubernetes cluster, allowing container groups and containers to be deployed within it. From a Kubernetes perspective, there is little difference between a node status monitor deployed on a node and this single virtual node status monitor; both can schedule relevant Kubernetes APIs, such as Capacity, OperatingSystem, CreatePod, UpdatePod, GetPod, GetPodStatus, GetPods, and NodeConditions. The only difference is that the virtual node status monitor can schedule containers within the cloud serverless API, rather than scheduling containers on the node itself. Deploying a virtual node status monitor does not affect the normal operation of other regular node status monitors.

[0047] However, if the relevant technology deploys a single virtual node status monitor in Deployment mode, that single virtual node status monitor will be assigned a different network tag each time it restarts. This will trigger the container group controller to evict the service container group originally monitored by the single virtual node, thereby causing the service container group to be rebuilt, which may result in the service container group being rebuilt frequently.

[0048] Furthermore, if the relevant technology deploys a single virtual node status monitor in Deployment mode, and this single virtual node status monitor encounters a failure and cannot communicate with the API server, and the communication failure time exceeds the container group eviction timeout, then if this solution is applied to a cloud serverless service scenario, since there are no ordinary node status monitors in the cloud serverless service scenario, and there are no other normally functioning virtual node status monitors in the subnet where this single virtual node status monitor is located, the failure rate of the subnet may reach 100%, which is already beyond the failure rate. At this time, the execution of the second container group eviction policy can be triggered. If the cluster corresponding to the subnet where this single virtual node status monitor is located is a small cluster, the second eviction rate is 0 pods / second, which is equivalent to eviction failure. This will cause the business containers deployed on this single virtual node status monitor to be unable to continue communicating with Kubernetes through the virtual node status monitor.

[0049] It is evident that the deployment scheme of deploying a single virtual node status monitor in Deployment mode in related technologies may cause frequent business container group rebuilds. Furthermore, if applied to cloud serverless service scenarios, it may also lead to eviction failure. In order to solve the above technical problems, this disclosure provides a virtual node status monitor processing scheme that can be applied to cloud serverless service scenarios, reducing the frequency of business container group rebuilds and reducing the probability of eviction failure.

[0050] like Figure 2 The diagram illustrates a framework of a virtual node status monitor deployment method provided in this disclosure. This disclosure can be implemented based on a Kubernetes container network framework. For example, the container network includes multiple subnets, each of which may contain at least three virtual node status monitors. Each virtual node status monitor includes zero or at least one group of business containers. This disclosure is applicable to cloud serverless service scenarios; therefore, each subnet may only deploy virtual node status monitors without deploying node status monitors. This implementation framework forms a container cloud, which is a cloud computing network primarily composed of containers. For example, it can be customized and optimized based on open-source Kubernetes and Moby (a Docker community project) to deliver cloud computing CaaS (communication as a service) capabilities, mainly continuous integration, continuous deployment, and application-oriented microservice capabilities.

[0051] Container cloud supports scalable business services in the form of containers, thereby providing application-oriented service capabilities. Depending on the application type, it can be applied to various scenarios such as medical cloud, cloud IoT, cloud security, cloud call, private cloud, public cloud, hybrid cloud, cloud gaming, cloud education, cloud conferencing, cloud social networking, and artificial intelligence cloud services.

[0052] Medical cloud refers to a cloud platform for healthcare services created using cloud computing, mobile technology, multimedia, 4G communication, big data, and the Internet of Things, combined with medical technology. This platform enables the sharing of medical resources and expands the scope of medical care. Because of the application of cloud computing technology, medical cloud improves the efficiency of medical institutions and makes it more convenient for residents to access medical care.

[0053] Cloud security refers to the collective term for security software, hardware, users, organizations, and security cloud platforms based on cloud computing business models. Cloud security integrates emerging technologies and concepts such as parallel processing, grid computing, and the identification of unknown virus behavior. Through a large network of clients, it monitors abnormal software behavior on the network, obtains the latest information on Trojans and malware on the internet, sends it to the server for automatic analysis and processing, and then distributes solutions for viruses and Trojans to each client.

[0054] A private cloud is a cloud infrastructure and hardware / software resources created within a firewall, allowing various departments within an organization or enterprise to share resources within a data center. In addition to hardware resources, creating a private cloud typically involves cloud equipment (IaaS, Infrastructure as a Service) software.

[0055] Public cloud typically refers to a cloud service provided by a third-party provider to users. Public clouds are generally accessible via the Internet and may be free or inexpensive. The core attribute of a public cloud is shared resource service. Many instances of this type of cloud exist, providing services across today's open public networks.

[0056] Hybrid cloud, which combines public cloud and private cloud, has become a major model and development direction of cloud computing in recent years. Private cloud primarily targets enterprise users; for security reasons, enterprises prefer to store data in private clouds, but at the same time, they also want access to the computing resources of public clouds. Hybrid cloud is increasingly adopted in this context, combining and matching public and private clouds to achieve optimal results. This personalized solution achieves both cost-effectiveness and security.

[0057] Cloud gaming, also known as gaming on demand, is an online gaming technology based on cloud computing. It enables thin clients with relatively limited graphics processing and data processing capabilities to run high-quality games. In cloud gaming, the game does not reside on the player's terminal but runs on a cloud server. The cloud server renders the game scene as a video and audio stream, which is then transmitted to the player's terminal via the network. The player's terminal does not need powerful graphics processing and data processing capabilities; it only needs basic streaming media playback capabilities and the ability to receive player input commands and send them to the cloud server.

[0058] Cloud Computing Education (CCEDU) refers to an education platform service based on cloud computing business models. On the cloud platform, all educational institutions, training institutions, enrollment service agencies, publicity agencies, industry associations, management agencies, industry media, legal structures, etc., are centrally integrated into a resource pool. These resources can be displayed and interacted with each other, communicate on demand, and reach agreements, thereby reducing education costs and improving efficiency.

[0059] Cloud conferencing is an efficient, convenient, and low-cost form of meeting based on cloud computing technology. Users only need to use an internet interface to quickly and efficiently share voice, data files, and video with teams and clients around the world. The complex technologies such as data transmission and processing during the meeting are handled by the cloud conferencing service provider.

[0060] Cloud social networking is a virtual social application model that integrates the Internet of Things, cloud computing, and mobile internet. Its purpose is to establish a well-known "resource-sharing relationship graph" to facilitate online social interaction. The main characteristic of cloud social networking is the unified integration and evaluation of a large amount of social resources, forming an effective resource pool to provide services to users on demand. The more users participate in sharing, the greater the value created.

[0061] Artificial intelligence cloud services are generally also known as AIaaS (AI as a Service). This is currently a mainstream service model for artificial intelligence platforms. Specifically, AIaaS platforms break down several common AI services and provide them as independent or packaged services in the cloud. This service model is similar to opening an AI-themed marketplace: all developers can access and use one or more AI services provided by the platform through API interfaces. Some experienced developers can also use the AI ​​frameworks and AI infrastructure provided by the platform to deploy and maintain their own dedicated cloud AI services.

[0062] The following describes a method for deploying a virtual node status monitor disclosed herein. Figure 3 This diagram illustrates a flowchart of a virtual node status monitor deployment method according to an embodiment of this disclosure. This disclosure provides the method operation steps described in the embodiments or flowcharts, but based on conventional or non-inventive methods, more or fewer operation steps may be included. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only possible execution order. In actual system or server product execution, the method can be executed sequentially according to the embodiments or drawings, or in parallel (e.g., in a parallel processor or multi-threaded processing environment). Specifically, as shown in the diagram... Figure 3As shown, the above method may include:

[0063] S101. Provide a Kubernetes cluster that contains at least one subnet.

[0064] A Kubernetes cluster may include at least one subnet, and in this embodiment of the disclosure, subsequent processing steps can be performed independently for each subnet.

[0065] The aforementioned Kubernetes cluster can be deployed in a cloud serverless environment, and the business container group in the status monitor of each virtual node is used to provide cloud serverless services.

[0066] S103. Deploy at least three copies of container groups containing virtual node status monitors in each subnet; at least one service container group is deployed in at least one subnet; the at least one service container group is monitored by at least one virtual node status monitor in the at least one subnet.

[0067] In this disclosure, each service container group can be independently monitored by any virtual node status monitor within the same subnet, and only by one virtual node monitor. For an example, please refer to... Figure 4 The diagram illustrates container deployment in subnet A. If subnet A has four virtual node status monitors (A0, A1, A2, A3) and two service container groups (BO and B1) exist within it, then service container group BO can be scheduled to any one of the four virtual node status monitors (A0, A1, A2, A3). If BO is scheduled to A0, it cannot be simultaneously scheduled to A1, A2, and A3. The scheduling of service container group B1 is independent of service container group B0; it can be independently scheduled to any one of the four virtual node status monitors (A0, A1, A2, A3). If B1 is scheduled to A2, it cannot be simultaneously scheduled to A0, A1, and A3.

[0068] At the beginning of the construction of subnet A, the four virtual node status monitors A0, A1, A2, and A3 may not have any service container groups deployed. As services are built, migrated, and expanded, the service container groups corresponding to the services can be scheduled to any virtual node status monitor in subnet A.

[0069] Please refer to Figure 5 It shows a schematic diagram of the Kubernetes architecture in a scenario. Figure 5The Kubernetes cluster consists of two subnets, ZoneA and ZoneB. ZoneA includes three virtual node status monitors, and ZoneB also includes three virtual node status monitors. The three virtual node status monitors in ZoneA are ZA-vk-0, ZA-vk-1, and ZA-vk-2, and those in ZoneB are ZB-vk-0, ZB-vk-1, and ZB-vk-2. ZoneB also deploys two service container groups, Service 3 and Service 4. Both of these service container groups are scheduled to the virtual node status monitor ZB-vk-0, meaning that virtual node status monitor ZB-vk-0 monitors Service 3 and Service 4.

[0070] In this disclosure, three copies of a container group containing a virtual node status monitor can be deployed in each subnet, or more copies of a container group containing a virtual node status monitor can be deployed as needed.

[0071] This disclosure uses a stateful service deployment pattern to deploy a copy of each container group containing a virtual node status monitor. The stateful service deployment pattern ensures that, in scenarios involving restarting or upgrading the virtual node status monitor within a subnet, the virtual node status monitor is restarted or upgraded sequentially.

[0072] Step S105. Expose the business container group in the at least one virtual node status monitor using a headless service.

[0073] This disclosure ensures the sequential consistency of restarting or upgrading virtual node status monitors in a subnet. Specifically, this disclosure details a method for restarting all virtual node status monitors in at least one subnet. The method for restarting all virtual node status monitors in at least one subnet includes sequentially restarting each virtual node status monitor in the at least one subnet. Please refer to [link to relevant documentation]. Figure 6 It illustrates a method for restarting the status monitor for each virtual node, the method including:

[0074] S201. If the restart time of the above virtual node status monitor is less than the container group eviction timeout time, then the above virtual node status monitor shall be restarted directly.

[0075] This disclosure uses a stateful service deployment mode to deploy the virtual node status monitor. This allows the virtual node status monitor to continue using the original network tags after restarting. If the restart time of the virtual node status monitor is less than the container group eviction timeout, there is no need to rebuild the business container group monitored by the virtual node status monitor; the virtual node status monitor can be restarted directly.

[0076] S203. If the restart time of the above-mentioned virtual node status monitor is greater than or equal to the above-mentioned container group eviction timeout time, then each service container group monitored by the above-mentioned virtual node status monitor shall be evictioned to another virtual node status monitor in at least one of the above-mentioned subnets that is different from the above-mentioned virtual node status monitor, and the above-mentioned virtual node status monitor shall be restarted.

[0077] by Figure 4 Taking virtual node status monitor A0 as an example, if A0 monitors service container group B0, and the restart time of A0 is 6 minutes, exceeding the preset container group eviction timeout of 5 minutes, then the eviction of service container group B0 will be triggered. Service container group B0 may be evicted to any one of the three virtual node status monitors A1, A2, and A3. If the restart time of A0 is 4 minutes, which has not exceeded the aforementioned container group eviction timeout, then A0 in the virtual node status monitor can be restarted directly.

[0078] Each subnet in this disclosure includes at least three virtual node status monitors, so that if one of them needs to be restarted, the other virtual node status monitors can still operate normally. Figure 4 Taking subnet A as an example, if virtual node status monitor A0 restarts, it cannot perform normal status monitoring during the restart. At this time, it is equivalent to a faulty node. Since there are four virtual node status monitors in subnet A, and A1, A2, and A3 are working normally, the faulty node ratio of subnet A is 25%, which does not reach the Kubernetes faulty node ratio threshold of 55%. Therefore, the execution of Kubernetes' second container group eviction policy will not be triggered, but the execution of the first container group eviction policy can be triggered. According to the first container group eviction policy, the business container groups corresponding to the virtual node status monitor that needs to be restarted can be evictioned to other virtual node status monitors in the same subnet. For example, the business container group B0 corresponding to A0 can be evictioned to any one of the three virtual node status monitors A1, A2, and A3, and then the virtual node status monitor that needs to be restarted can be restarted.

[0079] In one implementation, each service container group monitored by the aforementioned virtual node status monitor can be independently and randomly expelled to any other virtual node status monitor in at least one subnet that is different from the aforementioned virtual node status monitor.

[0080] In one implementation, for any one of the aforementioned virtual node status monitors, a target virtual node status monitor that receives the service container group can be determined. The target virtual node status monitor is another virtual node status monitor in the at least one subnet that is different from the aforementioned virtual node status monitor. Then, the aforementioned service container group is rebuilt and scheduled to the target virtual node status monitor, thereby achieving the eviction of the service container group.

[0081] For example, this disclosure uses Figure 5 Taking the restart of a subnet (ZoneB) in the Kubernetes architecture shown below as an example, the restart process is detailed as follows:

[0082] According to the order of the virtual node status monitors in the subnet ZoneB, ZB-vk-0 is restarted first. If the restart time of ZB-vk-0 is less than the container group eviction timeout, ZB-vk-0 is restarted directly. If the restart time of ZB-vk-0 is greater than or equal to the container group eviction timeout, the eviction of service container groups 3 and 4 monitored by ZB-vk-0 is triggered, and ZB-vk-0 is restarted after the eviction.

[0083] During the expulsion process, services 3 and 4 can be randomly expelled to ZB-vk-1 or ZB-vk-2 independently. If service 3 is expelled to ZB-vk-1, service 3 is rebuilt and scheduled to ZB-vk-1; if service 4 is expelled to ZB-vk-2, service 4 is rebuilt and scheduled to ZB-vk-2.

[0084] After ZB-vk-0 restarts, ZB-vk-1 and ZB-vk-2 can be restarted sequentially using the same logic.

[0085] Based on the same concept, any subnet ZoneM containing N (N>3) virtual node status monitors can be restarted. The N virtual node status monitors in ZoneM are restarted sequentially. For any virtual node monitor, if its restart time is less than the container group eviction timeout, it is restarted directly; otherwise, the service containers monitored by the virtual node monitor are evictioned to the other N-1 virtual node status monitors, and then the virtual node monitor is restarted.

[0086] Based on the same concept, this disclosure can also upgrade all virtual node status monitors in at least one subnet. The method for upgrading all virtual node status monitors in at least one subnet includes sequentially upgrading each virtual node status monitor in the at least one subnet. Please refer to [reference needed]. Figure 7It illustrates a method for upgrading the status monitor of each virtual node, the method including:

[0087] S301. If the restart time of the above virtual node status monitor is less than the container group eviction timeout time, then the above virtual node status monitor shall be upgraded directly.

[0088] S203. If the restart time of the above-mentioned virtual node status monitor is greater than or equal to the above-mentioned container group eviction timeout time, then each service container group monitored by the above-mentioned virtual node status monitor shall be evictioned to another virtual node status monitor in at least one of the above-mentioned subnets that is different from the above-mentioned virtual node status monitor, and the above-mentioned virtual node status monitor shall be upgraded.

[0089] The execution details of the method for upgrading all virtual node status monitors in at least one subnet in this disclosure are similar to the execution details of the method for restarting all virtual node status monitors in at least one subnet, and will not be repeated here.

[0090] For example, this disclosure describes the upgrade process in detail below, using the upgrade of a subnet (ZoneB) in a Kubernetes architecture as an example:

[0091] According to the order of the virtual node status monitors in the subnet ZoneB, ZB-vk-0 is upgraded first. If the restart time of ZB-vk-0 is less than the container group eviction timeout, ZB-vk-0 is upgraded directly. If the restart time of ZB-vk-0 is greater than or equal to the container group eviction timeout, the eviction of service container groups 3 and 4 monitored by ZB-vk-0 is triggered, and ZB-vk-0 is upgraded after the eviction.

[0092] During the expulsion process, services 3 and 4 can be randomly expelled to ZB-vk-1 or ZB-vk-2 independently. If service 3 is expelled to ZB-vk-1, service 3 is rebuilt and scheduled to ZB-vk-1; if service 4 is expelled to ZB-vk-2, service 4 is rebuilt and scheduled to ZB-vk-2.

[0093] After ZB-vk-0 is upgraded, ZB-vk-1 and ZB-vk-2 can be upgraded sequentially using the same logic.

[0094] This disclosure discloses a method for deploying a virtual node status monitor. By deploying a copy of each container group containing the virtual node status monitor using a stateful service deployment mode, the probability of eviction and reconstruction of the service container group monitored by the virtual node status monitor can be reduced when the virtual node status monitor is restarted or upgraded. Furthermore, since at least three virtual node status monitors are deployed in the subnet, the probability of executing a second container group eviction policy is reduced, as is the probability of service container group eviction failure. This ensures the robustness and success rate of virtual node status monitor restarts or upgrades in the subnet. The virtual node status monitor deployment method disclosed in this disclosure provides a high-availability solution for managing virtual node status monitors and also provides reliability guarantees for service container groups scheduled to the virtual node status monitors.

[0095] This disclosure also discloses a virtual node status monitoring processing device, such as... Figure 8 As shown, the above-mentioned device includes:

[0096] Subnet determination module 401 is used to provide a Kubernetes cluster that contains at least one subnet.

[0097] Deployment module 403 is used to deploy at least three copies of container groups containing virtual node status monitors in each subnet; wherein at least one service container group is deployed in at least one subnet; the at least one service container group is monitored by at least one virtual node status monitor in the at least one subnet.

[0098] Headless service module 405 is used to expose the business container group in at least one of the virtual node status monitors using headless service.

[0099] Specifically, the virtual node status monitoring processing device disclosed in this disclosure and the corresponding method embodiment described above are both based on the same inventive concept. For details, please refer to the method embodiment; further elaboration will not be repeated here.

[0100] This disclosure also provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the aforementioned virtual node status monitor deployment method.

[0101] This disclosure also provides a computer-readable storage medium that can store multiple instructions. These instructions are adaptable for a processor to load and execute the virtual node status monitor deployment method described in this disclosure.

[0102] Furthermore, Figure 9 A schematic diagram of a hardware structure for implementing the methods provided in the embodiments of this disclosure is shown. This device may constitute or include the apparatus or system provided in the embodiments of this disclosure. Figure 9 As shown, device 10 may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. 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 power supply, and / or a camera. Those skilled in the art will understand that... Figure 9 The structure shown is for illustrative purposes only and does not limit the structure of the electronic device described above. For example, device 10 may also include a... Figure 9 The more or fewer components shown, or having the same Figure 9 The different configurations shown.

[0103] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuitry are generally referred to herein as "data processing circuitry". This data processing circuitry may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuitry may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within device 10 (or mobile device). As involved in embodiments of this disclosure, the data processing circuitry serves as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0104] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the method described in the embodiments of this disclosure. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the above-described method for deploying a virtual node status monitor. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the device 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0105] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of device 10. In one example, the transmission device 106 includes a network interface controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a radio frequency (RF) module, used for wireless communication with the Internet.

[0106] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of device 10 (or mobile device).

[0107] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, specific embodiments of this disclosure have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired results. Additionally, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired results. In some implementations, multitasking and parallel processing are also possible or may be advantageous.

[0108] The various embodiments in this disclosure are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device and server embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0109] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0110] The above are merely preferred embodiments of this disclosure and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for deploying a virtual node status monitor, characterized in that, The method includes: Provide a Kubernetes cluster that contains at least one subnet; Deploy at least three copies of container groups containing virtual node status monitors in each subnet; deploy at least one service container group in at least one subnet; the at least one service container group is monitored by at least one virtual node status monitor in the at least one subnet; each service container group is independently monitored by any one virtual node status monitor in the same subnet, and is monitored by only one virtual node monitor. The business container group in the at least one virtual node status monitor is exposed using a headless service.

2. The method according to claim 1, characterized in that, The deployment of at least three replicas of container groups containing virtual node status monitors in each subnet includes: In each subnet, three copies of a container group containing a virtual node status monitor are deployed.

3. The method according to claim 1 or 2, characterized in that, The deployment of at least three replicas of container groups containing virtual node status monitors in each subnet includes: Deploy a copy of each container group containing a virtual node state monitor using a stateful service deployment pattern.

4. The method according to claim 3, characterized in that, It also includes the step of restarting all virtual node status monitors in at least one subnet, wherein restarting all virtual node status monitors in at least one subnet includes: The status monitors of each virtual node in the at least one subnet are restarted sequentially. When restarting each virtual node status monitor, the following steps are performed: If the restart time of the virtual node status monitor is less than the container group eviction timeout, then the virtual node status monitor will be restarted directly. If the restart time of the virtual node status monitor is greater than or equal to the container group eviction timeout time, then each service container group monitored by the virtual node status monitor will be evictioned to another virtual node status monitor in the at least one subnet that is different from the virtual node status monitor, and the virtual node status monitor will be restarted.

5. The method according to claim 3, characterized in that, It also includes the step of upgrading all virtual node status monitors in at least one subnet, wherein upgrading all virtual node status monitors in at least one subnet includes: The status monitors of each virtual node in the at least one subnet are upgraded sequentially. When upgrading each virtual node status monitor, the following steps are performed: If the restart time of the virtual node status monitor is less than the container group eviction timeout, then the virtual node status monitor will be upgraded directly. If the restart time of the virtual node status monitor is greater than or equal to the container group eviction timeout time, then each service container group monitored by the virtual node status monitor will be evictioned to another virtual node status monitor in the at least one subnet that is different from the virtual node status monitor, and the virtual node status monitor will be upgraded.

6. The method according to claim 4 or 5, characterized in that, The step of relocating the various service container groups monitored by the virtual node status monitor to other virtual node status monitors in the at least one subnet that are different from the virtual node status monitor includes: Each service container group monitored by the virtual node status monitor is independently and randomly expelled to any other virtual node status monitor in the at least one subnet that is different from the virtual node status monitor.

7. The method according to claim 4 or 5, characterized in that, The step of relocating the various service container groups monitored by the virtual node status monitor to other virtual node status monitors in the at least one subnet that are different from the virtual node status monitor includes: For any service container group in the virtual node status monitor, determine the target virtual node status monitor that receives the service container group, and the target virtual node status monitor is another virtual node status monitor in the at least one subnet that is different from the virtual node status monitor. Rebuild any one of the service container groups and schedule the any one of the service container groups to the target virtual node status monitor.

8. The method according to claim 1, characterized in that, The Kubernetes cluster is deployed in a cloud serverless environment, and the business container group in each virtual node status monitor is used to provide cloud serverless services.

9. A virtual node status monitoring processing device, characterized in that, The device includes: The subnet determination module is used to provide a Kubernetes cluster that contains at least one subnet. A deployment module is used to deploy at least three copies of container groups containing virtual node status monitors in each subnet; wherein at least one service container group is deployed in at least one subnet; the at least one service container group is monitored by at least one virtual node status monitor in the at least one subnet; each service container group is independently monitored by any one virtual node status monitor in the same subnet, and is monitored by only one virtual node monitor. A headless service module is used to expose the business container group in the at least one virtual node status monitor using a headless service.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one instruction, which is loaded and executed by a processor to implement a virtual node status monitor deployment method as described in any one of claims 1 to 8.

11. A virtual node status monitoring and processing device, characterized in that, The system includes at least one processor and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that are executed by the at least one processor, and the at least one processor implements a virtual node status monitor deployment method as described in any one of claims 1 to 8 by executing the instructions stored in the memory.

12. A computer program product comprising computer instructions stored in a computer-readable storage medium, wherein a processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions to cause the computer device to perform a virtual node status monitor deployment method as described in any one of claims 1 to 8.

Images