CN107580083A - A kind of method and system of container IP address distribution - Google Patents

Abstract

The invention discloses a kind of method and system of container IP address distribution, it is related to field of computer technology.One embodiment of this method includes：The part IP address in total address pool is established into one-to-one binding relationship with corresponding container according to the first distribution requirements；Whether in the case of the request for receiving distribution IP address, judging the container of IP address to be allocated with IP address has binding relationship；If so, the IP address bound in the container of the IP address to be allocated is then distributed into the container；Otherwise, IP address unbound in total address pool is distributed to the container of the IP address to be allocated.The embodiment can realize the binding of IP address and container, and then ensure that IP address is constant when container is restarted or migrated, it is ensured that service is not interrupted.

Description

Method and system for allocating container IP addresses

technical field

The present invention relates to the field of computer technology, in particular to a method and system for allocating container IP addresses.

Background technique

A container is a series of processes isolated from the rest of the system, running from a template image that provides all the files needed to support the process. Among them, Docker is an open source application container engine that allows developers to package their applications and dependent packages into a portable container, and then publish it to any running Linux machine, and can also realize virtualization. Containers use a sandbox mechanism completely, and there will be no interfaces between them. Nowadays, the application of Docker is becoming more and more extensive, whether it is from the code activity on github, or Redhat's support for Docker integrated in RHEL6.5, and even Google's omput Engine also supports Docker to run on it. Kubernetes is Google's open source container cluster management system and an important member of the Docker ecosystem. It provides functions such as application deployment, maintenance, and expansion mechanisms. Kubernetes can easily manage containerized applications running across machines. And how Kubernetes flexibly configures the IP address of the container is undoubtedly an important issue in building a network.

Currently, methods such as Flannel and Calico-cni are used for Kubernetes network management. Flannel cooperates with Docker to allow all nodes in the cluster to re-plan the rules for using IP addresses, so that containers on different nodes can obtain IP addresses that "belong to the same intranet" and "non-duplicate", and let containers on different nodes Able to communicate directly through intranet IP. However, when designing the network, if you need to specify the container IP range on each physical machine or certain physical machines, you need to configure the etcd server. Moreover, Flannel packs TCP data in another network packet for routing, forwarding and communication. The default data communication method between nodes is UDP forwarding. This results in loss of network performance and complicates the analysis of network failures.

Calico-cni is a CNI or network plug-in mode, which requires the combination of two executable files and configuration files, calico and calico-ipam. It directly integrates with kubelet, runs on each node to discover the created container, randomly assigns a subnet from the configured address segment to the physical node, and assigns an address from the subnet to the container. In this method, containers on the same physical machine share the same subnet, and containers on different physical machines cannot share the same subnet.

None of the above methods can realize the binding between the container and the IP address. When the container is restarted on the same physical machine or migrated to another physical machine, the IP address will change. In this way, services that listen to fixed IP addresses will not work properly.

Contents of the invention

In view of this, the embodiments of the present invention provide a method and system for allocating container IP addresses, which can allocate IP addresses for all nodes through the configured total address pool, and can also allocate part of the IP addresses in the total address pool with The container is bound to ensure that the IP address remains unchanged when the container is restarted or migrated, ensuring that the service is not interrupted.

To achieve the above object, according to an aspect of the embodiments of the present invention, a method for allocating container IP addresses is provided.

The method for allocating container IP addresses according to the embodiment of the present invention includes: establishing a one-to-one binding relationship between some IP addresses in the total address pool and corresponding containers according to the first allocation requirement; when a request for allocating an IP address is received , judging whether the container to be assigned an IP address has a binding relationship with the IP address; if so, assign the IP address bound to the container to be assigned an IP address to the container; otherwise, assign the IP address bound to the container to be assigned an IP address; The unbound IP address is allocated to the container to which the IP address is to be allocated.

Optionally, the step of establishing a one-to-one binding relationship between some IP addresses in the total address pool and corresponding containers according to the first allocation requirement includes: reading out some IP addresses from the total address pool according to the first allocation requirement IP address, and determine the binding label of the container to be bound to the IP address according to the first allocation requirement; establish a one-to-one correspondence between the binding label and the read IP address; record the correspondence In the static allocation list; the step of judging whether the container with the IP address to be assigned has a binding relationship with the IP address includes: judging whether the container with the IP address to be assigned has a binding label; The step of assigning the IP address bound to the container to the container includes: obtaining the binding label of the container to be allocated the IP address; finding the corresponding IP address in the static allocation list according to the binding label; The IP address is allocated to the container to which the IP address is to be allocated.

Optionally, before the step of establishing a one-to-one binding relationship between some of the IP addresses in the total address pool and corresponding containers according to the first allocation requirement, it further includes: configuring the total address pool according to a predetermined number of IP addresses ; Then store the total address pool in the database of etcd.

Optionally, before the step of establishing a one-to-one binding relationship between some IP addresses in the total address pool and corresponding containers according to the first allocation requirement, it also includes: according to the second allocation requirement, for the specified physical machine through The configuration file configures a specified address pool, and all IP addresses in the specified address pool are included in the total address pool;

The step of allocating the unbound IP address in the total address pool to the container with the IP address to be allocated includes: judging whether the physical machine where the container with the IP address to be allocated is configured with a specified address pool; if If not, allocate the unbound IP address in the total address pool to the container of the IP address to be allocated; otherwise, allocate the unbound IP address in the specified address pool to the IP address to be allocated container.

Optionally, the step of allocating unbound IP addresses in the total address pool to the containers to be allocated IP addresses further includes: judging whether the specified address pool is compatible with specified address pools of other physical machines intersection; if there is an intersection, then output an error message; otherwise, assign the IP address in the unassigned list in the specified address pool to the container of the IP address to be assigned, and move the IP address from the unassigned list and correspondingly record the IP address and the container from which the IP address is obtained in the assigned list.

Optionally, the step of allocating the IP address bound to the container to which the IP address is to be allocated to the container includes: determining the first IP address according to the order of the currently bound IP addresses, and then assigning the The IP address is assigned to the container; the step of assigning the unbound IP address in the total address pool to the container to be assigned an IP address includes: determining according to the order of the unbound IP addresses in the total address pool The IP address in the first place, and then assign that IP address to the container.

Optionally, after assigning the IP address to the container, it also includes: according to the assigned IP address, creating a pair of veth-pairs for the container obtaining the IP address.

The container IP address allocation system in the embodiment of the present invention includes: a configuration module, configured to establish a one-to-one binding relationship between some IP addresses in the total address pool and corresponding containers according to the first allocation requirement; a judging module, configured to In the case of receiving a request to allocate an IP address, determine whether the container to be allocated an IP address has a binding relationship with the IP address; the static allocation module is used to determine whether the container to be allocated an IP address is related to After the IP address has a binding relationship, assign the IP address bound to the container with the IP address to be assigned to the container; the dynamic allocation module is used to determine the relationship between the container with the IP address to be assigned in the judgment module After the IP address has no binding relationship, allocate the unbound IP address in the total address pool to the container with the IP address to be allocated.

Optionally, the configuration module is further configured to read part of the IP addresses from the total address pool according to the first distribution requirement, and determine the binding label of the container to be bound to the IP address according to the first distribution requirement; The binding label establishes a one-to-one correspondence with the read IP address; the correspondence is recorded in the static distribution list; the judging module is also used to judge whether the container to be assigned the IP address has a binding set the label.

Optionally, the static allocation module includes: an acquisition unit, configured to acquire a binding label of a container to be allocated an IP address; a search unit, configured to find the corresponding IP address in the static allocation list according to the binding label IP address; an allocation unit, configured to allocate the IP address to the container to be allocated an IP address.

Optionally, the configuration module is further configured to, before the step of establishing a one-to-one binding relationship between some IP addresses in the total address pool and corresponding containers according to the first allocation requirement, according to the predetermined number of IP addresses Configure the total address pool; then store the total address pool in the database of etcd.

Optionally, the configuration module is further configured to, before the step of establishing a one-to-one correspondence binding relationship between some IP addresses in the total address pool and corresponding containers according to the first allocation requirement, assign the specified IP addresses according to the second allocation requirement The physical machine configures a specified address pool through a configuration file, and all IP addresses in the specified address pool are included in the total address pool; and

The dynamic allocation model is also used to determine whether the physical machine where the container to be allocated an IP address is located is configured with a specified address pool; if not, then allocate the unbound IP address in the total address pool to the A container with an IP address to be allocated; otherwise, assign an unbound IP address in the specified address pool to the container with an IP address to be allocated.

Optionally, the dynamic allocation module is also used to determine whether there is an intersection between the specified address pool and specified address pools of other physical machines; if there is an intersection, output an error message; The IP address in the allocation list is allocated to the container of the IP address to be allocated, and the IP address is removed from the unallocated list, and the IP address is correspondingly recorded in the container for obtaining the IP address. assignment list.

Optionally, the static assignment module is also used to determine the first IP address according to the order of the currently bound IP addresses, and then assign the IP address to the container;

The dynamic allocation module is also used to determine the first IP address according to the order of unbound IP addresses in the total address pool, and then assign the IP address to the container.

Optionally, it also includes: a creation module, configured to create a pair of veth-pairs for the container that obtains the IP address according to the allocated IP address after the IP address is allocated to the container.

In order to achieve the above purpose, according to an aspect of the embodiments of the present invention, a device for allocating container IP addresses is provided.

The device for allocating container IP addresses in the embodiment of the present invention includes: one or more processors; a storage device for storing one or more programs, when the one or more programs are executed by the one or more processors , enabling the one or more processors to implement the above method for allocating container IP addresses.

In order to achieve the above object, according to an aspect of the embodiment of the present invention, a computer-readable medium is provided, on which a computer program is stored, and it is characterized in that, when the program is executed by a processor, the above-mentioned container IP address allocation method is realized .

An embodiment of the above invention has the following advantages or beneficial effects: after configuring the general address pool, a one-to-one binding relationship is established between some IP addresses in the total address pool and corresponding containers according to the first allocation requirement, This makes it possible to allocate IP addresses according to the binding relationship when allocating them. After receiving the request for assigning an IP address, and judging that the container to which the IP address is to be assigned has been bound to an IP address, static allocation is performed, and the bound IP address is assigned to the container. Furthermore, when the container is restarted on the same physical machine or migrated to another physical machine, the IP address will not change, ensuring uninterrupted services. It solves the problem that the binding between the container and the IP address cannot be realized when the IP address is allocated to the container in the prior art. Moreover, the total address pool configured in the present invention can be used by all containers in the cluster, and in the process of assigning IP addresses, the IP addresses in the total address pool can be directly obtained and assigned to the container, which not only ensures that any IP address can Used on all nodes, it improves the flexibility of the cluster and simplifies the method of container IP address allocation.

The further effects of the above-mentioned non-conventional alternatives will be described below in conjunction with specific embodiments.

Description of drawings

The accompanying drawings are used to better understand the present invention, and do not constitute improper limitations to the present invention. in:

Fig. 1 is a schematic diagram of the main flow of the method for container IP address allocation according to an embodiment of the present invention;

Fig. 2 is a schematic diagram of dynamic allocation according to an embodiment of the present invention;

Fig. 3 is a schematic diagram of static allocation according to an embodiment of the present invention;

Fig. 4 is a schematic diagram of the main modules of the system for container IP address distribution according to an embodiment of the present invention;

FIG. 5 is an exemplary system architecture diagram to which the embodiment of the present invention can be applied;

Fig. 6 is a schematic structural diagram of a computer system suitable for implementing a terminal device or a server according to an embodiment of the present invention.

detailed description

The exemplary embodiments of the present invention are described below in conjunction with the accompanying drawings, which include various details of the embodiments of the present invention to facilitate understanding, and they should be considered as exemplary only. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

The technical terms involved in the embodiments of the present invention are explained as follows:

Kubernetes: Kubernetes is Google's open-source container cluster management system, which provides functions such as application deployment, maintenance, and expansion mechanisms. Using Kubernetes can easily manage containerized applications running across machines;

Kubelet: In a Kubernetes cluster, a Kubelet service is started on each Node node (also known as Minion). This process is used to process tasks sent by the Master node to the local node, and manage Pods and containers in Pods. Each Kubelet process will register the node's own information on the API Server, regularly report the usage of node resources to the Master node, and monitor the container and node resources through cAdvise;

Docker: Docker is an open source application container engine that allows developers to package their applications and dependencies into a portable container, and then publish it to any running Linux machine, and can also implement virtualization. Containers use the sandbox mechanism completely, and there will be no interfaces between them;

Flannel: Flannel is a network planning service designed by the CoreOS team for Kubernetes; in simple terms, its function is to allow Docker containers created by different node hosts in the cluster to have unique virtual IP addresses for the entire cluster, and to enable Docker containers to communicate with each other. even;

CNI: CNI (Container Network Interface) is an operation container network specification, including method specification, parameter specification, etc. CNI only cares about the network connection of the container, allocates network resources when the container is created, and deletes the allocated resources when the container is deleted. For this reason, CNI has wide support and the specification is easy to implement. The CNI interface only needs to implement two methods, one is called when the container is created, and the other is called when the container is deleted;

Pod: A Pod corresponds to a container group consisting of several containers, and the containers in the same group share a network namespace and IP address. Pod mainly establishes an application-oriented "logical host" model in a containerized environment, which can contain one or more containers that are closely related to each other. Pod is responsible for creating new Pods by the replication controller to replace the old ones;

label: A label is a pair of key/value pairs attached to the Pod, which is used to pass user-defined attributes. For example, you may create a "staticIP" label to mark the IP name used by the Pod container through label (staticIP=domain1ServerIP);

Overlay: Overlay is to create a virtual network on the traditional network. The traditional network does not need any adaptation, so the physical layer network only corresponds to the calculation of the physical layer (physical machine, virtualization layer management network). Overlay implements network construction and expansion for edge network devices through control protocols. The specific implementation technologies include EVI, TRILL, VPLS, LISP, VXLAN, etc.;

etcd: etcd is a key/value storage service applied in a distributed environment. Utilizing the features of etcd, applications can share information, configure, or perform service discovery in the cluster, and etcd will replicate the data in each node of the cluster and ensure that the data is always correct. etcd is an indispensable part of both CoreOS and Kubernetes systems;

veth-pair: Virtual Ethernet Pair, veth-pair for short, is a pair of virtual network cards with a virtual link between them. All packets that come in on one end of the pair will come out the other, and vice versa.

Fig. 1 is a schematic diagram of the main flow of a method for container IP address allocation according to an embodiment of the present invention.

As shown in Figure 1, the method for container IP address allocation in the embodiment of the present invention mainly includes:

S101: Establish a one-to-one binding relationship between some IP addresses in the total address pool and corresponding containers according to the first allocation requirement. Before establishing the binding relationship, configure the total address pool according to the predetermined number of IP addresses, and store the total address pool in the etcd database to realize distributed storage. The total address pool can be stored not only in etcd, but also in other servers, as long as distributed storage can be realized. Among them, etcd is a key/value storage service applied in a distributed environment. Utilizing the features of etcd, applications can share information, configure or perform service discovery in the cluster, and etcd will replicate the data in each node of the cluster and ensure that the data is always correct. Wherein, the predetermined number of IP addresses may be set according to network planning, that is, the requirement for the number of IP addresses.

Establishing a binding relationship is to make a one-to-one correspondence between a certain container and a certain IP address in the total address pool, and record it on the etcd server. When assigning an address, check whether the container has a one-to-one correspondence with an IP address, if so, assign the IP address to the container, otherwise use the unbound IP address in the total address pool to assign the container . Wherein, according to the first distribution requirement, read out part of the IP addresses from the total address pool, and determine the binding label (label) of the container to be bound to the IP address according to the first distribution requirement; combine the binding label with the read out Establish a one-to-one correspondence with the IP address; record the correspondence in the static allocation list. In the static allocation list, all bound IP addresses can be found, and the static allocation list can also be distributed and stored in etcd. The step of judging whether the container to be assigned the IP address has a binding relationship with the IP address includes: judging whether the container to be assigned the IP address has a binding label. In addition, the step of assigning the IP address bound to the container to be assigned the IP address to the container includes: obtaining the binding label of the container to be assigned the IP address; finding the corresponding IP address in the static allocation list according to the binding label ; Assign an IP address to the container to be assigned an IP address. Establishing a binding relationship between the label and the IP address is convenient for the user to call, because the MAC (Media Access Control) addresses of different containers are different during multiple visits, but the label can remain the same. Therefore, if the external service is based on IP, through the binding of label and IP address, it can ensure that the IP address obtained by the user in multiple visits remains unchanged, which is more convenient for the user to call.

S102: When receiving a request for assigning an IP address, determine whether the container to which the IP address is to be assigned has a binding relationship with the IP address. If the IP address is bound to the corresponding container through the label, after receiving the request for assigning the IP address, it is judged whether the container to be assigned the IP address has a label, and if so, the container to be assigned the IP address can be judged There is a binding relationship with an IP address in the total address pool, and S103 is further executed, that is, static allocation is performed. If the container to be assigned an IP address does not have a label, it is determined that the container to be assigned an IP address is not bound to an IP address, and S104 is further executed, that is, dynamic allocation is performed.

S103: Assign the IP address bound to the container to which the IP address is to be assigned to the container. In the process of static allocation, according to the received request for IP address allocation, the binding label of the container to be allocated IP address is obtained, and the corresponding IP address is found in the static allocation list according to the binding label, and the IP address is allocated For the container to be assigned an IP address.

S104: Allocate unbound IP addresses in the total address pool to containers to be allocated IP addresses. In the process of configuring the total address pool, the specified address pool can be configured for the specified physical machine through the configuration file according to the second allocation requirement, and all IP addresses in the specified address pool are included in the total address pool, that is, the specified address pool belongs to Total address pool. Because in practical applications, there may be a need to specifically set a designated address pool for a certain physical machine, and when assigning an IP address to the physical machine, obtain an IP address from the designated address pool for allocation. If there is no need to configure a specified address pool, when allocating IP addresses, you can directly obtain IP addresses from the general address pool for allocation.

Therefore, dynamic allocation also includes: judging whether the physical machine where the container to be allocated an IP address is located is configured with a specified address pool. If not, assign the unbound IP address in the total address pool to the container to be assigned an IP address; otherwise, assign the unbound IP address in the specified address pool to the container to be assigned an IP address. Through this process, the user's requirement of setting a corresponding designated address pool for a specific physical machine in the allocation of IP addresses can be better met. At the same time, the dynamic allocation also includes: judging whether the specified address pool overlaps with the specified address pools of other physical machines; if there is an intersection, output an error message; otherwise, assign the IP address in the unallocated list in the specified address pool to the IP address to be allocated The container of the IP address, and the IP address is removed from the unassigned list, and the IP address is correspondingly recorded in the allocated list with the container from which the IP address was obtained. By judging whether the specified address pool overlaps with the specified address pools of other physical machines, it can be ensured that the IP address can uniquely identify the container.

After configuring the total address pool or the specified address pool, create an unassigned list and an allocated list, and initialize the unassigned list as the total address pool or the specified address pool (the IP addresses in the total address pool or the specified address pool are all in the unassigned allocated list), initializes the allocated list to empty. Moreover, the IP addresses in the unallocated list are sorted and stored according to the size of the IP addresses. In the process of allocating IP addresses, take out the IP address on the header from the unallocated list, and move the IP address to the allocated list. At the same time, the corresponding relationship between the allocated IP address and the container that obtained the IP address is recorded in the allocated list, so that when a certain container is deleted, the IP address of the deleted container can be found through the corresponding relationship. Reclaiming the IP address means moving the IP address from the assigned list to the unassigned list, and deleting the corresponding relationship stored in the assigned list and the information of the IP address. And, add this IP address to the end of the unassigned list without breaking the original order. The above allocation process is the way of dequeue and enqueue. In order to assign the IP address in the total address pool to the container to be assigned an IP address according to the method of dequeueing and entering the queue, it can be used to predict the IP address allocated to the container, and solve the problem of the prior art Calico-cni for each physical machine Assigning subnets randomly causes problems that users cannot foresee.

The method for allocating container IP addresses according to the embodiment of the present invention further includes: after performing static allocation or dynamic allocation, that is, after the container to be allocated an IP address is allocated an IP address, according to the allocated IP address, for the container to obtain the IP address Create a veth-pair (Virtual Ethernet Pair). Create a pair of veth-pairs, one end is sent to the inside of the container, and the other end exists in the form of a network card outside the container. There is no need to use a bridge interface, and the network packet is directly forwarded from the network card to the inside of the container. The address allocated by the container IP address allocation method of the embodiment of the present invention is configured to the network card inside the container, and routing is needed to ensure smooth network. The container IP address allocation method of the embodiment of the present invention is based on the IP address of the traditional network without using overlay or bridging, which simplifies the network architecture and ensures maximum network performance.

Fig. 2 is a schematic diagram of dynamic allocation according to an embodiment of the present invention.

When a request for IP address allocation is received, after the dynamic allocation is determined, as shown in Figure 2, it is determined whether the physical machine to which the container to be allocated an IP address belongs is configured with a specified address pool. If the specified address pool is not configured, the IP address is obtained from the total address and assigned to the container to be assigned the IP address. In the process of allocation, in order to distinguish allocated IP addresses from unallocated IP addresses, an unallocated list (unsignedIPs queue) and an allocated list (signedIPs queue) can be created. If it has already been created, it does not need to be created again. After creating the unassigned list and the assigned list, take out the first IP address in the unassigned list and assign it to the container, delete the IP address from the unassigned list, and add the IP address to the assigned list at the same time. For example, the IP address queue is initially arranged in ascending order, but when an address is released, it will be added to the tail of the queue, and then IP addresses will be allocated from the beginning to the end according to the order of the queue. For example: the initial queue of IP addresses is 172.30.1.1, 172.30.1.2, 172.30.1.3, 172.30.1.4. When there are three containers applying for addresses, 172.30.1.1, 172.30.1.2, and 172.30.1.3 will be assigned to the three containers respectively, so only the address 172.30.1.4 remains in the unsignedIPs queue. When the container with 172.30.1.2 is destroyed and the address is released, the released address will be added to the tail of the unsignedIPs queue, namely 172.30.1.4 and 172.30.1.2. If another container applies for IP address allocation, it will be allocated according to the order of the IP addresses in the current unsignedIPs queue, and then the address 172.30.1.4 will be allocated to the container instead of 172.30.1.2.

If the physical machine to which the container to be assigned an IP address belongs is configured with a specified address pool, it will be judged whether the specified address pool belongs to the total address pool, and if not, an error will be prompted. Because the total address pool set in the embodiment of the present invention can be used globally, each specified address pool configured should belong to the total address pool. After judging that the specified address pool belongs to the general address pool, in order to ensure the uniqueness of the container IP address, continue to judge whether the specified address pool overlaps with the specified address pools of other physical machines. If there is an intersection, an error is also displayed. Because the configuration of the specified address pool for the physical machine is realized through the configuration file, it is judged that there is no intersection between the specified address pool and the specified address pool of other physical machines, and the specified address pool is recorded in the etcd database. Synchronization of etcd. If the specified address pool has already been recorded on etcd, there is no need to record it again.

As shown in Figure 2, after recording the specified address pool on etcd, create an unsignedIPs queue and a signedIPs queue for the specified address pool, and initialize the unsignedIPs queue to the specified address pool, that is, the IP addresses in the specified address pool are all in unsignedIPs in queue. At the same time, initialize the signedIPs queue to be empty. If IP addresses have been allocated for the physical machines in the specified address pool, there is no need to create unsignedIPs queues and signedIPs queues, nor to perform initialization operations. After the above steps, the process of allocating IP addresses is still carried out in the way of dequeueing and entering pairs, that is, the first IP address in the current unsignedIPs queue is taken out, and if there is a container to be deleted, the IP address of the container is added to the unsignedIPs queue. At last.

After taking out the first IP address in the unsignedIPs queue, judge whether the IP address belongs to the static allocation list. The address continues to be judged. If the IP address taken out does not belong to the static allocation list, the IP address is moved from the unsignedIPs queue to the signedIPs queue. Furthermore, the unsignedIPs queue stores unassigned IP addresses, the IP addresses allocated in the records in the signedIPs queue and the container information for obtaining the IP addresses.

Fig. 3 is a schematic diagram of static allocation according to an embodiment of the present invention.

After the static allocation is determined according to the label of the container to be assigned an IP address, as shown in Figure 3, judge whether the IP address bound to the container belongs to the total address pool according to the label, because the total address pool is used globally, if not It is a prompt error. If the IP address bound to the container belongs to the general address pool, modify the container corresponding to the bound IP address to the current container, and record it in the static allocation list. In the process of static allocation, an IP address can be reused, and the IP address can be allocated to different containers by modifying the binding relationship. Then according to the judgment to this binding relationship, and judge which container is assigned to the IP address found by the binding relationship, determine whether the binding relationship between the IP address and the container changes. If the binding relationship has changed, it is necessary to record which container this address is currently using. If the binding relationship has not changed, there is no need to record it again.

On the basis of the above process, it will be relatively simple to recover the IP address when the container is deleted. First find the IP address through the correspondence between the container and the IP address, move the IP address from the signedIPs queue to the unsignedIPs queue, and clear the correspondence between the IP address and the container. And if the IP address is in the static binding list, you only need to delete the corresponding relationship between the IP address and the container.

In the process of assigning IP addresses by flannel in the prior art, users need to set up a flannel overlay network belonging to the same intranet IP segment on the etcd server. When Docker on a physical node starts, flannel will allocate a small range of subnets from the overlay network to this node if the flannel network model is used. In this way, the containers on the physical node will use the IP addresses in this subnet. The specific process includes: first set a {"Network":"10.1.0.0/16"} overlay network on the etcd server, and then use flannel parameters when the docker process on the physical machine starts, and flannel allocates subnets, such as For the following two physical machines, one is assigned 10.1.15.1/24 and the other is assigned 10.1.20.1/24. Then the containers on these two physical machines will use the IP addresses in the two subnets respectively. The embodiment of the present invention simplifies the process of allocating IP addresses by setting an address pool, which is similar to directly obtaining addresses from the 10.1.0.0/16 network without allocating subnets for each physical machine.

Moreover, when designing a network, if it is necessary to specify the container IP range on each physical machine or certain physical machines, flannel needs to configure an etcd server, while the container IP address allocation method in the embodiment of the present invention only needs to modify the configuration file . The container IP address allocation method of the embodiment of the present invention is a KubernetesCNI method, which can be used in conjunction with a binary file sDHClient and a configuration file. The configuration file is loaded when the kubelet starts, and configures the IP address used by the container on this node, that is, the specified address pool (subnet). In addition, it also configures the static allocation list of the specified container and IP address binding on etcd. The static allocation list records the correspondence between the label field of the container pod and the IP address. CNI generally needs to implement two interfaces cmdAdd and cmdDel, cmdAdd is used to give a container an address, and cmdDel is used to take back an address. Wherein, cmdAdd, cmdDel are a function interface in the CNI plug-in, and the embodiment of the present invention is all realized by the CNI plug-in.

First, check whether there is a label in the parameter (container name or container ID) of cmdAdd. If there is a label, it will be allocated statically, otherwise it will be allocated dynamically.

For dynamically assigning IP addresses, a total address pool (defaultPool) set in the etcd database is first required. The subnet in the configuration file on each kubelet node must belong to this address pool. If no subnet is configured, defaultPool is used by default. sDHClient also needs to check on etcd whether there is a specified address pool that intersects with the subnet. If there is, an error will be reported and the user will be prompted to modify the configuration to prevent the same IP address from being allocated.

sDHClient will allocate IP addresses to container pods in a way of dequeueing and entering pairs. And record the unsignedIPs queue and the assigned signedIPs queue in etcd to ensure that no duplicate IP addresses will be assigned. In addition, the subnet configured by the physical machine should be recorded on etcd to prevent overlapping with other nodes. Also, record the correspondence between the container and the allocated IP address on etcd, so that the IP address can be correctly reclaimed when the container is deleted. At the same time, before assigning the IP address to the container, it is also necessary to check whether the IP address is in the static address binding list. If it is in the list, the address needs to be skipped and removed from the unsignedIPs list to prevent sDHClient Assign this IP address to the unbound container.

Fig. 4 is a schematic diagram of main modules of a system for container IP address allocation according to an embodiment of the present invention. As shown in Figure 4, the container IP address allocation system 400 of the embodiment of the present invention mainly includes: a configuration module 401, a judgment module 402, a static allocation module 403 and a dynamic allocation module 404.

After the configuration module 401 is used to configure the total address pool, according to the first allocation requirement, a part of the IP addresses in the total address pool and the corresponding container are set up a one-to-one binding relationship;

Judgment module 402 is used for under the situation that receives the request of assigning IP address, judges whether the container of IP address to be assigned establishes binding relationship with the IP address in the total address pool;

The static allocation module 403 is used to perform static allocation after the judging module determines that the container to be allocated an IP address has a binding relationship with the IP address in the total address pool. The static allocation includes: placing the container to be allocated an IP address in the total address pool Assign the bound IP address to the container to be assigned the IP address;

The dynamic allocation module 404 is used to perform dynamic allocation after the judging module judges that the container to be allocated an IP address does not establish a binding relationship with the IP address in the total address pool. The dynamic allocation includes: unbound IP addresses in the total address pool The address is assigned to the container whose IP address is to be assigned.

Wherein, the configuration module 401 determines the binding label of the container to be bound to the IP address according to the first allocation requirement; establishes a one-to-one correspondence between the binding label and the IP address in the total address pool; records the correspondence in the static assignment list. Moreover, the static allocation module 403 includes: an acquisition unit, configured to obtain the binding label of the container to be allocated an IP address according to the received request for allocation of the IP address; a search unit, configured to search the static allocation list according to the binding label output the corresponding IP address; the allocation unit is used to allocate the IP address to the container to be allocated the IP address.

The configuration module 401 is also used to configure the total address pool according to network planning, and store the total address pool in a distributed manner in the etcd database. And, according to the second allocation requirement, the specified address pool is configured for the specified physical machine through the configuration file, and the IP addresses in the specified address pool are all included in the total address pool.

The dynamic allocation module 404 is also used to determine whether the physical machine where the container of the IP address to be allocated is located is configured with a specified address pool; if not, the dynamic allocation module allocates the unbound IP address in the total address pool to the IP address to be allocated Otherwise, the dynamic allocation module allocates the unbound IP address in the specified address pool to the container to be allocated the IP address. The dynamic allocation module is also used to judge whether there is an intersection between the specified address pool and the specified address pool of other physical machines; if there is an intersection, output an error message; otherwise, assign the IP address in the unallocated list in the specified address pool to the IP address to be allocated The container of the IP address, and the IP address is removed from the unassigned list, and the IP address is correspondingly recorded in the allocated list with the container from which the IP address was obtained.

In the process of allocating IP addresses, the static allocation module and the dynamic allocation module allocate the IP addresses in the total address pool to the containers to be allocated IP addresses according to the mode of going out and entering the team. And the container IP address allocation system of the embodiment of the present invention also includes a creation module, which is used to create a pair of veth-pairs for the container to be allocated an IP address according to the allocated IP address after static allocation or dynamic allocation.

The container IP address allocation system of the embodiment of the present invention writes a total address pool in the etcd database in advance, and each kubelet node can freely share this total address pool as required. Each kubelet node can also configure a specified address pool for the kubelet node through the configuration file according to requirements, but the specified address pool belongs to the pre-written total address pool in etcd. If no specified address pool is configured, the preset total address pool in etcd will be used by default during the process of allocating IP addresses. At the same time, the container IP address allocation system in the embodiment of the present invention also provides the function of binding the container and the IP address, unlike DHCP (Dynamic Host Configuration Protocol, Dynamic Host Configuration Protocol, dynamic host configuration protocol) through MAC address and IP address binding, The binding in the container IP address allocation system of the embodiment of the present invention is to bind the container label and the IP address. The container IP address allocation system of the embodiment of the present invention will also create a veth-pair, one end is sent to the inside of the container, and the other end exists in the form of a network card outside the container. There is no need to use a bridge interface, and the network packet is directly forwarded from the network card to the inside of the container. The address allocated by the container IP address allocation system in the embodiment of the present invention is configured to the network card inside the container, and routing is required to ensure the smooth flow of the network.

Fig. 5 shows an exemplary system architecture 500 to which the method for allocating container IP addresses or the system for allocating container IP addresses according to the embodiments of the present invention can be applied.

As shown in FIG. 5 , the system architecture 500 may include terminal devices 501, 502, 503, a network 504 and a server 505. The network 504 serves as a medium for providing communication links between the terminal devices 501, 502, 503 and the server 505. Network 504 may include various connection types, such as wires, wireless communication links, or fiber optic cables, among others.

Users can use terminal devices 501 , 502 , 503 to interact with server 505 via network 504 to receive or send messages and the like. Various communication client applications can be installed on the terminal devices 501, 502, and 503, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, and the like.

Terminal devices 501, 502, 503 may be various electronic devices with display screens and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers and desktop computers, and the like.

The server 505 may be a server that provides various services, such as a background management server that provides support for shopping websites browsed by users using the terminal devices 501, 502, and 503. The background management server can analyze and process the received data such as product information query requests, and feed back the processing results to the terminal device.

It should be noted that the container IP address allocation method provided by the embodiment of the present invention is generally executed by the server 505, and correspondingly, the container IP address allocation system is generally set in the server 505.

It should be understood that the numbers of terminal devices, networks and servers in Figure 5 are only illustrative. According to the implementation needs, there can be any number of terminal devices, networks and servers.

Referring to Fig. 6, it shows a schematic structural diagram of a computer system 600 suitable for implementing a terminal device according to an embodiment of the present invention. The terminal device shown in FIG. 6 is only an example, and should not limit the functions and scope of use of this embodiment of the present invention.

As shown in FIG. 6 , a computer system 600 includes a central processing unit (CPU) 601 that can be programmed according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage section 608 into a random-access memory (RAM) 603 Instead, various appropriate actions and processes are performed. In the RAM 603, various programs and data necessary for the operation of the system 600 are also stored. The CPU 601 , ROM 602 , and RAM 603 are connected to each other through a bus 604 . An input/output (I/O) interface 605 is also connected to the bus 604 .

The following components are connected to the I/O interface 605: an input section 606 including a keyboard, a mouse, etc.; an output section 607 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker; a storage section 608 including a hard disk, etc. and a communication section 609 including a network interface card such as a LAN card, a modem, or the like. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the I/O interface 605 as needed. A removable medium 611, such as a magnetic disk, optical disk, magneto-optical disk, semiconductor memory, etc., is mounted on the drive 610 as necessary so that a computer program read therefrom is installed into the storage section 608 as necessary.

In particular, according to the disclosed embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the disclosed embodiments of the present invention include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes program codes for executing the methods shown in the flowcharts. In such an embodiment, the computer program may be downloaded and installed from a network via communication portion 609, and/or installed from removable media 611. When this computer program is executed by a central processing unit (CPU) 601, the above-mentioned functions defined in the system of the present invention are performed.

It should be noted that the computer-readable medium shown in the present invention may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. A computer readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer readable storage media may include, but are not limited to, electrical connections with one or more wires, portable computer diskettes, hard disks, random access memory (RAM), read only memory (ROM), erasable Programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination of the above. In the present invention, a computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In the present invention, however, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code therein. Such propagated data signals may take many forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the foregoing. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device. . Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, program segment, or portion of code that includes one or more logical functions for implementing specified executable instructions. It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or they may sometimes be executed in the reverse order, depending upon the functionality involved. It should also be noted that each block in the block diagrams or flowchart illustrations, and combinations of blocks in the block diagrams or flowchart illustrations, can be implemented by a dedicated hardware-based system that performs the specified function or operation, or can be implemented by a A combination of dedicated hardware and computer instructions.

The modules involved in the embodiments of the present invention can be realized by software or by hardware. The described modules can also be set in a processor, for example, it can be described as: a processor includes a configuration module, a judging module, a static allocation module and a dynamic allocation module. Wherein, the names of these modules do not constitute a limitation on the module itself under certain circumstances. For example, the configuration module can also be described as "after the general address pool is configured, the A module that establishes a one-to-one binding relationship between some IP addresses and corresponding containers."

As another aspect, the present invention also provides a computer-readable medium. The computer-readable medium may be included in the device described in the above embodiments, or it may exist independently without being assembled into the device. The above-mentioned computer-readable medium carries one or more programs, and when the above-mentioned one or more programs are executed by one device, the device includes: after the general address pool is configured, according to the first allocation requirement, the Part of the IP address of the corresponding container establishes a one-to-one correspondence binding relationship; in the case of receiving a request for assigning an IP address, determine whether the container to be assigned an IP address establishes a binding relationship with the IP address in the total address pool ; If yes, perform static allocation, the static allocation includes: assigning the IP address bound to the container with the IP address to be allocated in the total address pool to the container with the IP address to be allocated; otherwise, perform Dynamic allocation, the dynamic allocation includes: allocating unbound IP addresses in the total address pool to the container of the to-be-allocated IP address.

According to the technical solution of the embodiment of the present invention, a total address pool is configured for use by all containers in the cluster, and it is guaranteed that any address can be used by all nodes. And through the establishment of a binding relationship between the container label and the IP address, the IP address does not change when the container is restarted or migrated. By integrating dynamic IP address allocation and static IP address allocation into one, it is more convenient for network layout.

The above specific implementation methods do not constitute a limitation to the protection scope of the present invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations and substitutions may occur depending on design requirements and other factors. Any modifications, equivalent replacements and improvements made within the spirit and principles of the present invention shall be included within the protection scope of the present invention.

Claims (17)

1. A kind of 1. method of container IP address distribution, it is characterised in that including：

   The part IP address in total address pool is established into one-to-one binding with corresponding container according to the first distribution requirements to close System；

   In the case of the request for receiving distribution IP address, judge whether the container of IP address to be allocated has to bind with IP address and close System；

   If so, the IP address bound in the container of the IP address to be allocated is then distributed into the container；

   Otherwise, IP address unbound in total address pool is distributed to the container of the IP address to be allocated.
2. 2. according to the method for claim 1, it is characterised in that

   Described established the part IP address in total address pool with corresponding container according to the first distribution requirements is tied up correspondingly The step of determining relation includes：Part IP address is read out from total address pool according to the first distribution requirements, and according to first point Determine to treat the binding tab of the container of binding IP address with demand；The binding tab and the IP address read out are established one To one corresponding relation；The corresponding relation is recorded in static allocation list；

   Whether the container for judging IP address to be allocated with IP address has the step of binding relationship to include：With judging IP to be allocated Whether the container of location has binding tab；

   The step of IP address by bound in the container of the IP address to be allocated distributes to the container includes：Obtain and treat point The binding tab of container with IP address；IP corresponding to being found out according to the binding tab in the static allocation list Location；The IP address is distributed to the container of the IP address to be allocated.
3. 3. according to the method for claim 1, it is characterised in that it is described according to the first distribution requirements by the portion in total address pool Before the step of point IP address establishes one-to-one binding relationship with corresponding container, in addition to：According to predetermined IP Number of addresses configures total address pool；Then total address pool is stored in etcd database.
4. 4. according to the method for claim 1, it is characterised in that

   Described established the part IP address in total address pool with corresponding container according to the first distribution requirements is tied up correspondingly Before the step of determining relation, in addition to：It is that the physical machine specified configures specified ground by configuration file according to the second distribution requirements Location pond, and the IP address in the given pool is integrally incorporated in total address pool；

   Described the step of IP address unbound in total address pool is distributed into the container of the IP address to be allocated, includes： Whether the physical machine where judging the container of the IP address to be allocated is configured with given pool；If it is not, by described in Unbound IP address distributes to the container of the IP address to be allocated in total address pool；Otherwise, by the given pool Unbound IP address distributes to the container of the IP address to be allocated.
5. 5. according to the method for claim 4, it is characterised in that described by IP address point unbound in total address pool Also include the step of the container of IP address to be allocated described in dispensing：

   Judge whether the given pool and the given pool of other physical machines have common factor；

   If occuring simultaneously, then error information is exported；Otherwise, the IP address in unallocated list in the given pool is distributed To the container of the IP address to be allocated, and will be removed in the IP address never distribution list, and by the IP address Container with obtaining the IP address is accordingly recorded in distribution list.
6. 6. according to the method for claim 1, it is characterised in that

   The step of IP address by bound in the container of the IP address to be allocated distributes to the container includes：According to current The order determination of the IP address of binding is located at primary IP address, and the IP address then is distributed into the container；

   Described the step of IP address unbound in total address pool is distributed into the container of the IP address to be allocated, includes： Determined to be located at primary IP address according to the order of IP address unbound in total address pool, then distribute to the IP address The container.
7. 7. according to the method for claim 1, it is characterised in that after IP address is distributed into container, in addition to：

   According to allocated IP address, a pair of veth-pair are created to obtain the container of the IP address.
8. A kind of 8. system of container IP address distribution, it is characterised in that including：

   Configuration module, for being established the part IP address in total address pool one by one with corresponding container according to the first distribution requirements Corresponding binding relationship；

   Judge module, for receive distribution IP address request in the case of, judge IP address to be allocated container whether There is binding relationship with IP address；

   Static allocation module, for judging that the container of the IP address to be allocated has binding with IP address in the judge module After relation, the IP address bound in the container of the IP address to be allocated is distributed into the container；

   Dynamically distributes module, for judging that the container of the IP address to be allocated is not tied up with IP address in the judge module After determining relation, IP address unbound in total address pool is distributed to the container of the IP address to be allocated.
9. 9. system according to claim 8, it is characterised in that

   The configuration module is additionally operable to, and part IP address is read out from total address pool according to the first distribution requirements, and according to First distribution requirements are determined to treat the binding tab of the container of binding IP address；By the binding tab and the IP address read out Establish man-to-man corresponding relation；The corresponding relation is recorded in static allocation list；

   The judge module is additionally operable to, and judges the container of IP address to be allocated and whether has binding tab.
10. 10. system according to claim 9, it is characterised in that the static allocation module includes：

    Acquiring unit, the binding tab of the container for obtaining IP address to be allocated；

    Searching unit, for finding out corresponding IP address in the static allocation list according to the binding tab；

    Allocation unit, for the IP address to be distributed to the container of the IP address to be allocated.
11. 11. system according to claim 8, it is characterised in that the configuration module is additionally operable to, according to the first distribution need Before asking the step of part IP address in total address pool is established into one-to-one binding relationship with corresponding container, according to pre- The total address pool of IP address quantity configuration first determined；Then total address pool is stored in etcd database.
12. 12. system according to claim 8, it is characterised in that the configuration module is additionally operable to, according to the first distribution requirements Before the step of part IP address in total address pool is established into one-to-one binding relationship with corresponding container, according to second Distribution requirements are that the physical machine specified configures given pool, and the IP address in the given pool by configuration file It is integrally incorporated in total address pool；And

    The dynamically distributes model is additionally operable to, and whether the physical machine where judging the container of the IP address to be allocated is configured with finger Determine address pool；If it is not, IP address unbound in total address pool is distributed to the appearance of the IP address to be allocated Device；Otherwise, IP address unbound in the given pool is distributed to the container of the IP address to be allocated.
13. 13. system according to claim 12, it is characterised in that the dynamically distributes module is additionally operable to, and judges the finger Whether the given pool for determining address pool and other physical machines has common factor；If occuring simultaneously, then error information is exported；Otherwise, will IP address in the given pool in unallocated list distributes to the container of the IP address to be allocated, and by the IP Removed in the never distribution list of address, and the IP address has been divided with obtaining the container of the IP address and being accordingly recorded in With in list.
14. 14. system according to claim 8, it is characterised in that

    The static allocation module is additionally operable to, and is determined to be located at primary IP address according to the order of the IP address of current bindings, Then the IP address is distributed into the container；

    The dynamically distributes module is additionally operable to, and is determined according to the order of IP address unbound in total address pool positioned at primary IP address, the IP address is then distributed into the container.
15. 15. system according to claim 8, it is characterised in that also include：

    Creation module, after IP address is distributed into container, according to allocated IP address, to obtain the appearance of the IP address Device creates a pair of veth-pair.
16. A kind of 16. container IP address assigned unit, it is characterised in that including：

    One or more processors；

    Storage device, for storing one or more programs,

    When one or more of programs are by one or more of computing devices so that one or more of processors are real The now method as described in any in claim 1-7.
17. 17. a kind of computer-readable medium, is stored thereon with computer program, it is characterised in that described program is held by processor The method as described in any in claim 1-7 is realized during row.