Container group isolation method, system, device, program product, and storage medium

Abstract

Provided in the present disclosure are a container group isolation method based on a container management platform, a system, a device, a program product, and a storage medium. The container management platform is used for scheduling a container group in a container group cluster to a work node in a work node cluster for operation, wherein each container group is created on the basis of definition data of the container group, and the definition data includes at least one piece of attribute information of the container group. The method is applied to the work node, and comprises: acquiring a preset isolation rule, wherein the isolation rule includes target attribute information of at least two container groups that need to be subjected to network isolation, and the target attribute information is attribute information included in definition data; in response to having acquired a network request, on the basis of information carried by the network request, determining attribute information of a source container group that sends the network request and attribute information of a destination container group to which the network request is sent; and if the attribute information of the source container group and the attribute information of the destination container group match the target attribute information in the isolation rule, isolating the network request.

Description

[0001] Container Group Isolation Method, System, Device, Program Product, and Storage Medium. This disclosure claims priority to Chinese patent application number 202410309172.0, filed with the China Patent Office on March 18, 2024, entitled "Container Group Isolation Method, System, Device, Program Product, and Storage Medium," the entire contents of which are incorporated herein by reference. Technical Field: This disclosure relates to the field of container technology, and more particularly to container group isolation methods, systems, devices, program products, and storage media. Background: Containerized applications are packaged into an independent, standardized runtime environment to enable rapid deployment, portability, and cross-platform application functionality. Currently, several container management platforms exist that facilitate the management of container group clusters. In existing container management platforms, container groups within a cluster can communicate with each other. However, in some scenarios, there is a need for network isolation between container groups within a cluster. Implementing a high-precision container isolation solution has become a pressing technical challenge. SUMMARY To overcome problems existing in related technologies, the present disclosure provides a container group isolation method, system, device, program product, and storage medium based on a container management platform. According to a first aspect of an embodiment of this specification, a container group isolation method based on a container management platform is provided. The container management platform is configured to schedule a container group in a container group cluster to a worker node in a worker node cluster for execution. The container group is created based on definition data for the container group, the definition data including at least one attribute information of the container group. The method, applied to the worker node, includes: obtaining a preset isolation rule, the isolation rule including target attribute information of at least two types of container groups to be network isolated, the target attribute information being attribute information included in the definition data; in response to obtaining a network request, determining attribute information of a source container group issuing the network request and attribute information of a destination container group to which the network request is sent based on information carried in the network request; and isolating the network request if the attribute information of the source container group and the attribute information of the destination container group match the target attribute information in the isolation rule. According to a second aspect of an embodiment of this specification, a container management system is provided. The system includes a worker node cluster, the worker node cluster includes at least one worker node, and the worker node is used to run at least one container group. The worker node is used to perform the steps of the container group isolation method described in the first aspect.According to a third aspect of the embodiments of this specification, a computer device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the steps of the method embodiment described in the first aspect are implemented. According to a fourth aspect of the embodiments of this specification, a computer program product is provided, comprising a computer program, wherein when the processor executes the computer program, the steps of the method embodiment described in the first aspect are implemented. According to a fifth aspect of the embodiments of this specification, a computer-readable storage medium is provided, wherein the computer program is stored on the medium, wherein when the processor executes the computer program, the steps of the method embodiment described in the first aspect are implemented. The technical solutions provided by the embodiments of this specification can include the following beneficial effects: In the embodiments of this specification, a container management platform is used to schedule a container group in a container group cluster to a worker node in a worker node cluster for execution. The container group is created based on the container group's definition data, which includes at least one attribute information of the container group. The method of this embodiment, when applied to the worker node, can maintain preset isolation rules, which include target attribute information of at least two types of container groups requiring network isolation. In response to receiving a network request, the method determines the attribute information of the source container group issuing the network request and the attribute information of the destination container group to which the network request is sent based on the information carried in the network request. If the attribute information of the source container group and the attribute information of the destination container group match the target attribute information in the isolation rule, the network request is isolated. In this embodiment, the isolation rule uses the attribute information of the container group in the container group's definition data. Therefore, this attribute information does not change with frequent scheduling of the container group. Therefore, there is no need to update the isolation rule based on the scheduling of the container group to different worker nodes. This ensures the stability and accuracy of isolation, and reduces the maintenance cost of the isolation rule. It should be understood that the above general description and the following detailed description are merely exemplary and explanatory and do not limit the present disclosure.Figure 1 is a schematic diagram of a container management platform according to an exemplary embodiment of this specification; Figure 2A is a flowchart of a container group isolation method based on the container management platform according to an exemplary embodiment of this specification; Figure 2B is an application scenario diagram of a container group isolation method based on the container management platform according to an exemplary embodiment of this specification; Figure 2C is a flowchart of another container group isolation method based on the container management platform according to an exemplary embodiment of this specification; and Figure 3 is a hardware structure diagram of a computer device containing a container group isolation device based on the container management platform according to an exemplary embodiment of this specification. DETAILED DESCRIPTION OF THE EMBODIMENTS Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different drawings represent identical or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this specification. Rather, they are merely examples of devices and methods consistent with certain aspects of this specification, as detailed in the appended claims. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit this specification. As used in this specification and the appended claims, the singular forms "a," "an," "the," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and / or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It should be understood that while this specification may employ the terms "first," "second," and "third," etc. to describe various information, such information should not be limited to these terms. These terms are merely used to distinguish information of the same type from one another. For example, first information could be referred to as second information, and similarly, second information could be referred to as first information, without departing from the scope of this specification. Depending on the context, the term "if," as used herein, could be interpreted as meaning "when," "at the time," or "in response to determining." All user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, storage, and display) involved in this disclosure are authorized by the user or fully authorized by all parties. The collection, use, and processing of such data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding access points are provided for users to choose to authorize or deny such access. The container management platform in this embodiment includes but is not limited to systems capable of cluster management, such as Kubernetes.The container group in this embodiment can be called a Pod in Kubernetes, and a container in other platforms such as Docker Swarm (a container management platform) or Apache Mesos (a container management platform). The container isolation method of this embodiment can be applied to these different cluster management systems, and the specific processes are relatively similar. For ease of description, the following embodiments will be described using Kubernetes as an example. It should be emphasized that although the Kubernetes architecture is used as the basis for the explanation, those skilled in the art will understand that the solution of this embodiment can be ported to other similar architectures such as Docker Swarm or Apache Mesos, and this embodiment is not limited to this. Figure 1 is a schematic diagram of the Kubernetes architecture according to an exemplary embodiment of this specification. In terms of cluster management, Kubernetes can divide the machines in the cluster into one or more master nodes and a number of worker nodes. For ease of illustration, Figure 1 shows only one master node and three worker nodes: worker node 1 (Node 1), worker node 2 (Node 2), and worker node 3 (Node 3).

[0002] (1) Master

[0003] The Master in Kubernetes refers to the main node used for cluster control. Every Kubernetes cluster requires a Master to manage and control the entire cluster. Basically, all Kubernetes control commands are sent to it, and it is responsible for the specific execution process. The Master can occupy one or more independent servers. A set of processes related to cluster management runs on the Master. These processes implement management functions such as resource management, Pod scheduling, elastic scaling, security control, system monitoring and error correction for the entire cluster, and all are completed automatically. (2) Node

[0004] A node is a worker node in a cluster. It can be a physical machine or a virtual machine in a private or public cloud. Nodes can be dynamically added to a Kubernetes cluster during runtime. The smallest operating unit managed by Kubernetes on a node is a Pod, and a node can run one or more Pods. For example, Node1, Node2, and Node3 shown in Figure 1 can run different numbers of Pods. Nodes run the Kubernetes kubelet and kube-proxy service processes, which are responsible for creating, starting, monitoring, restarting, and destroying Pods, as well as implementing a software-based load balancer.

[0005] (3) Pod

[0006] A pod can be composed of one or more containers. For example, if at least two containerized applications are tightly coupled and combined to provide external services, these two containers can be packaged into a pod. For example, consider a computer program that requires a specific runtime environment, libraries, and configuration files to run properly. This program and all its dependencies can be packaged into a container, which can then be packaged into a pod. This pod can be scheduled to run on a node, providing the program with an independent runtime environment where it can run without being affected by the external environment. In other examples, a pod can contain at least two containers. For example, if at least two containerized applications are tightly coupled and combined to provide external services, these two containers can be packaged into a pod. This approach is often used for two closely related services, such as a web server and its log collection program, or an application and its auxiliary tasks. By packaging these two services into the same pod, they can work together better. Cloud services can be provided to users based on the aforementioned container management platform. For example, when a user needs to run an instance in the cloud, he or she can create one or more Pods in the container management platform and schedule them to run in the Node. The Pod contains the container corresponding to the user's instance.

[0007] Kubernetes assigns each pod a unique virtual Internet Protocol (IP) address, called a Pod IP. Multiple containers within a pod share the Pod IP address. Kubernetes requires that the underlying network support direct TCP / IP (Transmission Control Protocol / Internet Protocol) communication between any two pods within the cluster, typically achieved through virtual Layer 2 networking technologies. Therefore, in Kubernetes, containers in one pod can communicate directly with containers in pods on other machines. Typically, when a container in a pod stops, Kubernetes automatically detects this and restarts the pod (and all containers within it). If the node hosting a pod crashes, all pods on that node are rescheduled to other nodes. When a pod is rescheduled to a different node, its IP address changes. Therefore, frequent changes in a pod's Pod IP address are common in Kubernetes. In some application scenarios, micro-isolation of network requests between pods is necessary. For example, a container cluster has two namespaces: Namespace A and Namespace B. Suppose 10 containers are created in Namespace A and 50 containers are created in Namespace B. It is desirable to isolate network requests between these two namespaces. Related technologies utilize the operating system's firewall functionality to achieve this. For example, based on the IP+port model, this approach obtains the IP addresses and ports of all pods in the cluster and configures these IP and port lists as rules, thereby achieving micro-isolation of containers. For example, each pod in Namespace A can run on one or more nodes. Therefore, 50 isolation rules need to be configured on the firewall of each node involved in Namespace A to deny the IP addresses and ports of the 50 containers in Namespace B. Similarly, each pod in Namespace B can run on one or more nodes. Furthermore, 10 isolation rules need to be configured on the firewall of each node involved in Namespace B to deny the IP addresses and ports of the 10 containers in Namespace A.Due to the nature of container deployment, the 60 containers under Namespace A and Namespace B may frequently change their IP addresses. Whenever these changes occur, isolation rules must be updated accordingly. Furthermore, assuming that Namespace A and Namespace B each involve only one node, the configured isolation rules are determined by the number of containers. In this example, 60 isolation rules are required. As can be seen from the above example, in this solution, the number of isolation rules is positively correlated with the number of pods, resulting in a large number of isolation rules and difficulties in maintenance. Furthermore, due to the frequent changes in container IP addresses, isolation rules also frequently change. Furthermore, the complexity of virtual and physical IP addresses can easily lead to misconfiguration of isolation rules, making isolation stability unreliable. To address this issue, this embodiment provides a container group isolation method based on a container management platform. Isolation rules utilize the container group's attribute information within its definition data. Therefore, these attributes do not change with the frequent scheduling of the container group. Therefore, there is no need to update isolation rules based on the scheduling of the container group to different worker nodes. This ensures isolation stability and accuracy, and reduces the maintenance cost of isolation rules. As shown in FIG2A , FIG2A is a flowchart illustrating a container group isolation method based on a container management platform according to an exemplary embodiment of this specification. The container management platform is used to schedule a container group in a container group cluster to a worker node in a worker node cluster for execution. The container group is created based on container group definition data, wherein the definition data includes at least one attribute information of the container group. The method is applied to the worker node and may include the following steps: In step 202, a preset isolation rule is obtained. The isolation rule includes target attribute information of at least two types of container groups to be network isolated, where the target attribute information is attribute information included in the definition data. In step 204, in response to obtaining a network request, attribute information of the source container group issuing the network request and attribute information of the destination container group to which the network request is sent are determined based on information carried in the network request. In step 206, if the attribute information of the source container group and the attribute information of the destination container group match the target attribute information in the isolation rule, the network request is isolated. As an example, the container management platform creates a resource object based on its definition data.Taking Kubernetes as an example, most concepts, such as Node or Pod, can be considered resource objects. All resource objects in Kubernetes can be defined or described using files in YAML (Yin't Markup Language) or JavaScript Object Notation (JavaScript, JSON) formats. For example, a worker node definition file can be submitted to the master node in Kubernetes. Upon receiving the worker node definition file, the master node can obtain the worker node information defined in the file. A pod definition file can also be submitted to the master node in Kubernetes. Upon receiving the pod definition file, the master node creates the pod and schedules it to a worker node. The container group definition data can be used to define one or more pod information, such as name, labels, number of replicas, CPU limit, memory limit, or storage volume. In practical applications, this can be configured as needed and is not limited in this embodiment. As an example, in a container management platform, a label can be a key-value pair, where the key and value can be specified by the user. Labels can be attached to various resource objects, such as nodes or pods. A resource object can define any number of labels, and the same label can be attached to any number of resource objects. Labels are typically determined when the resource object is defined, but can also be dynamically added or removed after the object is created. Therefore, the container group definition data contains one or more fixed attributes of the container group—attributes that do not change when the pod is scheduled to run on different nodes. The pod's IP address is typically not included in the definition file and is not user-defined. Instead, it is assigned by the container management platform after the pod is created based on the definition file. The IP address changes as the pod is scheduled. The isolation rules of this embodiment utilize these attributes in the definition data that do not change with pod scheduling, eliminating the need to update the isolation rules after the pod is scheduled. In some examples, the method can be applied to an isolation program, where each worker node in the worker node cluster runs the isolation program. Optionally, the master node managing the cluster in the container management platform can also run the isolation program as needed. Exemplarily, the isolation program may be a program running on the operating system, or may be included in the operating system as a sub-function of the operating system.FIG2B illustrates an application scenario for container group isolation according to an exemplary embodiment of this specification. Based on FIG1 , isolation programs of this embodiment, such as isolation program 1, isolation program 2, and isolation program 3 shown in FIG2B , can be run on each node to implement micro-isolation of containers. Container micro-isolation in this embodiment refers to isolating network requests between pods in a cluster that could otherwise communicate with each other. Implementing container micro-isolation can prevent east-west attacks between containers and reduce the attack surface. For example, there may be multiple nodes in a cluster, and the programs on each node need to maintain isolation rules. Optionally, one isolation program can obtain user-configured custom isolation rules and then send them to other isolation programs. For example, an isolation program can provide a configuration interface for configuring custom isolation rules. This configuration interface can be implemented in various ways. For example, a graphical user interface can be used to allow users to modify isolation rule configuration information. Users can enter new configuration parameters through interactive elements on the interface (such as text boxes, drop-down menus, checkboxes, etc.) and trigger a save or submit operation to update the isolation rules. Alternatively, users can submit isolation rules by entering specific commands and parameters through a command line interface. Alternatively, isolation rules can be saved in a file using a predefined configuration file format. Users can directly edit the configuration file and save the edited file to submit the isolation rules. One or more of the above interface implementations can be combined based on actual needs, and this embodiment is not limited thereto. The above embodiment facilitates user configuration of isolation rules and enables each node to promptly obtain user-configured isolation rules. Users can configure isolation rules using the configuration interface of one of the clients. After obtaining the isolation rules, the client can send them to other clients in various ways, such as sending them to the server, which then sends them to clients running on other worker nodes in the worker node cluster. Alternatively, clients can communicate directly with each other, with the client that obtains the isolation rules sending them directly to other clients. Alternatively, a server can be implemented. For example, obtaining the preset isolation rules can include obtaining the preset isolation rules from a server, where the server configures the isolation rules. As an example, the server can obtain user-configured custom isolation rules and send them to other isolation programs. The server may provide a configuration interface for configuring customized isolation rules. The implementation of the configuration interface may be seen in the embodiment of the configuration interface of the client described above.Based on this, the server can receive isolation rules submitted by users and send them to the client running on each worker node in the worker node cluster. For example, the isolation program of this embodiment can continue to run after the worker node is started. Worker nodes in the worker node cluster may change, such as when a new worker node is added or when the machine where the worker node resides is shut down and relocated to another machine. The isolation program of this embodiment can be launched and deactivated as worker nodes come online and go offline. Therefore, if a worker node cluster contains multiple worker nodes, each worker node can promptly obtain the current isolation rules. At the same time, each worker node can execute the container group isolation embodiment based on the isolation rules, ensuring the stability and accuracy of isolation. In this embodiment, the isolation program can detect network requests generated by each process running on the node. Based on the network protocol, network requests can carry one or more types of information. Based on this information, the source container group issuing the network request and the destination container group to which the request is sent can be located. The tag information of the source container group and the tag information of the destination container group can be determined to determine whether to match the isolation rules to determine whether to isolate the network request. Thus, in step 206, if the attribute information of the source container group and the attribute information of the destination container group match the target attribute information in the isolation rule, the network request is isolated. In other examples, if the attribute information of the source container group and the attribute information of the destination container group do not match the target attribute information in the isolation rule, the network request may not be isolated. In actual applications, isolation rules can be implemented in various ways. Isolation rules use attribute information in the Pod definition file to describe which container groups require network isolation. For example, the attribute information of two types of container groups requiring network isolation contained in the isolation rule can distinguish between the source Pod and the destination Pod, and thus network requests sent from the source Pod to the destination Pod can be intercepted. As an example, the isolation rule can be specifically: srcNamespace: aaa, targetNamespace: bbb. This isolation rule uses two key-value pairs as an example. The first key-value pair indicates that the namespace of the source Pod to be isolated is aaa. ,The second key-value indicates that the namespace of a type of destination Pod that needs to be isolated is bbb. In other examples, an isolation rule may include attribute information of multiple types of container groups that need to be network isolated. For example, the isolation rule may be specifically: srcNamespace: aaa, targetNamespace: bbb, targetNamespace: ccc. Compared with the previous isolation rule, this isolation rule has an additional type of destination Pod with namespace ccc; that is, the container group in namespace aaa sent to namespace bbb or namespace ccc needs to be isolated. In other examples, it is also possible not to distinguish between source Pod and destination Pod, and the network requests between the two types of container groups can be intercepted. In actual applications, isolation rules can be implemented in many ways, and this embodiment does not limit this. Exemplarily, the attribute information of the container group contained in the isolation rule can be arbitrary, and this embodiment does not limit this. For example, the attribute information of the Pod can include but is not limited to:

[0008] Pod name (Name) refers to: the unique name identifier of the Pod in the Kubemetes cluster. Namespace (Namespace) refers to: the namespace to which the Pod belongs, used to isolate and manage resources in the cluster. Labels (Labels): labels in the form of key-value pairs, used to identify and select Pods. Annotations (Annotations) refer to: metadata information related to the Pod, providing additional descriptive information. Images (Images) refer to: the name and version information of the image used by the container in the Pod. The Pod attribute information used in the isolation rules of this embodiment includes, but is not limited to, a combination of one or more of the following container information: namespace, label, or image, etc., which is not limited in this embodiment. For example, the maintained isolation rules can be one or more, which is not limited in this embodiment. In some examples, the information carried by the network request includes: source network information representing a source container group issuing the network request, and destination network information representing a destination container group to which the network request is sent. Determining attribute information of the source container group issuing the network request and attribute information of the destination container group to which the network request is sent based on the information carried by the network request may include: obtaining container group data of the container group cluster provided by the container management platform; the container group data of the container group cluster includes container group information of each container group in the container group cluster; and determining attribute information of the source container group corresponding to the source network information and attribute information of the destination container group corresponding to the destination network information based on the container group data. As an example, in a network protocol, a network request may carry multiple types of information, for example, source network information and destination network information. The source network information may include the IP address and port number of the network request initiator, which identifies the source of the request. The destination network information may include the target IP address and port number of the network request, which specifies the target of the network request. Therefore, the source and destination pods of a network request can be determined using the IP address and port number. Furthermore, container group data for a container group cluster, namely, container information for each container group in the cluster, can be obtained from the container management platform. The container management platform creates container groups based on definition files and stores the pod information defined in the pod definition files. It also maintains additional pod information, such as the pod's IP address and other network information.Therefore, the network information carried in the network request can be associated with the container group data managed by the container management platform to obtain attribute information of the source container group corresponding to the source network information and attribute information of the destination container group corresponding to the destination network information. For example, the container group data of 100 pods in the container group cluster obtained from the container management platform may include:

[0009] Pod1's various information: name, namespace, app, network information, image, annotations Pod2's various information: name, namespace, app, network information, image, annotations>

[0010] >

[0011] Pod 100 contains various information: name, namespace, app, network information, image, annotations... The source and destination network information carried in the monitored network request are abcd and efgh, respectively. In the container group data, abcd and efgh correspond to Pod 8 and Pod 9, respectively. The isolation rule specifies the target attribute information for at least two container groups that need to be isolated, which is namespace: aaa and bbb. The namespaces of Pod 8 and Pod 9, respectively, are aaa and bbb, respectively. This matches the isolation rule, and the network request can be isolated. As another example, the source and destination IP addresses in the network protocol can be associated with the corresponding container Pod information. For example, if the source IP address is 1.2.3.4, the cache query shows it is the IP address of Pod A, whose namespace is 1, image is 2, and app is 3. In this case, the isolation rule also contains a rule such as "Source APP: 3," and the network request is associated with this rule. Therefore, network information (IP, Port) can be associated with container group data (pod[IP, Namespace, Image, podName]), and cache information is associated with isolation rules (rule[srcApp: aaa, targetNamespace: bbb]), thus enabling micro-isolation of pods based on network information. Therefore, this embodiment first determines the attribute information of the source and destination container groups based on the address information and container group data in the network request, and then determines whether the isolation rules are met. This allows accurate isolation of network requests, and isolation rules do not need to be maintained based on frequent pod scheduling, resulting in low maintenance costs. In some examples, the container management platform provides a container group information acquisition interface. Obtaining the container group data for the container group cluster provided by the container management platform may include initiating a call request for container information of each container group in the container group cluster to the container group information acquisition interface, obtaining container group data containing the container information of each container group in the container group cluster returned by the container management platform, and then storing the container group data locally. In this embodiment, the container information of each container group in the cluster can be obtained by calling the container group information acquisition interface provided by the container management platform.As an example, in Kubernetes, you can use the Kubernetes API (Application Programming Interface) to obtain information about each pod in the cluster. For example, the Kubernetes API provides a container group information retrieval API (e.g., Representational State Transfer, or RESTful). By calling this API, you can communicate with the Kubernetes cluster and obtain information about various resources, including pods. In implementation, you construct a call request to the container group information retrieval API, for example, specifying the API path or parameters for the pod information you want to retrieve. Then, you send the call request, for example, by sending the constructed call request to an endpoint on the Kubernetes API server. Then, you parse the API response. For example, after receiving the response, you parse the response data, which can be in JSON or another format, to extract the required pod information. Information about each pod is typically included in a response list. Then, you process the pod information, for example, by processing or using the pod information obtained from the API as needed. In actual applications, pods within a cluster may be frequently scheduled, and pod information may change frequently. Therefore, maintaining a new and accurate copy of container group data is necessary. Therefore, in some examples, obtaining the container group data for the container group cluster provided by the container management platform may also include a combination of one or more of the following steps: periodically sending a call request to update locally stored container group data; in response to a worker node change in the worker node cluster, sending a call request to update locally stored container group data; in response to a container group change in the container group cluster, sending a call request to update locally stored container group data. This embodiment can implement local caching of accurate container group data through one or more of the above methods to achieve accurate isolation of network requests. For example, periodic call requests can be sent to update locally stored container group data; periodic call requests can be sent to obtain current container group data to ensure the accuracy of locally stored data. A scheduled task or periodic polling mechanism can be set up to send requests to the container management platform at a certain frequency to obtain container group information and update local storage. When the number of worker nodes in the worker node cluster increases, decreases, or the status changes, a call request can be sent in time to update the locally stored container group data.By monitoring changes to working nodes, the consistency of container group data and cluster status can be maintained. Changes to container groups within a container group cluster, such as creation, deletion, and scheduling, can be monitored. Once a change occurs, a call request is sent to update the locally stored container group data. This ensures that the locally stored container group data promptly reflects the actual state of the cluster, maintaining data accuracy. By combining the above methods, accurate container group data can be effectively maintained, improving the stability and reliability of the network isolation in this embodiment. In this embodiment, network request isolation can be implemented in a variety of ways, such as intercepting network requests. For example, the isolation program can intercept network requests, preventing them from being sent to the destination Pod. This prevents the source and destination Pods from completing the TCP three-way handshake and, consequently, preventing them from establishing a connection. Alternatively, other isolation behaviors, such as redirection, may be included in practical applications, and this is not limited in this embodiment. In some examples, the isolation rules may include: target attribute information for the first type of container group to be network isolated, target attribute information for the second type of container group, and the type of isolation behavior. If the attribute information of the source container group and the attribute information of the destination container group match the target attribute information in the isolation rule, isolating the network request may include: if it is determined that the attribute information of the source container group matches the target attribute information of the first type of container group, and the attribute information of the destination container group matches the target attribute information of the second type of container group, isolating the network request according to the type of isolation behavior. In this embodiment, the isolation rules maintained by the isolation program may be rules for different isolation behaviors, and the isolation rules may include the type of isolation behavior. The specific type can be configured according to actual needs, for example, including interception, redirection, isolation sandboxing, analysis, etc. For example, interception means not sending the network request to the destination Pod. Redirection means, when a network request is detected to pose a potential security risk, redirecting the request to a secure environment for processing to ensure system and data security. Isolation sandboxing can place suspicious or untrusted network requests in an isolated sandbox environment to limit their access rights and scope of impact, while monitoring their behavior and preventing damage to the system. Analysis can include in-depth scrutiny and analysis of network requests to identify potential malicious code, attack behaviors, or anomalies, allowing timely implementation of appropriate protective measures. Based on this, this embodiment can implement multiple types of isolation behaviors through isolation rules, allowing users to implement different processing methods for different types of network requests.As can be seen from the above embodiment, using a container attribute isolation policy instead of the existing IP+port isolation policy avoids micro-isolation rule configuration issues caused by rule expansion due to inaccurate IP acquisition or frequent IP changes, thereby improving isolation accuracy and reducing rule maintenance costs. In this embodiment, only a small number of isolation rules need to be configured to achieve the desired effect. Moreover, since the isolation rules use pod attribute information and are independent of the IP address, they remain effective even after the pod's IP address changes, ensuring the stability of the isolation rules. FIG2C is a flowchart of another embodiment of a container group isolation method based on a container management platform, according to an exemplary embodiment of this specification. When each worker node in a worker node cluster begins operation, it can obtain isolation rules, such as by obtaining isolation rules through a server or other means as in the above embodiment. It can also obtain container group data, such as by obtaining container group data through a container management platform or other means as in the above embodiment. When a worker node receives a network request for itself, it can use the information carried in the network request, such as source network information and destination network information, to obtain attribute information of the source container group corresponding to the source network information and attribute information of the destination container group corresponding to the destination network information from the container group data. Therefore, the attribute information of the source container group and the destination container group can be used to determine whether the isolation rules match. If they do not match, the network request may not be isolated; if they do match, the corresponding isolation behavior may be executed. Corresponding to the aforementioned embodiments of the container group isolation method based on the container management platform, this specification also provides embodiments of a container group isolation apparatus based on the container management platform and a computer device for use therein. The embodiments of the container group isolation apparatus based on the container management platform described herein can be applied to computer devices, such as servers or terminal devices. The apparatus embodiments can be implemented using software, hardware, or a combination of software and hardware. For example, in a software implementation, as a logical device, the corresponding computer program instructions are read from non-volatile memory into memory and executed by a processor performing file processing. From a hardware perspective, FIG3 shows a hardware structure diagram of a computer device housing the container group isolation device based on the container management platform described herein. In addition to the processor 310, memory 330, network interface 320, and non-volatile memory 340 shown in FIG3 , the computer device housing the container group isolation device based on the container management platform in this embodiment may also include other hardware components, typically based on the actual functionality of the computer device. These components will not be further detailed.As an example, a container group isolation device based on a container management platform can be applied to a worker node. The device may include: a rule maintenance module, configured to obtain a preset isolation rule, wherein the isolation rule includes target attribute information of at least two types of container groups requiring network isolation, wherein the target attribute information is attribute information included in the definition data; a determination module, configured to, in response to obtaining a network request, determine attribute information of a source container group issuing the network request and attribute information of a destination container group to which the network request is sent based on information carried in the network request; and an isolation determination module, configured to isolate the network request if the attribute information of the source container group and the attribute information of the destination container group match the target attribute information in the isolation rule. In some examples, the device is applied to an isolation program, and a worker node in the worker node cluster runs the isolation program. The rule maintenance module obtains the preset isolation rule, including obtaining the preset isolation rule from a server, wherein the isolation rule is configured by the server. In some examples, the information carried by the network request includes: source network information representing a source container group issuing the network request, and destination network information representing a destination container group to which the network request is sent. The determination module, based on the information carried by the network request, determines attribute information of the source container group issuing the network request and attribute information of the destination container group to which the network request is sent, including: obtaining container group data for the container group cluster provided by the container management platform; the container group data for the container group cluster includes container group information of each container group in the container group cluster; and determining attribute information of the source container group corresponding to the source network information and attribute information of the destination container group corresponding to the destination network information based on the container group data. In some examples, the container management platform provides a container group information acquisition interface; the determination module, obtaining the container group data for the container group cluster provided by the container management platform, includes: initiating a call request for container group information of each container group in the container group cluster to the container group information acquisition interface, obtaining container group data including container group information of each container group in the container group cluster returned by the container management platform, and then storing the container group data locally.In some examples, the determination module obtains container group data for the container group cluster provided by the container management platform and is further configured to: periodically send the call request to update the locally stored container group data; in response to a worker node change in the worker node cluster, send the call request to update the locally stored container group data; and / or in response to a container group change in the container group cluster, send the call request to update the locally stored container group data. In some examples, the isolation rule includes: target attribute information of a first-category container group to be network isolated, target attribute information of a second-category container group, and a type of isolation behavior; and the isolation determination module isolating the network request if the attribute information of the source container group and the attribute information of the destination container group match the target attribute information in the isolation rule includes: if it is determined that the attribute information of the source container group matches the target attribute information of the first-category container group and the attribute information of the destination container group matches the target attribute information of the second-category container group, isolating the network request according to the type of isolation behavior. The implementation process of the functions and effects of each module in the aforementioned container group isolation device based on a container management platform is described in detail in the implementation process of the corresponding steps in the aforementioned container group isolation method based on a container management platform, and will not be repeated here. Accordingly, embodiments of this specification also provide a container management system, comprising a worker node cluster, the worker node cluster including at least one worker node, the worker node configured to run at least one container group; the worker node configured to execute the steps of the aforementioned embodiment of the container group isolation method based on a container management platform. Accordingly, embodiments of this specification also provide a computer program product, comprising a computer program, which, when executed by a processor, implements the steps of the aforementioned embodiment of the container group isolation method based on a container management platform. Accordingly, embodiments of this specification also provide a computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein, when the processor executes the program, the processor implements the steps of the embodiment of the container group isolation method based on a container management platform. Accordingly, embodiments of this specification also provide a computer-readable storage medium storing a computer program, which, when executed by the processor, implements the steps of the embodiment of the container group isolation method based on a container management platform. As for the device embodiment, since it basically corresponds to the method embodiment, the relevant parts can be referred to the partial description of the method embodiment.The device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, that is, they may be located in one location or distributed across multiple network modules. Some or all of these modules may be selected based on actual needs to achieve the objectives of the solutions described herein. Persons of ordinary skill in the art will be able to understand and implement the solutions without inventive effort. The above embodiments may be applied to one or more computer devices, which are devices capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions. The hardware of the computer devices includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, and the like. The computer device can be any electronic product capable of human-computer interaction with a user, such as a personal computer, tablet computer, smartphone, personal digital assistant (PDA), game console, Internet Protocol Television (IPTV), smart wearable device, etc. The computer device may also include a network device and / or a user device. The network device includes, but is not limited to, a single network server, a server group consisting of multiple network servers, or a cloud based on cloud computing consisting of a large number of hosts or network servers. The network in which the computer device resides includes, but is not limited to, the Internet, a wide area network, a metropolitan area network, a local area network, a virtual private network (VPN), etc. The above description of specific embodiments of this specification is intended. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. In addition, the processes depicted in the figures do not necessarily require the specific order or sequential order shown to achieve the desired results. In certain implementations, multitasking and parallel processing are also possible or may be advantageous.The above division of steps in the various methods is for clarity of description only. During implementation, they may be combined into a single step, or some steps may be split into multiple steps. As long as they share the same logical relationship, they are all within the scope of protection of this patent. Adding minor modifications or introducing minor design changes to the algorithm or process, but without changing the core design of the algorithm or process, is also within the scope of protection of this application. While this specification contains many specific implementation details, these should not be construed as limiting the scope of any invention or the scope of protection claimed. Instead, they are primarily intended to describe the features of specific embodiments of a particular invention. Certain features described in multiple embodiments within this specification may also be implemented in combination in a single embodiment. Conversely, various features described in a single embodiment may also be implemented separately in multiple embodiments or in any suitable subcombination. Furthermore, while features may function in certain combinations as described above and may even be initially claimed as such, one or more features from a claimed combination may in some cases be removed from that combination, and a claimed combination may refer to a subcombination or variations of that subcombination. References to "specific examples" or "some examples" mean that the specific features, structures, materials, or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of this specification. In this specification, schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Those skilled in the art will readily identify other implementations of this specification after considering this specification and practicing the inventions claimed herein. This specification is intended to cover any variations, uses, or adaptations of this specification that follow the general principles of this specification and include common knowledge or customary techniques in the art not otherwise claimed. The description and examples are to be considered merely as exemplary; the true scope and spirit of this specification are to be indicated by the following claims. It should be understood that this specification is not limited to the precise configuration described above and illustrated in the drawings, and that various modifications and variations may be made without departing from its scope. The scope of this specification is to be limited solely by the appended claims. The above description is only a preferred embodiment of this specification and is not intended to limit this specification. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of this specification shall be included in the scope of protection of this specification.

Claims

Claims 1. A container group isolation method based on a container management platform, wherein the container management platform is used to schedule a container group in a container group cluster to run on a worker node in a worker node cluster, wherein the container group is created based on definition data of the container group, wherein the definition data includes at least one attribute information of the container group; the method is applied to the worker node, and comprises: Acquire a preset isolation rule, where the isolation rule includes target attribute information of at least two types of container groups that require network isolation, and the target attribute information is attribute information included in the definition data; In response to obtaining the network request, determining, according to information carried in the network request, attribute information of a source container group that issues the network request and attribute information of a destination container group to which the network request is sent; If the attribute information of the source container group and the attribute information of the destination container group match the target attribute information in the isolation rule, the network request is isolated.

2. The method according to claim 1, wherein the method is applied to an isolation program, a worker node in the worker node cluster runs the isolation program, and the obtaining of a preset isolation rule comprises: Obtain preset isolation rules from the server, where the isolation rules are configured by the server.

3. The method according to any one of claims 1-2, wherein the information carried by the network request comprises: Source network information representing the source container group that issues the network request, and destination network information representing the destination container group to which the network request is sent; The determining, based on information carried in the network request, attribute information of a source container group that issues the network request and attribute information of a destination container group to which the network request is sent, includes: obtaining container group data of the container group cluster provided by the container management platform; the container group data of the container group cluster includes container group information of each container group in the container group cluster; and determining, based on the container group data, attribute information of the source container group corresponding to the source network information and attribute information of the destination container group corresponding to the destination network information.

4. The method according to claim 3, wherein the container management platform provides a container group information acquisition interface; and obtaining the container group data of the container group cluster provided by the container management platform comprises: A call request for container group information of each container group in the container group cluster is initiated to the container group information acquisition interface to obtain container group data including the container group information of each container group in the container group cluster returned by the container management platform, and the container group data is stored locally.

5. The method according to claim 4, wherein obtaining the container group data of the container group cluster provided by the container management platform further comprises a combination of one or more of the following steps: periodically sending the call request to update the locally stored container group data; in response to a worker node change in the worker node cluster, sending the call request to update the locally stored container group data; and in response to a container group change in the container group cluster, sending the call request to update the locally stored container group data.

6. The method according to any one of claims 1 to 5, wherein the isolation rule comprises: Target attribute information of the first type of container group that requires network isolation, target attribute information of the second type of container group, and the type of isolation behavior; If the attribute information of the source container group and the attribute information of the destination container group match the target attribute information in the isolation rule, isolating the network request includes: if it is determined that the attribute information of the source container group matches the target attribute information of the first type of container group, and the attribute information of the destination container group matches the target attribute information of the second type of container group, isolating the network request according to the type of the isolation behavior.

7. A container management system, comprising a worker node cluster, the worker node cluster comprising at least one worker node, the worker node configured to run at least one container group; the worker node configured to execute the steps of the method of any one of claims 1 to 6.

8. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer program product, comprising a computer program, wherein when the computer program is executed by a processor, the computer program implements the steps of any one of the methods of claims 1 to 6.

10. A computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images