CN112153167B

CN112153167B - Internet interconnection protocol management method, device, electronic equipment and storage medium

Info

Publication number: CN112153167B
Application number: CN202010784924.0A
Authority: CN
Inventors: 左志鹏
Original assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Current assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Priority date: 2020-08-06
Filing date: 2020-08-06
Publication date: 2023-02-28
Anticipated expiration: 2040-08-06
Also published as: CN112153167A

Abstract

The application discloses an IP management method, an IP management device, electronic equipment and a storage medium, and relates to the field of cloud computing and the Internet, wherein the method comprises the following steps: the IP address management server acquires an IP application request sent by a request object of the client, determines the network type of the requested IP address, and allocates the IP address for the request object according to the determined network type. By applying the scheme, the waste of IP resources and the like can be reduced.

Description

Internet interconnection protocol management method, device, electronic equipment and storage medium

Technical Field

The present application relates to computer application technologies, and in particular, to a method and an apparatus for internet protocol management in the field of cloud computing and the internet, an electronic device, and a storage medium.

Background

The Kubernetes open source container cluster management system (abbreviated as k8 s) supports various network plug-ins and the like, for example, the Kubernetes open source container cluster management system can support various container network plug-ins to run in the same cluster. Various network plug-ins and the like require an IP Address Management (IPAM) module to allocate Internet Protocol (IP) addresses to them.

Currently, the following IP address allocation is generally adopted: one or more IP network segments are respectively allocated to each node in the cluster, and if an IP address needs to be allocated to a request object (namely, an object requesting to allocate an IP address, such as a network plug-in), whether an available IP address exists in the allocated IP network segments can be checked, and if so, an available IP address can be allocated to the request object.

In the above manner, the IP network segments are respectively reserved for the nodes in advance, but the use conditions of the nodes are different, for example, a certain node may be used very rarely, which causes waste of IP resources and the like.

Disclosure of Invention

The application provides an IP management method, an IP management device, electronic equipment and a storage medium.

An IP management method, which is applied in an IP address management server, the method comprising:

acquiring an IP application request sent by a request object serving as a client;

determining a network type of the requested IP address;

and allocating an IP address to the request object according to the network type.

An IP management apparatus, the apparatus being applied in an IP address management server, the apparatus comprising: a first management module;

the first management module is used for acquiring an IP application request sent by a request object serving as a client, determining the network type of the requested IP address, and allocating the IP address to the request object according to the network type.

An electronic device, comprising:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein, the first and the second end of the pipe are connected with each other,

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform a method as described above.

A non-transitory computer readable storage medium having stored thereon computer instructions for causing the computer to perform the method as described above.

A computer program product comprising a computer program which, when executed by a processor, implements a method as described above.

One embodiment in the above application has the following advantages or benefits: the IP address management server is used for managing IP addresses in a unified mode, all request objects serve as clients to send IP application requests to the IP address management server, and the IP address management server distributes the IP addresses according to the requested network types and the like, so that centralized IP management is achieved, waste of IP resources is reduced, and the like.

It should be understood that the statements in this section do not necessarily identify key or critical features of the embodiments of the present disclosure, nor do they limit the scope of the present disclosure. Other features of the present disclosure will become apparent from the following description.

Drawings

The drawings are included to provide a better understanding of the present solution and are not intended to limit the present application. Wherein:

FIG. 1 is a flow chart of an embodiment of an IP management method according to the present application;

FIG. 2 is a schematic diagram illustrating an interaction between a request object as a client and an IP address management server according to the present application;

fig. 3 is a schematic structural diagram of an embodiment of an IP management device 30 according to the present application;

fig. 4 is a block diagram of an electronic device according to the method of an embodiment of the present application.

Detailed Description

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

In addition, it should be understood that the term "and/or" herein is merely one type of association relationship that describes an associated object, meaning that three relationships may exist, e.g., a and/or B may mean: a exists alone, A and B exist simultaneously, and B exists alone. In addition, the character "/" herein generally indicates that the former and latter related objects are in an "or" relationship.

Fig. 1 is a flowchart of an embodiment of an IP management method according to the present application. The method can be applied to an IP address management Server (IPAM-Server). As shown in fig. 1, the following detailed implementation may be included.

In 101, an IP application request transmitted as a request object of a client is acquired.

In 102, the network type of the requested IP address is determined.

In 103, an IP address is assigned to the requested object according to the determined network type.

In the embodiment of the method, the IP address management server is used for uniformly managing the IP addresses, all request objects are used as clients to initiate IP application requests to the IP address management server, and the IP address management server allocates the IP addresses according to the requested network types and the like, so that centralized IP management is realized, the waste of IP resources is reduced, and the like.

If the existing method is adopted, and it is assumed that node 1 is allocated with the IP network segment of 10.200.1.0/24, only the request object on this node will be allocated with the IP address from this IP network segment.

In the manner described in the present application, taking 10.200.0.0/16 IP segment as an example, the request object on each node may be allocated to an IP address from the IP segment.

In the existing mode, each node respectively manages the own IP network segment, the client and the server are not distinguished, and the IP addresses are difficult to uniformly manage. In the mode, after the IP address is uniformly managed by the IP address management server, different request objects only need to be used as clients of the IP address management server to apply for the IP address and the like, specific IP address allocation and management logic are given to the IP address management server, code upgrading also only needs to update the IP address management server, interfaces are not changed, updating and changing of various request objects are not needed, log inquiry and IP use information inquiry also only need to use the IP address management server as a single inlet, and therefore management, operation and maintenance capacity of the IP address is greatly improved

In addition, in the existing method, each node has its own separate IP network segment, that is, the IP network segments of each node are different from each other, and for any container, its IP address is allocated from the IP network segment of the node where it is located, which may cause the following problems: for k8s, containers may drift between nodes, and if a container drifts from node a to node B, the container is reassigned to an IP address in the IP network segment of node B, so that the IP address in the IP network segment of node a before the drift can no longer be used. The IP address management server in the mode is used as a centralized IP management platform, and the managed IP network segment does not have the node division problem, so that the container can be supported to keep the IP address unchanged after the container drifts among the nodes.

As described in 101, the IP address management server can acquire an IP application request transmitted as a request object of the client. Correspondingly, for any request object, when an IP address needs to be requested, an IP application request may be sent to the IP address management server through a HyperText Transfer Protocol (HTTP) interface, where the request may carry information such as a network type of the requested IP address.

As described in 102 and 103, the IP address management server may assign an IP address to the request object according to the network type of the requested IP address. The network type may include an intranet, a public network, and the like. The IP addresses of different network types are non-interfering.

Taking the container as an example, there may be a plurality of network cards, and correspondingly, the IP addresses corresponding to the network types may be respectively applied for different network types.

Preferably, for the obtained IP application request, the IP address management server may further determine an object type of the request object, and then determine a manager corresponding to the object type of the request object according to a pre-established correspondence between the object type and a manager (handler), so that the manager allocates an IP address to the request object according to the requested network type and an IP management logic corresponding to the manager. Wherein, the manager is a component in the IP address management server.

The object type may include stateful, deployment, and the like. The corresponding relation between different object types and the corresponding managers can be established in advance, and then the manager corresponding to the object type of the request object can be determined according to the established corresponding relation. Different managers can respectively correspond to respective IP management logics, and the specific IP management logic can be determined according to actual needs. In this way, the manager can assign an IP address to the requested object, i.e., assign an available IP address, based on the requested network type and corresponding IP management logic.

By the processing mode, the distribution and management of the IP address can be finer grained, so that the management, operation and maintenance capabilities of the IP address are further improved.

The IP address management server may further acquire an IP release request transmitted from the request object and release the requested IP address. The released IP address may be reassigned, such as to other request objects.

In addition, the IP address management server may also manage the IP address by using M hierarchical IP pools, each IP pool may include at least one IP network segment, and M is a positive integer. That is, the IP address management server may manage the IP address using one hierarchical IP pool, or may manage the IP address using a plurality of hierarchical IP pools. Each IP pool may include one IP segment or a plurality of IP segments.

Specifically, managing IP addresses using M hierarchical IP pools may include at least one of: and respectively establishing corresponding IP pools for different network types, respectively establishing corresponding IP pools for different tenants, and respectively establishing corresponding IP pools for different k8s high-level objects. Generally, the IP pool level corresponding to the network type is higher than the IP pool level corresponding to the tenant, and the IP pool level corresponding to the tenant is higher than the IP pool level corresponding to the k8s high-level object.

For example, corresponding IP pools can be respectively established for different network types such as an internal network and a public network, and the corresponding IP pools are used for storing corresponding IP addresses. For another example, in the case of multiple tenants, if the network segments between the tenants need to be isolated, corresponding IP pools can be respectively established for different tenants. For another example, for different k8s advanced objects, such as stateful, deployment, etc., there may be multiple containers under each advanced object, and in order to facilitate management and meet the customization requirements of different objects, corresponding IP pools may be respectively established for different k8s advanced objects.

If the three types of IP pools simultaneously exist, the IP pools corresponding to different network types may be used as the IP pool of the first hierarchy, the IP pools corresponding to different tenants may be used as the IP pool of the second hierarchy, and the IP pools corresponding to different k8s advanced objects may be used as the IP pool of the third hierarchy. For each IP pool of the previous level, a plurality of IP pools of the next level may be included. For example, the IP pool corresponding to the network type of the public network may include a plurality of IP pools of the second hierarchy, each of which corresponds to a different tenant, and each of the IP pools of the second hierarchy may include a plurality of IP pools of the third hierarchy, and the like.

By means of the IP pool, IP addresses can be managed and operated and maintained better. For example, for a multi-tenant k8s environment, multiple tenants may use the same time, if the IP addresses of the pod and the like of each tenant are allocated to the same IP network segment, the use and the division are more convenient, and advanced restrictions are more convenient to perform, for example, traffic control, permission isolation restriction and other operations can be performed on the own IP network segment, and if the IP network segment is common to all tenants and randomly allocated to a single tenant, the use cost and the operation and maintenance cost are both greatly increased.

In addition, the network environment in a real situation is very complex, such as the following problems may occur: when a certain container is deleted, the IP address management server is informed to release the IP address occupied by the container, and at the moment, if the network communication is abnormal, the IP address management server cannot receive the IP release request, so that the IP address occupied by the container is leaked.

To this end, the IP address management server may also periodically perform the following operations: and releasing the IP addresses which are matched with the release condition in the IP addresses allocated to the request object.

Specifically, each IP pool may be traversed (list), and when any IP pool is traversed, if it is determined that the IP pool meets the first release condition, the IP pool may be deleted, and all IP addresses in the IP pool may be released.

For any IP pool, compliance with the first release condition may mean that a user of an IP address in that IP pool does not already exist. For example, if a tenant corresponding to an IP pool does not exist, the IP pool may be considered to meet the first release condition, so that the IP pool may be deleted, and all IP addresses in the IP pool may be released. In addition, for any IP address, the second release condition is met, which may mean that the IP address is marked as available for release, or that a user of the IP address does not exist and does not belong to an IP address reservation situation. In practical applications, for various reasons, it may be caused that an IP address marked as available for release is not released, and accordingly, such an IP address may be considered to meet the second release condition, thereby releasing the IP address. For any IP address, assuming that its user does not exist and the IP address does not belong to the IP address reservation, it can also be considered that the second release condition is satisfied, and the IP address is released.

The above-mentioned situations of meeting the first release condition and meeting the second release condition are only examples, and are not used to limit the technical solution of the present application, and the specific conditions may be determined according to actual needs.

The freed-up IP address may be marked as available and assigned to the desired request object.

By the method, each IP address can be normally used, and the utilization rate of IP resources is improved. In addition, in the existing method, a method of randomly allocating available IP addresses is generally adopted, that is, randomly traversing an IP address list to find an available IP address, but in a real scenario, a more complex requirement may be imposed, for example, in a k8s scenario, a binding combination related to a k8s high-level object may be customized, for example, for a stateful set, names of containers owned by each stateful set are fixed, that is, names of containers are predictable during a stateful set expansion process, it is assumed that when a stateful set name is sts-test copy number is 2, names of two containers are sts-test-0 and sts-test-1, respectively, when a copy number expansion is 1, a name of this container is sts-test-0, when a copy number is 2, names of two containers are sts-test-0 and sts-test-1, respectively, an IP address of a container may be fixed according to an ID of the name of the container, and when an expansion of the container is again assigned, an IP address of the new container may not be changed, and the new IP address of the new container may not be deleted accordingly.

Based on the above description, fig. 2 is a schematic diagram illustrating an interaction manner between a request object as a client and an IP address management server according to the present application. As shown in fig. 2, when an IP application request sent by a request object is obtained, the IP address management server may select a corresponding manager according to the object type, and the manager selects a corresponding IP pool according to the requested network type, and allocates an IP address to the request object from the selected IP pool, and when an IP release request sent by the request object is obtained, the requested IP address may be correspondingly released.

It should be noted that the foregoing method embodiments are described as a series of acts or combinations for simplicity in explanation, but it should be understood by those skilled in the art that the present application is not limited by the order of acts described, as some steps may occur in other orders or concurrently depending on the application. Further, those skilled in the art should also appreciate that the embodiments described in the specification are preferred embodiments and that the acts and modules referred to are not necessarily required in this application.

The above is a description of method embodiments, and the embodiments of the present application are further described below by way of apparatus embodiments.

Fig. 3 is a schematic structural diagram of an embodiment of an IP management device 30 according to the present application. The IP management device 30 can be applied to the IP address management server in the above method embodiment. As shown in fig. 3, includes: a first management module 301.

The first management module 301 is configured to obtain an IP application request sent as a request object of a client, determine a network type of a requested IP address, and allocate an IP address to the request object according to the determined network type.

Specifically, the first management module 301 may determine an object type of the request object, and determine a manager corresponding to the object type of the request object according to a pre-established correspondence between the object type and the manager, so that the manager allocates an IP address to the request object according to the requested network type and an IP management logic corresponding to the manager. Wherein, the manager is a component in the IP address management server.

The first management module 301 may further obtain an IP release request sent by the request object, and release the requested IP address.

As shown in fig. 3, the IP management apparatus 30 may further include a second management module 302, configured to manage IP addresses by using M hierarchical IP pools, where each IP pool includes at least one IP network segment, and M is a positive integer.

Specifically, the second management module 302 may manage the IP addresses by using M hierarchical IP pools, and the management may include at least one of: and respectively establishing corresponding IP pools for different network types, respectively establishing corresponding IP pools for different tenants, and respectively establishing corresponding IP pools for different k8s high-level objects. The hierarchy of the IP pool corresponding to the network type is higher than that of the IP pool corresponding to the tenant, and the hierarchy of the IP pool corresponding to the tenant is higher than that of the IP pool corresponding to the k8s high-level object.

For example, corresponding IP pools can be respectively established for different network types such as an internal network and a public network, and the corresponding IP pools are used for storing corresponding IP addresses. For another example, in the case of multiple tenants, if the network segments between the tenants need to be isolated, corresponding IP pools can be respectively established for different tenants. For another example, for different k8s high-level objects, such as stateful, deployment, etc., there may be multiple containers under each high-level object, and in order to facilitate management and meet the customization requirements of different objects, corresponding IP pools may be respectively established for different k8s high-level objects.

If the three types of IP pools simultaneously exist, the IP pools corresponding to different network types may be used as the IP pool of the first hierarchy, the IP pools corresponding to different tenants may be used as the IP pool of the second hierarchy, and the IP pools corresponding to different k8s high-level objects may be used as the IP pool of the third hierarchy. For each IP pool of the previous level, a plurality of IP pools of the next level may be included.

As shown in fig. 3, the IP management apparatus 30 may further include a third management module 303, configured to periodically perform the following operations: and releasing the IP addresses which are matched with the release condition in the IP addresses allocated to the request object.

Specifically, the third management module 303 may traverse each IP pool, and when any IP pool is traversed, if it is determined that the IP pool meets the first release condition, the IP pool may be deleted, and all IP addresses in the IP pool may be released.

For any IP pool, meeting the first release condition may include: the users of the IP addresses in the IP pool do not already exist. For any IP address, compliance with the second release condition may include: the IP address is marked as being available for release or the user of the IP address is not present and does not belong to the IP address reservation case.

For a specific work flow of the apparatus embodiment shown in fig. 3, reference is made to the related description in the foregoing method embodiment, and details are not repeated.

In short, by adopting the scheme of the embodiment of the application device, the IP address management server can be used for uniformly managing the IP addresses, all request objects are used as clients to initiate IP application requests to the IP address management server, and the IP address management server allocates the IP addresses according to the requested network types and the like, so that the centralized IP management is realized, and the waste of IP resources and the like are reduced; moreover, the IP address can be better managed, operated and maintained by means of the IP pool; in addition, each IP address can be ensured to be normally used through periodic polling, so that the utilization rate of IP resources is improved.

According to an embodiment of the present application, an electronic device and a readable storage medium are also provided.

Fig. 4 is a block diagram of an electronic device according to the method of the embodiment of the present application. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be examples only, and are not meant to limit implementations of the present application that are described and/or claimed herein.

As shown in fig. 4, the electronic apparatus includes: one or more processors Y01, a memory Y02, and interfaces for connecting the components, including a high speed interface and a low speed interface. The various components are interconnected using different buses and may be mounted on a common motherboard or in other manners as desired. The processor may process instructions for execution within the electronic device, including instructions stored in or on the memory to display graphical information for a graphical user interface on an external input/output device (such as a display device coupled to the interface). In other embodiments, multiple processors and/or multiple buses may be used, along with multiple memories and multiple memories, as desired. Also, multiple electronic devices may be connected, with each device providing portions of the necessary operations (e.g., as a server array, a group of blade servers, or a multi-processor system). In fig. 4, one processor Y01 is taken as an example.

The memory Y02 is a non-transitory computer readable storage medium provided by the present application. Wherein the memory stores instructions executable by at least one processor to cause the at least one processor to perform the methods provided herein. The non-transitory computer readable storage medium of the present application stores computer instructions for causing a computer to perform the methods provided herein.

The memory Y02, which is a non-transitory computer readable storage medium, may be used to store non-transitory software programs, non-transitory computer executable programs, and modules, such as program instructions/modules corresponding to the methods in the embodiments of the present application. The processor Y01 performs various functional applications of the server and data processing, i.e., implements the method in the above-described method embodiment, by executing non-transitory software programs, instructions, and modules stored in the memory Y02.

The memory Y02 may include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required for at least one function; the storage data area may store data created according to use of the electronic device, and the like. Further, the memory Y02 may include high speed random access memory, and may also include non-transitory memory, such as at least one magnetic disk storage device, flash memory device, or other non-transitory solid state storage device. In some embodiments, the memory Y02 may optionally include a memory remotely located from the processor Y01, and these remote memories may be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the internet, intranets, blockchain networks, local area networks, mobile communication networks, and combinations thereof.

The electronic device may further include: an input device Y03 and an output device Y04. The processor Y01, the memory Y02, the input device Y03, and the output device Y04 may be connected by a bus or other means, and are exemplified by being connected by a bus in fig. 4.

The input device Y03 may receive input numeric or character information and generate key signal inputs related to user settings and function control of the electronic apparatus, such as a touch screen, a keypad, a mouse, a track pad, a touch pad, a pointing stick, one or more mouse buttons, a track ball, a joystick, or other input devices. The output device Y04 may include a display apparatus, an auxiliary lighting device, a tactile feedback device (e.g., a vibration motor), and the like. The display device may include, but is not limited to, a liquid crystal display, a light emitting diode display, and a plasma display. In some implementations, the display device can be a touch screen.

Various implementations of the systems and techniques described here can be realized in digital electronic circuitry, integrated circuitry, application specific integrated circuits, computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include: implemented in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, receiving data and instructions from, and transmitting data and instructions to, a storage system, at least one input device, and at least one output device.

These computer programs (also known as programs, software applications, or code) include machine instructions for a programmable processor, and may be implemented using high-level procedural and/or object-oriented programming languages, and/or assembly/machine languages. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, apparatus, and/or device (e.g., magnetic discs, optical disks, memory, programmable logic devices) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal used to provide machine instructions and/or data to a programmable processor.

To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having: a display device (e.g., a cathode ray tube or a liquid crystal display monitor) for displaying information to a user; and a keyboard and a pointing device (e.g., a mouse or a trackball) by which a user may provide input to the computer. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic, speech, or tactile input.

The systems and techniques described here can be implemented in a computing system that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local area networks, wide area networks, blockchain networks, and the internet.

The computer system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The server can be a cloud server, also called a cloud computing server or a cloud host, and is a host product in a cloud computing service system, so that the defects of high management difficulty and weak service expansibility in the traditional physical host and VPS service are overcome.

It should be understood that various forms of the flows shown above may be used, with steps reordered, added, or deleted. For example, the steps described in the present application may be executed in parallel, sequentially, or in different orders, as long as the desired results of the technical solutions disclosed in the present application can be achieved, and the present invention is not limited herein.

The above-described embodiments should not be construed as limiting the scope of the present application. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may be made in accordance with design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. An Internet Protocol (IP) management method, which is applied to an IP address management server and comprises the following steps:

determining a network type of the requested IP address;

allocating an IP address to the request object according to the network type, including: determining the object type of the request object, determining a manager corresponding to the object type of the request object according to a pre-established corresponding relationship between the object type and the manager, so that the manager allocates an IP address to the request object according to the network type and an IP management logic corresponding to the manager, wherein the manager is a component in the IP address management server, and the object type comprises: state set stateful and deployment.

2. The method of claim 1, further comprising:

acquiring an IP release request sent by the request object;

the requested IP address is released.

3. The method of claim 1, further comprising:

and managing the IP addresses by adopting M hierarchical IP pools, wherein each IP pool comprises at least one IP network segment, and M is a positive integer.

4. The method of claim 3, wherein the managing IP addresses with M tiers of IP pools comprises at least one of:

respectively establishing corresponding IP pools for different network types;

IP pools respectively and correspondingly established for different tenants;

respectively establishing corresponding IP pools for different Kubernetes open source container cluster management system high-level objects;

the hierarchy of the IP pool corresponding to the network type is higher than that of the IP pool corresponding to the tenant, and the hierarchy of the IP pool corresponding to the tenant is higher than that of the IP pool corresponding to the kubernets open source container cluster management system high-level object.

5. The method of claim 3, further comprising:

periodically performing the following: and releasing the IP addresses which are matched with the release condition in the IP addresses allocated to the request object.

6. The method of claim 5, wherein the releasing the IP addresses that meet the release condition from the IP addresses allocated to the request object comprises:

traversing each IP pool, and when any IP pool is traversed, if the IP pool is determined to meet a first release condition, deleting the IP pool and releasing all IP addresses in the IP pool;

and traversing each IP address in the IP pool for any IP pool which does not accord with the first release condition, and releasing the IP address if any IP address accords with the second release condition.

7. The method of claim 6, wherein,

for any IP pool, meeting the first release condition comprises: users of IP addresses in the IP pool do not already exist;

for any IP address, the compliance with the second release condition includes: the IP address is marked as being available for release, or the user of the IP address does not exist and does not belong to the IP address reservation condition.

8. An Internet Protocol (IP) management device applied to an IP address management server, the device comprising: a first management module;

the first management module is configured to obtain an IP application request sent by a request object serving as a client, determine a network type of a requested IP address, and allocate an IP address to the request object according to the network type, and includes: determining the object type of the request object, determining a manager corresponding to the object type of the request object according to a pre-established corresponding relationship between the object type and the manager, so that the manager allocates an IP address to the request object according to the network type and an IP management logic corresponding to the manager, wherein the manager is a component in the IP address management server, and the object type comprises: state set stateful and deployment.

9. The apparatus of claim 8, wherein the first management module is further configured to obtain an IP release request sent by the request object, and release the requested IP address.

10. The apparatus of claim 8, further comprising: a second management module;

and the second management module is used for managing the IP addresses by adopting M levels of IP pools, each IP pool comprises at least one IP network segment, and M is a positive integer.

11. The apparatus of claim 10, wherein the second management module to manage IP addresses using M tiers of IP pools comprises at least one of: the method comprises the steps of respectively establishing corresponding IP pools for different network types, respectively establishing corresponding IP pools for different tenants, and respectively establishing corresponding IP pools for different Kubernets open source container cluster management system high-level objects, wherein the hierarchy of the IP pool corresponding to the network type is higher than that of the IP pool corresponding to the tenant, and the hierarchy of the IP pool corresponding to the tenant is higher than that of the IP pool corresponding to the Kubernets open source container cluster management system high-level object.

12. The apparatus of claim 10, further comprising: a third management module;

the third management module is configured to periodically perform the following operations: and releasing the IP addresses which are matched with the release condition in the IP addresses allocated to the request object.

13. The apparatus according to claim 12, wherein the third management module traverses each IP pool, and when traversing any IP pool, if it is determined that the IP pool meets a first release condition, deletes the IP pool and releases all IP addresses in the IP pool, and for any IP pool that does not meet the first release condition, traverses each IP address in the IP pool, and if any IP address meets a second release condition, releases the IP address.

14. The apparatus of claim 13, wherein,

for any IP address, the compliance with the second release condition includes: the IP address is marked as being available for release, or the user of the IP address does not exist and belongs to the IP address reservation condition.

15. An electronic device, comprising:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein the content of the first and second substances,

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-7.

16. A non-transitory computer readable storage medium having stored thereon computer instructions for causing the computer to perform the method of any one of claims 1-7.