CN113986539A

CN113986539A - Method, device, electronic equipment and readable storage medium for realizing pod fixed IP

Info

Publication number: CN113986539A
Application number: CN202111241420.5A
Authority: CN
Inventors: 徐强
Original assignee: Chongqing Unisinsight Technology Co Ltd
Current assignee: Chongqing Unisinsight Technology Co Ltd
Priority date: 2021-10-25
Filing date: 2021-10-25
Publication date: 2022-01-28

Abstract

The application provides a method, a device, an electronic device and a readable storage medium for realizing a pod fixed IP, wherein a first target node corresponding to a pod to be created in a cluster is determined by acquiring a fixed IP required by the pod to be created in a creation request, and the first target node has a host IP address of the first target node. And creating the pod to be created to deploy the created pod to the first target node, and binding a fixed IP required by the deployed pod on a network card of the first target node so that the deployed pod uses the fixed IP to start service for external access. In the scheme, the fixed IP of the pod is not affected by the host IP of the node where the pod is located, and the fixed IP bound by the pod can not be affected during subsequent reconstruction or migration, so that the abnormal phenomenon caused by IP change in the prior art can be avoided.

Description

Method, device, electronic equipment and readable storage medium for realizing pod fixed IP

Technical Field

The present application relates to the field of communications technologies, and in particular, to a method, an apparatus, an electronic device, and a readable storage medium for implementing a pod fixed IP.

Background

Kubernetes as a container management engine provides powerful container orchestration capability, supports immutable infrastructure and declarative Open api, while isolating underlying infrastructure differences, has become a foundation and de facto standard native to the cloud. Kubernets uses pods, which are also the smallest unit of k8s arrangement, to manage a containerized application, and each pod may contain multiple pods, each with its own IP address, with the pods within a pod sharing the same IP and port space, and with the pods being created with their IP addresses assigned internally.

The lifetime of a pod in kubernets is short, and in case of pod reconstruction, migration, etc., the controller will allocate a new IP for the pod, for example, when the pod migrates from one node to another, the IP address of the pod changes from the host IP address of the node where the pod is originally located to the host IP address of the node to which the pod migrates. With the wider and wider use of kubernets, the general way of accessing services no longer meets the traffic demands in some complex and specific scenarios. For example, some service discovery uses IP as an example unique identifier, and an exception occurs after the IP inside the pod changes.

Disclosure of Invention

The present application includes, for example, providing a method, an apparatus, an electronic device, and a readable storage medium for implementing a pod fixed IP, which can avoid the occurrence of an abnormal phenomenon due to an IP change of a pod in the related art.

The embodiment of the application can be realized as follows:

in a first aspect, the present application provides a method for implementing a pod fixed IP, where the method is applied to a controller in a kubernets cluster, where the kubernets cluster further includes a plurality of nodes, and the method includes:

acquiring a fixed IP required by a pod to be created in the creation request;

determining a first target node corresponding to the pod to be created in the cluster, wherein the first target node has a host IP address of the first target node;

creating the pod to be created so as to deploy the created pod to the first target node;

and binding a fixed IP required by the deployed pod on the network card of the first target node, so that the deployed pod uses the fixed IP to start the service for external access.

In an alternative embodiment, the method further comprises:

under the condition of obtaining a scheduling instruction, obtaining a pod to be scheduled and a second target node to be scheduled, which are pointed by the scheduling instruction;

obtaining a fixed IP bound by the pod to be scheduled;

dispatching the pod to be dispatched, bound with the fixed IP, to the second target node;

and binding the fixed IP bound by the pod to be scheduled on the network card of the second target node.

In an alternative embodiment, the method further comprises:

and under the condition that the pod to be scheduled is scheduled successfully, removing the fixed IP of the pod to be scheduled, which is bound on the network card of the node where the pod to be scheduled is located before the pod to be scheduled is scheduled.

In an optional embodiment, the step of determining the first target node corresponding to the pod to be created in the cluster includes:

detecting whether the fixed IP required by the pod to be created is used by any node in the cluster;

if the fixed IP is not used by any node in the cluster, acquiring node information contained in the creation request as a first target node;

and if the fixed IP is used by the nodes in the cluster, using the nodes using the fixed IP as first target nodes.

In an optional embodiment, if the fixed IP is used by a node in the cluster, the step of using the node using the fixed IP as a first target node includes:

under the condition that the fixed IP is used by the nodes in the cluster, judging whether the fixed IP is an exclusive IP or not, wherein the exclusive IP is an IP bound by a single pod;

if the fixed IP is not the exclusive IP, taking the node using the fixed IP as a first target node;

and if the fixed IP is the exclusive IP, prompting binding abnormal information.

In an alternative embodiment, the method further comprises:

under the condition of obtaining a deleting instruction, obtaining a pod to be deleted, which is pointed by the deleting instruction;

obtaining a fixed IP of the pod to be deleted bound on a network card of a node where the pod to be deleted is located;

and deleting the pod to be deleted from the node, and deleting the fixed IP of the pod to be deleted on the network card.

In an optional implementation manner, the step of deleting the fixed IP of the pod to be deleted on the network card includes:

detecting whether other pots bound with the same fixed IP with the pot to be deleted exist on the node where the pot to be deleted is located;

and if not, deleting the fixed IP of the pod to be deleted on the network card.

In an optional embodiment, the step of creating the pod to be created and deploying the created pod to the first target node includes:

configuring the fixed IP required by the pod to be created into an environment variable of the pod;

obtaining deployment strategy information based on the determined first target node configuration;

and generating the pod to be created according to the environment variable, and deploying the pod obtained through creation to the first target node based on the deployment strategy information.

In a second aspect, the present application provides an apparatus for implementing pod fixed IP, where the apparatus is applied to a controller in a kubernets cluster, where the kubernets cluster further includes a plurality of nodes, and the apparatus:

the acquisition module is used for acquiring a fixed IP required by the pod to be created in the creation request;

a determining module, configured to determine a first target node corresponding to the pod to be created in the cluster, where the first target node has a host IP address of the first target node;

the deployment module is used for creating the pod to be created so as to deploy the created pod to the first target node;

and the binding module is used for binding the fixed IP required by the deployed pod on the network card of the first target node so that the deployed pod uses the fixed IP to start the service for external access.

In a third aspect, the present application provides an electronic device comprising a memory for storing computer instructions and a processor for retrieving the computer instructions from the memory to perform the method according to any of the preceding embodiments.

In a fourth aspect, the present application provides a computer-readable storage medium storing computer instructions which, when executed by a processor, implement the method according to any one of the preceding embodiments.

The beneficial effects of the embodiment of the application include, for example:

the application provides a method, a device, an electronic device and a readable storage medium for realizing a pod fixed IP, wherein a first target node corresponding to a pod to be created in a cluster is determined by acquiring a fixed IP required by the pod to be created in a creation request, and the first target node has a host IP address of the first target node. And creating the pod to be created to deploy the created pod to the first target node, and binding a fixed IP required by the deployed pod on a network card of the first target node so that the deployed pod uses the fixed IP to start service for external access.

In the scheme, the pod is deployed to the first target node by performing fixed IP binding on the pod, and the fixed IP is bound on the network card of the first target node. The fixed IP of the pod is not affected by the host IP of the node where the pod is located, and the fixed IP bound by the pod can not be affected during subsequent reconstruction or migration, so that the abnormal phenomenon caused by IP change in the prior art can be avoided.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are required to be used in the embodiments will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present application and therefore should not be considered as limiting the scope, and for those skilled in the art, other related drawings can be obtained from the drawings without inventive effort.

Fig. 1 is a schematic diagram of a system architecture of a kubernets cluster according to an embodiment of the present disclosure;

fig. 2 is a flowchart of a method for implementing pod fixed IP according to an embodiment of the present disclosure;

FIG. 3 is a flowchart of sub-steps included in step S102 of FIG. 2;

fig. 4 is a flowchart of sub-steps included in step S1023 in fig. 3;

FIG. 5 is a flowchart of sub-steps involved in step S103 of FIG. 2;

fig. 6 is a flowchart of a scheduling method in a method for implementing a pod fixed IP according to the embodiment of the present application;

fig. 7 is a flowchart of a deletion method in a method for implementing pod fixed IP according to an embodiment of the present application;

fig. 8 is another flowchart of a method for implementing pod fixed IP according to an embodiment of the present disclosure;

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

fig. 10 is a functional block diagram of an apparatus for implementing pod fixed IP according to an embodiment of the present application.

Icon: 10-means to implement pod fixed IP; 101-an acquisition module; 102-a determination module; 103-deployment module; 104-binding module.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some embodiments of the present application, but not all embodiments. The components of the embodiments of the present application, generally described and illustrated in the figures herein, can be arranged and designed in a wide variety of different configurations.

Thus, the following detailed description of the embodiments of the present application, presented in the accompanying drawings, is not intended to limit the scope of the claimed application, but is merely representative of selected embodiments of the application. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, it need not be further defined and explained in subsequent figures.

In the description of the present application, it is noted that the terms "first", "second", and the like are used merely for distinguishing between descriptions and are not intended to indicate or imply relative importance.

It should be noted that the features of the embodiments of the present application may be combined with each other without conflict.

Please refer to fig. 1, which is a schematic diagram of a system architecture of a kubernets cluster according to an embodiment of the present application, in which the system includes a plurality of nodes, such as Node1, Node2, and Node3 … … in the figure, and the plurality of nodes can communicate with each other. Wherein, one or more pods can be deployed on each node, and a pod can be understood as a Container group, and each Container group encapsulates one or more containers (containers) for carrying software programs. Pod is the basic unit of operation of Kubernetes, the smallest unit of deployment that can be created, debugged, and managed. In each pod, multiple containers therein may share network resources.

In this embodiment, the Kubernetes cluster further includes a controller, and the controller may implement management of the pod in the cluster, such as scheduling, deleting, creating, and the like. The controller may be any node in the cluster, for example, the cluster may include a master node, which may be a controller in the cluster, and a plurality of computing nodes in communication with the master node.

In this embodiment, in the kubernets cluster, an external service may be provided, where the external service includes an admission control service (deployment) and a node processing service (daemon), where the admission control service may be implemented by an admission control module, and the node control service may be implemented by a node control module. The admission control module can be used as a deployment (deployment) service to provide services in a single copy, and the node control module can be used as a daemon process control (daemon) service at each node. The admission control module and the node control module may perform operations under the relevant instructions of the controllers of the cluster. For example, the admission control module may implement operations such as intercepting a pod creation request, judging occupation of IP address information of a pod, and the like, and the node control module may monitor creation conditions, migration conditions, and the like of the pod on the node where the node is located.

Referring to fig. 2, an embodiment of the present application provides a method for implementing pod fixed IP, where the method is applied to a controller in a kubernets cluster, where the controller may be any node in the cluster, and the method includes the following steps.

Step S101, acquiring a fixed IP required by the pod to be created in the creation request.

Step S102, determining a first target node corresponding to the pod to be created in the cluster, wherein the first target node has a host IP address of the first target node.

Step S103, creating the pod to be created, so as to deploy the created pod to the first target node.

Step S104, binding a fixed IP required by the deployed pod on the network card of the first target node, so that the deployed pod uses the fixed IP to start service for external access.

In this embodiment, the pod to be created may be newly created or may be reconstructed. In doing pod creation, the fixed IP required to label the pod to be created with it in the form of label may be used. Also, pod-related information, such as type information of a pod, a corresponding name, and a corresponding ID, etc., may also be set. In addition, the type of fixed IP of the pod may also be set, e.g., whether the fixed IP is an exclusive IP.

The admission control module in the cluster can be used to realize the update configuration of the information of the pod and acquire the fixed IP required by the pod.

Since the pod finally needs to be deployed to a node in the cluster, the pod to be created should have a corresponding node, i.e., a node to which it can be deployed, which is named herein as a first target node. The determination method of the first target node may be specified, or may be determined by a certain policy. Each node in the cluster has its own host IP address, which is independent of the IP to which the pod needs to bind.

In this embodiment, after the first target node corresponding to the pod to be created is determined, the pod to be created is created, so that the created pod is deployed to the first target node.

Networking requirements are provided among a plurality of nodes in the cluster, generally, the networking requirements of each node in the cluster are the same, for example, each node has a network card of a data network as a node. In this embodiment, after the pod to be created is deployed to the first target node, the fixed IP required by the deployed pod needs to be bound on the network card of the first target node accordingly. And binding the fixed IP on the network card by utilizing the node control module on the first target node.

In this embodiment, since the fixed IP needs to be bound to the network card, the pod needs to open the host network mode.

In this embodiment, the pod to be created is deployed to the first target node by binding the fixed IP for the pod to be created, and the fixed IP is bound to the network card of the first target node. After the pod is successfully started on the node, the corresponding fixed IP is also bound on the node, and because the pod adopts a host network mode, the inside of the pod can access the service through the fixed IP only after the fixed IP is used for starting the service.

The fixed IP of the pod to be created is not influenced by the host IP of the node, so that the condition of the change of the IP of the pod cannot occur under the condition of subsequent migration or reconstruction, and the abnormal phenomenon caused by the change of the IP is further avoided.

In this embodiment, when a pod is created, a target node of the pod to be created may be specified, but in actual implementation, a phenomenon that a fixed IP to be bound to the pod to be created has an IP collision in a cluster may occur, and based on this consideration, referring to fig. 3, in the step of determining the first target node corresponding to the pod to be created, this embodiment may be implemented in the following manner:

step S1021, detecting whether the fixed IP required by the pod to be created is used by any node in the cluster, if the fixed IP is not used by any node in the cluster, executing the following step S1022, and if the fixed IP is used by a node in the cluster, executing the following step S1023.

Step S1022, the node information included in the creation request is acquired as the first target node.

In step S1023, the node using the fixed IP is used as the first target node.

In this embodiment, the fixed IP required by the pod to be created may have been used by other nodes in the cluster, that is, there may be a problem of IP collision. Since each node in the cluster may support the deployment of one or more pods. In order to avoid the problem of IP collision, therefore, the pod affinity configuration may be performed, that is, the node using the fixed IP may be used as the first target node corresponding to the pod to be created, and the pod to be created may be deployed to the node using the fixed IP.

And if the fixed IP required by the pod to be created is not used by the nodes in the cluster, the fixed IP can be used as the first target node according to the node information in the intercepted creating request. That is, the pod to be created is subsequently deployed to the node specified by the create request.

Accordingly, in the step of binding the fixed IP required by the deployed pod to the network card of the first target node, it may be detected whether the fixed IP required by the deployed pod is bound to the network card of the first target node.

If the first target node is a node occupying the fixed IP required by the pod to be created, the fixed IP required by the pod to be created is already bound to the network card of the node, and therefore, the binding is not required to be repeated.

If the fixed IP required by the pod to be created is not used by the node, that is, the fixed IP required by the pod to be created is not bound to the network card of the first target node specified in the creation request. In this case, the fixed IP required for creating the pod needs to be bound to the network card of the first target node.

In this embodiment, by performing the above-described operation on whether there is a fixed IP required by the node to use the pod to be created, and if there is a fixed IP, the node to be used is taken as the first target node of the pod to be created, and if there is no fixed IP, the node specified by the creation request is taken as the first target node of the pod to be created, so that the phenomenon of IP collision can be avoided.

As described above, when creating a pod, it is possible to set whether or not the IP required for the pod is an exclusive IP. In the cluster, when there is a node using a fixed IP required by a pod to be created, the IP bound to the node may also be an exclusive IP, and similarly, if the pod to be created is deployed to the node, an IP collision still occurs, which causes an exception. In view of this, referring to fig. 4, in the present embodiment, in the case that the fixed IP is used by the nodes in the cluster, the following steps may be performed:

step S10231, when the fixed IP is used by the nodes in the cluster, determining whether the fixed IP is an exclusive IP, where the exclusive IP is an IP bound by a single pod, if the fixed IP is not an exclusive IP, executing the following step S10232, and if the fixed IP is an exclusive IP, executing the following step S10233.

In step S10232, a node using a fixed IP that is not an exclusive IP is set as the first target node.

Step S10233, binding exception information is prompted.

In this embodiment, the exclusive IP is that only one pod can use the IP, and if the fixed IP is determined to be the exclusive IP by the above-mentioned detection when there is a node using the fixed IP required by the pod to be created, the problem of IP collision due to the exclusivity of the exclusive IP can be avoided.

In this embodiment, in the case that the IP is not an exclusive IP, a single IP may be bound by multiple pods, which are deployed on the same node. If the IP is exclusive, the IP can be occupied by a single pod. The effect of multiple pods using one IP or an IP exclusively owned by a single pod can be achieved depending on the setting.

After the first target node corresponding to the pod to be created is determined in the above manner, when pod creation and deployment are performed, the method can be implemented in the following manner, please refer to fig. 5 in combination:

and step S1031, configuring the fixed IP required by the pod to be created into the environment variable of the pod.

Step S1032, obtains deployment policy information based on the determined first target node configuration.

Step S1033, generating the pod to be created according to the environment variable, and deploying the pod obtained by the creation to the first target node based on the deployment policy information.

In this embodiment, after the interception pod is created, the admission control module may inject relevant information, such as the type information of the required fixed IP and pod, into the environment variable. And monitoring the creation of the pod on the node to which the pod belongs through the node control module of each node, deploying the created pod to the corresponding first target node based on the deployment strategy information by the controller, and monitoring the deployment action of the pod by the node control module of the first target node to complete the actions such as the binding of the fixed IP and the like so as to complete the deployment of the pod to be created. And, the node control module can also maintain the state of the fixed IP bound on the node.

In implementation, a node may fail, or resources of the node are insufficient, and in such a case, migration of the pod needs to be performed to migrate the pod to a normal node to continue providing services. In view of this, referring to fig. 6, the method provided in this embodiment may further include the following steps:

step S201, in a case of obtaining a scheduling instruction, obtaining a pod to be scheduled and a second target node to be scheduled, which are pointed by the scheduling instruction.

Step S202, obtaining the fixed IP bound by the pod to be scheduled.

Step S203, the pod to be scheduled, to which the fixed IP is bound, is scheduled to the second target node.

Step S204, the fixed IP bound by the pod to be scheduled is bound on the network card of the second target node.

In this embodiment, if a node is down, or resources on the node are insufficient, such as insufficient processing resources and insufficient storage resources, at this time, at least some of the nodes deployed on the node need to be migrated to other nodes capable of working normally, or nodes with sufficient storage resources and sufficient processing resources. Thereby ensuring that the pod and the container bearing the software program can work normally.

The scheduling instruction is generated under the condition that the scheduling instruction occurs, and the scheduling instruction comprises the pod to be scheduled which needs to be scheduled and the second target node to which the scheduling needs to be scheduled. The pod to be scheduled is a pod deployed on a node with a downtime situation or a node with insufficient node resources. In addition, the node with the lower resource occupancy rate can be determined as the second target node by acquiring the occupancy of each node in the cluster, for example, the occupancy of the processing resource and the storage resource of each node.

And the pod to be scheduled is a pod which is created and deployed in the node, and the pod to be scheduled is bound with a fixed IP. If the pod to be scheduled is created and deployed, through the detection of whether the IP conflicts exist, other nodes in the current cluster except the node where the pod to be scheduled is located do not use the fixed IP of the pod to be scheduled.

After the pod to be scheduled is scheduled to the second target node, the fixed IP bound to the pod to be scheduled needs to be bound to the network card of the second target node. The network card of a single node is bound with a plurality of fixed IPs, and the pods with the same fixed IP are required to be deployed on the same node.

Therefore, in this embodiment, the pod to be scheduled may be one pod or a plurality of pods. For example, when multiple pods collectively bind the same fixed IP, then the scheduling operation should be directed to the multiple pods, and the multiple pods bound the same fixed IP are scheduled onto the same node.

Therefore, when a certain node in the cluster is monitored to be down or insufficient in resources, the pod deployed on the node and the fixed IP bound by each deployed pod are obtained. And determining whether there are pods bound with the same fixed IP, and if there are a plurality of pods bound with the same fixed IP, taking the plurality of pods as pods to be scheduled. And dispatching the plurality of pods to be dispatched to the same second target node. Thus, the problem that the pod binding the same fixed IP is positioned on different nodes and IP conflict exists after scheduling can be avoided.

And after the pod to be scheduled is scheduled to the second target node, executing a fixed IP binding action of the network card of the second target node, wherein the fixed IP bound by the pod to be scheduled does not change when the pod to be scheduled is scheduled to the second target node.

In this embodiment, because the pod supports binding the fixed IP, the fixed IP is not affected by the host IP of the node where the pod is located, and when the node is down or the resources are insufficient, the controller can also work normally in scheduling the pod, and can migrate the pod to a normal node to continue providing services, and the bound fixed IP also migrates along with the pod, thereby realizing high availability of the services.

In this embodiment, the node control module on each node may monitor pod creation, migration, and the like on the node. For example, for a node where a pod to be scheduled is located before scheduling, when the pod to be scheduled is scheduled successfully, the fixed IP of the pod to be scheduled, which is bound to the network card of the node where the pod to be scheduled is located before scheduling, is removed.

In addition, in this embodiment, a node control module on a node may also be used to monitor a deletion condition of a pod on the node, and accordingly, referring to fig. 7, the method provided in this embodiment further includes the following steps:

step S301, in a case that a deletion instruction is obtained, obtaining a pod to be deleted, which is pointed by the deletion instruction.

Step S302, obtaining the fixed IP of the pod to be deleted, which is bound on the network card of the node where the pod to be deleted is located.

Step S303, deleting the pod to be deleted from the node, and deleting the fixed IP of the pod to be deleted on the network card.

The lifecycle of a pod in Kubernetes is short-lived, and when a pod fails or ends its lifecycle, it is necessary to replace the failed pod with a new pod. In this case, a delete instruction may be generated, where the pod pointed to by the delete instruction is the pod to be deleted, and the pod to be deleted may be one pod or multiple pods.

And after the pod to be deleted is deleted from the node, whether the fixed IP bound on the network card is deleted needs to be judged.

As can be seen from the above, one fixed IP can be bound by multiple pods, or can be bound by a single pod. When multiple pods bind the same fixed IP, they are on the same node. Therefore, when determining whether to delete the fixed IP bound to the network card, it may be detected whether there are other pods bound to the same fixed IP as the pod to be deleted on the node where the pod to be deleted is located, and if not, the fixed IP of the pod to be deleted on the network card is deleted.

In addition, if other pots bound with the same fixed IP with the pot to be deleted also exist on the node where the pot to be deleted is located, the fixed IP of the pot to be deleted on the network card is not deleted.

For example, pod-0 to pod-3 are deployed on node1, where pod-0, pod-1, and pod-2 are bound to the same fixed IP, and pod-3 is bound to another fixed IP.

If the pod to be deleted pointed by the delete instruction is single, for example, the pod to be deleted is pod-0, the node1 also has a pod bound with the same fixed IP as the pod to be deleted, including pod-1 and pod-2. In this case, the fixed IP of the pod-0 bound to the network card of the node1 is not deleted.

In another situation, if the to-be-deleted pod pointed by the delete instruction is a single pod, but the to-be-deleted pod is pod-3, the node1 has pod-0 to pod-2 in addition to the pod-3, and the fixed IP bound to the pod-0 to pod-2 is different from the fixed IP bound to the pod-3, that is, the node1 does not have other pods bound to the same fixed IP as the to-be-deleted pod. In this case, the fixed IP of the pod-3 bound to the network card of the node1 is deleted.

In another case, if the number of the to-be-deleted pod pointed by the delete instruction is multiple, for example, the to-be-deleted pod includes pod-0, pod-1, and pod-2, and the three pods are bound with the same fixed IP. Pod3 on node1 has a different fixed IP bound to the three pods. That is, node1 does not have other pod bound with the same fixed IP as the pod to be deleted. In this case, the fixed IPs of pod-0 to pod-2 bound to the network card of node1 are deleted.

In this embodiment, the pod is deleted under the delete instruction by monitoring the lifecycle and the failure condition of the pod as described above. And correspondingly determining whether to delete the fixed IP bound on the network card according to the fixed IP binding conditions of the pod to be deleted and other pods on the node. Situations where bound IP exceptions occur can be avoided.

In an implementation manner, the overall flow of the method for implementing pod fixed IP provided by this embodiment may be as shown in fig. 8, and specifically may include the following steps:

step S401, acquiring a fixed IP required by a pod to be created in the creation request;

step S402, detecting whether the fixed IP required by the pod to be created is used by any node in the cluster;

when the fixed IP required for the pod to be created is not used by any node in the cluster, step S403 is performed:

step S403, acquiring node information contained in the creation request as a first target node;

when the fixed IP required for the pod to be created is used by the nodes in the cluster, step S404 is performed:

step S404, judging whether the fixed IP is an exclusive IP;

when the fixed IP is the exclusive IP, step S405 is executed;

step S405, prompting the binding abnormal information and exiting the binding process;

when the fixed IP is not the exclusive IP, step S406 is executed:

step S406, using a node of a fixed IP which is not an exclusive IP as a first target node;

step S407, configuring the fixed IP required by the pod to be created into the environment variable of the pod;

step S408, obtaining deployment strategy information based on the first target node configuration;

step S409, generating a pod to be created according to the environment variable, and deploying the pod obtained through creation to a first target node based on deployment strategy information;

step S410, a fixed IP required by the deployed pod is bound on the network card of the first target node.

After the above steps are performed, the binding process may be ended. On this basis, if the scheduling instruction is acquired, step S411 to step S414 may be executed:

step S411, under the condition of obtaining the scheduling instruction, obtaining a pod to be scheduled and a second target node to be scheduled, which are pointed by the scheduling instruction;

step S412, obtaining a fixed IP bound by the pod to be scheduled;

step S413, dispatching the pod to be dispatched, bound with the fixed IP, to a second target node;

step S414, the fixed IP bound by the pod to be scheduled is bound on the network card of the second target node.

After the scheduling step is completed, the scheduling process can be ended and quit.

Furthermore, after the pod is deployed on the node, if the delete instruction is acquired, step S415 to step S420 may be executed.

Step S415, in a case that the delete instruction is obtained, obtaining a pod to be deleted, which is pointed by the delete instruction;

step S416, obtaining a fixed IP of the pod to be deleted, which is bound on the network card of the node where the pod to be deleted is located;

step S417, deleting the pod to be deleted from the node;

step S418, detecting whether other pod bound with the same fixed IP with the pod to be deleted exists on the node where the pod to be deleted is located;

in the case that there is no other pod bound with the same fixed IP as the pod to be deleted on the node where the pod to be deleted is located, step S419 is executed:

step S419, deleting the fixed IP of the pod to be deleted on the network card;

if there are other pods bound with the same fixed IP as the pod to be deleted on the node where the pod to be deleted is located, then step S420 is executed;

step S420, the fixed IP of the pod to be deleted on the network card is not deleted.

According to the method for realizing the pod fixed IP, the pod can support the binding of the fixed IP and is not lost along with the reconstruction or deletion of the pod. A single fixed IP may be bound for use by multiple pods deployed on the same node or may be exclusive to a pod. When the node is down, the controller can schedule the pod, the pod can be migrated to a normal node to continue providing services, and the fixed IP can also be migrated along with the pod, so that high availability of the services is realized.

In addition, in this embodiment, the label mode is adopted to implement the IP of the pod in the fixed controller, and the configuration is simple and friendly to the upper layer service.

Referring to fig. 9, a block diagram of an electronic device according to an embodiment of the present disclosure is provided, where the electronic device may be the controller, that is, any node described above. The controller may be a laptop, desktop, cell phone, tablet, server, etc., where the server may be a virtual machine or a physical machine.

As shown in fig. 9, the electronic device may include a processor, a memory, an interface device, a communication device, a display device, an input device, a speaker, a microphone, and the like. The processor may be a central processing unit CPU, a microprocessor MCU, or the like. The memory includes, for example, a ROM (read only memory), a RAM (random access memory), a nonvolatile memory such as a hard disk, and the like. The interface device includes, for example, a USB interface, a headphone interface, and the like.

The communication means is capable of wired or wireless communication, for example, and may specifically include Wifi communication, bluetooth communication, 2G/3G/4G/5G communication, and the like. The display device is, for example, a liquid crystal display panel, a touch panel, or the like. The input means may include, for example, a touch screen, a keyboard, a somatosensory input, and the like. A user can input/output voice information through the speaker and the microphone.

The electronic device shown in fig. 9 is merely illustrative and is in no way intended to limit the present application, its applications, or uses. In an embodiment of the present application, the memory of the electronic device is configured to store instructions for controlling the processor to operate to perform any one of the method steps provided by the embodiment of the present application.

It will be appreciated by those skilled in the art that although a plurality of means are shown for the electronic device in fig. 9, the present application may relate to only some of the means therein, for example, the electronic device may relate to only a processor and a memory means. The skilled person can design the instructions according to the solution disclosed in the present application. How the instructions control the operation of the processor is well known in the art and will not be described in detail herein.

Referring to fig. 10, an apparatus 10 for implementing a pod fixed IP is further provided in the embodiment of the present application, where the apparatus includes an obtaining module 101, a determining module 102, a deploying module 103, and a binding module 104.

An obtaining module 101, configured to obtain a fixed IP required by a pod to be created in the creation request.

It is understood that the obtaining module 101 may be configured to perform the step S101, and for a detailed implementation of the obtaining module 101, reference may be made to the content related to the step S101.

A determining module 102, configured to determine a first target node corresponding to the pod to be created in the cluster, where the first target node has a host IP address of the first target node.

It is understood that the determining module 102 can be used to execute the step S102, and the detailed implementation of the determining module 102 can refer to the content related to the step S102.

A deployment module 103, configured to create the pod to be created, so as to deploy the created pod to the first target node.

It is understood that the deployment module 103 may be configured to perform the step S103, and for the detailed implementation of the deployment module 103, reference may be made to the content related to the step S103.

A binding module 104, configured to bind, on the network card of the first target node, a fixed IP required by the deployed pod, so that the deployed pod uses the fixed IP to start a service for external access.

It is understood that the binding module 104 can be used to perform the step S104, and the detailed implementation of the binding module 104 can refer to the content related to the step S104.

In a possible implementation manner, the apparatus further includes a scheduling module, and the scheduling module may be configured to:

obtaining a fixed IP bound by the pod to be scheduled;

In one possible implementation, the scheduling module may be further configured to:

In a possible implementation manner, the determining module 102 may specifically be configured to:

and if the fixed IP is used by the nodes in the cluster, using the nodes using the fixed IP as a first target node.

In one possible implementation manner, the apparatus further includes a deletion module, and the deletion module may be configured to:

In a possible implementation manner, the deleting module may specifically be configured to:

and if not, deleting the fixed IP of the pod to be deleted on the network card.

In a possible implementation manner, the deployment module 103 may specifically be configured to:

The description of the processing flow of each module in the device and the interaction flow between the modules may refer to the related description in the above method embodiments, and will not be described in detail here.

Further, an embodiment of the present application also discloses a computer-readable storage medium for storing a computer program, wherein the computer program, when executed by a processor, implements the method for implementing pod fixed IP disclosed in any of the foregoing embodiments.

In summary, the method, the apparatus, the electronic device, and the readable storage medium for implementing a pod fixed IP provided in the embodiments of the present application determine a first target node corresponding to a pod to be created in a cluster by obtaining a fixed IP required by the pod to be created in a creation request, where the first target node has a host IP address of the first target node. And creating the pod to be created so as to deploy the created pod to the first target node, binding a fixed IP required by the deployed pod on a network card of the first target node, and enabling the deployed pod to use the fixed IP to start service for external access.

In the scheme, the pod is deployed to the first target node by performing fixed IP binding on the pod, and the fixed IP is bound on the network card of the first target node, so that the deployed pod can use the fixed IP to start the service for external access. And the fixed IP of the pod is not affected by the host IP of the node where the pod is located, and the fixed IP bound by the pod can not be affected during subsequent reconstruction or migration, so that the abnormal phenomenon caused by IP change in the prior art can be avoided.

The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any changes or substitutions that can be easily conceived by those skilled in the art within the technical scope of the present application should be covered within the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A method for realizing pod fixed IP, which is applied to a controller in a Kubernets cluster, wherein the Kubernets cluster further comprises a plurality of nodes, and the method comprises the following steps:

acquiring a fixed IP required by a pod to be created in the creation request;

2. The method of implementing pod fixed IP as claimed in claim 1, further comprising:

obtaining a fixed IP bound by the pod to be scheduled;

3. The method of implementing pod fixed IP as claimed in claim 2, further comprising:

4. The method of claim 1, wherein the step of determining the first target node corresponding to the pod to be created in the cluster comprises:

5. The method of claim 4, wherein if the fixed IP is used by the nodes in the cluster, the step of using the node using the fixed IP as the first target node comprises:

6. The method of implementing pod fixed IP as claimed in claim 1, further comprising:

7. The method for realizing pod fixed IP according to claim 6, wherein the step of deleting the fixed IP of the pod to be deleted on the network card comprises:

and if not, deleting the fixed IP of the pod to be deleted on the network card.

8. The method of claim 1, wherein the step of creating the pod to be created and deploying the created pod to the first target node comprises:

9. An apparatus for implementing pod fixed IP, applied to a controller in a kubernets cluster, wherein the kubernets cluster further includes a plurality of nodes, and the apparatus:

10. An electronic device comprising a memory for storing computer instructions and a processor for retrieving the computer instructions from the memory to perform the method of any one of claims 1-8.

11. A computer-readable storage medium, wherein the storage medium stores computer instructions, which when executed by a processor, implement the method of any one of claims 1-8.