Container network configuration method and device, equipment and storage medium

Abstract

The invention provides a container network configuration method and device, equipment and a storage medium. The method comprises the following steps: in response to a container group Pod creation instruction, calling a container group to create an application programming interface (API), creating the container group, and appointing a network configuration identifier of the container group; wherein the network configuration identifier and the subnet have a mapping relationship; in a configuration file, obtaining a subnet corresponding to the network configuration identifier; wherein one container group corresponds to one network configuration identifier, and one network configuration identifier corresponds to one subnet; and allocating a network protocol IP address to the container in the container group according to the subnet corresponding to each container group, configuring a gateway for the container in the container group according to the allocated IP address, and allowing the container in the container group to access an external network through the gateway.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to the fields of cluster technology, container management, and container network management. Background Technology

[0002] Containers are a lightweight, portable, and self-contained software packaging technology that packages an application and all its dependencies (such as code, runtime, libraries, configuration files, etc.) together, enabling it to run consistently in any environment that supports container runtimes. The goal of container networking is to enable communication between containers and between containers and the outside world. However, container network management schemes in clusters often have complex architectures, leading to complex network configuration processes and a high risk of errors. Summary of the Invention

[0003] This disclosure provides a container network configuration method, apparatus, device, and storage medium to solve or mitigate one or more technical problems in the prior art.

[0004] Firstly, this disclosure provides a container network configuration method, including: In response to the Pod creation command, the container group creation application programming interface (API) is invoked to create the container group and specify the network configuration identifier of the container group; wherein, the network configuration identifier has a mapping relationship with the subnet; In the configuration file, the subnet corresponding to the network configuration identifier is obtained; wherein, one container group corresponds to one network configuration identifier, and one network configuration identifier corresponds to one subnet; Assign network protocol IP addresses to containers in each container group based on the subnet corresponding to each container group, and configure gateways for the containers in the container group based on the assigned IP addresses, allowing the containers in the container group to access the external network through the gateways.

[0005] Secondly, this disclosure provides a container network configuration apparatus, including: The first creation module is used to respond to the Pod creation command by calling the Container Group Creation Application Programming Interface (API) to create the container group and specify the network configuration identifier of the container group; wherein, the network configuration identifier has a mapping relationship with the subnet; A delivery module is used to deliver the network configuration identifier of the container group to the network configuration plugin; The first acquisition module is used to acquire the subnet corresponding to the network configuration identifier of the container group according to the network configuration identifier in the configuration file; wherein, one container group corresponds to one network configuration identifier, and one network configuration identifier corresponds to one subnet; The allocation module assigns network protocol IP addresses to containers in the container group according to the subnet corresponding to each container group, and configures a gateway for the containers in the container group according to the assigned IP addresses, allowing the containers in the container group to access the external network through the gateway.

[0006] Thirdly, an electronic device is provided, comprising: At least one processor; and The memory is communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform any of the methods described in the present disclosure.

[0007] Fourthly, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause the computer to perform any of the methods according to embodiments of the present disclosure.

[0008] Fifthly, a computer program product is provided, including a computer program that, when executed by a processor, implements any of the methods according to embodiments of the present disclosure.

[0009] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0010] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the various drawings denote the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings depict only some embodiments provided according to this disclosure and should not be construed as limiting the scope of this disclosure.

[0011] Figure 1 This is a flowchart illustrating a container network configuration method according to an embodiment of the present disclosure; Figure 2 This is a flowchart illustrating a container network configuration method according to another embodiment of the present disclosure; Figure 3 This is a flowchart illustrating a container network configuration method according to another embodiment of the present disclosure; Figure 4 This is a flowchart illustrating a container network configuration method according to another embodiment of the present disclosure; Figure 5 This is an architecture diagram of a container configuration system according to an embodiment of the present disclosure; Figure 6This is a schematic flowchart illustrating the initialization process of a container configuration method according to an embodiment of the present disclosure; Figure 7 This is a schematic flowchart of a container creation method according to an embodiment of the present disclosure; Figure 8 This is a schematic diagram of a container network configuration apparatus according to an embodiment of the present disclosure; Figure 9 This is a schematic diagram of the structure of a container network configuration apparatus according to another embodiment of the present disclosure; Figure 10 This is a block diagram of an electronic device used to implement the methods of the embodiments of this disclosure. Detailed Implementation

[0012] The present disclosure will now be described in further detail with reference to the accompanying drawings. The same reference numerals in the drawings denote elements that have the same or similar functions. Although various aspects of embodiments are shown in the drawings, they are not necessarily drawn to scale unless specifically indicated otherwise.

[0013] Furthermore, to better illustrate this disclosure, numerous specific details are set forth in the following detailed description. Those skilled in the art will understand that this disclosure can be practiced without certain specific details. In some instances, methods, means, components, and circuits well known to those skilled in the art have not been described in detail in order to highlight the main points of this disclosure.

[0014] The technical terms used in the embodiments of this disclosure will be explained below: CNI (Container Network Interface) is a project of the Cloud Native Computing Foundation. It consists of a set of specifications and libraries for writing plugins to configure network interfaces in Linux containers, and includes a series of supported plugins. CNI focuses on container network connectivity and the removal of allocated resources when a container is deleted. This focus has led to widespread support for CNI, and its specifications are easy to implement. It not only defines the rules for creating and managing container network resources, but also implements and provides built-in and general-purpose network plugins, while also reserving space for third-party implementations to extend its specifications.

[0015] containerd is an open-source container runtime that runs as a daemon on the system. It exposes an underlying Remote Procedure Call (RPC) application programming interface (API) for upper-layer systems (such as container orchestration systems like Swarm, Kubernetes, and Mesos) to manage containers on the machine. containerd manages the entire lifecycle of a container, including image transfer and storage, container execution and monitoring, underlying storage and network attachments, emphasizing simplicity, robustness, and portability.

[0016] containerd API: The application programming interface provided by containerd. Through this interface, upper-layer systems can call containerd functions to manage the container lifecycle, such as creating, starting, stopping, and deleting containers, as well as managing container images.

[0017] containerd / plugins: This is the plugin system for containerd. Containerd has an extensible plugin architecture, allowing users to extend its functionality by developing and installing plugins. For example, different storage drivers and network plugins can be implemented through plugins. The bridge plugin discussed in this article is one such network plugin, used to implement specific container network configuration functions.

[0018] The bridge plugin is a network plugin within the containerd / plugins component. Through custom development of its source code, it manages different network segments and outgoing interfaces based on the container's namespace. This plugin reads a configuration file (located in the / etc / cni / net.d / directory) that conforms to containerd's CNI version standard specifications, thereby configuring the container network, including assigning IP addresses, gateways, and determining outgoing interfaces.

[0019] Kubernetes is an open-source container orchestration system that automates the deployment, scaling, and management of containers, helping users manage large-scale containerized applications more efficiently. Kubernetes comprises numerous components, such as kube-controller-manager (responsible for managing and controlling resources within the cluster), kube-scheduler (responsible for scheduling containers), kube-api-server (providing APIs for interaction with other components), kube-proxy (implementing service discovery and load balancing), and kube-flannel (a CNI plugin used to provide network solutions for Kubernetes clusters). However, due to the large number of components, the operational costs are high, and the technical requirements are also demanding.

[0020] multus-cni: An open-source plugin compliant with the CNI specification, used as a "meta-plugin" on Kubernetes. It does not provide network configuration functionality itself, but instead calls other CNI-compliant plugins (such as flannel, SR-IOV CNI plugin, etc.) to configure multiple network interfaces for containers in a Kubernetes environment, thereby supporting network redundancy and providing support for scenarios such as control plane and data plane separation.

[0021] Pod: The smallest manageable "container" unit in Kubernetes, which can be simply understood as a collection of closely related containers. These containers share resources such as storage and network, and containers within the same Pod typically collaborate closely to complete specific business functions. In this patented solution, by identifying the namespace at the time of Pod creation, different Pods can be configured with different network segments.

[0022] Namespace: In this solution, namespaces are the key identifiers for implementing segmented container network management. Each Pod is associated with a namespace upon creation. The bridge plugin identifies this namespace and, based on the mapping between namespaces and network segments stored in the configuration file ( / etc / cni / net.d / ), allocates appropriate network resources to the Pod, such as IP addresses, gateways, and outgoing interfaces for a specific network segment. This enables the isolation and management of different Pods across different network segments. In containerd, namespaces are also used for logical isolation of resources such as images and containers; resources under different namespaces are independent of each other.

[0023] Figure 1 This is a flowchart illustrating a container network configuration method according to an embodiment of the present disclosure. In one embodiment, the method may include: S110. In response to the container group Pod creation instruction, the container group creation application programming interface (API) is invoked to create the container group and specify the network configuration identifier of the container group; wherein, the network configuration identifier has a mapping relationship with the subnet; S120. In the configuration file, obtain the subnet corresponding to the network configuration identifier; wherein, one container group corresponds to one network configuration identifier, and one network configuration identifier corresponds to one subnet; S130. Assign network protocol IP addresses to containers in the container group according to the subnet corresponding to each container group, configure gateways for containers in the container group according to the assigned IP addresses, and allow containers in the container group to access the external network through the gateways.

[0024] In one embodiment of this disclosure, a container is an operating system-level virtualization technology that encapsulates an application and all its runtime dependencies (including binary files, libraries, configuration files, environment variables, etc.) into a lightweight, portable, self-contained execution unit. This unit shares the operating system kernel with the host machine and other containers, and achieves isolation and restriction of resources such as processes, networks, file systems, and users through Linux kernel mechanisms such as namespaces and control groups (cgroups).

[0025] In one embodiment of this disclosure, namespaces are an isolation mechanism provided by the Linux kernel. By creating independent instances (i.e., "namespaces") for specific types of system resources, processes running in different namespaces have their own private global resource views, achieving process-level environment isolation without relying on hardware virtualization. Namespaces are one of the underlying technologies for building containers (such as Docker, containerd, and Podman). Namespaces can be used to implement segmented management of container networks. Each container group (Pod) is associated with a namespace upon creation. The bridge plugin identifies this namespace and, based on the mapping between namespaces and network segments (or subnets) stored in the configuration file, allocates corresponding network resources to the container group (Pod), such as IP addresses, gateways, and outgoing interfaces for specific network segments, thereby achieving isolation and management of different Pods in different network segments. In the container runtime (containerd), namespaces can be used to logically isolate resources such as images and containers, with resources under different namespaces being independent of each other.

[0026] In one embodiment of this disclosure, a subnet (also known as a network segment) is a logical division of a large IP network into several smaller, independently managed network segments using subnetting technology. Subnetting can improve IP address utilization, enhance network performance, simplify network management, and improve security. In the TCP / IP protocol suite, a subnet refers to a part of an IP network. It has a unique network prefix and is distinguished from the host portion by a subnet mask. An IP address logically consists of a network prefix and a host identifier. The network prefix, located in the high-order bits of the address, identifies the physical network where the host resides. The host identifier, located in the low-order bits of the address, identifies a specific host within that network. For example, an IPv4 address is a 32-bit binary number composed of four decimal numbers ranging from 0 to 255, separated by periods (.). Each number represents 8 bits, or one byte. To distinguish between the network prefix and the host identifier, IPv4 uses a subnet mask. Both IPv4 and IPv6 can use the more modern Classless Inter-Domain Routing (CIDR) notation. CIDR notation appends a forward slash ( / ) and the number of bits in the network prefix to the IP address. For example, for the subnet "10.22.1.0 / 24", the first 24 bits represent the network prefix, i.e., "10.22.1", and the remaining 8 bits are the host identifier, i.e., "1", with a corresponding subnet mask of 255.255.255.0. Devices within the same subnet can communicate directly (usually within the same broadcast domain), while communication across subnets requires forwarding through a router or Layer 3 switch.

[0027] In one embodiment of this disclosure, the mapping relationship between namespaces and subnets can be pre-defined. For example, in a configuration file, the mapping relationship between namespace "ns1" and subnet "10.22.1.0 / 24", and the mapping relationship between namespace "ns2" and subnet "10.22.2.0 / 24", can be set. When creating a container group, the namespace of the created container group can be set according to the namespace in the namespace-subnet mapping relationship. That is, it is allowed to select an unused preset namespace from a plurality of preset namespaces as the namespace of the created container group. For example, if the namespace mapping relationship contains namespaces "ns1", "ns2", "ns3", and "ns4", when creating a new container group, the namespace of the new container group can be set to "ns1". If "ns1" has been used by other container groups, the namespace of the new container group is set to "ns2".

[0028] In one embodiment of this disclosure, the Container Network Interface (CNI) is used to write plugins to configure the network interface in a Linux container. The CNI can include a series of supported plugins. The CNI focuses on the container's network connectivity and the removal of allocated resources when the container is deleted. The CNI can not only define rules for the creation and management of container network resources, but also provide built-in and general-purpose network plugins.

[0029] In one embodiment of this disclosure, from the perspective of network model type, CNI plugins can be categorized into Overlay network plugins, Underlay / Layer 3 network plugins, and cloud plugins. From a functional perspective, CNI plugins can be categorized into basic network plugins, policy-driven network plugins, and high-performance / next-generation network plugins. CNI (Container Network Interface) plugins can provide standardized, pluggable network configuration capabilities for container runtimes (e.g., containerd). Through CNI plugins, containers can obtain independent namespaces, IP addresses, routing, and DNS, thereby enabling reliable communication across hosts and nodes. A container group (Pod) is the smallest manageable "container" unit in a cluster, a collection of closely related containers. These containers share storage, network, and other resources, and containers within the same Pod can collaborate to complete specific business functions. By identifying the namespace at the time of Pod creation, different Pods can be configured to correspond to different network segments. When containers in a container group start, the CNI plugin can create virtual network interfaces (such as one end of a veth pair) in the container's namespace; allocate a unique IP address from a predefined address pool; and configure basic network parameters such as subnet mask and default gateway. For example, when container group "ns1" is created, the CNI plugin can allocate the subnet "10.22.1.0 / 24" and configure routing for the container group. The CNI plugin can connect container groups to the host or cluster network by connecting their virtual interfaces to the host network stack. For example, it can attach the container group's virtual interfaces to a CNI bridge, such as cni0. Alternatively, it can add the container group's virtual interfaces to a VXLAN / Geneve Overlay tunnel. Or, it can directly bind the container group's virtual interfaces to the physical network. Through the CNI plugin, connectivity between container groups and other containers on the same node, containers on different nodes, and external services can be achieved.

[0030] In one embodiment of this disclosure, the CNI bridge plugin is a basic, built-in network plugin in CNI that enables Layer 2 connectivity between container groups on a single host via a Linux bridge. The CNI bridge plugin can allocate IP addresses using IP Address Management (IPAM) plugins such as host-local and dhcp, thereby constructing a simple local container network. During container group creation, the container group's namespace can be transferred to the CNI bridge plugin via the CNI plugin's environment variables, and then the CNI bridge plugin resolves the environment variables to obtain the container group's namespace.

[0031] In one implementation, the network configuration identifier includes the namespace of the container group or the label of the container group; the mapping relationship between the network configuration identifier and the subnet is used to indicate the correspondence between the network configuration identifier and the subnet.

[0032] In one implementation, one or more of the following parameters are also passed via the network configuration plugin: a network add command; a path to the container's namespace; and environment variables, wherein the environment variables include the network configuration identifier of the container group.

[0033] In one embodiment of this disclosure, since a namespace-subnet mapping relationship is pre-defined, and the namespace specified for the container group when creating the container also comes from the pre-defined namespace-subnet mapping relationship, after the CNI bridge plugin obtains the namespace of the container group, it can search in the namespace-subnet mapping relationship through the namespace of the container group to obtain the subnet corresponding to the namespace of the container group.

[0034] In one embodiment of this disclosure, when creating container groups, multiple container groups can be created in batches, and different namespaces can be assigned to each container group. Namespaces are passed in batches via a CNI plugin, and a batch lookup is performed in the namespace-to-subnet mapping relationship of the configuration file to obtain the subnets corresponding to the namespaces of each of the multiple container groups.

[0035] In one embodiment of this disclosure, a subnet can logically contain multiple IP addresses with the same network prefix. For example, the subnet "10.22.1.0 / 24" can include all IP addresses in the range 10.22.1.x, where x can be 0-255. After obtaining the subnet corresponding to the namespace of the container group, an IP address can be randomly selected from the IP addresses under the subnet and assigned to a container in the container group. For example, for the namespace "ns1", whose corresponding subnet is "10.22.1.0 / 24", 10.22.1.2 can be used as the IP address of a container in this container group.

[0036] In one embodiment of this disclosure, when configuring a gateway for a newly created container group, the interface of the new container group can be added to a CNI bridge plugin. Then, IP addresses are assigned to the containers within the new container group from the subnet corresponding to the namespace of the new container group, and the gateway is configured. For example, for the namespace "ns1" and its corresponding subnet "10.22.1.0 / 24", the IP address 10.22.1.1 under the subnet can be selected as the IP address of the gateway corresponding to the IP addresses of all containers in the container group under that subnet. Different IP addresses are assigned to the containers in the new container group, and the gateway with IP address 10.22.1.1 is used to configure the network for all containers in the new container group. After the gateway configuration is complete, network access permissions for the containers in the new container group can be set, allowing the containers in the new container group to access the external network through the gateway, thus completing the creation of the container group and the automatic configuration of the container network within the container group.

[0037] In one embodiment of this disclosure, when configuring a gateway for a newly created container in an already created container group, an IP address can be selected from the subnet corresponding to the container group's namespace, different from the IP address of a container already configured with a network in the container group. This IP address is then set as the IP address of the container in the container group under that subnet. The IP address of the gateway corresponding to this container is then obtained based on the subnet. For example, for the namespace "ns1" and its corresponding subnet "10.22.1.0 / 24", the IP address of an existing container in the container group is 10.22.1.2. For a new container, 10.22.1.3 can be selected as the IP address of the new container. The IP address of the gateway under this subnet is configured as 10.22.1.1, and 10.22.1.1 can be selected as the IP address of the gateway corresponding to the IP addresses of all containers in the container group under this subnet. After the gateway configuration is complete, network access permissions for the new container can be set, allowing the new container to access the external network through the gateway, thus completing the container creation and automatic configuration of the container network.

[0038] According to embodiments of this disclosure, when creating a container group, the container network configuration can be automatically completed by specifying a preset namespace with corresponding subnets. This reduces the complexity and tedium of manually configuring the container network, reduces the occurrence of container network configuration errors, simplifies the container network configuration process, and improves the efficiency and accuracy of container network configuration.

[0039] Figure 2 This is a flowchart illustrating a container network configuration method according to another embodiment of the present disclosure. The method may include one or more features of the container configuration method described above. In one implementation, obtaining one or more subnets corresponding to the namespaces of the one or more containers based on the mapping relationship between namespaces and subnets may include: S210. In response to the network add command, the network configuration identifier of the container group is obtained by parsing environment variables through the network configuration plugin; wherein, the network configuration plugin includes at least one of a bridge plugin, a media access control plugin, and a network protocol control plugin; S220. Using the network configuration plugin, read the mapping relationship between the network configuration identifier and the subnet from the configuration file to obtain the subnet corresponding to the network configuration identifier of the container group.

[0040] In one embodiment of this disclosure, the CNI plugin's interface can issue a network add command to the CNI bridge plugin, which instructs the CNI bridge plugin to perform a network add operation. The CNI plugin's interface can also pass the container group's namespace path to the CNI bridge plugin. Furthermore, the CNI plugin's interface can pass environment variables to the CNI bridge plugin, which can store information that the CNI plugin needs to pass. For example, the container group's namespace "ns1" can be passed via the environment variable K8S_POD_NAMESPACE=ns1.

[0041] In one embodiment of this disclosure, after receiving a network add command, the CNI bridge plugin performs environment variable resolution. The CNI bridge plugin can resolve the container group's namespace from the passed namespace path and environment variables. For example, resolving K8S_POD_NAMESPACE yields the container group's namespace "ns1".

[0042] In one embodiment of this disclosure, the CNI bridge plugin can obtain the mapping relationship between namespaces and subnets from a configuration file. After parsing the namespace of a container, the CNI bridge plugin can read the subnet corresponding to the namespace of the container group from the namespace-subnet mapping relationship.

[0043] According to embodiments of this disclosure, the subnet corresponding to the specified namespace of the container group can be automatically obtained from the mapping relationship between namespace and subnet through the CNI bridge plugin based on the specified namespace of the container group. This reduces the difficulty of obtaining subnets, reduces the error of manually pulling subnets, and improves the efficiency of subnet allocation.

[0044] Figure 3 This is a flowchart illustrating a container network configuration method according to another embodiment of the present disclosure. The method may include one or more features of the container configuration method described above. In one embodiment, the subnet includes a subnet address and a subnet mask; network protocol IP addresses are assigned to containers in the container group based on the subnet corresponding to each container group; a gateway is configured for the containers in the container group based on the assigned IP addresses; and containers in the container group are allowed to access an external network through the gateway, including: S310. Using the local network protocol address management IPAM plugin, allocate unused IP addresses to containers in the container group according to the subnet of the container group; S320. Add the interfaces of the containers in the container group to the network configuration plugin, and configure the gateway for the containers in the container group according to the subnet of the container group; S330. Configure the containers in the container group to access the external network via the Network Address Translation (NAT) plugin of the packet filtering firewall.

[0045] In one embodiment of this disclosure, the IPAM plugin is a core component of the CNI architecture, enabling dynamic allocation, management, and reclaiming of IP addresses and related network configurations (such as subnets, gateways, routes, DNS, etc.) for containers within a container group in a cluster. A packet filtering firewall is a basic network security device or mechanism operating at the network layer (Layer 3) and transport layer (Layer 4). It examines the header fields of each passing data packet (such as source / destination IP address, protocol type, port number, etc.) and determines whether to allow the packet to pass based on a predefined rule set. Common packet filtering firewalls include iptables and nftables. A NAT plugin is a network technology that dynamically rewrites the source and / or destination IP addresses and ports when IP packets pass through a router or packet filtering firewall. It can be used to address IPv4 address exhaustion, enhance network security, and simplify internal network management. NAT plugins can include dynamic NAT plugins, static NAT plugins, Port Address Translation (PAT) plugins, and bidirectional NAT plugins. The NAT plugin enables functions such as Pods or containers in the cluster to access the external network, the external network to access the cluster, and traffic forwarding.

[0046] In one embodiment of this disclosure, the local host can use the IPAM plugin to obtain unused IP addresses from the subnet based on the subnet read by the CNI bridge plugin and the IP allocation records in the configuration file, and then allocate these unused IP addresses to containers in the container group that need network configuration. For example, the IPAM plugin can allocate IP address 10.22.1.4 to the container in the container group belonging to the namespace "ns1" corresponding to the subnet "10.22.1.0 / 24" and the already allocated information for 10.22.1.2 and 10.22.1.3 in the IP allocation records.

[0047] In one embodiment of this disclosure, the container interface is added to a CNI bridge plugin. After obtaining the container's IP address, the IP address of the gateway corresponding to that IP address can be determined. The IP address of the gateway corresponding to the container's IP address is then configured as the container's gateway. For example, for a container with an IP address of 10.22.1.4, 10.22.1.1 can be used as its gateway. The NAT plugin is then enabled via iptables rules, allowing the current container to access the external network.

[0048] According to embodiments of this disclosure, an IP address can be assigned to a container, and attributes such as bridge, gateway, and network visibility can be configured, enabling the container to access external networks and complete the network configuration of the created container, thereby improving the efficiency and accuracy of container network configuration.

[0049] In one embodiment, the method may further include: configuring the network configuration plugin, the network configuration plugin including a network configuration identifier parsing instruction and a configuration file query instruction, the network configuration identifier parsing instruction being used to parse a network configuration identifier from received environment variables, and the configuration file query instruction being used to find the corresponding subnet in the configuration file based on the parsed network configuration identifier.

[0050] In one embodiment of this disclosure, a network configuration plugin needs to be added to the existing cluster in the initial state. After adding the network configuration plugin, the path of the network configuration plugin needs to be set in the container runtime, and then the container runtime needs to be restarted for the network configuration plugin to take effect. The network configuration plugin may include a bridge plugin, a media access control plugin, and a network protocol control plugin, etc.

[0051] In one embodiment, the method may further include: Create the configuration file, which includes one or more of the following: The mapping relationship between the namespace of the container group and the subnet; The mapping relationship between the container group's tags and subnets Information about the network configuration plugin; Information about the IPAM plugin; wherein, the information about the IPAM plugin may include IP allocation records.

[0052] In one embodiment of this disclosure, the configuration file can store one or more of the following configuration information: CNI plugin version, CNI plugin name, CNI plugin type, CNI plugin bridge, whether a gateway needs to be configured, whether the NAT plugin is enabled, IPAM plugin information, and the mapping relationship between namespaces and subnets. The IPAM plugin information may include one or more of the following: local host (e.g., host-local), the global network segment where the subnet is located, routing information, and IP allocation records. By setting various fields in the configuration file and adding preset namespace-to-subnet mapping information, a new configuration file is obtained, containing the preset namespace-to-subnet mapping. After setting the new configuration file, the path to the new configuration file is set for the container runtime, allowing the container runtime to read the new configuration file. Then, the container runtime (containerd) is restarted to make the new configuration file take effect.

[0053] According to embodiments of this disclosure, by configuring a CNI bridge plugin with container namespace resolution and configuration file reading capabilities for the container runtime, and setting a configuration file that includes the mapping relationship between namespaces and subnets, automatic configuration of the container network can be achieved through the combined action of the CNI bridge plugin and the configuration file, thereby improving the efficiency and accuracy of container network configuration.

[0054] Figure 4 This is a flowchart illustrating a container network configuration method according to another embodiment of the present disclosure. The method may include one or more features of the container configuration method described above. In one embodiment, the method may further include: S410. Based on the first namespace or first tag of the first container group, obtain the first subnet corresponding to the first container group in the mapping relationship between network configuration identifier and subnet; S420. Based on the second namespace or second label of the second container group, obtain the second subnet corresponding to the second container group in the mapping relationship between network configuration identifier and subnet; S430. Configure routing rules for the first subnet and the second subnet, wherein the routing rules are used to control cross-segment communication between the first subnet and the second subnet.

[0055] In one embodiment of this disclosure, a first container group has a first namespace or a first label derived from the mapping relationship between namespaces and subnets, and a first subnet corresponding to the first namespace or the first label. A second container group has a second namespace or a second label derived from the mapping relationship between namespaces and subnets, and a second subnet corresponding to the second namespace or the second label. Specifically, the use of "first" and "second" is merely to distinguish different container groups, namespaces, labels, and subnets, and does not imply that it can only apply to two containers; it can also apply to multiple container groups. Routing rules are a set of policies in an operating system or network device used to determine how data packets are forwarded. When a data packet meets certain conditions, the corresponding routing table can be used for next-hop lookup. In an operating system, routing rules are a component of Policy-Based Routing (PBR), supporting flexible traffic scheduling based on multiple dimensions such as source IP, ingress interface, protocol, and firewall marking (fwmark). By configuring the subnets of multiple container groups that need to communicate across namespaces on the host machine to be routed to the same CNI bridge plugin, cross-namespace communication between multiple containers can be achieved through the bridge's forwarding.

[0056] In one implementation, the method may further include: in response to a network isolation command, blocking routing rules of the first subnet and the second subnet through a packet filtering firewall to prohibit cross-segment communication between the first subnet and the second subnet.

[0057] In one embodiment of this disclosure, for multiple container groups that have established cross-namespace communication, cross-namespace communication between multiple container groups can be restricted by setting routing rules in a packet filtering firewall (e.g., iptables).

[0058] According to embodiments of this disclosure, the connectivity of a container network can be freely configured through a preset mapping relationship between namespaces and subnets, reducing operational complexity and improving the efficiency of container network management.

[0059] In one embodiment, the method may further include: in response to a new network configuration identifier instruction, adding a new network configuration identifier and its corresponding subnet to the mapping relationship between the network configuration identifier and the subnet in the configuration file.

[0060] In one embodiment of this disclosure, more namespaces and subnets, or tags and subnets, can be injected into the configuration file in real time. Specifically, the namespaces and corresponding subnets (or tags and subnets) to be added are obtained, a mapping relationship is established between the new namespaces and corresponding subnets (or tags and subnets), and the data is added to the configuration file. The newly added namespaces and subnets (or tags and subnets) can take effect the next time the container is created without restarting the container runtime.

[0061] According to embodiments of this disclosure, the mapping relationship between namespaces (or tags) and subnets can be flexibly adjusted, improving the flexibility and ease of use of container network configuration.

[0062] In one implementation, the method may further include: in response to a new host instruction, configuring the new host with the same network configuration plugin as the original host.

[0063] In one embodiment of this disclosure, if it is necessary to add a new host to the cluster, in order to enable the new host to quickly access the cluster, the new host can be configured with the same CNI bridge plugin as the original host. In this way, the new host can inherit the original container network of the cluster, without having to reconfigure the container network for the new host.

[0064] In one embodiment, the method may further include: In the event of IP address allocation failure, a first error location instruction is executed to query the IP allocation record. If all available IPs have been allocated, a message indicating that the subnet is exhausted is displayed. The IP allocation record includes records of IP addresses allocated to containers by the network configuration plugin based on the mapping relationship between network configuration identifiers and subnets. If the IP address allocation fails, execute the second error location instruction to query the IP allocation record. If multiple containers reuse the same IP address, indicate an IP address conflict.

[0065] In one embodiment of this disclosure, if it fails to allocate an IP address to a container, the IP allocation record can be queried. If the IP allocation record records IP addresses 0-255 under the allocated subnet, it means that all IP addresses under the subnet have been allocated, and the subnet can be exhausted.

[0066] In one embodiment of this disclosure, if it fails to assign an IP address to a container, the IP assignment record can be queried. If the IP assignment record contains multiple assignment records with the same IP address, it indicates that multiple containers are using the same IP address. An IP address conflict can be indicated, and the conflicting IP address and the corresponding container can be listed.

[0067] According to embodiments of this disclosure, when container network configuration fails, the cause of the failure can be automatically located and corresponding prompts can be provided, thereby improving the efficiency of troubleshooting.

[0068] This disclosure discloses a container configuration method with a lightweight architecture, relying only on containerd and CNIbridge plugins. Single-node memory usage can be reduced to below 100MB, making it suitable for resource-constrained scenarios such as edge computing and embedded devices. Through deep binding of namespaces and network segments, namespaces serve as the core identifier for network segment allocation (e.g., namespace ns1 corresponds to network segment 10.22.1.0 / 24, and ns2 corresponds to 10.22.2.0 / 24), achieving the extremely simple logic of "automatically matching network segments when creating containers." The configuration file is stored in / etc / cni / net.d / , using JSON format to define the mapping relationship between namespaces and network segments. Operations personnel can quickly adjust network policies by modifying the file without restarting the service. Following the CNI 0.4.0 standard, the configuration file can be directly recognized by mainstream runtimes such as containerd and CRI-O, avoiding plugin compatibility issues. It supports hybrid deployment scenarios: on the same host machine, some containers are managed through this solution (based on namespace segmentation), while other containers are managed through standard CNI plugins, providing greater flexibility. This solution reduces network hop levels; the network configuration path is: containerd API → CNI bridge plugin → kernel network module, reducing configuration latency by approximately 20ms. Fault localization is simplified; network faults can be directly investigated using containerd CNI commands or CNI logs, reducing fault localization time by over 60%.

[0069] Figure 5 This is an architecture diagram of a container configuration system according to an embodiment of the present disclosure, such as... Figure 5 As shown: Hardware layer A supports physical machines or virtual machines running Linux systems and requires basic network equipment (such as an Ethernet controller).

[0070] The software layer, BF (Block Frame), uses containerd as the container runtime, responsible for container lifecycle management and interacting with containers through the containerd-shim process. The CNI bridge plugin adds namespace awareness logic. Configuration files, stored in ` / etc / cni / net.d / `, use the CNI standard JSON format and define the mapping between namespaces and network segments. The upper-layer management software manages containers and container networks through the containerd API.

[0071] Table 1 describes the components and functions of a container configuration system according to an embodiment of the present disclosure, as follows: Table 1 Figure 6 This is a schematic flowchart illustrating the initialization of a container configuration method according to an embodiment of the present disclosure, which may include: S610 adds a CNI bridge plugin with namespace resolution and configuration file reading; in the bridge plugin's Add function, the container's namespace is extracted from the parameters passed to containerd (via the runtime.Namespace field). Example code is as follows: func (b Bridge) Add(args cni.CNIArgs) error { namespace := args.RuntimeArgs.Namespace / / Get the namespace from runtime parameters subnet, err := b.getSubnetByNamespace(namespace) / / Query the configuration file to get the corresponding subnet if err != nil { return fmt.Errorf("failed to get subnet for namespace %s", namespace) } / / Subnet will be used for IP allocation later }

[0072] S620. Write the CNI configuration file; file path: / etc / cni / net.d / mynet.conf. An example of the configuration content is as follows: { "cniVersion": "0.4.0", / / version "name": "mynet", / / name "type": "bridge", / / Plugin type "bridge": "cni0", / / Plugin bridge "isGateway": true, / / Gateway configuration is required "ipMasq": true, / / Snat "ipam": { "type": "host-local", / / Local IP address type "subnet": "10.22.0.0 / 16", / / Global network segment, actually allocated based on namespace (network segments that do not use namespaces) "routes": [{"dst": "0.0.0.0 / 0"}], / / routes "dataDir": " / var / lib / cni / mynet" / / Stores IP allocation records() }, "namespaces": { / / Add namespace and subnet mappings "ns1": "10.22.1.0 / 24", "ns2": "10.22.2.0 / 24" }

[0073] S630, configure containerd to support the CNI bridge plugin. Modify the containerd configuration, specifying the CNI plugin path and configuration directory in ` / etc / containerd / config.toml` as shown in the following example: [plugins."io.containerd.network.v1.cni"] cni_config_path = " / etc / cni / net.d" / / Path configured in mynet.conf cni_plugin_dir = " / opt / cni / bin" / / path to bridge.

[0074] S640, Restart containerd: systemctl restart containerd.

[0075] Figure 7 This is a flowchart illustrating a container creation method according to an embodiment of the present disclosure. In one implementation, it may include: S710, upper-layer software calls the containerd API to create a container and specifies the namespace; example code is as follows: client, err := containerd.New(" / run / containerd / containerd.sock") if err != nil { log.Fatal(err) } ctx := context.Background() / / Specify namespace when creating container container, err := client.CreateContainer( ctx, "pod1", `containerd.WithNewSandbox(ctx,"sandbox1",containerd.WithNamespace("ns1"))` / / Adds the `containerd.WithNamespace("ns1")` parameter to set a normalized namespace. The normalized namespace is related to the configuration file. ).

[0076] S720, containerd triggers the CNI plugin, passing the namespace; when creating a container, containerd passes one or more of the following key parameters through the CNI interface: CNI_COMMAND=ADD: instructs the plugin to perform a network add operation. CNI_NETNS: the namespace path of the container (e.g., / proc / 1234 / ns / net). K8S_POD_NAMESPACE=ns1: passes namespace information via environment variables.

[0077] The S730 and CNI bridge plugins perform network configuration, configuring container networks for containers and setting access permissions; resolving namespaces and retrieving ns1 from the environment variable K8S_POD_NAMESPACE. It queries the network segment, reads the configuration file, and obtains the subnet 10.22.1.0 / 24 corresponding to ns1 (24 is the subnet mask). It assigns IP addresses, allocating unused IPs (such as 10.22.1.2) from the subnet using the host-local IPAM plugin. It creates a bridge, ensuring the cni0 bridge exists, adds the container interface to the bridge, and configures the gateway 10.22.1.1 (gateway). It enables IP masquerading, enabling NAT via iptables rules to allow containers to access the external network. Examples of key command execution are as follows: # Create a container network interface The command `ip link add veth1234 type veth peer name cni0-eth1234` specifies the name of the actual network interface card outside the container. ip link set cni0-eth1234 master cni0 # Configure IP address ip netns exec<container_netns> `ip addr add 10.22.1.2 / 24 dev eth0` / / eth0 refers to the name of the actual network interface card inside the container.

[0078] The container network configuration method according to an embodiment of this disclosure can achieve the following functions: Example 1: Cross-namespace communication mechanism, a specific example is as follows: Scenario: Containers in namespaces ns1 (network segment 10.22.1.0 / 24) and ns2 (10.22.2.0 / 24) need to communicate.

[0079] Implementation method: 1. Configure routing rules on the host to allow cross-network segment traffic: ip route add 10.22.2.0 / 24 via10.22.0.1 dev cni0.

[0080] 2. Isolation: Access across namespaces can be restricted using iptables: iptables -A FORWARD -s10.22.1.0 / 24 -d 10.22.2.0 / 24 -j DROP.

[0081] Example 2: Dynamic updates of space and subnets, as detailed below: 1. Load the configuration file; 2. To add a new namespace (such as ns3), simply modify / etc / cni / net.d / mynet.conf and add: "namespaces": { ..., "ns3": "10.22.3.0 / 24" }

[0082] 3. Restart containerd or the plugin, and the changes will take effect automatically the next time a container is created.

[0083] Example 3: Machine network expansion, specific examples are as follows: 1. Configure plugins such as Flannel; 2. Add a Flannel configuration file to ` / etc / cni / net.d / ` to enable multi-host communication via Multus CNI (non-Kubernetes version). Example configuration is as follows: { "cniVersion": "0.4.0", "name": "flannel", "type": "flannel", "delegate": { "type": "bridge", "bridge": "cni0 } }

[0084] Example 4: Problem localization, a specific example is as follows: 1. IP allocation failure: Check if there is an IP conflict in / var / lib / cni / mynet / ipam.db, or if the subnets in the configuration file are exhausted.

[0085] 2. Network connectivity issues: resolve via containerd execution. <container>Use `ip route show` to check the container routes and confirm that the gateway configuration is correct; check whether the host machine's network bridge `cni0` is running normally.

[0086] Example 5: To implement log viewing, a specific example is as follows: To enable debug mode, add "debug":true to the configuration file. Logs will be output to / tmp / cni-debug.log.

[0087] Command to view containerd logs: journalctl -u containerd -f.

[0088] In this embodiment, lightweight container network segmentation management based on Containerd is achieved by adding a CNI bridge plugin with namespace awareness and configuration file reading capabilities, and a configuration file storing the mapping relationship between namespaces and subnets. When a container is created, the upper-layer software specifies the namespace through the Containerd API, and the plugin automatically assigns IP addresses to the corresponding network segments. Hot updates of configuration files and multi-host network expansion are supported. Through lightweight architecture design and namespace-aware network management logic, significant advantages are achieved in the simplicity, efficiency, and flexibility of container network configuration. Examples of specific beneficial effects and technical advantages are as follows: I. Lightweight architecture reduces operation and maintenance costs and lowers technical barriers. 1. No heavy component dependencies and simplified operation and maintenance: Relying solely on the containerd runtime and the CNI bridge plugin, hardware resource consumption is reduced by over 70%. There's no need to maintain complex clusters; configuration files use the CNI standard JSON format (stored in / etc / cni / net.d / ), allowing operations personnel to directly edit and modify them, significantly lowering the technical barrier to entry.

[0089] 2. Simplified container management process and plug-and-play CNI plugins: By directly calling the Containerd API, upper-layer software (such as self-developed container management tools) can create containers directly through the containerd API, skipping the intermediate layer and reducing at least two network request jumps, thus reducing container creation latency by approximately 20ms. The modified bridge plugin is compatible with the CNI standard and can directly replace the default CNI plugin for containerd without modifying the containerd source code or recompiling, reducing deployment costs by more than 50%.

[0090] II. Namespace-Driven Automated Network Segmentation 1. Dynamic network segment allocation and isolation: An automated process is implemented through plugin source code, which automatically identifies the namespace during container creation, matches the network segment in the configuration file, and assigns the corresponding IP address. For example: Namespace ns1 → Network segment 10.22.1.0 / 24 → IP 10.22.1.2; Namespace ns2 → Network segment 10.22.2.0 / 24 → IP 10.22.2.3.

[0091] It eliminates the need for additional network policy controllers (such as Kubernetes' NetworkPolicy), naturally achieving network isolation for multi-tenants or multi-services, making it suitable for traffic partitioning in microservice architectures.

[0092] 2. Maintainability of configuration files The configuration file directly defines the namespaces field to map namespaces and subnets, resulting in a concise and easy-to-read format. { "namespaces": { "ns1": "10.22.1.0 / 24", "ns2": "10.22.2.0 / 24" } }

[0093] When adding a new network segment, only the configuration file needs to be modified and the container restarted. There is no need to restart the plugin or containerd. The configuration change response time is less than 10 seconds.

[0094] 3. Flexibility of cross-namespace communication Dynamic routing configuration is supported. The host machine can flexibly control cross-network segment traffic through iptables or iproute commands, for example: Allow communication: ip route add 10.22.2.0 / 24 via 10.22.0.1 dev cni0.

[0095] Disable communication: iptables -A FORWARD -s 10.22.1.0 / 24 -d 10.22.2.0 / 24 -j DROP.

[0096] Application scenarios: It can realize the isolation of "development environment → test environment" or the traffic control of "sensitive business → public business" as needed.

[0097] III. High performance and standardization compatibility 1. Reduce network configuration layer overhead with direct CNI calls. The container network configuration path is "containerd→CNI plugin→kernel". Compared with the "Kubelet→CRI→CNI plugin→kernel" path, it reduces one inter-process communication (IPC) and reduces network configuration latency by about 20ms.

[0098] Kernel-level performance optimization utilizes the ipMasq (IP masquerading) and isGateway (gateway mode) parameters to directly leverage the Linux kernel's NAT and bridging functions, avoiding performance losses caused by user-space proxies and increasing network throughput by 15%-20%.

[0099] 2. Cross-platform compatibility and scalability: Adapted to general CNI standards, configuration files conform to the CNI 0.4.0 specification, and can be directly used with other runtimes that support CNI (such as CRI-O and Docker) without secondary development. For example, the same configuration can manage network segments for both containerd and Docker containers simultaneously.

[0100] 3. Hybrid plugin support: It can be used in conjunction with CNI plugins such as Flannel and Calico to achieve a composite network architecture of "local segmentation + cross-host interconnection". For example, the bridge plugin in this embodiment is responsible for segmentation within the namespace; the Flannel plugin is responsible for cross-host VXLAN communication; and Multus CNI (non-Kubernetes version) acts as a meta-plugin to coordinate the configuration of multiple plugins.

[0101] IV. Typical Application Scenarios 1. Network management of edge computing devices Edge nodes (such as smart factory gateways and retail terminals) have limited resources and need to run multiple containers (such as data acquisition, protocol conversion, and local storage), requiring low latency and high reliability. A lightweight architecture adapts to the CPU and memory limitations of edge devices. Namespace segmentation avoids traffic interference between containers, ensuring network stability for real-time data acquisition tasks.

[0102] 2. Cloud-native development and testing environment The development team needs to set up multi-environment isolated container clusters locally (such as development, testing, and pre-production) to quickly verify microservice interactions. Containers can be started locally by calling the containerd API, eliminating the need to deploy a Kubernetes cluster and reducing development environment setup time from "hours" to "minutes". Containers in different environments are automatically assigned independent network segments, simplifying network debugging processes (e.g., the ns-dev container only needs to access a specific port in the ns-test network segment).

[0103] In this embodiment, a highly efficient network segmentation is achieved with a minimalist architecture. By combining a namespace-aware CNI plugin with standardized configuration files, the high cost, complexity, and low flexibility of container network configuration in lightweight scenarios are addressed. This reduces resource consumption, improves operational efficiency, and lowers the technical barrier to container network management through standardized design, providing a practical solution for scenarios such as edge computing.

[0104] Namespace-based network configuration management manages different network segments and outgoing interfaces by identifying the namespace of a Pod. When a Pod is created, a corresponding network segment is assigned based on its namespace. For example, if Pod1 uses namespace 1, it is assigned network segment 1, and if Pod2 uses namespace 2, it is assigned network segment 2, thus achieving fine-grained management of container networks.

[0105] A specific configuration file format is used, located at ` / etc / cni / net.d / `, to store network configuration information such as network segments corresponding to different namespaces, used for allocating IP addresses, gateways, and outgoing interfaces. The configuration file conforms to containerd's standard specifications for CNI versions, ensuring compatibility and maintainability.

[0106] Optimized for specific scenarios, this solution provides a lightweight container network management solution for scenarios where only the containerd API is called to maintain container lifecycle management, reducing operation and maintenance costs and technical requirements.

[0107] In one embodiment of this disclosure, namespace identification and network configuration can be replaced, as follows: In addition to namespaces, custom tags (such as `network-segment: seg1`) can be added to Pods. The bridge plugin then parses the tag information and matches the corresponding network segment for network configuration. This approach can be used in parallel with the namespace mechanism, providing a more flexible network segmentation strategy.

[0108] Introduce a rules engine (such as one based on Lua or Python scripts) to dynamically generate network configurations based on various container attributes (such as creator ID, startup time, resource requirements, etc.). For example, containers created within a specific time period can be automatically assigned to a test network segment.

[0109] In one embodiment of this disclosure, the plugin implementation and extension scheme may further include: setting other types of CNI plugins (such as macvlan and ipvlan plugins) to implement network configuration based on namespaces or other identifiers. For example, using the macvlan plugin to assign independent MAC addresses and network segments to containers in different namespaces. A mechanism for chaining multiple plugins is designed, such as first having the namespace-aware plugin allocate the basic network segment, and then having other plugins (such as firewall plugins and traffic monitoring plugins) perform subsequent processing to extend the container network management functionality.

[0110] In one embodiment of this disclosure, the diversification and expansion of configuration files may further include splitting the configuration file into a global configuration file and namespace-specific configuration files. The global file defines basic parameters, while the namespace file overrides or supplements specific configurations, improving the maintainability and reusability of the configuration. The configuration file supports reading network segment mapping information from external data sources (such as databases or distributed configuration centers). For example, through integration with etcd, the mapping between namespaces and network segments can be dynamically updated without restarting the plugin or containerd.

[0111] In one embodiment of this disclosure, the platform and application scenarios can be expanded, as detailed below: Extend the solution to other container runtimes that support the CNI standard, such as CRI-O and Docker (with containerd as the backend), to achieve cross-platform container network management.

[0112] To address the limited resources of edge computing devices, we optimize the resource consumption of plugins; in a hybrid cloud environment, we achieve a unified namespace-aware network configuration between the local data center and cloud containers.

[0113] In one embodiment of this disclosure, the security and access control extension may include: integrating firewall functionality into the bridge plugin and configuring different access control policies based on namespaces. For example, prohibiting containers in specific namespaces from initiating connections to certain ports. Configuring encrypted channels (such as IPsec and TLS) for container networks in different namespaces ensures secure data transmission, especially strengthening protection for namespaces containing sensitive services.

[0114] In one embodiment of this disclosure, dynamic resource management and scheduling may include: dynamically adjusting the network segment to which a container belongs or migrating it to a network segment with lower load based on the container's real-time load (CPU, memory, network bandwidth) to optimize resource utilization. A network segment resource pool is constructed, and when the number of containers in a certain namespace surges, additional network segments are automatically allocated from the resource pool to avoid IP address exhaustion.

[0115] Figure 8 This is a schematic diagram of a container network configuration apparatus according to an embodiment of the present disclosure. In one embodiment, the apparatus may include: The first creation module 801 is used to respond to the container group Pod creation instruction, call the container group creation application programming interface API, create the container group, and specify the network configuration identifier of the container group; wherein, the network configuration identifier has a mapping relationship with the subnet; The first acquisition module 802 is used to acquire the subnet corresponding to the network configuration identifier in the configuration file; wherein, one container group corresponds to one network configuration identifier, and one network configuration identifier corresponds to one subnet; The allocation module 803 is used to allocate network protocol IP addresses to containers in the container group according to the subnet corresponding to each container group, configure gateways for containers in the container group according to the allocated IP addresses, and allow containers in the container group to access external networks through the gateways.

[0116] In one implementation, the network configuration identifier includes the namespace of the container group or the label of the container group; the mapping relationship between the network configuration identifier and the subnet is used to indicate the correspondence between the network configuration identifier and the subnet.

[0117] In one implementation, one or more of the following parameters are also passed via a network configuration plugin: Add network command; The path to the container's namespace; Environment variables, wherein the environment variables include the network configuration identifier of the container group.

[0118] Figure 9 This is a schematic diagram of a container network configuration apparatus according to another embodiment of the present disclosure. The apparatus may include: a first creation module 901, a first acquisition module 902, and an allocation module 903. The functions of each module of the container configuration apparatus can be found in the descriptions of the first creation module 801, the first acquisition module 802, and the allocation module 803, and will not be repeated here. In one embodiment, the first acquisition module 902 includes: A submodule 9021 is added to respond to a network add command by parsing environment variables through a network configuration plugin to obtain the network configuration identifier of the container group; wherein the network configuration plugin includes at least one of a bridge plugin, a media access control plugin, and a network protocol control plugin; The reading submodule 9022 is used to read the mapping relationship between the network configuration identifier and the subnet from the configuration file through the network configuration plugin, and obtain the subnet corresponding to the network configuration identifier of the container group.

[0119] In one implementation, such as Figure 9 As shown, the subnet includes a subnet address and a subnet mask, and the allocation module 903 includes: The allocation submodule 9031 is used to manage IPAM plugins through local network protocol addresses and allocate unused IP addresses to containers in the container group according to the subnet of the container group; The first configuration submodule 9032 is used to add the interfaces of the containers in the container group to the network configuration plugin, and configure the gateway for the containers in the container group according to the subnet of the container group; The second configuration submodule 9033 is used to configure the containers in the container group to be allowed to access the external network through the Network Address Translation (NAT) plugin of the packet filtering firewall.

[0120] In one implementation, such as Figure 9 As shown, the device may further include: The configuration module 904 is used to configure the network configuration plugin. The network configuration plugin includes a network configuration identifier parsing instruction and a configuration file query instruction. The network configuration identifier parsing instruction is used to parse the network configuration identifier from the received environment variables. The configuration file query instruction is used to find the corresponding subnet in the configuration file based on the parsed network configuration identifier.

[0121] In one implementation, such as Figure 9 As shown, the device may further include: The second creation module 905 is used to create the configuration file, which includes one or more of the following: The mapping relationship between the namespace of the container group and the subnet; The mapping relationship between the container group's tags and subnets Information about the network configuration plugin; Information about the IPAM plugin; wherein, the information about the IPAM plugin may include IP allocation records.

[0122] In one implementation, such as Figure 9 As shown, the device may further include: The second acquisition module 906 is used to acquire the first subnet corresponding to the first container group based on the first namespace or first tag of the first container group in the mapping relationship between network configuration identifier and subnet; The third acquisition module 907 is used to obtain the second subnet corresponding to the second container group based on the second namespace or second tag of the second container group in the mapping relationship between network configuration identifier and subnet; The configuration module 908 is used to configure the routing rules for the first subnet and the second subnet, and the routing rules are used to control cross-segment communication between the first subnet and the second subnet.

[0123] In one implementation, such as Figure 9 As shown, the device may further include: Isolation module 909 is used to block the routing rules of the first subnet and the second subnet through packet filtering firewall in response to network isolation command, so as to prohibit cross-segment communication between the first subnet and the second subnet.

[0124] In one implementation, such as Figure 9 As shown, the device may further include: A new network configuration identifier module 910 is added to the mapping relationship between network configuration identifiers and subnets in the configuration file in response to the new network configuration identifier instruction.

[0125] In one implementation, such as Figure 9 As shown, the device may further include: The new host module 911 is used to respond to the new host command and configure the new host with the same network configuration plugin as the original host.

[0126] In one implementation, such as Figure 9 As shown, the device may further include: The prompting module 912 is used to execute a first error location instruction and query the IP allocation record in the event of IP address allocation failure. If all available IPs have been allocated, the module will prompt that the subnet is exhausted. The IP allocation record includes records of the network configuration plugin allocating IP addresses to the container according to the mapping relationship between the network configuration identifier and the subnet. The prompting module 912 is also used to execute a second error location instruction to query the IP allocation record in the event of IP address allocation failure, and to prompt an IP address conflict when multiple containers reuse the same IP address.

[0127] The specific functions and examples of each module and submodule of the apparatus in this disclosure can be found in the relevant descriptions of the corresponding steps in the above method embodiments, and will not be repeated here.

[0128] The acquisition, storage, and application of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0129] Figure 10 This is a structural block diagram of an electronic device according to an embodiment of the present disclosure. Figure 10 As shown, the electronic device includes a memory 1010 and a processor 1020. The memory 1010 stores a computer program that can run on the processor 1020. The number of memories 1010 and processors 1020 can be one or more. The memory 1010 can store one or more computer programs, which, when executed by the electronic device, cause the electronic device to perform the methods provided in the above-described method embodiments. The electronic device may also include a communication interface 1030 for communicating with external devices and performing data exchange and transmission.

[0130] If the memory 1010, processor 1020, and communication interface 1030 are implemented independently, they can be interconnected via a bus to communicate with each other. This bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 10 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0131] Optionally, in a specific implementation, if the memory 1010, processor 1020 and communication interface 1030 are integrated on a single chip, then the memory 1010, processor 1020 and communication interface 1030 can communicate with each other through an internal interface.

[0132] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting Advanced Reduced Instruction Set Machines (ARM) architecture.

[0133] Further, optionally, the aforementioned memory may include read-only memory and random access memory, and may also include non-volatile random access memory. The memory may be volatile or non-volatile, or may include both. Non-volatile memory may include read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may include random access memory (RAM), which serves as an external cache. Many forms of RAM are available by way of example, but not limitation. Examples include Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate Synchronous DRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct RAMBUS RAM (DR RAM).

[0134] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this disclosure are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line, DSL) or wireless (e.g., infrared, Bluetooth, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer, or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., Digital Versatile Discs (DVDs)), or semiconductor media (e.g., Solid State Disks (SSDs)). It is worth noting that the computer-readable storage media mentioned in this disclosure can be non-volatile storage media; in other words, it can be non-transient storage media.

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

[0136] In the description of embodiments of this disclosure, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this disclosure. Furthermore, the described specific features, structures, materials, or characteristics may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of those different embodiments or examples.

[0137] In the description of the embodiments disclosed herein, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone.

[0138] In the description of embodiments of this disclosure, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of embodiments of this disclosure, unless otherwise stated, "a plurality of" means two or more.

[0139] The above description is merely an exemplary embodiment of this disclosure and is not intended to limit this disclosure. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the protection scope of this disclosure.< / container>

Claims

1. A container network configuration method, comprising: In response to the Pod creation command, the container group creation application programming interface (API) is invoked to create the container group and specify the network configuration identifier of the container group; wherein, the network configuration identifier has a mapping relationship with the subnet; In the configuration file, the subnet corresponding to the network configuration identifier is obtained; wherein, one container group corresponds to one network configuration identifier, and one network configuration identifier corresponds to one subnet; Assign network protocol IP addresses to containers in each container group based on the subnet corresponding to each container group, and configure gateways for the containers in the container group based on the assigned IP addresses, allowing the containers in the container group to access the external network through the gateways.

2. The method according to claim 1, wherein, The network configuration identifier includes the namespace of the container group or the label of the container group; the mapping relationship between the network configuration identifier and the subnet is used to indicate the correspondence between the network configuration identifier and the subnet.

3. The method according to claim 1, further comprising passing one or more of the following parameters via a network configuration plugin: Add network command; The path to the container's namespace; Environment variables, among which, The environment variables include the network configuration identifier of the container group.

4. The method according to claim 1, wherein, In the configuration file, the subnet corresponding to the network configuration identifier is obtained, including: In response to a network add command, the network configuration identifier of the container group is obtained by parsing environment variables through a network configuration plugin; wherein, the network configuration plugin includes at least one of a bridge plugin, a media access control plugin, and a network protocol control plugin; The network configuration plugin reads the mapping relationship between the network configuration identifier and the subnet from the configuration file to obtain the subnet corresponding to the network configuration identifier of the container group.

5. The method according to claim 1, wherein, The subnet includes a subnet address and a subnet mask. Based on the subnet corresponding to each container group, network protocol IP addresses are assigned to containers in the container group. A gateway is configured for the containers in the container group based on the assigned IP addresses, allowing the containers in the container group to access the external network through the gateway. This includes: The IPAM plugin, which manages network protocol addresses locally, allocates unused IP addresses to containers in the container group based on the subnet of the container group. Add the interfaces of the containers in the container group to the network configuration plugin, and configure the gateway for the containers in the container group according to the subnet of the container group; By using the Network Address Translation (NAT) plugin of the packet filtering firewall, the containers in the container group are configured to be allowed to access the external network.

6. The method according to any one of claims 1 to 5, further comprising: Configure the network configuration plugin, which includes a network configuration identifier parsing instruction and a configuration file query instruction. The network configuration identifier parsing instruction is used to parse the network configuration identifier from the received environment variables, and the configuration file query instruction is used to find the corresponding subnet in the configuration file based on the parsed network configuration identifier.

7. The method according to any one of claims 1 to 5, further comprising: Create the configuration file, which includes one or more of the following: The mapping relationship between the namespace of the container group and the subnet; The mapping relationship between the container group's tags and subnets Information about the network configuration plugin; Information about the IPAM plugin; wherein, the information about the IPAM plugin may include IP allocation records.

8. The method according to any one of claims 1 to 5, further comprising: Based on the first namespace or first tag of the first container group, obtain the first subnet corresponding to the first container group in the mapping relationship between network configuration identifier and subnet; Based on the second namespace or second tag of the second container group, obtain the second subnet corresponding to the second container group in the mapping relationship between network configuration identifier and subnet; Configure routing rules for the first subnet and the second subnet, the routing rules being used to control cross-segment communication between the first subnet and the second subnet.

9. The method according to claim 8, further comprising: In response to the network isolation command, the routing rules of the first subnet and the second subnet are blocked by the packet filtering firewall to prohibit cross-segment communication between the first subnet and the second subnet.

10. The method according to any one of claims 1 to 5, further comprising: In response to the instruction to add a new network configuration identifier, the new network configuration identifier and its corresponding subnet are added to the mapping relationship between the network configuration identifier and the subnet in the configuration file.

11. The method according to any one of claims 1 to 5, further comprising: In response to the new host command, configure the new host with the same network configuration plugin as the original host.

12. The method according to any one of claims 1 to 5, further comprising: In the event of IP address allocation failure, a first error location instruction is executed to query the IP allocation record. If all available IPs have been allocated, a message indicating that the subnet is exhausted is displayed. The IP allocation record includes records of IP addresses allocated to containers by the network configuration plugin based on the mapping relationship between network configuration identifiers and subnets. If the IP address allocation fails, execute the second error location instruction to query the IP allocation record. If multiple containers reuse the same IP address, indicate an IP address conflict.

13. A container network configuration apparatus, comprising: The first creation module is used to respond to the Pod creation command by calling the Container Group Creation Application Programming Interface (API) to create the container group and specify the network configuration identifier of the container group; wherein, the network configuration identifier has a mapping relationship with the subnet; The first acquisition module is used to acquire the subnet corresponding to the network configuration identifier from the configuration file; wherein, one container group corresponds to one network configuration identifier, and one network configuration identifier corresponds to one subnet; The allocation module is used to allocate network protocol IP addresses to containers in the container group according to the subnet corresponding to each container group, and configure gateways for the containers in the container group according to the allocated IP addresses, allowing the containers in the container group to access the external network through the gateways.

14. An electronic device comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1 to 12.

Images