CN115484231B

CN115484231B - Pod IP distribution method and related device

Info

Publication number: CN115484231B
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: 2023-07-18
Anticipated expiration: 2042-09-14
Also published as: CN115484231A

Abstract

The application discloses a Pod IP distribution method and a related device, and relates to the technical field of communication. In the method, a scheduler sends a Pod creation request to a target node conforming to IP requirements according to IP requirements stored in an associated mode of the Pod creation request, the target node applies for Pod IP conforming to the IP requirements to an IP manager, creates a target Pod, configures the Pod IP for the target Pod, establishes a binding relation between the Pod IP and the IP requirements, continuously monitors the IP requirements, and when the IP requirements are determined to be updated, re-applies for new Pod IP to the IP manager or drives the target Pod to the scheduler to be rescheduled. In this way, even if the IP requirements are updated, the Pod may avoid rescheduling, so that flexibility of IP allocation is improved, the IP requirements are independently managed, the system can perform IP allocation for multiple IP requirements, and limitations of an IP allocation method are reduced.

Description

Pod IP distribution method and related device

Technical Field

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

Background

An open source container orchestration system (Kubernetes, K8s for short) is an open source for managing containerized applications on multiple hosts in a cloud platform, the goal of Kubernetes being to make deploying containerized applications simple and efficient. Pod is the most important and fundamental concept of Kubernetes, which is the smallest unit of deployment that can be created, scheduled and managed, one Pod can encapsulate one container or multiple containers. Kubernetes assigns each Pod a unique internet protocol address (Internet Protocol Address, IP address), also known as Pod IP, which is shared by multiple containers in a Pod.

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

For example, in practical application, some services use IP addresses as unique identifiers for access, that is, service functions provided by each container in a corresponding Pod are called by Pod IP, such Pod has no special requirement for IP addresses when being started for the first time, a system randomly allocates an IP address to the Pod, and in order to ensure normal access of subsequent services, such Pod particularly requires that once-used IP addresses be used when restarting, that is, the IP requirements of the Pod are updated when restarting.

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

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

However, the IP allocation method in the related art can only allocate a fixed IP address to the Pod according to the fixed IP requirement, and cannot cope with the IP requirement changing at any time, so that the Pod IP address cannot be updated, and once the Pod IP address cannot be updated in time, the related service cannot be successfully and continuously invoked, thereby affecting the service use effect.

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

Disclosure of Invention

The embodiment of the application provides a Pod IP allocation method and a related device, 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, applied to a scheduler, where the method includes:

receiving a Pod creation request, acquiring IP requirements which are stored in an associated mode and correspond to the Pod creation request, and acquiring a first IP type indicated by the IP requirements;

sending a Pod creation request to a first target node so that the first target node creates 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 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 requirement, determining that the IP requirement is updated, wherein the Pod IP does not conform to the second IP type indicated by the updated IP requirement;

And 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.

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

receiving a Pod creation request sent by a scheduler, and acquiring an IP requirement which is associated with and stored in correspondence to 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 adapted to the first IP type;

creating a target Pod, and configuring a Pod IP conforming to 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 updated and the Pod IP does not meet the second IP type indicated by the updated IP demand, expelling the target Pod to a scheduler so that the scheduler migrates the target Pod to a second target node to perform 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, applied to a scheduler, where the apparatus includes:

the first receiving module is used for receiving the Pod creation request, acquiring the IP requirement which is associated and stored in correspondence to the Pod creation request, and acquiring a first IP type indicated by the IP requirement;

The first sending module is used for sending a Pod creation request to the first target node so as to enable the first target node to create a target Pod and configure 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;

the second receiving module is configured to receive a target Pod that is 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, wherein the Pod IP does not conform to the 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 to perform Pod IP reconfiguration, wherein the IP address used by the second target node is matched with the second IP type.

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

receiving a Pod creation request triggered by a target object;

and acquiring IP requirements which are stored in association with corresponding Pod creation requests at the designated storage position, wherein the IP requirements are declared by the target object when the Pod creation requests are triggered and stored at the designated storage position, and after the IP requirements are stored, the target object updates in real time based on the use requirements.

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

the receiving module is used for receiving the Pod creation request sent by the scheduler and acquiring an IP requirement which is associated and stored 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 adapted to the first IP type;

the creating module is used for creating a target Pod and configuring a Pod IP conforming to the first IP type for the target Pod based on the IP requirement;

and the monitoring module is used for continuously monitoring the IP requirements, and when the IP requirements are updated and the Pod IP does not accord with the second IP type indicated by the updated IP requirements, expelling the target Pod to the scheduler so that the scheduler migrates the target Pod to the second target node to reconfigure the Pod IP, wherein the IP address used by the second target node is matched with the second IP type.

Optionally, when receiving the Pod creation request sent by the scheduler and obtaining the 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 the bound Pod IP is stored in the corresponding IP requirement, when configuring the Pod IP conforming to the first IP type for the target Pod based on the IP requirement, the creating module is specifically configured to:

acquiring a bound Pod IP from a designated storage location based on the IP requirements, wherein the bound Pod IP conforms to a first IP type;

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

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

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

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

the first IP type is sent to an IP manager, and Pod IP conforming to the first IP type returned by the IP manager is received;

and configuring Pod IP for the target Pod.

Optionally, the creating module is further configured to:

if the IP manager does not return the Pod IP conforming to the first IP type, prompting the target object that the creation of the target Pod fails.

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

A binding relationship is established between Pod IP and IP requirements.

Optionally, the creating module is further configured to:

in the process of continuously monitoring the IP requirements, when the IP requirements are determined to be deleted, any one of the following operations is performed:

unbinding the binding relation;

and (5) unbinding 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 monitor module is configured to:

when the IP requirement is updated and the Pod IP does not accord with 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 new Pod IP is adapted, re-applying the new Pod IP conforming to the second IP type to the IP manager;

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, including a memory, a processor, and a computer program stored on the memory and executable by the processor, wherein the processor implements the method according to any one of the first aspects when executing the computer program.

In a sixth aspect, embodiments of the present application provide a computer readable storage medium having a computer program stored thereon, characterized in that the computer program when executed by a processor implements the steps of the method according to any of the first aspects.

In a seventh aspect, embodiments of the present application provide a computer program product, characterized in that the computer program product, when invoked by a computer, causes the computer to perform the method according to the first aspect.

In the embodiment of the application, a scheduler sends a Pod creation request to a target node conforming to IP requirements according to IP requirements stored in an associated manner of the Pod creation request, the target node communicates with an IP manager, applies for Pod IP conforming to the IP requirements to the IP manager, returns the Pod IP to the target node, creates a target Pod for the Pod IP management module in the target node, configures the Pod IP for the Pod IP management module, establishes a binding relationship between the Pod IP and the IP requirements, continuously monitors the IP requirements associated with the target Pod, and when the IP requirements are determined to be updated, the Pod IP management module applies for Pod IP conforming to the updated IP requirements again to the IP manager or ejects the target Pod to the scheduler, and the target Pod is scheduled to other target nodes again by the scheduler.

By adopting the mode, after the Pod creation request and the IP demand are managed separately, the Pod is successfully created, even if the IP demand is updated, the Pod can avoid rescheduling, so that the flexibility of IP allocation is improved, meanwhile, the IP demand and the Pod IP adopt a dynamic binding mode, a target node and an IP manager can monitor the change of the IP demand more accurately, and because the IP demand adopts an independent management mode, when the Pod presents a new IP demand, the system can allocate the IP according to various IP demands only by adding the realization of the IP demand manager, and the limitation of an IP allocation method is reduced.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings that are needed in the description of the embodiments will be briefly described below, it will be apparent that the drawings in the following description are only some embodiments of the present invention, and that other drawings can be obtained according to these drawings without inventive effort for a person skilled in the art. In the drawings:

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

FIG. 2 is a flowchart of a scheduler step in Pod IP allocation in an embodiment of the present application;

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

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

fig. 5 is a flowchart of steps of a scheduler in Pod IP allocation in a specific application scenario in the embodiment of the present application;

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

fig. 7 is a logic schematic diagram of communication between a Pod IP management module and an IP manager in a specific application scenario in an 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 steps 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 steps for recovering IP resources by the 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 distribution device according to an embodiment of the present application;

fig. 12 is a schematic structural diagram of a Pod IP distribution device according to 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

For the purposes of making the objects, technical solutions and advantages of the embodiments of the present application more clear, 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 apparent that the described embodiments are some embodiments of the technical solutions of the present application, but not all embodiments. All other embodiments, which can be made by a person of ordinary skill in the art without any inventive effort, based on the embodiments described in the present application are intended to be within the scope of the technical solutions of the present application.

Some of the concepts involved in the embodiments of the present application are described below.

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

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

(3) A scheduler: in Kubernetes, a scheduler discovers pods in a cluster that are newly created and have not yet been scheduled to nodes by a Kubernetes monitoring (Watch) mechanism, and the scheduler will schedule each of the discovered unscheduled pods to an appropriate node for execution.

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

(5) Pod IP management module: in each node, it is responsible for creating a Pod and applying an IP address to the IP manager, configuring a Pod IP for the Pod, and for binding or unbinding the Pod IP and the IP requirements associated with the Pod.

(6) IP resource pool: maintaining all IP addresses in the Kubernetes system is responsible for provisioning and reclaiming Pod IP.

(7) etcd: a reliable distributed data store that persists data for all resource objects in the cluster configuration Kubernetes is maintained in etcd.

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

Referring to fig. 1, in the embodiment of the present application, five main parts of a Pod 100 to be created, a scheduler 101, a target node 102, an IP manager 103, and an IP resource pool 104 are included, where the target node 102 further includes a Pod IP management module 105, and the Pod to be created has an IP requirement 106 stored in association. The scheduler 101 receives the Pod creation request of the Pod 100 to be created, sends the Pod creation request of the Pod to be created to the target node 102 through the IP requirement 106 stored in association with the Pod to be created, the Pod IP management module 105 in the target node 102 communicates with the IP manager 103, obtains the IP address adapted to the IP requirement 106 from the IP resource pool 104, and configures the IP resource pool to the target Pod after the creation is successful, the IP management module 105 continuously monitors the IP requirement 106, once the IP requirement 106 is updated, the target node 102 decides whether to configure a new Pod IP for the target Pod according to the updated IP requirement 106, and the scheduler 101 decides whether to reschedule the target Pod to the new target node.

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

step 201: the dispatcher receives the Pod creation request, acquires the IP requirement which is associated and stored corresponding to the Pod creation request, and acquires the first IP type indicated by the IP requirement.

Specifically, in the embodiment of the application, the dispatcher receives a Pod creation request triggered by a target object, and obtains, at a designated storage location, an IP requirement associated with and stored in the corresponding Pod creation request, where the IP requirement is declared by the target object when the Pod creation request is triggered, and stored in the designated 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 the target object, and in etcd, obtains an IP requirement associated and stored in correspondence with the Pod creation request 1, and obtains a first IP type indicated by the IP requirement, and presumes that the first IP type is a class C network segment: 192.168.0.0-192.168.255.255.

Step 202: the scheduler sends a Pod creation request to the first target node to cause the first target node to create a target Pod and configure 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, which is exactly in the class C 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 class C network segment.

Step 203: the scheduler receives a target Pod that the first target node evicts based on the trigger event.

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

For example, the target object associates Pod 1 with a first IP type indicated by the stored IP requirements: class C network segment, updated to the second IP type: when the class 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 class B network segment: 172.16.0.0-172.31.255.255, the scheduler will receive the target Pod 1 evicted from the target node 1.

Step 204: and 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 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 a 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, the 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 which is associated and stored in correspondence to the Pod creation request.

The IP requirement is used to indicate the first IP type, and the IP address used by the first target node is adapted to the first IP type.

Specifically, in the embodiment of the present application, a first target node receives a Pod creation request 1 sent by a scheduler, and obtains, at a designated storage location, an IP requirement associated with and stored in the corresponding 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 in the designated 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 obtains, in the etcd, the IP requirement stored in association with the corresponding Pod creation request 1, and obtains the first IP type indicated by the IP requirement, and it is assumed that the first IP type is a class C network segment: 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 target node 1 is adapted to the first IP type.

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

Step 302: the first target node creates a target Pod and configures a Pod IP conforming to the first IP type for the target Pod based on the IP requirements.

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

case one: if the bound Pod IP is stored corresponding to the IP requirement, the first target node acquires the bound Pod IP from the designated storage location based on the IP requirement, wherein the bound Pod IP accords with the first IP type, and configures the acquired bound Pod IP to the target Pod.

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

Further, in the embodiment of the present application, when configuring the Pod IP, the first target node enters a network naming space of the target Pod, and configures the bonded 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.

And a second case: if the bound Pod IP is not stored in the corresponding IP requirement, the first target node sends the first IP type to the IP manager and receives the Pod IP which accords with the first IP type and is returned by the IP manager; the first target node configures Pod IP for the target Pod.

For example, if the corresponding IP requirement does not hold the bound Pod IP, then the target node 1 will be of the first IP type: the class C network segment is sent to the IP manager, the IP manager finds out the IP address belonging to the class C 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, the IP management module in the target node 1 configures this Pod IP for the target Pod 1.

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

For example, when Pod creation requests association with a first IP type indicated by the saved IP requirement is: 192.168.1.4, i.e. the Pod IP required for the Pod creation request must be 192.168.1.4, and this IP address is already occupied by other running pods, the IP manager will not return 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 performed, the first target node establishes a binding relationship between Pod IP and IP requirements before step 303 is performed.

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

Based on the step 302, a 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 requirement more accurately, and the IP allocation is more flexible.

Step 303: and the first target node continuously monitors the IP requirement, and when the IP requirement is updated and the Pod IP does not meet the second IP type indicated by the updated IP requirement, the target Pod is evicted to the scheduler, so that the scheduler migrates the target Pod to the second target node for Pod IP reconfiguration.

Specifically, in the embodiment of the present application, on the 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:

first kind: and (5) unbinding the binding relation.

Second kind: and (5) unbinding 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 is characterized that the target Pod 1 no longer has a special requirement on the required IP address, if it no longer indicates that the required IP address must belong to a specific network segment, at this time, 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 turned off, the current Pod IP is released, and the Pod IP thereof is recovered by the IP manager.

On the other hand, in the process of continuously monitoring the IP requirement, when the IP requirement is updated and the Pod IP does not accord with the second IP type indicated by the updated IP requirement, the target Pod is evicted to the dispatcher.

Specifically, in the embodiment of the present 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, suppose that the Pod IP of the 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: class C network segment, updated to the second IP requirement: and when the network segment is of type B, namely the Pod IP of the target Pod 1 does not accord with the second IP type indicated by the updated IP requirement, and the IP address used by the target node 1 is not matched with the second IP type, the target node 1 drives out the target Pod 1 to a dispatcher.

If so, the first target node re-applies for a new Pod IP conforming to the second IP type 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, suppose that the Pod IP of the 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: class C network segment, updated to the second IP requirement: 192.168.1.1-192.168.1.2, namely, 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 is still adapted to the second IP type, then the target node 1 re-applies for a new Pod IP conforming to the second IP type to the IP manager, and receives the new Pod IP returned by the IP manager, for example: 192.168.1.2, configuring a new Pod IP for the target Pod.

Based on the step 303, when the target node is matched with the IP type indicated by the updated IP requirement, a new Pod IP can be directly applied for the target node without rescheduling the target Pod, thereby improving the operability of Pod management in the container cloud platform.

The above embodiments are described in further detail below with reference to a specific application scenario.

In the container cloud platform, the containers are scheduled by taking the Pod as a unit, and the Kubernetes allocates the same IP address to a plurality of containers in one Pod, which is called Pod IP, and referring to fig. 4, a specific flow of Pod IP allocation in the embodiment of the present application is as follows:

the target object puts forward a Pod creation request while declaring the IP requirements of Pod as: 192.168.1.7 in the etcd, the scheduler receives the Pod creation request provided by the target object and acquires the IP requirement stored in association with the Pod creation request, screens the target node meeting the IP requirement, and because the IP address used by the target node 2 is 192.168.1.8 and the Pod IP required by the Pod creation request belongs to the same network segment, the scheduler sends the Pod creation request to the target node 2, the target node 2 acquires the IP requirement stored in association with the Pod creation request after receiving the Pod creation request, then the target node 2 communicates with the IP manager, acquires the Pod IP meeting the IP requirement returned by the IP manager from the IP resource pool, and finally the target node 2 creates the target Pod 2 and configures the Pod IP to the target Pod 2.

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

after the scheduler acquires the Pod creation request, the following operations are performed, where the Pod creation request includes the Pod evicted from the target node, and the Pod creation request is made because of the need to restart.

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

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

If so, step 503 is executed, otherwise, the flow ends.

Step 503: the Pod-creation 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, the flow chart of creating the target Pod 2 by the Pod IP management module is shown in fig. 6:

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

Step 602: and judging whether the IP requirement stores the bound Pod IP or not. If so, step 604 is performed, otherwise, step 605 is performed.

Step 603: and communicating with an IP manager, and applying for Pod IP meeting the IP requirement.

Step 604: whether the application of Pod IP by the IP manager is successful or not is judged, if yes, step 605 is executed, otherwise, the flow ends, and the target node 2 prompts the failure of Pod creation to the target object.

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

Specifically, when step 603 is executed, a schematic diagram of a scenario in which the Pod IP management module communicates with the IP manager is shown in fig. 7, the Pod IP management module issues an IP application request to the IP manager, the IP manager receives the IP application request, acquires an IP address meeting the IP requirement from the IP resource pool, and returns the IP address to the Pod IP management module, where all the IP addresses in the system are maintained in the IP resource pool.

Further, after receiving the IP application request, the IP manager applies for the flow chart of Pod IP as shown in fig. 8:

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

Step 802: judging whether the IP requirement stores the bound Pod IP, if so, executing step 805, otherwise, executing step 803.

Step 803: and querying an 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 flow, and if not, executing 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 continuously monitors whether the IP requirement of the target Pod 2 is updated, and reconfigures the Pod IP of the target Pod 2 according to the updated IP requirement, or the scheduler reschedules the target Pod 2, and the flow chart 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: if the IP requirement is updated, step 903 is executed, otherwise, the process ends without performing any operation on the target Pod.

Step 903: whether the IP requirement is deleted is determined, if so, step 906 is performed, otherwise, step 904 is performed.

Step 904: whether the node meets the updated IP requirement is determined, if so, step 907 is performed, otherwise, step 905 is performed.

Step 905: communicating with the IP manager to reapply Pod IP meeting the updated IP requirement.

Step 906: and (5) removing the binding relation between the Pod IP and the IP requirement.

Step 907: whether the current Pod IP meets the updated IP requirement is determined, if so, the process ends, otherwise, step 908 is performed.

Step 908: the target Pod is evicted from the node to the scheduler for rescheduling.

Optionally, when step 906 is performed, the Pod IP of the target Pod may be released at the same time, depending on whether the target Pod is still in an operating state, the IP manager will recover the released IP resources, and the specific execution flow is shown in fig. 10:

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

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

Step 1003: whether the IP requirement is deleted and the corresponding Pod stops running is determined, if so, step 1004 is executed, otherwise, the process ends.

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

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

Furthermore, although the operations of the methods of the present application are depicted in the drawings in a particular order, this is not required to or suggested that these operations must be performed in this particular order or that all of the illustrated operations must be performed in order to achieve desirable results. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step to perform, and/or one step decomposed into multiple steps to perform.

Based on the same technical concept, referring to fig. 11, the 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, obtain an IP requirement stored in association with the corresponding Pod creation request, and obtain 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 configure 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;

the second receiving module 1103 is configured to receive a target Pod that is 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, wherein the Pod IP does not conform to the second IP type indicated by the updated IP requirement;

and 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 a second IP type.

Optionally, when receiving the Pod creation request and acquiring the 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, the embodiment of the present application further provides a Pod IP allocation 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 associated with and stored in correspondence to 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 conforming to the first IP type for the target Pod based on the IP requirement;

the monitoring module 1203 is 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, expel the target Pod to the scheduler, so that the scheduler migrates the target Pod to the 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 the Pod creation request sent by the scheduler and acquiring the 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 the bound Pod IP is stored in the corresponding IP requirement, when configuring the Pod IP conforming to the first IP type 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 a target Pod.

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

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

and configuring Pod IP for the target Pod.

Optionally, the creation module 1202 is further configured to:

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

A binding relationship is established between Pod IP and IP requirements.

Optionally, the creation module 1202 is further configured to:

unbinding the binding relation;

and (5) unbinding 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 listening 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 application also provides electronic equipment, which can realize the Pod IP allocation method flow provided by the embodiment of the 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:

the present embodiment of the present application does not limit a specific connection medium between the processor 1301 and the memory 1302, and in fig. 13, the processor 1301 and the memory 1302 are exemplified by a bus 1300. Bus 1300 is shown in bold lines in fig. 13, and the manner in which the other components are connected is merely illustrative and not limiting. The bus 1300 may be divided into an address bus, a data bus, a control bus, etc., and is shown with only one thick line in fig. 13 for convenience of illustration, but does not represent only one bus or one type of bus. Alternatively, processor 1301 may be referred to as a controller, with no limitation on the 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 a Pod IP allocation method as described above by executing the instructions stored in the memory 1302. Processor 1301 may implement the functions of the various 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 apparatus using various interfaces and lines, and perform overall monitoring of the apparatus by executing or executing instructions stored in the memory 1302 and calling data stored in the memory 1302, various functions of the apparatus, and processing data.

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

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 device, discrete hardware components, that may implement or perform the methods, steps, and logic blocks disclosed in embodiments of the present application. The general purpose processor may be a microprocessor or any conventional processor or the like. The steps of a Pod IP allocation method disclosed in connection with the embodiments of the present application may be directly embodied in a hardware processor for execution, or may be executed by a combination of hardware and software modules in the processor.

The 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, which may include, for example, flash Memory, hard disk, multimedia card, card Memory, random access Memory (Random Access Memory, RAM), static random access Memory (Static Random Access Memory, SRAM), programmable Read-Only Memory (Programmable Read Only Memory, PROM), read-Only Memory (ROM), charged erasable programmable Read-Only Memory (Electrically Erasable Programmable Read-Only Memory), magnetic Memory, magnetic disk, optical disk, and the like. 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 present embodiment may also be circuitry or any other device capable of implementing a memory function for storing program instructions and/or data.

By programming the processor 1301, the code corresponding to one Pod IP allocation method described in the foregoing embodiment may be cured into the chip, so that the chip can execute the steps of one Pod IP allocation method of the embodiment shown in fig. 3 at runtime. How to design and program the processor 1301 is a technique well known to those skilled in the art, and will not be described in detail herein.

Based on the same inventive concept, the embodiments of the present application also provide a storage medium storing computer instructions that, when executed on a computer, cause the computer to perform a Pod IP allocation method as previously discussed.

In some possible embodiments, the present application provides that aspects of a Pod IP allocation method may also be implemented in the form of a program product comprising program code for causing the control apparatus to carry out the steps of a Pod IP allocation method according to the various exemplary embodiments of the present application as described herein above 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 a division is merely exemplary and not mandatory. Indeed, the features and functions of two or more of the elements described above may be embodied in one element in accordance with embodiments of the present application. Conversely, the features and functions of one unit described above may be further divided into a plurality of units to be embodied.

It will be appreciated by those skilled in the art that 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 flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations 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 modifications and variations can be made in the present application without departing from the spirit or scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims and the equivalents thereof, the present application is intended to cover such modifications and variations.

Claims

1. A Pod IP allocation method for use with a scheduler in an open source container orchestration system Kubernetes, the method comprising:

receiving a Pod creation request, acquiring an IP requirement which is associated and stored corresponding to 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 so that the first target node creates a target Pod, and configuring a corresponding PodIP 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, wherein 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-creation request and obtaining IP requirements stored in association with the corresponding Pod-creation request comprises:

Receiving a Pod creation request triggered by a target object;

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

3. A Pod IP allocation method applied to a first target node in an open source container orchestration system Kubernetes, the method comprising:

receiving a Pod creation request sent by a scheduler, and acquiring an IP requirement which is associated and stored corresponding to 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 adapted to the first IP type;

creating a target Pod, and configuring a PodIP conforming to the first IP type for the target Pod based on the IP requirements;

and continuously monitoring the IP demand, and when the IP demand is updated and the Pod IP does not meet a 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 to perform PodIP reconfiguration, wherein an IP address used by the second target node is matched with the second IP type.

4. The method of claim 3, wherein receiving the Pod-creation request sent by the scheduler and obtaining the IP requirements stored in association with the corresponding Pod-creation request comprises:

receiving a Pod creation request sent by the scheduler;

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

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

acquiring the bound Pod IP from a designated storage location based on the IP requirements, wherein the bound Pod IP conforms to the first IP type;

and configuring the acquired bound PodIP to the target Pod.

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

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

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

sending the first IP type to an IP manager and receiving Pod IP conforming to the first IP type returned by the IP manager;

and configuring the PodIP for the target Pod.

8. The method as recited in claim 7, further comprising:

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

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 PodIP and the IP requirement.

10. The method as recited in claim 9, further comprising:

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

Releasing the binding relation;

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 PodIP does not meet the second IP type indicated by the updated IP demand, comprises:

when the IP requirement is updated and the PodIP does not meet 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;

and if the target Pod is not suitable, expelling the target Pod to the scheduler.

12. The method as recited in claim 11, further comprising:

if so, re-applying for a new PodIP conforming to the second IP type to an IP manager;

receiving the new PodIP returned by the IP manager;

and configuring the new PodIP for the target Pod.

13. A PodIP allocation apparatus, for use in a scheduler, comprising:

the first receiving module is used for receiving a Pod creation request, acquiring an IP requirement which is associated and stored corresponding to the Pod creation request, and acquiring a first IP type indicated by the IP requirement;

The first sending module is used for sending 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;

the second receiving module is 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, wherein 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 carrying out PodIP reconfiguration, wherein the IP address used by the second target node is matched with the second IP type.

14. A PodIP allocation apparatus, for use with a first target node, comprising:

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

The creating module is used for creating a target Pod and configuring a PodIP conforming to 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 updated and the PodIP does not meet a second IP type indicated by the updated IP requirement, expelling the target Pod to the scheduler so that the scheduler migrates the target Pod to a second target node to perform Pod IP reconfiguration, wherein an 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, wherein the processor implements the method of any one of claims 1-2 or 3-12 when executing the computer program.

16. A computer readable storage medium, on which a computer program is stored, characterized in that the computer program, when being executed by a processor, implements the steps of the method according to any of claims 1-2 or 3-12.