A method and related apparatus for managing containers.

Abstract

This application provides a container management method and related apparatus, relating to the field of cloud computing. The method is applied to worker nodes in a Kubernetes cluster, where multiple containers are deployed. The method includes: determining a first set of containers whose services have been successfully activated, the first set including one or more containers; and, if the first set and a second set are inconsistent, sending an instruction to a load balancer to instruct the load balancer to update the containers in the second set, the second set including one or more containers recorded in the load balancer for providing services to the outside world by the worker node. This method ensures that the container readiness status is consistent with the container status providing services to the outside world in the load balancer, avoiding the problem of external traffic entering some business containers that are not yet ready, resulting in access errors and improving user experience.

Description

Technical Field

[0001] This application relates to cloud computing technology, and more particularly to a container management method and related apparatus. Background Technology

[0002] Kubernetes (K8S) cluster is an open-source container orchestration system that provides functions such as application deployment, maintenance, and scaling mechanisms. K8S can utilize the cluster to run various container-based applications.

[0003] Starting a business container in a Kubernetes cluster typically requires a certain amount of time for service startup, database connection, and external service preparation. In some cases, the container's readiness status may differ from its service provision status, causing external traffic to enter some containers that are not yet ready, resulting in access errors and a poor user experience. Summary of the Invention

[0004] This application provides a container management method and related apparatus to solve the problem that external traffic enters some containers that are not yet ready, resulting in access errors and a poor user experience.

[0005] Firstly, this application provides a container management method, which can be executed by worker nodes in a Kubernetes cluster. Multiple containers are deployed on each worker node. Exemplarily, the method includes: determining a first set of containers from the plurality of containers whose services have been successfully activated, the first set of containers comprising one or more containers; and, if the first set of containers is inconsistent with a second set of containers, sending an indication message to a load balancer to instruct the load balancer to update the containers in the second set of containers, the second set of containers including one or more containers recorded in the load balancer for providing services externally by the worker node.

[0006] Based on the above technical solution, the worker node compares the first set of containers in which services have been successfully activated with the second set of containers recorded in the load balancer for providing services to the outside world. If the two are inconsistent, the worker node sends an instruction to the load balancer to instruct the load balancer to update the containers in the second set of containers. This ensures that the container readiness status is consistent with the container status in the load balancer that is providing services to the outside world, preventing external traffic from entering some business containers that are not yet ready and returning errors. This achieves high availability from a global perspective and improves the user experience.

[0007] In conjunction with the first aspect, in one possible implementation of the first aspect, when the number of containers in the first container set is less than the number of containers in the second container set, the indication information is used to indicate which containers in the second container set need to be deleted, and the containers to be deleted include containers in the second container set other than those in the first container set; when the number of containers in the first container set is greater than the number of containers in the second container set, the indication information is used to indicate which containers in the second container set need to be added, and the containers to be added include containers in the first container set other than those in the second container set.

[0008] In conjunction with the first aspect, in one possible implementation of the first aspect, determining the first set of containers in which services have been successfully probed includes: performing service probes on each of the multiple containers through the kubelet component in the worker node to obtain the first set of containers, wherein the service probes on each container are implemented based on a predefined probe script.

[0009] In conjunction with the first aspect, in one possible implementation of the first aspect, the predefined probe script includes a service probe count threshold and a service probe interface, wherein the service probe count threshold is used to limit the number of times a service probe fails for each container.

[0010] In conjunction with the first aspect, in one possible implementation of the first aspect, the method further includes: creating a service liveness detection file, the service liveness detection file being used to store the service liveness detection status of each of the plurality of containers, the service liveness detection status including: service liveness detection successful or service liveness detection failed.

[0011] In conjunction with the first aspect, in one possible implementation of the first aspect, the method further includes: updating the service activation status file after each service activation test.

[0012] In conjunction with the first aspect, in one possible implementation of the first aspect, the method further includes: determining the containers that have successfully been activated among the plurality of containers based on the first service activation of each container among the plurality of containers; registering the containers that have successfully been activated to the load balancer to obtain the second container set.

[0013] In conjunction with the first aspect, in one possible implementation of the first aspect, registering the container that has successfully activated the service to the load balancer includes: sending container information of the container that has successfully activated the service to the load balancer, the container information including an Internet Protocol (IP) address and / or port.

[0014] In conjunction with the first aspect, in one possible implementation of the first aspect, determining the first set of containers in which services have been successfully detected and activated among the plurality of containers includes: periodically determining the first set of containers in which services have been successfully detected and activated among the plurality of containers; and sending an indication message to the load balancer to instruct the load balancer to update the containers in the second set of containers when the first set of containers is inconsistent with the second set of containers includes: sending an indication message to the load balancer to instruct the load balancer to update the containers in the second set of containers when the most recently determined first set of containers is inconsistent with the second set of containers.

[0015] Secondly, this application provides a container management device, including: a determining unit and a transceiver unit. The determining unit is used to determine a first set of containers from a plurality of containers whose services have been successfully activated, the first set of containers including one or more containers; the transceiver unit is used to send indication information to a load balancer when the first set of containers is inconsistent with a second set of containers, to instruct the load balancer to update the containers in the second set of containers, the second set of containers including one or more containers recorded in the load balancer for providing services to the outside world by worker nodes.

[0016] Thirdly, this application provides a container management apparatus including a processor. The processor is coupled to a memory and can be used to execute a computer program in the memory to implement the methods described in the first aspect and any possible implementation thereof.

[0017] Optionally, the apparatus in the third aspect also includes a memory.

[0018] Optionally, the apparatus in the third aspect also includes a communication interface, to which the processor is coupled.

[0019] Fourthly, this application provides a chip system including at least one processor for supporting the implementation of the functions involved in the first aspect and any possible implementation of the first aspect, such as receiving or processing data involved in the above methods.

[0020] In one possible design, the chip system also includes a memory for storing program instructions and data, which may be located within or outside the processor.

[0021] The chip system can consist of chips or include chips and other discrete components.

[0022] Fifthly, this application provides a computer-readable storage medium storing a computer program (also referred to as code or instructions) that, when executed by a processor, causes the methods in the first aspect and any possible implementation thereof to be performed.

[0023] Sixthly, this application provides a computer program product comprising: a computer program (also referred to as code or instructions) that, when executed, causes the methods in the first aspect and any possible implementation thereof to be performed.

[0024] It should be understood that the second to sixth aspects of this application correspond to the technical solutions of the first aspect of this application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation are similar, and will not be repeated here.

[0025] It should also be understood that the container management method and related apparatus provided in this application can be applied to the field of cloud computing, as well as other fields. This application does not limit them in this regard. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of the system architecture applicable to the methods provided in the embodiments of this application;

[0027] Figure 2 This is a schematic flowchart of a container management method provided in an embodiment of this application;

[0028] Figure 3 This is a schematic diagram of the synchronization of the first container set and the second container set provided in an embodiment of this application;

[0029] Figure 4 This is a schematic diagram of the process for probing services to a container provided in an embodiment of this application;

[0030] Figure 5 This is a schematic block diagram of a container management device provided in an embodiment of this application;

[0031] Figure 6 This is another schematic block diagram of the container management device provided in the embodiments of this application. Detailed Implementation

[0032] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0033] The following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0034] Before introducing the embodiments of this application, the terminology involved in this application will be briefly explained.

[0035] 1. Kubernetes (K8S) cluster: A Kubernetes cluster is an open-source container orchestration system that provides application deployment, maintenance, and scaling mechanisms. K8S can run various container-based applications using a cluster. Typically, nodes within a K8S cluster can be divided into master nodes and worker nodes. The method provided in this application can be applied to K8S clusters.

[0036] 2. Master: This is the control node of the K8S cluster, responsible for the management and control of the entire K8S cluster.

[0037] 3. Worker Nodes: Workload nodes in a Kubernetes cluster, also known as node load balancing nodes, can be understood as virtual machines on the Kubernetes platform. Nodes can receive tasks assigned by the master.

[0038] 4. Kubernetes Proxy (kubelet): This is a component included in the worker nodes and is the core component responsible for the actual operation of containers. It is mainly responsible for the full lifecycle management of Pods on the worker nodes, including creation, modification, monitoring, and deletion.

[0039] 5. Etcd: A storage node in the Kubernetes cluster, a daemon process used to store application configuration information, Kubernetes cluster status information, and Pod information. In this embodiment, Etcd can be viewed as the database of the load balancer, used to store information related to container registration.

[0040] 6. Pod: A key concept in Kubernetes (K8S), it is a collection of application containers (hereinafter referred to as containers). Packaging multiple containers into a Pod forms the most basic unit of work and the smallest unit of K8S governance.

[0041] 7. Containers: A container is a lightweight, operating system-level virtual machine technology that allows us to run applications and other dependencies in a resource-isolated manner. All the necessary components for running an application are contained in a single, reusable image. When the image runs, it operates in an isolated environment and does not share the host operating system's memory, central processing unit (CPU), or disk with other applications.

[0042] To facilitate understanding of the container management method provided in the embodiments of this application, the system architecture applicable to the embodiments of this application will be described below. It is understood that the system architecture described in the embodiments of this application is for the purpose of more clearly illustrating the technical solutions of the embodiments of this application and does not constitute a limitation on the technical solutions provided in the embodiments of this application.

[0043] Figure 1 This is a schematic diagram of the system architecture applicable to the methods provided in the embodiments of this application. For example... Figure 1 As shown, the system architecture includes Etcd 110, master node 120, worker nodes 130, 140, and 150. Etcd 110 can be viewed as the database of the load balancer, used to store information related to container registration. Master node 120 can control and manage multiple worker nodes, such as worker nodes 130 to 150 in the figure. Each worker node deploys one or more Pods, and each Pod includes one or more containers. For example, worker node 130 includes three Pods: Pod 1, Pod 2, and Pod 3.

[0044] It should be understood that master node 120 can correspond to a physical machine or a virtual machine, and worker nodes 130 to 150 can correspond to virtual machines.

[0045] It should also be understood that Figure 1 For illustrative purposes only, this application does not limit the number of master nodes or the number of worker nodes connected to each master node. For example, Figure 1 The system architecture shown can also include more master nodes, each master node can connect to more or fewer worker nodes, and each worker node can include more or fewer Pods.

[0046] Containers in a Kubernetes cluster typically require a certain amount of time to start up services, connect to the database, and prepare external services. Once a container is ready, its services need to be exposed to an external load balancer, meaning it can provide services to the outside world. However, in some cases, the container's readiness and its service provision status may differ, causing external traffic to flow into containers that are not yet ready, resulting in access errors and a poor user experience.

[0047] To address the aforementioned issues, this application provides a container management method. Worker nodes compare a first set of containers whose services have been successfully activated within their deployed containers with a second set of containers stored in a load balancer for external service provision. If the two sets are inconsistent, the worker node sends an instruction to the load balancer to update the containers in the second set. This ensures that the container readiness status matches the status of containers providing external services in the load balancer, preventing external traffic from entering unprepared service containers and returning errors.

[0048] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0049] Figure 2 This is a schematic flowchart of the container management method 200 provided in the embodiments of this application. Figure 2 The container management method 200 shown may include steps 210 and 220. The individual steps in method 200 are described in detail below.

[0050] It should be understood that Figure 2 The method 200 shown uses a worker node as the execution subject, but this should not impose any limitation on the execution subject of the method. The method provided in this application can be executed as long as a program containing the code of the method provided in the embodiments of this application is run.

[0051] Figure 2 The method 200 shown can be applied to worker nodes in a Kubernetes cluster, on which multiple containers are deployed. It should be understood that a Kubernetes cluster may include one or more worker nodes, and the worker node can be any one of those worker nodes.

[0052] In step 210, a first set of containers in which the service was successfully detected is determined, the first set of containers including one or more containers.

[0053] Multiple containers are deployed on the worker node. For each container, the service provided by that container is considered available only if the service is successfully tested and confirmed to be active. The first set of containers includes one or more containers whose services have been successfully tested and confirmed to be active.

[0054] For example, worker nodes perform service activation on containers to identify containers that have successfully activated their services, and these containers are designated as the first container set. For instance, the multiple containers include container 1, container 2, container 3, and container 4. If service activation is successful for container 1 and container 2, then the first container set includes container 1 and container 2.

[0055] Optionally, determining the first set of containers from multiple containers that have successfully been tested for service activation includes: performing service activation on each of the multiple containers using the kubelet component to obtain the first set of containers, wherein the service activation for each container is implemented based on a predefined detection script.

[0056] In other words, for each of the multiple containers, the worker node can perform service liveness testing on it based on a predefined probe script to obtain the service liveness testing result, that is, whether the service liveness testing is successful or unsuccessful. Based on the service liveness testing result of each container, the first set of containers is determined, that is, the set of containers whose service liveness testing is successful.

[0057] One possible implementation is that worker nodes use the kubelet component to perform service liveness detection on each container. Specifically, the kubelet component executes a predefined detection script to complete the service liveness detection for each container by the worker nodes and obtain the service liveness detection results so that the worker nodes can determine the set of containers that have successfully performed service liveness detection, i.e., the first set of containers.

[0058] Optionally, the predefined detection script includes a service probe count threshold and a service probe interface. The service probe count threshold is used to limit the number of times a service probe fails for each container.

[0059] The service activation threshold limits the number of times a container can attempt service activation after a failed activation. In other words, worker nodes cannot attempt service activation on containers an unlimited number of times. For example, if the service activation threshold is 3, and a worker node fails its first service activation attempt on a container, it can still attempt service activation on the container a maximum of 2 more times.

[0060] The predefined detection scripts include service activation interfaces, which allow worker nodes to call these interfaces via the kubelet component to perform service activation on containers.

[0061] In step 220, if the first container set and the second container set are inconsistent, an indication message is sent to the load balancer to instruct the load balancer to update the containers in the second container set, which includes one or more containers recorded in the load balancer for worker nodes to provide services to the outside world.

[0062] The second container set is a collection of containers in the load balancer used by worker nodes to provide services externally. A discrepancy between the first and second container sets indicates a mismatch between the readiness status of multiple containers on a worker node and their actual service provision status. For example, if nine containers on a worker node are ready, but the load balancer has ten containers used by the worker node to provide services externally, this means one of those ten containers is not ready. In this case, external traffic can easily flow into the unready container. Therefore, when the first and second container sets are inconsistent, the worker node sends an instruction to the load balancer to instruct it to update the containers in the second container set, i.e., update the set of containers providing external services.

[0063] One possible implementation is that the worker node compares the ports of the containers in the first container set with the ports of the containers in the second container set recorded in the load balancer to determine whether the first container set and the second container set are consistent. If they are inconsistent, the worker node sends an indication message to the load balancer to instruct the load balancer to update the second container set.

[0064] The inconsistency between the first container set and the second container set includes the following two situations:

[0065] One possibility is that the number of containers in the first container set is less than the number of containers in the second container set. The indication information is used to indicate which containers in the second container set need to be deleted. The containers to be deleted include those in the second container set other than those in the first container set.

[0066] For example, the first container set includes container 1, container 2, container 3 and container 4, and the second container set includes container 1, container 2, container 3, container 4 and container 5. If the number of containers in the first container set is less than the number of containers in the second container set, then the worker node sends an indication message to the load balancer. This indication message is used to indicate that the container information (such as the port) corresponding to container 5 needs to be deleted.

[0067] Another possible scenario is that the number of containers in the first container set is greater than the number of containers in the second container set. In this case, the worker node sends an indication message to the load balancer, which indicates which containers need to be added to the second container set. The containers that need to be added include those in the first container set other than those in the second container set.

[0068] For example, the first container set includes container 1, container 2, container 3 and container 4, and the second container set includes container 1, container 2 and container 3. If the number of containers in the first container set is greater than the number of containers in the second container set, then the worker node sends an indication message to the load balancer. This indication message is used to indicate the container information (such as port) corresponding to the container 4 that needs to be added.

[0069] It's understandable that worker nodes can also directly report the first container set to the load balancer, allowing the load balancer to update the second container set. For example, the load balancer can compare the second and first container sets; if the number of containers in the first set is greater than the number of containers in the second set, it adds containers to the second set; if the number of containers in the first set is less than the number of containers in the second set, it deletes all containers in the second set except those in the first set. Alternatively, the load balancer can directly replace the second container set with the first set.

[0070] Optionally, determining a first set of containers in multiple containers where services have been successfully detected includes: periodically determining a first set of containers in multiple containers where services have been successfully detected; and in the event that the first set of containers is inconsistent with a second set of containers, sending an indication message to the load balancer to instruct the load balancer to update the containers in the second set of containers includes: in the event that the most recently determined first set of containers and the second set of containers are inconsistent, sending an indication message to the load balancer to instruct the load balancer to update the containers in the second set of containers.

[0071] It is understandable that the first set of containers may change. For example, the first set of containers may include container 1, container 2, and container 3. After a period of time, container 3 may become unable to provide services for some reason, meaning its service becomes unavailable. In this case, the first set of containers may then include container 1 and container 2, but not container 3. As another example, the first set of containers may include container 1, container 2, and container 3. After a period of time, the service of container 4 may become available. In this case, the first set of containers may then include container 1, container 2, container 3, and container 4.

[0072] Worker nodes periodically determine a first set of containers, and then check whether the most recently determined first set of containers matches a second set of containers. In other words, worker nodes periodically check whether their own ready containers match the containers in the second set of containers. For example, every 30 seconds, they check whether their own ready containers match the second set of containers. Specifically, every 30 seconds, a worker node determines the first set of containers, i.e., the set of currently ready containers. If the most recently determined first set of containers and the second set of containers do not match, the worker node sends an indication message to the load balancer to instruct the load balancer to update the second set of containers. It should be understood that the updated second set of containers is also the most recently updated second set of containers.

[0073] Optionally, Figure 2 The method 200 further includes: determining the containers that have successfully been activated among the multiple containers based on the first service activation of each container in the multiple containers; registering the containers that have successfully been activated to the load balancer to obtain a second container set.

[0074] After multiple containers are created, worker nodes perform service activation on them for the first time. For containers that are successfully activated, worker nodes register them directly with the load balancer, thereby obtaining a second set of containers. That is, the containers recorded in the load balancer are the containers that can be used by worker nodes to provide services to the outside world.

[0075] Optionally, registering containers that have successfully been identified as active to the load balancer includes sending container information of the containers that have successfully been identified as active to the load balancer, the container information including IP address and / or port.

[0076] One possible implementation is that worker nodes directly send the container information of containers that have successfully been activated to the load balancer for external service provision. Compared to the service collecting container information of ready containers from each worker node and then exposing it to the load balancer in a cluster, this significantly shortens the service exposure time, i.e., the time to provide services externally, improving service exposure efficiency, preventing service interruptions, and thus enhancing user experience.

[0077] Optionally, the above method further includes: creating a service liveness detection state file, which is used to store the service liveness detection state of each container in multiple containers, including: service liveness detection successful or service liveness detection failed.

[0078] Worker nodes can create service liveness detection status files to record the service liveness detection status of each container. In other words, worker nodes can determine the service liveness detection status of a container, i.e., whether the service liveness detection was successful, by querying this file.

[0079] Optionally, the above method further includes updating the service activation status file after each service activation test.

[0080] Each time a worker node performs a service liveness test, it updates the service liveness test status file so that the service liveness test status of a container obtained by the worker node based on the service liveness test status file is the latest service liveness test status of that container.

[0081] In this embodiment, if a worker node successfully probes a container for service activation, it can stop probing that container, thus reducing the worker node's power consumption. It should be noted that in the above scenario, the number of containers in the second container set recorded in the load balancer is inconsistent with the number of containers in the first container set. The only possible scenario is that the number of containers in the first container set is greater than the number of containers in the second container set. It can be understood that since service activation is not continued after a container is successfully probed, a situation where a container's first service activation is successful but subsequent activations fail will not occur. That is, the number of containers in the first container set will not be less than the number of containers in the second container set.

[0082] Figure 3 This is a schematic diagram illustrating the synchronization of the first container set and the second container set provided in an embodiment of this application. For example... Figure 3 As shown, each worker node deploys a containerized container reconciliation service (i.e., housekeeping as shown in the diagram). Each worker node includes one or more Pods. For containers whose services have been successfully tested and activated, their container information can be recorded in Etcd (i.e., the database corresponding to the load balancer), that is, the containers whose services have been successfully tested and activated are registered with the load balancer. First, the worker node identifies the containers whose services have been successfully tested and activated. Specifically, it loads the cluster certificate into the "configmap" configuration item. After the container starts, the "configmap" is resolved to a directory of the container, so that the Kubernetes cluster can be accessed through the cluster certificate. Based on the above cluster certificate, the kubelet component is called to obtain the container information of the ready containers. Second, every 30 seconds, the worker node compares the container information of the containers in Etcd with the container information of the containers whose services have been successfully tested and activated. If they are inconsistent, an indication message is sent to the load balancer to instruct the load balancer to update the container information of the containers in Etcd.

[0083] The process of service exploration for containers will be described in detail below.

[0084] It should be noted that Kubernetes health checks are implemented in two ways: liveness and readiness, which respectively represent whether the container is running normally and whether the service is available.

[0085] `liveness`: Indicates whether the container is running. Its function is to periodically check the service after the container starts normally; if a service interruption occurs, the container is killed and restarted. The detection logic is that if the `liveness` detection fails, the kubelet component will kill the container and trigger a reset strategy. By default, if not set, this status is `success`.

[0086] Readiness: Indicates whether the container can accept service requests. Its function is to periodically check the service before the container starts normally. If it is normal, the container's state is changed to ready, exposing the service. The detection logic is the same as the liveness parameter configuration; the default is fail before initializing the delayed detection period. If readiness detection is not set, the state is success. When the readiness detection succeeds, at the runtime level, the container's state changes from created to ready. It includes three main parameters: delayed detection, check period, and number of consecutive failures.

[0087] In this embodiment of the application, a liveness probe is used as a health check, that is, to detect the service activity of the container.

[0088] Figure 4 This is a schematic diagram of the process for service activation of a container provided in an embodiment of this application. The following will combine... Figure 4 This section describes in detail the process of using a liveness probe to perform service liveness detection on a container. Figure 4 In the process shown, the actions performed by the worker nodes can be specifically executed by the kubelet component.

[0089] like Figure 4 As shown, the container states include standby, pulled, and created. After the container is created, the kubelet component in the worker node executes the " / lifecycle / readiness_probe.sh" script built into the image. This script includes a service liveness probe threshold (e.g., a threshold of 3) and the service liveness probe interface. The specific process is as follows:

[0090] Step 1: First, check if the value in the service liveness detection status file is 1, that is, whether 'a' in the diagram equals 1. If a = 1, it means that the service liveness detection has been successful, and no further detection will be performed, i.e., return to the end; if a ≠ 1, proceed to Step 2.

[0091] Step 2: Determine if the number of service activation failures is less than or equal to 3. If not, end the process; if yes, proceed to Step 3.

[0092] Step 3: Call the health check interface (“APP_HEALTH_CHECK” interface).

[0093] Step 4: Determine if an OK response is received. If yes, set the container status to ready; otherwise, continue waiting for 60 seconds. After 60 seconds, return to Step 2, which checks if the number of service liveness detection failures is less than or equal to 3.

[0094] Table 1 shows the similarities and differences between the service activation service provided in this application embodiment and the native liveness probe service activation service. Table 1 compares them from the perspectives of image dependency, failure actions, parameter configuration, and triggering methods.

[0095] Table 1

[0096]

[0097] As shown in Table 1, the service liveness probe provided in this embodiment relies on a predefined probe script. The failure action is a container not-ready restart, meaning the container restarts after a service liveness probe fails. The parameter configuration does not require separate configuration, and the triggering method is periodic liveness probes by the kubelet component. Furthermore, the service liveness probe status is updated upon successful liveness probes, and containers that have successfully completed liveness probes will not be re-registered with the load balancer. The native liveness probe service liveness probe does not rely on a predefined probe script. The failure action is a container not-ready restart, meaning the container restarts after a service liveness probe fails. The parameter configuration requires separate configuration, such as the service liveness probe method, service liveness probe interface, and service liveness probe cycle. The triggering method is periodic liveness probes by the kubelet component.

[0098] Based on the above technical solution, the worker node compares the first set of containers in which services have been successfully activated with the second set of containers recorded in the load balancer for providing services to the outside world. If the two are inconsistent, the worker node sends an instruction to the load balancer to instruct the load balancer to update the containers in the second set of containers. This ensures that the container readiness status is consistent with the container status in the load balancer that is providing services to the outside world, preventing external traffic from entering some business containers that are not yet ready and returning errors. This achieves high availability from a global perspective and improves the user experience.

[0099] Figure 5 This is a schematic block diagram of a container management device provided in an embodiment of this application.

[0100] like Figure 5 As shown, the device 500 may include a determining unit 510 and a transceiver unit 520. The device 500 can be used to implement... Figure 2 or Figure 4 The method described in the illustrated embodiment.

[0101] For example, when the device 500 is used to implement Figure 2 When the method is described in the illustrated embodiment, the determining unit 510 can be used to determine a first set of containers in which services have been successfully activated among multiple containers. The first set of containers includes one or more containers. The transceiver unit 520 can be used to send indication information to the load balancer when the first set of containers is inconsistent with the second set of containers, so as to instruct the load balancer to update the containers in the second set of containers. The second set of containers includes one or more containers recorded in the load balancer for providing services to the outside world by the worker nodes.

[0102] Optionally, if the number of containers in the first container set is less than the number of containers in the second container set, the indication information is used to indicate which containers in the second container set need to be deleted, and the containers to be deleted include containers in the second container set other than those in the first container set; if the number of containers in the first container set is greater than the number of containers in the second container set, the indication information is used to indicate which containers in the second container set need to be added, and the containers to be added include containers in the first container set other than those in the second container set.

[0103] Optionally, the determining unit 510 is specifically used to perform service activation testing on each of the plurality of containers through the kubelet component to obtain a first container set, wherein the service activation testing of each container is implemented based on a predefined detection script.

[0104] Optionally, the predefined detection script includes a service activation threshold and a service activation interface. The service activation threshold is used to limit the number of times a service activation attempt is made again after each container service activation attempt fails.

[0105] Optionally, the device 500 further includes a creation unit 530, which is used to create a service activation status file. The service activation status file is used to store the service activation status of each of the plurality of containers, and the service activation status includes: service activation successful or service activation failed.

[0106] Optionally, the determining unit 510 is further configured to update the service activation status file after each service activation.

[0107] Optionally, the determining unit 510 is further configured to determine the containers that have successfully been activated among the plurality of containers based on the first service activation of each of the plurality of containers; the device 500 further includes a registration unit 540, which is configured to register the containers that have successfully been activated to the load balancer to obtain the second container set.

[0108] Optionally, the registration unit 540 is specifically used to send container information of containers that have successfully activated their services to the load balancer, the container information including IP address and / or port.

[0109] Optionally, the determining unit 510 is specifically used to periodically determine the first set of containers in the plurality of containers whose services have been successfully activated; the transceiver unit 520 is specifically used to send an indication message to the load balancer in the case that the most recently determined first set of containers and the second set of containers are inconsistent, so as to instruct the load balancer to update the containers in the second set of containers.

[0110] It should be understood that the division of units in the embodiments of this application is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods. Furthermore, the functional units in the various embodiments of this application can be integrated into a single processor, exist as separate physical units, or be integrated into one unit by two or more units. The integrated units described above can be implemented in hardware or as software functional modules.

[0111] Figure 6 This is another schematic block diagram of the application system splitting device provided in the embodiments of this application.

[0112] The device 600 can be used to achieve the above. Figure 2 or Figure 4 The method described in the illustrated embodiment. The device 600 can be a chip system. In this embodiment, the chip system can be composed of chips, or it can include chips and other discrete devices.

[0113] like Figure 6 As shown, the device 600 may include at least one processor 610.

[0114] For example, processor 610 can be used to determine a first set of containers from the plurality of containers where service activation has been successfully achieved, the first set of containers including one or more containers; if the first set of containers is inconsistent with a second set of containers, an indication message is sent to the load balancer to instruct the load balancer to update the containers in the second set of containers, the second set of containers including one or more containers recorded in the load balancer for providing services to the outside world by the worker node. See the detailed description in the method example for further details, which will not be repeated here.

[0115] The device 600 may further include at least one memory 620, which can be used to store program instructions and / or data. The memory 620 is coupled to the processor 610. The coupling in this embodiment is an indirect coupling or communication connection between devices, units, or modules, and can be electrical, mechanical, or other forms, used for information exchange between devices, units, or modules. The processor 610 may operate in conjunction with the memory 620. The processor 610 may execute program instructions stored in the memory 620. At least one of the at least one memory may be included in the processor.

[0116] The device 600 may further include a communication interface 630 for communicating with other devices via a transmission medium, thereby enabling the device 600 to communicate with other devices. The communication interface 630 may be, for example, a transceiver, interface, bus, circuit, or a device capable of transmitting and receiving functions. The processor 610 may utilize the communication interface 630 to transmit and receive data and / or information, and to implement... Figure 2 or Figure 4 The method described in the illustrated embodiment.

[0117] This application embodiment does not limit the specific connection medium between the processor 610, memory 620, and communication interface 630. This application embodiment... Figure 6 The processor 610, memory 620, and communication interface 630 are connected via bus 640. Bus 640 is... Figure 6 The connections between other components are shown in bold and are for illustrative purposes only, not as limiting information. The bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, Figure 6 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0118] This application also provides a chip system, the chip system including at least one processor for implementing the above. Figure 2 and / or Figure 4 The method described in the illustrated embodiment.

[0119] In one possible design, the chip system also includes a memory for storing program instructions and data, which may be located within or outside the processor.

[0120] The chip system can consist of chips or include chips and other discrete components.

[0121] This application also provides a computer program product, the computer program product comprising: a computer program (also referred to as code or instructions), which, when run, causes a computer to perform the following actions: Figure 2 and / or Figure 4 The method described in the illustrated embodiment.

[0122] This application also provides a computer-readable storage medium storing a computer program (also referred to as code or instructions). When the computer program is executed, it causes the computer to perform actions such as... Figure 2 and / or Figure 4 The method described in the illustrated embodiment.

[0123] It should be noted that the container management method and related apparatus provided in the embodiments of this application can be applied to the field of cloud computing, or to any field other than cloud computing, and this application does not limit them.

[0124] It should be understood that the processor in the embodiments of this application can be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method embodiments can be completed by the integrated logic circuitry in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above method.

[0125] It should also be understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0126] The terms “unit”, “module”, etc., used in this specification may be used to refer to computer-related entities, hardware, firmware, combinations of hardware and software, software, or software in execution.

[0127] Those skilled in the art will recognize that the various illustrative logical blocks and steps described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application. In the several embodiments provided in this application, it should be understood that the disclosed apparatus, devices, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interface; the indirect coupling or communication connection of apparatus or modules may be electrical, mechanical, or other forms.

[0128] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0129] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more units can be integrated into one module.

[0130] In the above embodiments, the functions of each functional module can be implemented entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions (programs). When the computer program instructions (programs) are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs, DVDs), or semiconductor media (e.g., solid-state disks, SSDs), etc.

[0131] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0132] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for managing containers, characterized in that, The method, applied to worker nodes in a Kubernetes cluster, wherein multiple containers are deployed on the worker nodes, includes: Periodically determine the first set of containers in which the service is successfully detected among the plurality of containers, the first set of containers including one or more containers; If the first container set and the second container set are inconsistent, an indication message is sent to the load balancer to instruct the load balancer to update the containers in the second container set, which includes one or more containers recorded in the load balancer for the worker node to provide services to the outside world. Wherein, if the number of containers in the first container set is less than the number of containers in the second container set, the indication information is used to indicate which containers in the second container set need to be deleted, and the containers to be deleted include containers in the second container set other than those in the first container set; If the number of containers in the first container set is greater than the number of containers in the second container set, the indication information is used to indicate which containers need to be added to the second container set. The containers that need to be added include containers in the first container set other than those in the second container set. The periodic determination of the first set of containers in which services have been successfully probed includes: performing service probes on each of the multiple containers through the kubelet component in the worker node to obtain the first set of containers, wherein the service probes on each container are implemented based on a predefined probe script.

2. The method as described in claim 1, characterized in that, The predefined detection script includes a service activation threshold and a service activation interface. The service activation threshold is used to limit the number of times a service activation attempt is performed again after each container service activation attempt fails.

3. The method as described in claim 1 or 2, characterized in that, The method further includes: Create a service liveness detection status file, which is used to store the service liveness detection status of each of the plurality of containers, and the service liveness detection status includes: service liveness detection successful or service liveness detection failed.

4. The method as described in claim 3, characterized in that, The method further includes: After each service activation test, the service activation status file is updated.

5. The method as described in claim 1 or 2, characterized in that, The method further includes: Based on the initial service activation of each of the plurality of containers, the containers that have been successfully activated are identified among the plurality of containers; The containers that successfully activate the service are registered to the load balancer to obtain the second set of containers.

6. The method as described in claim 5, characterized in that, Registering the container whose service has been successfully activated to the load balancer includes: Send container information of containers that have successfully activated their services to the load balancer. The container information includes Internet Protocol (IP) addresses and / or ports.

7. The method as described in claim 1, characterized in that, The step of sending an indication message to the load balancer when the first container set and the second container set are inconsistent, to instruct the load balancer to update the containers in the second container set, includes: If the most recently determined first container set and the second container set are inconsistent, an indication message is sent to the load balancer to instruct the load balancer to update the containers in the second container set.

8. A container management device, characterized in that, This is applied to worker nodes in a Kubernetes cluster, where multiple containers are deployed, including: A determining unit is used to periodically determine a first set of containers from a plurality of containers in which a service has been successfully detected and activated, the first set of containers including one or more containers; The transceiver unit is used to send an indication message to the load balancer when the first container set and the second container set are inconsistent, so as to instruct the load balancer to update the containers in the second container set, the second container set including one or more containers recorded in the load balancer for providing services to the outside world by the worker nodes. The determining unit is configured to, when the number of containers in the first container set is less than the number of containers in the second container set, use the indication information to indicate which containers in the second container set need to be deleted, and the containers to be deleted include containers in the second container set other than those in the first container set; If the number of containers in the first container set is greater than the number of containers in the second container set, the indication information is used to indicate which containers need to be added to the second container set. The containers that need to be added include containers in the first container set other than those in the second container set. The determining unit is specifically used to perform service activation testing on each of the multiple containers through the kubelet component in the working node to obtain a first container set. The service activation testing of each container is implemented based on a predefined detection script.

9. A container management device, characterized in that, Includes a processor and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes the computer execution instructions to implement the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Includes a computer program that, when run on a computer, causes the computer to perform the method as described in any one of claims 1 to 7.

11. A computer program product, characterized in that, Includes a computer program that, when run, causes a computer to perform the method as described in any one of claims 1 to 7.

Images