Container group isolation method, system and device, program product and storage medium
By using the attribute information in the container group's definition data as isolation rules, the problem of a large number of isolation rules and insufficient stability in container group network isolation is solved, and high-precision and low-cost container group isolation is achieved.
Patent Information
- Application Number
- CN202410309172.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-03-18
- Publication Date
- 2025-09-19
AI Technical Summary
In existing container management platforms, network isolation solutions between container groups are difficult to achieve high accuracy and stability, and the maintenance cost of isolation rules is high. The number of isolation rules is large and easy to misconfigure.
The attribute information in the definition data of the container group is used as the isolation rule. By obtaining the information carried by the network request, the attribute information of the source container group and the destination container group is determined. If the target attribute information in the isolation rule is matched, the network request is isolated.
It achieves stable network isolation between container groups, reduces the maintenance cost of isolation rules, improves the accuracy and stability of isolation, and avoids the rule expansion problem caused by frequent IP changes.
Smart Images
Figure CN120670079A_ABST
Abstract
Description
Technical Field
[0001] The present disclosure relates to the field of container technology, and in particular to a container group isolation method, system, device, program product, and storage medium. Background Art
[0002] Containerized applications are applications that are packaged with all their dependencies into an independent, standardized runtime environment. This enables rapid deployment, portability, and cross-platform compatibility. Several container management platforms exist that facilitate the management of container clusters. These platforms allow container groups within a cluster to communicate with each other. However, in some scenarios, network isolation is required between container groups within a cluster. Implementing a high-precision container isolation solution has become a pressing technical challenge. Summary of the Invention
[0003] To overcome the problems existing in the related art, the present disclosure provides a container group isolation method, system, device, program product and storage medium based on a container management platform.
[0004] According to a first aspect of an embodiment of this specification, a container group isolation method based on a container management platform is provided, 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;
[0005] The method is applied to the working node, and the method includes:
[0006] Obtaining a preset isolation rule, wherein the isolation rule includes target attribute information of at least two types of container groups that require network isolation, wherein the target attribute information is attribute information included in the definition data;
[0007] In response to obtaining the network request, 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;
[0008] 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.
[0009] According to a second aspect of an embodiment of this specification, a container management system is provided, the system including a worker node cluster, the worker node cluster including at least one worker node, the worker node being used to run at least one container group; the worker node being used to execute the steps of the container group isolation method described in the first aspect.
[0010] 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.
[0011] According to a fourth aspect of the embodiments of this specification, a computer program product is provided, comprising a computer program, which, when executed by a processor, implements the steps of the method embodiment described in the first aspect.
[0012] According to a fifth aspect of the embodiments of this specification, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps of the method embodiment described in the first aspect are implemented.
[0013] The technical solutions provided by the embodiments of this specification may have the following beneficial effects:
[0014] In an embodiment of the present specification, a container management platform is used to schedule a container group in a container group cluster to a working node in a working node cluster for execution. The container group is created based on the definition data of the container group, and the definition data includes at least one attribute information of the container group. The method of this embodiment is applied to the working node to maintain a preset isolation rule, and the isolation rule includes target attribute information of at least two types of container groups that need to be network isolated. In response to obtaining a network request, the attribute information of the source container group that issued the network request and the attribute information of the destination container group to which the network request is sent are determined based on the information carried by 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 definition data of the container group. Therefore, this attribute information will not change with the 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 working nodes. Therefore, the stability and accuracy of the isolation can be guaranteed, and the maintenance cost of the isolation rule is low.
[0015] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure. BRIEF DESCRIPTION OF THE DRAWINGS
[0016] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the specification and, together with the description, serve to explain the principles of the disclosure.
[0017] Figure 1 This is a schematic diagram of a container management platform according to an exemplary embodiment of this specification.
[0018] Figure 2A This is a flowchart of a container group isolation method based on a container management platform according to an exemplary embodiment of this specification.
[0019] Figure 2B This is an application scenario diagram of a container group isolation method based on a container management platform according to an exemplary embodiment of this specification.
[0020] Figure 2C This is a flowchart of another container group isolation method based on a container management platform according to an exemplary embodiment of this specification.
[0021] Figure 3 This is a hardware structure diagram of a computer device where a container group isolation device based on a container management platform is located according to an exemplary embodiment of this specification. DETAILED DESCRIPTION
[0022] 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 figures represent identical or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with this specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of this specification, as detailed in the appended claims.
[0023] The terms used in this specification are for the purpose of describing specific embodiments only and are 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.
[0024] It should be understood that although the terms first, second, third, etc. may be used in this specification 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 may also be referred to as second information, and similarly, second information may also be referred to as first information without departing from the scope of this specification. Depending on the context, the term "if" as used herein may be interpreted as "when," "when," or "in response to determining."
[0025] The 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, stored data, displayed data, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.
[0026] The container management platform in the solution of this embodiment includes but is not limited to systems that can perform cluster management, such as Kubernetes. Among them, the container group in this embodiment can be called Pod in Kubernetes, and can be called container in other platforms such as Docker Swarm (the name of a container management platform) or Apache Mesos (the name of a container management platform). The specific processes of the container isolation method embodiment of this embodiment that can be applied to these different cluster management systems are relatively similar. For the sake of ease of description, the following embodiments will be explained using Kubernetes as an example. It should be emphasized that although the explanation is based on the Kubernetes architecture, those skilled in the art should understand that the solution of this embodiment can be transplanted to other similar architectures such as Docker Swarm or Apache Mesos, and this embodiment does not limit this.
[0027] like Figure 1 FIG2 is a schematic diagram of the Kubernetes architecture according to an exemplary embodiment of the present specification. In terms of cluster management, Kubernetes can divide the machines in the cluster into one or more master nodes and some worker nodes. Figure 1 For the sake of convenience in the example, only one Master and three Nodes (Node1, Node2, and Node3) are shown.
[0028] (1)Master
[0029] The Master in Kubernetes refers to the main node used for cluster control. Every Kubernetes cluster requires a Master to be responsible for the management and control of the entire cluster. Basically, all control commands of Kubernetes are sent to it, and it is responsible for the specific execution process. The Master can occupy one or more independent servers.
[0030] A set of cluster management-related processes 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 are all completed automatically.
[0031] (2)Node
[0032] A node is a working 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 operation. The smallest operating unit managed by Kubernetes on a node is a Pod. A node can run one or more Pods. For example, Figure 1 Node1, Node2, and Node3 shown in the figure can run different numbers of Pods. Kubernetes' kubelet and kube-proxy service processes can run on the Nodes. These service processes are responsible for creating, starting, monitoring, restarting, and destroying Pods, as well as implementing a software-based load balancer.
[0033] (3)Pod
[0034] A Pod can be composed of one or more containers. For example, if at least two container applications are tightly coupled and combined into a whole to provide external services, these at least two containers can be packaged into a Pod.
[0035] 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 then be scheduled to run on a Node. The Pod provides an independent runtime environment for the program, allowing it to run without being affected by the external environment.
[0036] In other examples, a Pod can contain at least two containers; for example, when there are at least two containerized applications that are tightly coupled and combined into a whole to provide external services, the at least two containers can be packaged into a Pod. This approach is usually used for two closely related services, such as a web service program and its log collection program, or an application and its auxiliary tasks, etc. By packaging them in the same Pod, they can work together better. Cloud services can be provided to users based on the above-mentioned container management platform. For example, when a user needs to run an instance in the cloud, one or more Pods can be created in the container management platform and scheduled to run in the Node. The Pod contains the container corresponding to the user's instance.
[0037] 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 using virtual Layer 2 networking technologies. Therefore, in Kubernetes, containers in one Pod can communicate directly with containers in Pods on other machines.
[0038] Typically, when a container in a pod stops, Kubernetes automatically detects this and restarts the pod (and all its containers). If the node hosting the pod crashes, all pods on that node are rescheduled to other nodes. When a pod is scheduled to a different node, its IP address changes. Therefore, it's common for a pod's IP address to change frequently in Kubernetes.
[0039] In some application scenarios, there is a need to micro-isolate network requests between pods. 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 desired to isolate network requests between the two namespaces.
[0040] Related technologies use the firewall function of the operating system to achieve this. For example, based on the IP+port mode, the IP and port of all Pods in the cluster are obtained, and these IP and port lists are set as rules to achieve the effect of container micro-isolation.
[0041] For example, each pod in Namespace A can run on one or more nodes. For each node involved in Namespace A, set 50 isolation rules to deny the IP addresses and ports of 50 containers in Namespace B.
[0042] Similarly, each Pod under Namespace B can also run on one or more Nodes. It is also necessary to set 10 isolation rules for the firewall of each Node involved in Namespace B to reject the 10 container IPs and ports under Namespace A.
[0043] Due to the nature of container deployment, the IP addresses of the 60 containers in Namespace A and Namespace B may change frequently. 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.
[0044] The above example shows that in this solution, the number of isolation rules is positively correlated with the number of pods, making them large and difficult to maintain. Furthermore, due to the frequent changes in container IP addresses, isolation rules also frequently change. The complexity of virtual and physical IP addresses can easily lead to misconfiguration of isolation rules, making isolation stability unreliable.
[0045] Based on this, this description provides an embodiment of a container group isolation method based on a container management platform. The isolation rules use the attribute information of the container group in the definition data of the container group. Therefore, this attribute information will not change with the frequent scheduling of the container group. Therefore, there is no need to update the isolation rules based on the scheduling of the container group to different working nodes. Therefore, the stability and accuracy of the isolation can be guaranteed, and the maintenance cost of the isolation rules is low.
[0046] like Figure 2A As shown, Figure 2A This is a flowchart of 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 working node in a working node cluster for execution. The container group is created based on definition data of the container group, and the definition data includes at least one attribute information of the container group. The method is applied to the working node, and the method may include the following steps:
[0047] In step 202, a preset isolation rule is obtained.
[0048] The isolation rule includes target attribute information of at least two types of container groups that need to be network isolated, and the target attribute information is attribute information included in the definition data.
[0049] In step 204 , in response to obtaining the network request, attribute information of the source container group that issues 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.
[0050] 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.
[0051] As an example, the container management platform creates resource objects based on the definition data of the resource objects. Taking Kubernetes as an example, most concepts such as Node or Pod can be regarded as a resource object. All resource objects in Kubernetes can be defined or described using a file in a non-markup language name (YAML Ain't Markup Language, YAML) or object notation (JavaScript Object Notation, JavaScript, JSON) format. For example, the definition file of the working node can be submitted to the master node in Kubernetes so that the master node can obtain the information of the working node defined in the file after receiving the working node definition file. The definition file of the Pod can be submitted to the master node in Kubernetes so that the master node can create the Pod after receiving the Pod definition file and schedule it to run in a certain working node.
[0052] Among them, the definition data of the container group can be used to define one or more information of the Pod, such as name, label, number of replicas, CPU limit, memory limit or storage volume, etc. In actual application, it can be configured as needed, and this embodiment does not limit this.
[0053] For example, in a container management platform, a label can be a key-value pair, where the key and value are user-defined. 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 defined when a resource object is defined, but can also be added or removed dynamically after the object is created.
[0054] Therefore, the container group's definition data includes one or more fixed attributes of the container group, i.e., 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; rather, it is not user-defined attribute information in the definition file. Instead, it is assigned by the container management platform after the Pod is created based on the definition file. The IP address will change as the Pod is scheduled. The isolation rules of this embodiment utilize these attributes in the definition data that do not change when the Pod is scheduled, so there is no need to update the isolation rules after the Pod is scheduled.
[0055] In some examples, the method can be applied to an isolation program, where each worker node in the worker node cluster can run 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 can be a program running on an operating system or included in the operating system as a sub-function of the operating system.
[0056] like Figure 2B The figure shows an application scenario diagram of container group isolation according to an exemplary embodiment of this specification. Figure 1 Based on this, the isolation program of this embodiment can be run on each Node, such as Figure 2B Isolation programs 1, 2, and 3 are shown in the figure, and these isolation programs implement micro-isolation of containers. Container micro-isolation in this embodiment isolates network requests between pods in a cluster that could otherwise communicate with each other. This prevents east-west attacks between containers and reduces the attack surface.
[0057] As an 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 the user-configured custom isolation rules and then send the isolation rules to other isolation programs. For example, the isolation program can provide a configuration interface for configuring custom isolation rules. This configuration interface can be implemented in a variety of ways. For example, a graphical user interface can be used to provide users with the ability to change the configuration information of the isolation rules. 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 enter specific commands and parameters through a command line interface to submit the isolation rules. Alternatively, a predefined configuration file format can be used to save the isolation rules in a file. Users can directly edit the configuration file and save the edited file to submit the isolation rules, etc. Depending on actual needs, one or more of the above different interface implementation methods can be combined and used, and this embodiment does not limit this. The above embodiment facilitates user configuration of isolation rules and enables each node to obtain user-configured isolation rules in a timely manner. Users can configure isolation rules using the configuration interface of one client. After obtaining the isolation rules, the client can send them to other clients in various ways. For example, the client sends them to the server, which then sends them to clients running on other worker nodes in the worker cluster. Alternatively, clients can communicate directly with each other, with the client that obtains the isolation rules sending them directly to other clients.
[0058] Alternatively, a server may be implemented. Exemplarily, obtaining the preset isolation rules may include:
[0059] Obtain preset isolation rules from the server, where the isolation rules are configured by the server.
[0060] As an example, the server can obtain user-configured custom isolation rules and send them to other isolation programs. The server can provide a configuration interface for configuring custom isolation rules. The implementation of this configuration interface can be found in the embodiment of the client configuration interface described above. Based on this, the server can receive user-submitted isolation rules and send them to the client running on each worker node in the worker node cluster.
[0061] Exemplarily, the isolation program of this embodiment can continue to run after the working node is started. The working nodes in the working node cluster may change, such as adding a new working node, or scheduling the working node to another machine after the machine where the working node is located is shut down. The isolation program of this embodiment can be online as the working node is online, and offline as the working node is offline. Therefore, when the working node cluster contains multiple working nodes, each working node can obtain the current isolation rules in a timely manner, and at the same time, it is guaranteed that the container group isolation embodiment can be executed based on the isolation rules on each working node, thereby ensuring the stability and accuracy of the isolation.
[0062] In this embodiment, the isolation program can detect the network requests generated by each process running on the Node. Based on the network protocol, the network request can carry one or more types of information, based on which the source container group that issued the network request and the destination container group to which it is sent can be located. It can be determined whether the label information of the source container group and the label information of the destination container group hit the isolation rule 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.
[0063] In practical applications, isolation rules can be implemented in a variety of ways. Isolation rules use the attribute information in the Pod definition file to describe which container groups require network isolation. For example, the isolation rule contains the attribute information of two types of container groups that require network isolation, which can distinguish the source Pod and the destination Pod, and thus intercept the network request from the source Pod to the destination Pod. As an example, the isolation rule can be:
[0064] srcNamespace:aaa,targetNamespace:bbb
[0065] This isolation rule uses two key-value pairs as an example. The first key-value pair indicates that the namespace of a source Pod to be isolated is aaa, and the second key-value pair indicates that the namespace of a destination Pod to be isolated is bbb.
[0066] In other examples, an isolation rule may include attribute information of multiple types of container groups that require network isolation. For example, the isolation rule may specifically include:
[0067] srcNamespace:aaa,targetNamespace:bbb,targetNamespace:ccc
[0068] Compared to the previous isolation rule, this one adds a category of destination Pods whose namespace is ccc. That is, container groups in namespace aaa destined for namespace bbb or namespace ccc need to be isolated.
[0069] In other examples, source and destination Pods may not be distinguished, and network requests between the two types of container groups may be intercepted. In actual applications, isolation rules can be implemented in a variety of ways, which are not limited in this embodiment.
[0070] For example, the attribute information of the container group included 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:
[0071] Pod name (Name) refers to the unique name identifier of the Pod in the Kubernetes cluster.
[0072] Namespace refers to the namespace to which a Pod belongs, which is used to isolate and manage resources in the cluster.
[0073] Labels: Labels in the form of key-value pairs used to identify and select Pods.
[0074] Annotations refer to metadata information related to Pod, providing additional descriptive information.
[0075] Images refer to the name and version information of the image used by the container in the Pod.
[0076] The attribute information of the Pod used in the isolation rule in 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.
[0077] Exemplarily, the maintained isolation rule may be one or more, which is not limited in this embodiment.
[0078] In some examples, the information carried by the network request includes: source network information representing a source container group that issues the network request, and destination network information representing a destination container group to which the network request is sent; and determining, based on the information carried by the network request, attribute information of the source container group that issues the network request and attribute information of the destination container group to which the network request is sent, may include:
[0079] 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;
[0080] Based on the container group data, attribute information of a source container group corresponding to the source network information and attribute information of a destination container group corresponding to the destination network information are determined.
[0081] As an example, in a network protocol, a network request may carry multiple types of information. For example, a network request may carry source network information and destination network information.
[0082] Source network information, including the IP address and port number of the network request initiator, identifies the source of the request. Destination network information, including the target IP address and port number of the network request, specifies the destination of the network request. Therefore, the source and destination Pods of a network request can be determined using the IP address and port number.
[0083] In addition, you can obtain container group data for a container group cluster, namely, the container information for each container group in the cluster, from the container management platform. The container management platform creates container groups based on definition files. The container management platform stores the Pod information defined in the Pod definition file and also maintains more information about the Pod, 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 the attribute information of the source container group corresponding to the source network information and the attribute information of the destination container group corresponding to the destination network information.
[0084] For example, the container group data of 100 Pods in the container group cluster obtained from the container management platform may include:
[0085] Pod1 information: name, namespace, app, network information, image, annotations, etc.
[0086] Pod2 information: name, namespace, app, network information, image, annotations, etc.
[0087] …
[0088] Various Pod100 information: name, namespace, app, network information, image, annotations, etc.
[0089] The source and destination network information carried in the monitored network request are abcd and efgh respectively. Searching for abcd and efgh in the container group data shows that they correspond to Pod8 and Pod9 respectively.
[0090] The isolation rule contains the target attribute information of at least two types of container groups that need to be isolated, which is Namespace, namely aaa and bbb. The Namespaces of Pod8 and Pod9 are aaa and bbb, respectively, which match the isolation rule. Therefore, the network request can be isolated.
[0091] As another example, the source IP and destination IP in the network protocol can be associated with the corresponding container Pod information. For example, if the source IP is 1.2.3.4, the cache query shows that it is the IP of Pod A, pod A's Namespace is 1, image is 2, and app is 3. At this time, there is also a rule such as "Source APP: 3" in the isolation rule, and this network request is associated with this rule.
[0092] 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 achieving micro-isolation of Pods based on network information.
[0093] Therefore, this embodiment first determines the attribute information of the source container group and the attribute information of the destination container group through the address information and container group data in the network request, and then determines whether the isolation rule is hit. It can accurately implement the isolation of network requests, and the isolation rules do not need to be maintained based on the frequent scheduling of Pods, so the maintenance cost is low.
[0094] In some examples, the container management platform provides a container group information acquisition interface; obtaining the container group data of the container group cluster provided by the container management platform may include:
[0095] A call request for container information of each container group in the container group cluster is initiated to the container group information acquisition interface to obtain container group data containing container information of each container group in the container group cluster returned by the container management platform, and then the container group data is stored locally.
[0096] 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.
[0097] 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 acquisition interface (such as Representational State Transfer, RESTful). By sending a call request to this interface, you can communicate with the Kubernetes cluster and obtain information about various resources, including Pod information.
[0098] In specific implementation, you can construct a call request to the container group information acquisition interface API, for example, you can specify the API path or parameters of the Pod information to be obtained, etc.
[0099] Send a call request, for example, you can send the constructed call request to the endpoint of the Kubernetes API server.
[0100] Parse the API response. For example, after receiving the API response, parse the response data, which can be JSON or other formats, to extract the required Pod information. The information of each Pod is usually included in the response list.
[0101] Process Pod information, for example, process or use the Pod information obtained from the API as needed.
[0102] In actual applications, Pods in a cluster may be frequently scheduled, and Pod information may change frequently. Therefore, it is necessary to maintain a new and accurate container group data. Therefore, in some examples, obtaining the container group data of the container group cluster provided by the container management platform may also include a combination of one or more of the following steps:
[0103] Periodically sending the call request to update the locally stored container group data;
[0104] In response to a worker node change in the worker node cluster, sending the call request to update the locally stored container group data;
[0105] In response to a container group change occurring in the container group cluster, the call request is sent to update locally stored container group data.
[0106] This embodiment can implement local caching of an accurate copy of container group data through one or more of the above methods to achieve accurate isolation of network requests.
[0107] For example, you can periodically send call requests to update locally stored container group data. You can also periodically send call requests to obtain current container group data to ensure the accuracy of locally stored data. You can also set up a scheduled task or periodic polling mechanism to send requests to the container management platform at a certain frequency to obtain container group information and update local storage.
[0108] When worker nodes are added, removed, or their status changes in the worker node cluster, a call request can be sent in a timely manner to update the locally stored container group data. By monitoring changes in worker nodes, the consistency of container group data and cluster status can be maintained.
[0109] It monitors changes to container groups in a container group cluster, such as creation, deletion, and scheduling, and sends a call request to update the locally stored container group data whenever a change occurs. This ensures that the locally stored container group data promptly reflects the actual situation in the cluster, maintaining data accuracy.
[0110] By combining and applying the above methods, an accurate copy of container group data can be effectively maintained, thereby improving the stability and reliability of the network isolation of this embodiment.
[0111] In this embodiment, network request isolation can be implemented in a variety of ways. For example, it can be achieved by intercepting network requests. For example, the isolation program can intercept network requests so that the network request is not sent to the destination Pod. The source Pod and the destination Pod cannot complete the TCP three-way handshake, and thus the two cannot establish a connection. Optionally, other isolation behaviors can also be included in actual applications, such as redirection, etc., which are not limited in this embodiment.
[0112] In some examples, the isolation rule may include: target attribute information of the first type of container group to be network isolated, target attribute information of the second type of container group, and the type of isolation behavior;
[0113] 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:
[0114] 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, the network request is isolated according to the type of the isolation behavior.
[0115] In this embodiment, the isolation rules maintained by the isolation program may be rules for different isolation behaviors. The isolation rules may include the type of isolation behavior. The specific type can be configured according to actual needs, for example, interception, redirection, isolation sandbox, analysis, etc.
[0116] For example, interception means not sending a network request to the destination Pod. Redirection means that when a network request is detected to have a potential security risk, the request can be redirected to a secure environment for processing to ensure the security of the system and data. Isolation sandboxing allows suspicious or untrusted network requests to be placed in an isolated sandbox environment to limit their access rights and scope of influence, while monitoring their behavior and preventing damage to the system. Analysis means conducting in-depth review and analysis of network requests to identify possible malicious code, attack behaviors, or anomalies, and taking appropriate protective measures in a timely manner.
[0117] Based on this, this embodiment can implement a variety of different types of isolation behaviors through isolation rules, which can meet the needs of users to implement different processing methods for different types of network requests.
[0118] As can be seen from the above embodiments, using the container attribute isolation strategy instead of the existing IP+port isolation strategy avoids micro-isolation rule configuration issues caused by rule expansion due to inaccurate IP acquisition or frequent IP changes, 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 purpose. Moreover, since the isolation rules use the Pod's attribute information and are independent of the IP, they remain effective after the Pod's IP changes, ensuring the stability of the isolation rules.
[0119] like Figure 2C As shown, this specification illustrates a flowchart of another embodiment of a container group isolation method based on a container management platform according to an exemplary embodiment. When each working node in the working node cluster starts working, it can obtain isolation rules, such as obtaining isolation rules through a server or other means as in the aforementioned embodiment; it can also obtain container group data, such as obtaining container group data through a container management platform or other means as in the aforementioned embodiment; when the working node obtains a network request for this node, it can 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 through the information carried in the network request, such as the source network information and the destination network information. Therefore, it is possible to determine whether the isolation rules are matched based on the attribute information of the source container group and the attribute information of the destination container group; if they do not match, the network request may not be isolated; if they match, the corresponding isolation behavior may be executed.
[0120] Corresponding to the aforementioned embodiment of the container group isolation method based on the container management platform, this specification also provides an embodiment of a container group isolation device based on the container management platform and a computer device used therein.
[0121] The embodiment of the container group isolation device based on the container management platform of this specification can be applied to computer devices, such as servers or terminal devices. The device embodiment can be implemented through software, or through hardware or a combination of software and hardware. Taking software implementation as an example, as a device in a logical sense, it is formed by the processor of the file processing in which it is located reading the corresponding computer program instructions in the non-volatile memory into the memory for execution. From the hardware level, such as Figure 3 The following is a hardware structure diagram of the computer equipment where the container group isolation device of the container management platform is located. Figure 3 In addition to the processor 310, memory 330, network interface 320, and non-volatile memory 340 shown, the computer device in which the container group isolation device based on the container management platform is located in the embodiment may also include other hardware, generally depending on the actual function of the computer device, which will not be described in detail.
[0122] As an example, a container group isolation device based on a container management platform can be applied to a working node. The device may include:
[0123] A rule maintenance module is configured to: obtain a preset isolation rule, wherein the isolation rule includes target attribute information of at least two types of container groups that require network isolation, wherein the target attribute information is attribute information included in the definition data;
[0124] a determination module configured to: in response to obtaining a network request, determine 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 based on information carried in the network request;
[0125] The isolation determination module is 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.
[0126] In some examples, the apparatus is applied to an isolation program, a worker node in the worker node cluster runs the isolation program, and the rule maintenance module obtains a preset isolation rule, including:
[0127] Obtain preset isolation rules from the server, where the isolation rules are configured by the server.
[0128] In some examples, the information carried by the network request includes: source network information representing a source container group that issues the network request, and destination network information representing a destination container group to which the network request is sent;
[0129] The determining module determines, based on the information carried in the network request, the attribute information of the source container group that issues the network request and the attribute information of the destination container group to which the network request is sent, including:
[0130] 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;
[0131] 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 are determined.
[0132] In some examples, the container management platform provides a container group information acquisition interface;
[0133] The determining module obtains the container group data of the container group cluster provided by the container management platform, including:
[0134] 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 containing the container group information of each container group in the container group cluster returned by the container management platform, and then the container group data is stored locally.
[0135] In some examples, the determining module, which obtains the container group data of the container group cluster provided by the container management platform, is further configured to:
[0136] Periodically sending the call request to update the locally stored container group data;
[0137] 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 / or,
[0138] In response to a container group change occurring in the container group cluster, the call request is sent to update locally stored container group data.
[0139] In some examples, the isolation rule includes: target attribute information of the first type of container group to be network isolated, target attribute information of the second type of container group, and the type of isolation behavior;
[0140] The isolation determination module isolates 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, including:
[0141] 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, the network request is isolated according to the type of the isolation behavior.
[0142] The implementation process of the functions and effects of each module in the above-mentioned container group isolation device based on the container management platform is detailed in the implementation process of the corresponding steps in the above-mentioned container group isolation method based on the container management platform, and will not be repeated here.
[0143] Accordingly, an embodiment of this specification also provides a container management system, which 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 execute the steps of the aforementioned container group isolation method embodiment based on the container management platform.
[0144] Accordingly, an embodiment of this specification further provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of the aforementioned embodiment of the container group isolation method based on the container management platform.
[0145] Accordingly, an embodiment of this specification also provides a computer device, including 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 steps of an embodiment of a container group isolation method based on a container management platform are implemented.
[0146] Accordingly, an embodiment of this specification further provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the steps of an embodiment of a container group isolation method based on a container management platform are implemented.
[0147] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to the partial description of the method embodiments. The device embodiments described above are merely illustrative, wherein the modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, that is, they may be located in one place, or they may be distributed on multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this specification. A person of ordinary skill in the art can understand and implement it without paying any creative work.
[0148] The above embodiments can be applied to one or more computer devices, where the computer device is a device that can automatically perform numerical calculations and / or information processing according to pre-set or stored instructions. The hardware of the computer device includes but is not limited to a microprocessor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a digital signal processor (DSP), an embedded device, etc.
[0149] The computer device may be any electronic product that can interact with a user, such as a personal computer, a tablet computer, a smart phone, a personal digital assistant (PDA), a game console, an interactive network television (IPTV), a smart wearable device, etc.
[0150] The computer device may also include a network device and / or a user device, wherein 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.
[0151] The network where the computer device is located includes but is not limited to the Internet, wide area network, metropolitan area network, local area network, virtual private network (VPN), etc.
[0152] The foregoing description of this specification describes specific embodiments. 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. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.
[0153] The steps of the various methods above are divided only for the purpose of clear description. When implemented, they can be combined into one step or some steps can be split and decomposed into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this patent; adding insignificant modifications or introducing insignificant designs to the algorithm or process without changing the core design of the algorithm and process are all within the scope of protection of this application.
[0154] Although this specification includes many specific implementation details, these should not be interpreted as limiting the scope of any invention or the scope of protection claimed, but are mainly used to describe the features of specific embodiments of specific inventions. Certain features described in multiple embodiments within this specification may also be implemented in combination in a single embodiment. On the other hand, the various features described in a single embodiment may also be implemented separately in multiple embodiments or in any suitable sub-combination. In addition, although features may work in certain combinations as described above and even initially claimed as such, one or more features from the claimed combination may be removed from the combination in some cases, and the claimed combination may point to a sub-combination or a variation of the sub-combination.
[0155] The phrases "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. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.
[0156] Other embodiments of the present invention will readily occur to those skilled in the art upon consideration of the present invention and practice of the invention claimed herein. This specification is intended to cover any variations, uses, or adaptations of the present invention that follow the general principles of this specification and include common knowledge or customary techniques in the art not claimed herein. The description and examples are to be considered as exemplary only, with the true scope and spirit of the present invention being indicated by the following claims.
[0157] It should be understood that the present description is not limited to the exact structure that has been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present description is limited only by the appended claims.
[0158] 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 should be included in the scope of protection of this specification.
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 working node, and the method includes: Obtaining a preset isolation rule, wherein the isolation rule includes target attribute information of at least two types of container groups that require network isolation, wherein the target attribute information is attribute information included in the definition data; In response to obtaining the network request, 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; 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 is applied to an isolation program, wherein a worker node in the worker node cluster runs the isolation program, and obtaining 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 claim 1, wherein the information carried by the network request includes: 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 the information carried by the network request, the attribute information of the source container group that issues the network request and the attribute information of the 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; 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 are determined.
4. The method according to claim 3, wherein the container management platform provides a container group information acquisition interface; The obtaining of the container group data of the container group cluster provided by the container management platform includes: 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 containing the container group information of each container group in the container group cluster returned by the container management platform, and then 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; In response to a container group change occurring in the container group cluster, the call request is sent to update the locally stored container group data.
6. The method according to claim 1, 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, the network request is isolated according to the type of the isolation behavior.
7. A container management system, the system comprising a worker node cluster, the worker node cluster comprising at least one worker node, the worker node being used to run at least one container group; the worker node being used to execute the steps of any one of the methods 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 steps of the method according to any one of claims 1 to 6 are implemented.
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.