CN115484231A

CN115484231A - Pod IP allocation method and related device

Info

Publication number: CN115484231A
Application number: CN202211112956.1A
Authority: CN
Inventors: 马亮; 陆健健; 杨佳奇; 刘青; 周明伟
Original assignee: Zhejiang Dahua Technology Co Ltd
Current assignee: Zhejiang Dahua Technology Co Ltd
Priority date: 2022-09-14
Filing date: 2022-09-14
Publication date: 2022-12-16
Anticipated expiration: 2042-09-14
Also published as: CN115484231B

Abstract

The application discloses a Pod IP allocation method and a related device, and relates to the technical field of communication. In the application, a scheduler sends a Pod creation request to a target node meeting the IP requirement according to the IP requirement stored by the Pod creation request in a correlated manner, the target node applies the Pod IP meeting the IP requirement to an IP manager, creates a target Pod and configures the Pod IP for the target Pod, meanwhile, a binding relation is established between the Pod IP and the IP requirement, a Pod IP management module continuously monitors the IP requirement, and when the IP requirement is determined to be updated, a new Pod IP is applied to the IP manager again, or the target Pod is expelled to the scheduler for rescheduling. By adopting the method, the Pod can avoid rescheduling even if the IP requirement is updated, the flexibility of IP allocation is improved, the IP requirement is managed independently, the system can carry out IP allocation according to various IP requirements, and the limitation of the IP allocation method is reduced.

Description

Pod IP allocation method and related device

Technical Field

The present application relates to the field of communications technologies, and in particular, to a Pod IP allocation method and a related apparatus.

Background

An open source container orchestration system (kubernets, K8s for short) is an open source for managing containerized applications on multiple hosts in a cloud platform, and the goal of kubernets is to make deploying containerized applications simple and efficient. Pod is the most important and basic concept of Kubernetes, and is the smallest unit of deployment that can be created, scheduled, and managed, and a Pod or multiple pods can be packaged by a Pod. Kubernetes assigns a unique Internet Protocol Address (IP Address), which may also be referred to as Pod IP, to each Pod, and multiple containers in a Pod share the Pod IP.

With the wider and wider application range of kubernets, the existing IP allocation method gradually cannot meet the IP requirements of Pod in some complex and specific scenes.

For example, in practical applications, some services use an IP address as a unique identifier for access, that is, service functions provided by each container in a corresponding Pod are called through Pod IP, such a Pod has no special requirement for the IP address when being started for the first time, and a system randomly allocates an IP address for the Pod, and in order to ensure normal access to subsequent services, such a Pod specifically requires to use the IP address once when being restarted, that is, when being restarted, the IP address is updated.

However, in the IP allocation method in the related art, the IP requirement is tightly combined with the Pod, and the IP requirement can only be obtained in the Pod scheduling stage, so that the IP requirement cannot be modified under the condition that the Pod is not rescheduled, and the IP allocation method is not flexible enough.

For another example, in practical applications, the Pod using the macvlan virtual network card technology generally needs to allocate an IP address to a local area network exclusive network segment where the IP address of a node is located; and Pod using cni plug-in, it is usually necessary to allocate IP addresses to the Pod in the configured proprietary network segment, and the IP addresses in various proprietary network segments may be updated continuously with the modification of the service provider, and accordingly, the IP requirements of Pod will be updated accordingly.

However, the IP allocation method in the related art can only allocate a fixed IP address to a Pod according to the fixed IP requirement of the Pod, and cannot cope with the IP requirement that changes every moment, so that the IP address of the Pod cannot be updated, and once the IP address cannot be updated in time, the related service cannot be called continuously, thereby affecting the service effect.

Therefore, it is necessary to provide a Pod IP allocation method capable of meeting various different requirements, so as to improve flexibility of Pod IP allocation.

Disclosure of Invention

The embodiment of the application provides a method and a related device for allocating Pod IP, which are used for improving the flexibility of Pod IP allocation.

In a first aspect, an embodiment of the present application provides a Pod IP allocation method, which is applied to a scheduler, and the method includes:

receiving a Pod creation request, acquiring an IP (Internet protocol) requirement stored in association with the corresponding Pod creation request, and acquiring a first IP type indicated by the IP requirement;

sending a Pod creation request to a first target node to enable the first target node to create a target Pod, and configuring a corresponding Pod IP for the target Pod based on a first IP type; the IP address used by the first target node is matched with the first IP type;

receiving a target Pod which is evicted by a first target node based on a trigger event, wherein the trigger event is: in the process of continuously monitoring the IP demand, determining that the IP demand is updated and the Pod IP does not conform to a second IP type indicated by the updated IP demand;

and migrating the target Pod to a second target node to carry out Pod IP reconfiguration, wherein the IP address used by the second target node is matched with the second IP type.

In a second aspect, an embodiment of the present application provides a Pod IP allocation method, which is applied to a first target node, and the method includes:

receiving a Pod creation request sent by a scheduler, and acquiring an IP (Internet protocol) requirement stored in association with the corresponding Pod creation request, wherein the IP requirement is used for indicating a first IP type, and an IP address used by a first target node is matched with the first IP type;

creating a target Pod, and configuring a Pod IP (Internet protocol) which accords with the first IP type for the target Pod based on the IP requirement;

and continuously monitoring the IP demand, and when the IP demand is determined to be updated and the Pod IP does not conform to the second IP type indicated by the updated IP demand, expelling the target Pod to the scheduler so that the scheduler migrates the target Pod to a second target node for Pod IP reconfiguration, wherein the IP address used by the second target node is matched with the second IP type.

In a third aspect, an embodiment of the present application further provides a Pod IP allocation apparatus, which is applied to a scheduler, and the apparatus includes:

the first receiving module is used for receiving the Pod creation request, acquiring the IP requirement stored in association with the corresponding Pod creation request and acquiring a first IP type indicated by the IP requirement;

a first sending module, configured to send a Pod creation request to a first target node, so that the first target node creates a target Pod, and configures a corresponding Pod IP for the target Pod based on a first IP type; the IP address used by the first target node is matched with the first IP type;

a second receiving module, configured to receive a target Pod evicted by the first target node based on a trigger event, where the trigger event is: in the process of continuously monitoring the IP demand, determining that the IP demand is updated and the Pod IP does not conform to the second IP type indicated by the updated IP demand;

and the second sending module is used for migrating the target Pod to a second target node for Pod IP reconfiguration, wherein the IP address used by the second target node is matched with the second IP type.

Optionally, when receiving a Pod creation request and acquiring an IP requirement stored in association with the Pod creation request, the first receiving module is configured to:

receiving a Pod creation request triggered by a target object;

and acquiring an IP requirement stored in association with the corresponding Pod creation request at a specified storage position, wherein the IP requirement is declared by a target object when the Pod creation request is triggered and is stored at the specified storage position, and the target object updates in real time based on a use requirement after the IP requirement is stored.

In a fourth aspect, an embodiment of the present application further provides a Pod IP allocation apparatus, which is applied to a first target node, and the apparatus includes:

the receiving module is used for receiving the Pod creation request sent by the scheduler and acquiring the IP requirement stored in association with the corresponding Pod creation request, wherein the IP requirement is used for indicating a first IP type, and the IP address used by the first target node is matched with the first IP type;

the system comprises a creating module, a sending module and a receiving module, wherein the creating module is used for creating a target Pod and configuring a Pod IP which accords with a first IP type for the target Pod based on an IP requirement;

and the monitoring module is used for continuously monitoring the IP requirement, and when the IP requirement is determined to be updated and the Pod IP does not conform to the second IP type indicated by the updated IP requirement, the target Pod is expelled to the scheduler so that the scheduler migrates the target Pod to a second target node for Pod IP reconfiguration, wherein the IP address used by the second target node is adaptive to the second IP type.

Optionally, when receiving a Pod creation request sent by the scheduler and acquiring an IP requirement stored in association with the corresponding Pod creation request, the receiving module is configured to:

receiving a Pod creation request sent by a scheduler;

Optionally, if a bound Pod IP is stored in the corresponding IP requirement, when a Pod IP conforming to the first IP type is configured for the target Pod based on the IP requirement, the creating module is specifically configured to:

acquiring a bound Pod IP from a specified storage position based on an IP requirement, wherein the bound Pod IP conforms to a first IP type;

and configuring the acquired bound Pod IP to the target Pod.

Optionally, when the obtained bound Pod IP is configured to the target Pod, the creating module is further configured to:

and entering a network name space of the target Pod and configuring the bound Pod IP for the Pod network card.

Optionally, if the bound Pod IP is not stored in the corresponding IP requirement, when a corresponding Pod IP is configured for the target Pod based on the first IP type, the creating module is specifically configured to:

sending the first IP type to an IP manager, and receiving the Pod IP which is returned by the IP manager and accords with the first IP type;

and configuring the Pod IP for the target Pod.

Optionally, the creating module is further configured to:

and if the IP manager does not return the Pod IP which conforms to the first IP type, prompting failure of creating the target Pod to the target object.

Optionally, after configuring a corresponding Pod IP for the target Pod based on the first IP type, the creating module is further configured to:

and establishing a binding relation between the Pod IP and the IP requirement.

Optionally, the creating module is further configured to:

in the process of continuously monitoring the IP demand, when the IP demand is determined to be deleted, any one of the following operations is executed:

unbinding the binding relationship;

and releasing the binding relation and releasing the corresponding Pod IP.

Optionally, when it is determined that the IP requirement is updated and the Pod IP does not conform to the second IP type indicated by the updated IP requirement, the target Pod is evicted to the scheduler, and the monitoring module is configured to:

when the IP requirement is determined to be updated and the Pod IP does not conform to the second IP type indicated by the updated IP requirement, the first target node further judges whether the IP address used by the first target node is matched with the second IP type;

if not, the target Pod is evicted to the scheduler.

Optionally, the monitoring module is further configured to:

if the adaptation is carried out, a new Pod IP which is in accordance with the second IP type is applied to the IP manager again;

receiving a new Pod IP returned by the IP manager;

and configuring a new Pod IP for the target Pod.

In a fifth aspect, an embodiment of the present application provides an electronic device, which includes a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor implements the method according to any one of the first aspect when executing the computer program.

In a sixth aspect, the present application provides a computer-readable storage medium, on which a computer program is stored, where the computer program is executed by a processor to implement the steps of the method according to any one of the first aspect.

In a seventh aspect, the present application provides a computer program product, which when called by a computer, causes the computer to execute the method according to the first aspect.

In the embodiment of the application, a scheduler sends a Pod creation request to a target node meeting the IP requirement according to the IP requirement stored in association with the Pod creation request, the target node is communicated with an IP manager, a Pod IP meeting the IP requirement is applied to the IP manager and returned to the target node, a Pod IP management module in the target node creates the target Pod and configures the Pod IP for the target Pod, a binding relation is established between the Pod IP and the IP requirement, the Pod IP management module continuously monitors the IP requirement associated with the target Pod, when the IP requirement is determined to be updated, the Pod IP management module re-applies the Pod IP meeting the updated IP requirement to the IP manager, or the target Pod is expelled to the scheduler, and the scheduler re-schedules the target Pod to other target nodes.

By adopting the mode, the Pod creation request and the IP requirement are managed separately, and after the Pod is successfully created, even if the IP requirement is updated, the Pod can avoid rescheduling, so that the flexibility of IP allocation is improved, meanwhile, the IP requirement and the Pod IP adopt a dynamic binding mode, so that the target node and the IP manager can monitor the change of the IP requirement more accurately, and because the IP requirement adopts an independent management mode, when the Pod puts forward a new IP requirement, only the plug-in type is needed to increase the realization of the IP requirement manager, so that the system can carry out IP allocation according to various IP requirements, and the limitation of an IP allocation method is reduced.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without inventive exercise. In the drawings:

FIG. 1 is a system architecture diagram according to an embodiment of the present application;

FIG. 2 is a flowchart illustrating the steps of a scheduler during Pod IP allocation according to an embodiment of the present invention;

fig. 3 is a flowchart of a first target node step in Pod IP allocation in the embodiment of the present application;

fig. 4 is a logic diagram of Pod IP allocation in a specific application scenario in the embodiment of the present application;

FIG. 5 is a flowchart illustrating steps of a scheduler in a Pod IP allocation process in a specific application scenario according to an embodiment of the present application;

fig. 6 is a flowchart of a step of a target node in Pod IP allocation in a specific application scenario in the embodiment of the present application;

fig. 7 is a logic diagram illustrating communication between a Pod IP management module and an IP manager in a specific application scenario in the embodiment of the present application;

fig. 8 is a flowchart of steps of an IP manager in Pod IP allocation in a specific application scenario in the embodiment of the present application;

fig. 9 is a flowchart of a step of a Pod IP management module during Pod IP allocation in a specific application scenario in the embodiment of the present application;

fig. 10 is a flowchart of a step of recovering IP resources by an IP manager in a specific application scenario in the embodiment of the present application;

fig. 11 is a schematic structural diagram of a Pod IP allocation apparatus in an embodiment of the present application;

fig. 12 is a schematic structural diagram of a Pod IP allocation apparatus in an embodiment of the present application;

fig. 13 is a schematic structural diagram of an electronic device in an embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some embodiments, but not all embodiments, of the technical solutions of the present application. All other embodiments obtained by a person skilled in the art based on the embodiments described in the present application without any creative effort belong to the protection scope of the technical solution of the present application.

Some concepts related to the embodiments of the present application are described below.

(1) A container cloud platform: the container is used as a basic unit for resource segmentation and scheduling, the whole software runtime environment is packaged, and a platform for constructing, publishing and running distributed applications is provided for developers and system administrators.

(2) Open source container arrangement system (Kubernetes, K8s for short): the method is a distributed architecture solution based on container technology, and is used for automatically deploying, expanding and managing the open-source system of the containerized application program.

(3) A scheduler: in kubernets, a scheduler discovers newly created pots in a cluster and not scheduled to a node through a monitoring (Watch) mechanism of kubernets, and the scheduler schedules each discovered unscheduled pot to a suitable node to run.

(4) And (3) node: kubernetes performs all workloads by placing containers in a Pod running on a Node. The nodes may be a virtual machine or a physical machine, each containing the services required to run a Pod, depending on the cluster configuration in which it is located.

(5) A Pod IP management module: and the node is positioned in each node and is responsible for creating the Pod, applying for an IP address from the IP manager, configuring the Pod IP for the Pod and binding or unbinding the Pod IP and the IP requirement associated with the Pod.

(6) An IP resource pool: all IP addresses in the Kubernetes system are maintained, responsible for provisioning and reclaiming Pod IP.

(7) etcd: a reliable distributed data storage is provided, which can persistently store all data of all resource objects in Kubernetes configured by a cluster in etcd.

Preferred embodiments of the present application will be described in detail below with reference to the accompanying drawings.

Referring to fig. 1, the embodiment of the present application includes five main parts, i.e., a Pod to be created 100, a scheduler 101, a target node 102, an IP manager 103, and an IP resource pool 104, where the target node 102 further includes a Pod IP management module 105, and the Pod to be created has an associated stored IP requirement 106. The method comprises the steps that a scheduler 101 receives a Pod creation request of a Pod 100 to be created, the Pod creation request of the Pod to be created is sent to a target node 102 through an IP requirement 106 stored in association with the Pod to be created, a Pod IP management module 105 in the target node 102 communicates with an IP manager 103, an IP address adaptive to an IP requirement 106 is obtained from an IP resource pool 104 and is configured to a target Pod after successful creation, the IP management module 105 continuously monitors the IP requirement 106, once the IP requirement 106 is updated, the target node 102 determines whether to configure a new Pod IP for the target Pod or not according to the updated IP requirement 106, and the scheduler 101 determines whether to reschedule the target Pod to the new target node or not.

Based on the system architecture, referring to fig. 2, in the embodiment of the present application, a detailed flow executed by a scheduler in a Pod IP allocation process is as follows:

step 201: the dispatcher receives the Pod creation request, acquires the IP requirement stored in association with the corresponding Pod creation request, and acquires the first IP type indicated by the IP requirement.

Specifically, in the embodiment of the present application, a scheduler receives a Pod creation request triggered by a target object, and acquires, at a specified storage location, an IP requirement stored in association with the Pod creation request, where the IP requirement is declared by the target object when the Pod creation request is triggered and is stored at the specified storage location, and after the IP requirement is stored, the target object updates in real time based on a usage requirement.

For example, the scheduler receives a Pod creation request 1 triggered by a target object, and in an etcd, acquires an IP requirement stored in association with the corresponding Pod creation request 1, and acquires a first IP type indicated by the IP requirement, assuming that the first IP type is a C-type network segment: 192.168.0.0-192.168.255.255.

Step 202: the dispatcher sends a Pod creation request to the first target node so that the first target node creates a target Pod, and configures a corresponding Pod IP for the target Pod based on the first IP type.

Wherein the IP address used by the first target node is adapted to the first IP type.

For example, assuming that the IP address used by the target node 1 is 192.168.1.1, and belongs to the C-type network segment, the target node 1 is the first target node adapted to the first IP type, the scheduler sends a Pod creation request 1 to the target node 1, creates a target Pod 1 by the target node 1, and configures a corresponding Pod IP for the target Pod 1 based on the IP address in the C-type network segment.

Step 203: the scheduler receives a target Pod for eviction by the first target node based on the trigger event.

Wherein the triggering event is: and in the process of continuously monitoring the IP demand, determining that the IP demand is updated and the Pod IP does not conform to the second IP type indicated by the updated IP demand.

For example, the target object associates Pod 1 with the first IP type indicated by the saved IP requirement: and the type C network segment is updated to be of a second IP type: when the type B network segment is detected, the target node 1 monitors the update, and determines that the IP address used by the target node 1 does not conform to the second IP type, that is, 192.168.1.1 does not belong to the type B network segment: 172.16.0.0-172.31.255.255, the scheduler will receive the target Pod 1 evicted from target node 1.

Step 204: and the dispatcher migrates the target Pod to a second target node for Pod IP reconfiguration.

Wherein the IP address used by the second target node is adapted to the second IP type.

For example, assume that the IP address used by the target node 2 is: 172.16.1.1, belonging to the class B network segment, if the target node 2 is the second target node adapted to the second IP type, the scheduler migrates the target Pod 1 to the target node 2, and the target node 2 performs Pod IP reconfiguration on the target Pod 1.

Further, referring to fig. 3, in the embodiment of the present application, in the Pod IP allocation process, a detailed flow executed by the target node is as follows:

step 301: and the first target node receives the Pod creation request sent by the scheduler and acquires the IP requirement stored in association with the corresponding Pod creation request.

Wherein the IP requirement is used for indicating a first IP type, and the IP address used by the first target node is adapted to the first IP type.

Specifically, in this embodiment of the application, a first target node receives a Pod creation request 1 sent by a scheduler, and acquires, at a specified storage location, an IP requirement stored in association with the Pod creation request 1, where the IP requirement is declared by a target object when the Pod creation request 1 is triggered and is stored at the specified storage location, and after the IP requirement is stored, the target object updates in real time based on a usage requirement.

For example, the target node 1 receives the Pod creation request 1 sent by the scheduler, and in the etcd, acquires the IP requirement stored in association with the corresponding Pod creation request 1, and acquires the first IP type indicated by the IP requirement, assuming that the first IP type is a network segment of type C: 192.168.0.0-192.168.255.255, and the IP address used by the target node 1 is: 192.168.1.1, belonging to class C network segment, i.e. the IP address used by the destination node 1 is adapted to the first IP type.

Based on the step 301, the IP requirement and the Pod creation request are decoupled, and an independent management mode is adopted for the IP requirement, so that the system can perform IP allocation for various IP requirements, and the limitation of the IP allocation method is reduced.

Step 302: the first target node creates a target Pod and configures Pod IP which is in accordance with the first IP type for the target Pod based on the IP requirement.

Specifically, in this embodiment of the application, for whether the bound Pod IP is stored in the IP requirement, when the first target node configures the Pod IP for the target Pod, the following two situations specifically exist but are not limited to:

the first condition is as follows: and if the bound Pod IP is stored corresponding to the IP requirement, the first target node acquires the bound Pod IP from the specified storage position based on the IP requirement, wherein the bound Pod IP conforms to the first IP type, and the acquired bound Pod IP is configured to the target Pod.

For example, target node 1 creates target Pod 1, assuming the bound Pod IP is: 192.168.1.2, belonging to a class C network segment, that is, the bound Pod I conforms to the first IP type, and the target node 1 obtains the Pod IP from the IP resource pool and configures the Pod IP to the target Pod 1.

Further, in this embodiment of the application, when the Pod IP is configured, the first target node enters a network namespace of the target Pod, and configures the bound Pod IP for the Pod network card.

For example, the target node 1 enters the network namespace of the target Pod 1, and configures the bound Pod IP for the Pod network card of the target Pod 1.

Case two: if the bound Pod IP is not stored according to the IP requirement, the first target node sends the first IP type to the IP manager and receives the Pod IP which is returned by the IP manager and accords with the first IP type; and the first target node configures Pod IP for the target Pod.

For example, if the bound Pod IP is not saved for the corresponding IP requirement, the target node 1 will: and the C-type network segment is sent to the IP manager, the IP manager finds out an unoccupied IP address belonging to the C-type network segment from the IP resource pool, and returns the unoccupied IP address to the target node 1, and the assumption is that: 192.168.1.3, finally, the IP management module in the target node 1 configures the Pod IP for the target Pod 1.

Further, if the IP manager does not return a Pod IP meeting the first IP type, the first target node prompts to the target object that the creation of the target Pod fails.

For example, when the first IP type indicated by the IP requirement stored in the Pod create request association is: 192.168.1.4, that is, the Pod IP required by the Pod create request must be 192.168.1.4, and this IP address is already occupied by other running pods, the IP manager will not return a Pod IP conforming to the first IP type, at which point the target node 1 prompts the target object that the creation of the target Pod failed.

Specifically, after step 302 is executed and before step 303 is executed, the first target node establishes a binding relationship between the Pod IP and the IP requirement.

For example, the target node 1 establishes a binding relationship between the Pod IP with the IP address 192.168.1.3 and the target Pod 1.

Based on the step 302, the binding relationship is established between the Pod IP and the target Pod, so that the target node and the IP manager can monitor the change of the IP demand more accurately, and the IP allocation is more flexible.

Step 303: and the first target node continuously monitors the IP demand, and when the IP demand is determined to be updated and the Pod IP does not conform to the second IP type indicated by the updated IP demand, the target Pod is expelled to the scheduler so that the scheduler migrates the target Pod to the second target node for Pod IP reconfiguration.

Specifically, in this embodiment of the present application, on one hand, in the process of continuously monitoring the IP requirement, when it is determined that the IP requirement has been deleted, any one of the following operations is performed:

the first method comprises the following steps: and releasing the binding relationship.

And the second method comprises the following steps: and releasing the binding relation and releasing the corresponding Pod IP.

For example, when the target node 1 monitors that the IP requirement of the target Pod 1 is deleted, it indicates that the target Pod 1 has no special requirement for the required IP address, and if it no longer indicates that the required IP address must belong to a certain special network segment, the target Pod 1 may use any unoccupied IP address in the IP resource pool, so the target node 1 releases the binding relationship between the Pod IP and the IP requirement, if the target Pod 1 is still running, the target Pod 1 continues to use the current Pod IP, and if the target Pod 1 is closed, the current Pod IP is released, and the IP manager recovers the Pod IP.

On the other hand, in the process of continuously monitoring the IP demand, when the IP demand is determined to be updated and the Pod IP does not conform to the second IP type indicated by the updated IP demand, the target Pod is evicted to the scheduler.

Specifically, in this embodiment of the application, when it is determined that the IP requirement is updated and the Pod IP does not conform to the second IP type indicated by the updated IP requirement, the first target node further determines whether the IP address used by the first target node is adapted to the second IP type.

If not, the first target node evicts the target Pod to the scheduler.

For example, assume that the Pod IP of target Pod 1 is: 192.168.1.3, and the IP address used by the target node 1 is: 192.168.1.1, when the IP management module in the target node 1 determines that the IP requirement of the target Pod 1 is from the first IP requirement: and C type network segment, updating to the second IP requirement: when the type B network segment is used, that is, the Pod IP of the target Pod 1 does not conform to the second IP type indicated by the updated IP requirement, and the IP address used by the target node 1 itself is not adapted to the second IP type, the target node 1 evicts the target Pod 1 to the scheduler.

And if the target node is adaptive, the first target node applies for a new Pod IP which is in accordance with the second IP type again to the IP manager, receives the new Pod IP returned by the IP manager and configures the new Pod IP for the target Pod.

For example, assume that the Pod IP of target Pod 1 is: 192.168.1.3, and the IP address used by the target node 1 is: 192.168.1.1, when the IP management module in the target node 1 determines that the IP requirement of the target Pod 1 is from the first IP requirement: and C type network segment, updating to the second IP requirement: 192.168.1.1-192.168.1.2, that is, the Pod IP of the target Pod 1 does not conform to the second IP type indicated by the updated IP requirement, but the IP address used by the target node 1 itself still matches the second IP type, then the target node 1 re-applies to the IP manager for a new Pod IP conforming to the second IP type, and receives the new Pod IP returned by the IP manager, such as: 192.168.1.2, configure a new Pod IP for the target Pod.

Based on step 303, when the target node is adapted to the IP type indicated by the updated IP requirement, a new Pod IP may be directly applied for the target node without rescheduling the target Pod, which improves operability of Pod management in the container cloud platform.

The above embodiments are further described in detail by a specific application scenario.

In a container cloud platform, containers are scheduled in Pod units, kubernets allocate the same IP address, called Pod IP, to multiple containers in a Pod, and as shown in fig. 4, a specific process of Pod IP allocation in an embodiment of the present application is as follows:

the target object puts forward a Pod creation request and simultaneously declares that the IP requirement of the Pod is as follows: 192.168.1.7 stored in etcd, where the scheduler receives a Pod create request from a target object, obtains an IP requirement stored in association with the Pod, and screens a target node meeting the IP requirement, because the IP address used by the target node 2 is 192.168.1.8, and belongs to the same network segment as the Pod IP required by the Pod create request, the scheduler sends the Pod create request to the target node 2, after the target node 2 receives the Pod create request, the target node 2 obtains the IP requirement stored in association with the target node, then the target node 2 communicates with an IP manager, obtains the Pod IP meeting the IP requirement returned by the IP manager from an IP resource pool, and finally the target node 2 creates a target Pod 2 and configures the Pod IP to the target Pod 2.

Specifically, in the above embodiment, the flow of scheduling Pod creation request by the scheduler is shown in fig. 5:

after acquiring the Pod creation request, the scheduler performs the following operation, where the Pod creation request includes Pod evicted from the target node and Pod creation request issued due to restart.

Step 501: and acquiring the IP requirement stored in association.

Step 502: and judging whether a target node meeting the IP requirement exists or not.

If yes, go to step 503, otherwise, the process ends.

Step 503: a Pod create request is sent to the target node.

In the target node 2, the creation of the target Pod and the configuration of the Pod IP for the target Pod are all completed by the Pod IP management module, and after the target node 2 receives the Pod creation request sent by the scheduler, a flowchart of the Pod IP management module creating the target Pod 2 is shown in fig. 6:

step 601: and acquiring the IP requirement stored in association.

Step 602: and judging whether the bound Pod IP is stored in the IP demand. If yes, go to step 604, otherwise, go to step 605.

Step 603: and communicating with the IP manager to apply for the Pod IP meeting the IP requirement.

Step 604: and judging whether the application of the Pod IP by the IP manager is successful, if so, executing a step 605, otherwise, ending the process, and prompting the failure of Pod creation to the target object by the target node 2.

Step 605: and creating a target Pod, entering a Pod network name space, configuring a Pod IP for a Pod network card, and binding the Pod IP and the IP requirement.

Specifically, referring to fig. 7, when step 603 is executed, a scene schematic diagram of communication between the Pod IP management module and the IP manager is shown, where the Pod IP management module makes an IP application request to the IP manager, the IP manager receives the IP application request, acquires an IP address meeting an IP requirement from an IP resource pool, and returns the IP address to the Pod IP management module, where the IP resource pool maintains all IP addresses in the system.

Further, after the IP manager receives the IP application request, the flowchart of applying for Pod IP is shown in fig. 8:

step 801: and acquiring the IP requirement sent by the Pod IP management module.

Step 802: and judging whether the bound Pod IP is stored in the IP requirement, if so, executing a step 805, otherwise, executing a step 803.

Step 803: and inquiring the IP resource pool to obtain the Pod IP meeting the IP requirement.

Step 804: and judging whether the acquired Pod IP is occupied, if so, ending the process, and failing to apply for the Pod IP, otherwise, executing the step 805.

Step 805: and returning the Pod IP to the Pod IP management module.

Specifically, after the Pod IP management module successfully creates the target Pod 2 and configures the Pod IP for the target Pod 2, it will continuously monitor whether the IP requirement of the target Pod 2 is updated, and reconfigure the Pod IP of the target Pod 2 according to the updated IP requirement, or reschedule the target Pod 2 by the scheduler, and the flowchart of monitoring the IP requirement by the Pod IP management module is shown in fig. 9:

step 901: and monitoring the IP requirements associated with each Pod of the node.

Step 902: and judging whether the IP requirement is updated, if so, executing step 903, otherwise, ending the process and not needing to execute any operation on the target Pod.

Step 903: and judging whether the IP requirement is deleted, if so, executing a step 906, otherwise, executing a step 904.

Step 904: and judging whether the node meets the updated IP requirement, if so, executing a step 907, and otherwise, executing a step 905.

Step 905: and communicating with the IP manager, and reapplying the Pod IP meeting the updated IP requirement.

Step 906: and releasing the binding relation between the Pod IP and the IP requirement.

Step 907: and judging whether the current Pod IP meets the updated IP requirement or not, if so, ending the process, and otherwise, executing the step 908.

Step 908: and ejecting the target Pod from the node to the scheduler for rescheduling.

Optionally, when step 906 is executed, the Pod IP of the target Pod may be released at the same time, and specifically, depending on whether the target Pod is still in a running state, the IP manager will recycle the released IP resource, and a specific execution flow refers to fig. 10:

step 1001: and the Pod IP management module in the target node monitors the IP requirement of each Pod.

Step 1002: the IP manager periodically traverses the Pod IPs that have been bound.

Step 1003: and judging whether the IP requirement is deleted and whether the corresponding Pod stops running, if so, executing a step 1004, and if not, ending the process.

Step 1004: the IP manager reclaims the bound Pod IP.

Wherein, step 1001 is executed by the target node, and step 1002 is executed by the IP manager, which do not affect each other.

Further, while the operations of the methods of the present application are depicted in the drawings in a particular order, this does not require or imply that these operations must be performed in this particular order, or that all of the illustrated operations must be performed, to achieve desirable results. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step execution, and/or one step broken down into multiple step executions.

Based on the same technical concept, referring to fig. 11, an embodiment of the present application further provides a Pod IP allocation apparatus, applied to a scheduler, where the apparatus includes:

a first receiving module 1101, configured to receive a Pod creation request, acquire an IP requirement stored in association with the Pod creation request, and acquire a first IP type indicated by the IP requirement;

a first sending module 1102, configured to send a Pod creation request to a first target node, so that the first target node creates a target Pod, and configures a corresponding Pod IP for the target Pod based on the first IP type; the IP address used by the first target node is matched with the first IP type;

a second receiving module 1103, configured to receive a target Pod evicted by the first target node based on a trigger event, where the trigger event is: in the process of continuously monitoring the IP demand, determining that the IP demand is updated and the Pod IP does not conform to a second IP type indicated by the updated IP demand;

a second sending module 1104, configured to migrate the target Pod to a second target node for Pod IP reconfiguration, where an IP address used by the second target node is adapted to the second IP type.

Optionally, when receiving a Pod creation request and acquiring an IP requirement stored in association with the corresponding Pod creation request, the first receiving module 1101 is configured to:

receiving a Pod creation request triggered by a target object;

Based on the same technical concept, referring to fig. 12, an embodiment of the present application further provides a Pod IP allocating apparatus, applied to a first target node, where the apparatus includes:

a receiving module 1201, configured to receive a Pod creation request sent by a scheduler, and obtain an IP requirement stored in association with the Pod creation request, where the IP requirement is used to indicate a first IP type, and an IP address used by a first target node is adapted to the first IP type;

a creating module 1202, configured to create a target Pod and configure a Pod IP meeting the first IP type for the target Pod based on an IP requirement;

a monitoring module 1203, configured to continuously monitor the IP requirement, and when it is determined that the IP requirement is updated and the Pod IP does not conform to the second IP type indicated by the updated IP requirement, evict the target Pod to the scheduler, so that the scheduler migrates the target Pod to a second target node to perform Pod IP reconfiguration, where an IP address used by the second target node is adapted to the second IP type.

Optionally, when receiving a Pod creation request sent by the scheduler and acquiring an IP requirement stored in association with the corresponding Pod creation request, the receiving module 1201 is configured to:

receiving a Pod creation request sent by a scheduler;

Optionally, if a bound Pod IP is stored in the corresponding IP requirement, when a Pod IP conforming to the first IP type is configured for the target Pod based on the IP requirement, the creating module 1202 is specifically configured to:

and configuring the acquired bound Pod IP to the target Pod.

Optionally, when the obtained bound Pod IP is configured to the target Pod, the creating module 1202 is further configured to:

Optionally, if the bound Pod IP is not stored in the corresponding IP requirement, when a corresponding Pod IP is configured for the target Pod based on the first IP type, the creating module 1202 is specifically configured to:

and configuring the Pod IP for the target Pod.

Optionally, the creating module 1202 is further configured to:

Optionally, after configuring a corresponding Pod IP for the target Pod based on the first IP type, the creating module 1202 is further configured to:

and establishing a binding relation between the Pod IP and the IP requirement.

Optionally, the creating module 1202 is further configured to:

unbinding the binding relationship;

and releasing the binding relation and releasing the corresponding Pod IP.

Optionally, when it is determined that the IP requirement is updated and the Pod IP does not conform to the second IP type indicated by the updated IP requirement, the target Pod is evicted to the scheduler, and the monitoring module 1203 is configured to:

if not, the target Pod is evicted to the scheduler.

Optionally, the listening module 1203 is further configured to:

receiving a new Pod IP returned by the IP manager;

and configuring a new Pod IP for the target Pod.

Based on the same technical concept, the embodiment of the present application further provides an electronic device, and the electronic device can implement the method and the process for Pod IP allocation provided by the foregoing embodiment of the present application.

In one embodiment, the electronic device may be a server, a terminal device, or other electronic device.

Referring to fig. 13, the electronic device may include:

at least one processor 1301 and a memory 1302 connected to the at least one processor 1301, in this embodiment, a specific connection medium between the processor 1301 and the memory 1302 is not limited, and fig. 13 illustrates an example where the processor 1301 and the memory 1302 are connected through a bus 1300. The bus 1300 is shown by a thick line in fig. 13, and the connection manner between other components is merely illustrative and not limited thereto. The bus 1300 may be divided into an address bus, a data bus, a control bus, etc., and only one thick line is shown in fig. 13 for convenience of illustration, but does not indicate only one bus or one type of bus. Alternatively, processor 1301 can also be referred to as a controller, without limitation to name.

In the embodiment of the present application, the memory 1302 stores instructions executable by the at least one processor 1301, and the at least one processor 1301 can execute one of the Pod IP allocation methods discussed above by executing the instructions stored in the memory 1302. The processor 1301 may implement the functions of the respective modules in the apparatus shown in fig. 12.

The processor 1301 is a control center of the apparatus, and may connect various parts of the entire control device through various interfaces and lines, and perform various functions and process data of the apparatus by executing or executing instructions stored in the memory 1302 and calling data stored in the memory 1302, thereby performing overall monitoring of the apparatus.

In one possible design, processor 1301 may include one or more processing units and processor 1301 may integrate an application processor, which primarily handles operating systems, user interfaces, application programs, and the like, and a modem processor, which primarily handles wireless communications. It is to be appreciated that the modem processor described above may not be integrated into processor 1301. In some embodiments, processor 1301 and memory 1302 may be implemented on the same chip, or in some embodiments, they may be implemented separately on separate chips.

The processor 1301 may be a general-purpose processor, such as a CPU, digital signal processor, application specific integrated circuit, field programmable gate array or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or the like, that may implement or perform the methods, steps, and logic blocks disclosed in the embodiments of the present application. A general purpose processor may be a microprocessor or any conventional processor or the like. The steps of the Pod IP allocation method disclosed in the embodiments of the present application may be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor.

Memory 1302, which is a non-volatile computer-readable storage medium, may be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. The Memory 1302 may include at least one type of storage medium, and may include, for example, a flash Memory, a hard disk, a multimedia card, a card-type Memory, a Random Access Memory (RAM), a Static Random Access Memory (SRAM), a Programmable Read Only Memory (PROM), a Read Only Memory (ROM), a charge Erasable Programmable Read Only Memory (EEPROM), a magnetic Memory, a magnetic disk, an optical disk, and so on. The memory 1302 is any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer, but is not limited to such. The memory 1302 in the embodiments of the present application may also be circuitry or any other device capable of performing a storage function for storing program instructions and/or data.

By programming the processor 1301, the code corresponding to a Pod IP allocation method described in the foregoing embodiment may be solidified in the chip, so that the chip can execute the steps of the Pod IP allocation method in the embodiment shown in fig. 3 when running. How processor 1301 is programmed is well known to those skilled in the art and will not be described in further detail herein.

Based on the same inventive concept, embodiments of the present application further provide a storage medium storing computer instructions, which when executed on a computer, cause the computer to execute a Pod IP allocation method as discussed above.

In some possible embodiments, aspects of a Pod IP allocation method provided by the present application may also be implemented in the form of a program product including program code for causing a control apparatus to perform the steps in a Pod IP allocation method according to various exemplary embodiments of the present application described above in this specification, when the program product is run on a device.

It should be noted that although several units or sub-units of the apparatus are mentioned in the above detailed description, such division is merely exemplary and not mandatory. Indeed, the features and functions of two or more units described above may be embodied in one unit, according to embodiments of the application. Conversely, the features and functions of one unit described above may be further divided into embodiments by a plurality of units.

As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

It will be apparent to those skilled in the art that various changes and modifications may be made in the present application without departing from the spirit and scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is intended to include such modifications and variations as well.

Claims

1. A method for allocating Pod IP is applied to a scheduler in a Kubernets system of open source container arrangement, and comprises the following steps:

receiving a Pod creation request, acquiring an IP (Internet protocol) requirement which is stored in association with the Pod creation request, and acquiring a first IP type indicated by the IP requirement;

sending the Pod creation request to a first target node to enable the first target node to create a target Pod, and configuring a corresponding Pod IP for the target Pod based on the first IP type; wherein the IP address used by the first target node is adapted to the first IP type;

receiving the target Pod evicted by the first target node based on a trigger event, wherein the trigger event is: in the process of continuously monitoring the IP requirement, determining that the IP requirement is updated and the Pod IP does not conform to a second IP type indicated by the updated IP requirement;

and migrating the target Pod to a second target node for PodIP reconfiguration, wherein the IP address used by the second target node is matched with the second IP type.

2. The method of claim 1, wherein the scheduler receiving a Pod create request and obtaining the IP requirement saved in association with the Pod create request comprises:

receiving a Pod creation request triggered by a target object;

and acquiring an IP requirement which is stored in association with the Pod creation request at a specified storage position, wherein the IP requirement is declared by the target object when the Pod creation request is triggered and is stored at the specified storage position, and after the IP requirement is stored, the target object updates in real time based on a use requirement.

3. A method for allocating Pod IP is applied to a first target node in Kubernets of an open source container arranging system, and comprises the following steps:

receiving a Pod creation request sent by a scheduler, and acquiring an IP (Internet protocol) requirement stored in association with the Pod creation request, wherein the IP requirement is used for indicating a first IP type, and an IP address used by a first target node is matched with the first IP type;

creating a target Pod, and configuring PodIP which accords with the first IP type for the target Pod based on the IP requirement;

and continuously monitoring the IP demand, and when the fact that the IP demand is updated and the Pod IP does not conform to a second IP type indicated by the updated IP demand is determined, expelling the target Pod to the scheduler so that the scheduler migrates the target Pod to a second target node for Pod IP reconfiguration, wherein the IP address used by the second target node is matched with the second IP type.

4. The method of claim 3, wherein receiving a Pod create request sent by a scheduler and obtaining the IP requirement saved in association with the Pod create request comprises:

receiving a Pod creation request sent by the scheduler;

5. The method of claim 3 or 4, wherein if a bound Pod IP is stored for the IP requirement, configuring PodIP conforming to the first IP type for the target Pod based on the IP requirement comprises:

acquiring the bound Pod IP from a specified storage position based on the IP requirement, wherein the bound Pod IP conforms to the first IP type;

and configuring the acquired bound Pod IP to the target Pod.

6. The method of claim 5, wherein the configuring the obtained bound Pod IP to the target Pod comprises:

and entering a network name space of the target Pod, and configuring the bound PodIP for the Pod network card.

7. The method of claim 3 or 4, wherein if a bound Pod IP is not saved corresponding to the IP requirement, the configuring the corresponding Pod IP for the target Pod based on the first IP type comprises:

sending the first IP type to an IP manager, and receiving PodIP which is returned by the IP manager and accords with the first IP type;

and configuring the PodIP for the target Pod.

8. The method of claim 3 or 4, further comprising:

9. The method of claim 7, wherein after configuring the corresponding PodIP for the target Pod based on the first IP type, further comprising:

and establishing a binding relation between the Pod IP and the IP requirement.

10. The method of claim 9, further comprising:

releasing the binding relationship;

and releasing the binding relation and releasing the corresponding PodIP.

11. The method of claim 3 or 4, wherein the evicting the target Pod to the scheduler when it is determined that the IP demand has been updated and the Pod IP does not comply with the second IP type indicated by the updated IP demand comprises:

and if not, the target Pod is evicted to the scheduler.

12. The method of claim 11, further comprising:

if the second IP type is matched with the first IP type, re-applying a new Pod IP which is in accordance with the second IP type to an IP manager;

receiving the new Pod IP returned by the IP manager;

and configuring the new Pod IP for the target Pod.

13. A Pod IP allocation apparatus, applied to a scheduler, comprising:

the first receiving module is used for receiving a Pod creation request, acquiring an IP requirement which is stored in association with the Pod creation request and acquiring a first IP type indicated by the IP requirement;

a first sending module, configured to send the Pod creation request to a first target node, so that the first target node creates a target Pod, and configures a corresponding Pod IP for the target Pod based on the first IP type; wherein the IP address used by the first target node is adapted to the first IP type;

a second receiving module, configured to receive the target Pod evicted by the first target node based on a trigger event, where the trigger event is: in the process of continuously monitoring the IP requirement, determining that the IP requirement is updated and the Pod IP does not conform to a second IP type indicated by the updated IP requirement;

and the second sending module is used for migrating the target Pod to a second target node for Pod IP reconfiguration, wherein the IP address used by the second target node is adapted to the second IP type.

14. A Pod IP allocation apparatus, applied to a first target node, includes:

a receiving module, configured to receive a Pod creation request sent by a scheduler, and acquire an IP requirement stored in association with the Pod creation request, where the IP requirement is used to indicate a first IP type, and an IP address used by the first target node is adapted to the first IP type;

the creating module is used for creating a target Pod and configuring a Pod IP which accords with the first IP type for the target Pod based on the IP requirement;

and the monitoring module is used for continuously monitoring the IP requirement, and when the IP requirement is determined to be updated and the Pod IP does not conform to the second IP type indicated by the updated IP requirement, the target Pod is expelled to the scheduler so that the scheduler migrates the target Pod to a second target node for PodIP reconfiguration, wherein the IP address used by the second target node is matched with the second IP type.

15. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the processor implements the method according to any of claims 3-12 when executing the computer program.

16. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the steps of the method according to any one of claims 1 to 6.

17. A computer program product, which, when called by a computer, causes the computer to perform the method of any one of claims 1 to 6.