CN115150268A

CN115150268A - Network configuration method and device of Kubernetes cluster and electronic equipment

Info

Publication number: CN115150268A
Application number: CN202210883984.7A
Authority: CN
Inventors: 陈南飞; 王旸; 蒋驰
Original assignee: Mingyang Industrial Technology Research Institute Shenyang Co ltd
Current assignee: Mingyang Industrial Technology Research Institute Shenyang Co ltd
Priority date: 2022-07-26
Filing date: 2022-07-26
Publication date: 2022-10-04

Abstract

The present application relates to the field of computer technologies, and in particular, to a network configuration method and apparatus for a Kubernetes cluster, and an electronic device. The method comprises the following steps: acquiring a static IP name recorded in the metadata document of the Pod to be configured; accessing a database of the Kubernetes cluster, and acquiring a target static IP resource corresponding to the static IP name, wherein the target static IP resource comprises a target static IP parameter; acquiring at least one SR-IOV-based VF list of the Pod host server to be configured, and selecting a target VF from each VF list; creating a target virtual interface corresponding to the target VF in a network namespace corresponding to the Pod to be configured; and configuring the target virtual interface and the target VF according to the target static IP parameters so as to complete the network configuration of the Pod to be configured. The technical scheme provided by the application can set the static IP for the Pod in the Kubernets cluster.

Description

Network configuration method and device of Kubernetes cluster and electronic equipment

Technical Field

The present application relates to the field of computer technologies, and in particular, to a network configuration method and apparatus for a Kubernetes cluster, and an electronic device.

Background

When migrating a traditional application program to a kubernets cluster, it should be ensured as much as possible that the application program started through Pod and the traditional application program have the same network operating environment, for example, static IP addresses and ports are used for communication with each other, so as to solve the problem of higher migration cost caused by the modification of the traditional application program.

Based on this, those skilled in the art urgently need a network configuration method of a kubernets cluster to set a static IP for a Pod in the kubernets cluster.

Disclosure of Invention

Embodiments of the present application provide a network configuration method and apparatus for a kubernets cluster, and an electronic device, so that a static IP can be set for Pod in the kubernets cluster to at least some extent.

Other features and advantages of the present application will be apparent from the following detailed description, or may be learned by practice of the application.

According to an aspect of an embodiment of the present application, there is provided a network configuration method of a kubernets cluster, where the method includes: acquiring a static IP name recorded in the metadata document of the Pod to be configured; accessing a database of the Kubernetes cluster, and acquiring a target static IP resource corresponding to the static IP name, wherein the target static IP resource comprises a target static IP parameter; acquiring at least one SR-IOV-based VF list of the Pod host server to be configured, and selecting a target VF from each VF list; creating a target virtual interface corresponding to the target VF in a network namespace corresponding to the Pod to be configured; and configuring the target virtual interface according to the target static IP parameters so as to complete the network configuration of the Pod to be configured.

In some embodiments of the application, prior to accessing the database of the kubernets cluster, the method further comprises: creating at least one static IP resource, wherein each static IP resource corresponds to a static IP name; and writing each static IP resource into a database of the Kubernets cluster.

In some embodiments of the present application, before obtaining at least one SR-IOV-based VF list of the Pod hosting server to be configured, the method further includes: adding an SR-IOV management module in the Kubernetes cluster; creating at least one VF on each hosting server through the SR-IOV management module; and registering the identification information corresponding to each VF to the Kubernets cluster through the SR-IOV management module.

In some embodiments of the present application, the obtaining of at least one SR-IOV-based VF list of the Pod hosting server to be configured includes: identifying at least one network interface of the Pod hosting server to be configured; and obtaining a VF list based on SR-IOV corresponding to each network interface.

In some embodiments of the present application, the selecting a target VF from the respective VF lists includes: and selecting the target VF from each VF list according to the VF number of each VF list.

In some embodiments of the present application, the creating a target virtual interface corresponding to the target VF in the network namespace corresponding to the Pod to be configured includes: and creating a blank virtual interface in the network namespace corresponding to the Pod to be configured, connecting the blank virtual interface to the target VF, and taking the blank virtual interface as a target virtual interface.

In some embodiments of the present application, the configuring the target virtual interface and the target VF according to the target static IP parameters includes: configuring an IP address and a gateway of the target virtual interface according to the target static IP parameters; and configuring the virtual local area network name of the target VF according to the target static IP parameter.

In some embodiments of the present application, after configuring the target virtual interface according to the target static IP parameters, the method further comprises: marking the target VF as an allocated state; and marking the target static IP resource in a bound state.

According to an aspect of the present application, there is provided a kubernets cluster network configuration apparatus, the apparatus comprising: a first obtaining unit, configured to obtain a static IP name recorded in a metadata document of the Pod to be configured; the access unit is used for accessing a database of the Kubernetes cluster and acquiring a target static IP resource corresponding to the static IP name, wherein the target static IP resource comprises a target static IP parameter; a second obtaining unit, configured to obtain at least one SR-IOV-based VF list of the Pod host server to be configured, and select a target VF from each VF list; a creating unit, configured to create a target virtual interface corresponding to the target VF in the network namespace corresponding to the Pod to be configured; and the configuration unit is used for configuring the target virtual interface and the target VF according to the target static IP parameters so as to complete the network configuration of the Pod to be configured.

According to an aspect of the present application, there is provided an electronic device comprising one or more processors and one or more memories having stored therein at least one program code, which is loaded into and executed by the one or more processors to perform the operations performed by the kubernets clustered network configuration method as described.

Based on the scheme, the application has at least the following advantages or progresses:

in the technical solutions provided in some embodiments of the present application, static IP parameters are introduced into a kubernets cluster through a preloaded static IP resource, and then an independent network connection interface is provided for each Pod through a VF created in advance, so that a Pod with a static IP setting requirement can successfully configure a static IP, thereby ensuring that an application program started through the Pod has the same network operating environment as a conventional application program, and improving the use experience of a user of the kubernets cluster.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and together with the description, serve to explain the principles of the application.

It is obvious that the drawings in the following description are only some embodiments of the application, and that for a person skilled in the art, other drawings can be derived from them without inventive effort.

In the drawings:

fig. 1 shows a flow chart of a method of network configuration of a kubernets cluster according to an embodiment of the present application;

fig. 2 shows a flow chart of a method of network configuration of a kubernets cluster according to an embodiment of the present application;

FIG. 3 illustrates a flow diagram of a method of network configuration for a Kubernets cluster according to one embodiment of the present application;

FIG. 4 shows a schematic diagram of a network configuration in an embodiment in accordance with the present application;

FIG. 5 illustrates a schematic diagram of a Kubernets cluster network configuration apparatus according to an embodiment of the present application;

FIG. 6 illustrates a schematic structural diagram of a computer system suitable for use to implement the electronic device of the embodiments of the present application.

Detailed Description

Example embodiments will now be described more fully with reference to the accompanying drawings. Example embodiments may, however, be embodied in many different forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of example embodiments to those skilled in the art.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the application. One skilled in the relevant art will recognize, however, that the subject matter of the present application can be practiced without one or more of the specific details, or with other methods, components, devices, steps, and so forth. In other instances, well-known methods, devices, implementations, or operations have not been shown or described in detail to avoid obscuring aspects of the application.

The block diagrams shown in the figures are functional entities only and do not necessarily correspond to physically separate entities. I.e. these functional entities may be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor means and/or microcontroller means.

The flow charts shown in the drawings are merely illustrative and do not necessarily include all of the contents and operations/steps, nor do they necessarily have to be performed in the order described. For example, some operations/steps may be decomposed, and some operations/steps may be combined or partially combined, so that the actual execution sequence may be changed according to the actual situation.

It should be noted that: reference herein to "a plurality" means two or more. "and/or" describe the association relationship of the associated objects, meaning that there may be three relationships, e.g., A and/or B may mean: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship.

It should be noted that the embodiments proposed in the present application can be used in a cloud scenario, such as cloud computing, which is a computing mode that distributes computing tasks over a resource pool formed by a large number of computers, so that various application systems can obtain computing power, storage space, and information services as needed. The network that provides the resources is referred to as the "cloud". Resources in the cloud can be infinitely expanded to users, and can be acquired at any time, used as required and expanded at any time. The cloud computing resource pool mainly comprises computing equipment (which is a virtualization machine and comprises an operating system), storage equipment and network equipment.

It should be noted that the present application has technical content related to SR-IOV, single root I/O virtualization, which is an extension of PCI Express (PCIe). SR-IOV allows a device (e.g., a network adapter) to separate access to its resources among various PCIe hardware functions. These functions include one or more PCIe Virtual Functions (VFs). SR-IOV enables network traffic to bypass the software switch layer of the Hyper-V virtualization stack. Since VFs are assigned to sub-partitions, network traffic flows directly between VFs and sub-partitions. Thus, the I/O overhead in the software emulation layer is reduced and nearly the same network performance is achieved as in a non-virtualized environment. In the present application, a child partition may be a Pod that needs to configure a static IP.

The implementation details of the technical solution of the embodiment of the present application are set forth in detail below:

please refer to fig. 1.

Fig. 1 shows a flowchart of a network configuration method of a kubernets cluster according to an embodiment of the present application, and as shown in fig. 1, the method may include steps S101 to S105:

step S101, obtaining the static IP name recorded in the metadata document of the Pod to be configured.

Step S102, accessing a database of the Kubernetes cluster, and acquiring a target static IP resource corresponding to the static IP name, wherein the target static IP resource comprises a target static IP parameter.

Step S103, at least one VF list based on SR-IOV of the Pod host server to be configured is obtained, and a target VF is selected from each VF list.

Step S104, a target virtual interface corresponding to the target VF is established in the network namespace corresponding to the Pod to be configured.

Step S105, configuring the target virtual interface and the target VF according to the target static IP parameter, so as to complete network configuration of the Pod to be configured.

In the application, static IP parameters are introduced into a Kubernets cluster through preloaded static IP resources, and then independent network connection interfaces are provided for all the pods through the pre-established VF, so that the pods with the static IP setting requirements can be successfully configured with the static IP, an application program started through the pods and a traditional application program have the same network operation environment, and the use experience of a Kubernets cluster user is improved.

In this application, before accessing the database of the kubernets cluster, at least one static IP resource may be created, where each static IP resource corresponds to a static IP name, and then each static IP resource is written into the database of the kubernets cluster.

For example, a new CRD (custom resource definition) resource staticippaddress, i.e. the static IP resource, can be added to the kubernets cluster, which can be used to represent a static IP address for defining network type, VLAN ID, IP address, mask length, gateway, etc. The following example describes a static IP resource that can be used to create a static IP resource with a network type of sriov, VLAN ID of 100, IP address of 10.89.10.1, mask length of 24, gateway of 10.89.10.254, and static IP name of IP-01.

In the present application, if a static IP address needs to be set for a Pod, a corresponding static IP name may be set in yaml for creating the Pod.

For example, if a static IP address is to be set for a Pod and set as the static IP address in the above example, a key value pair of "network, mingyangtech, com, cn/static-IP: IP-01" must be specified in metadata.

Please refer to fig. 2.

Fig. 2 is a flowchart illustrating a network configuration method of a kubernets cluster according to an embodiment of the present application, and as shown in fig. 2, before acquiring at least one SR-IOV-based VF list of the Pod hosting server to be configured, the method may include steps S201 to S203:

step S201, adding an SR-IOV management module in the Kubernets cluster.

Step S202, at least one VF is created on each host server through the SR-IOV management module.

Step S203, registering the identification information corresponding to each VF to the kubernets cluster through the SR-IOV management module.

In the application, in order to provide static IP settings for different pods, an SR-IOV management module may be introduced to provide VFs for the pods, so that each Pod may connect to a network through its own VF, and successfully set a static IP, thereby reducing the problem of incapability of operating due to network change.

In this application, an SR-IOV management module may be added to the Kubernets cluster. The SR-IOV management module is operated by a Kubernets cluster Master node, and the main functions of the module are as follows:

(1) The SR-IOV management module may be responsible for creating VFs (Virtual functions) on all Master and Worker nodes of the Kubernetes cluster: first, the SR-IOV management module can identify all physical network cards supporting SR-IOV (except the management network card for Kubernets cluster management) on the physical server, and for each physical network card supporting SR-IOV, the SR-IOV management module is responsible for creating VF for the physical network card. At present, network cards produced by a plurality of manufacturers support SR-IOV, such as Intel 82599, X700 series network cards and the like, mellanox ConnectX-5, connectX-6 series network cards and the like. The VF creation modes of the network cards produced by different manufacturers are different, and the number of supported VFs may be different.

For example, taking an Intel 82599 network card as an example, how to create a VF on a CentOS 7 operating system is illustrated, and a network interface for creating the VF is denoted as ens1.

(1) When the command "echo 64>/sys/class/net/ens1/device/sriov _ numvfs" is executed, 64 VFs are created on the network interface ens1, and the numbers of the VFs are 0, 1, 2, 3,. And 63 in sequence.

(2) This command is added to the end of the/etc/profile file, ensuring that the server recreates the VF after restart.

Through the SR-IOV management module, a plurality of VFs can be created on each host server, and interface support is provided for the static IP access of the subsequent Pod.

(2) The SR-IOV management module may be responsible for registering VFs created on Master and Worker nodes, that is, the host server described in the present application, to a kubernets cluster. At registration time, for each Master (or Worker) node, the following information needs to be provided.

(1) Home server IP address, such as "10.89.1.10".

(2) The VF list, each entry in the list containing: interface names of network interfaces, such as ens1; VF numbering is configured in a format of "< SingleVF >, < FirstVF > - < LastVF >, < SingleVF >, < FirstVF > - < LastVF >", singleVF indicates a single VF number, firstVF indicates a first VF number of VF number intervals, and LastVF indicates a last VF number of VF number intervals, such as "0-2,4,6,9,13-20".

Please refer to fig. 3.

Fig. 3 is a flowchart illustrating a network configuration method of a kubernets cluster according to an embodiment of the present application, and as shown in fig. 3, the method for acquiring at least one SR-IOV-based VF list of a Pod hosting server to be configured may include steps S301 to S302:

step S301, identifying at least one network interface of the Pod hosting server to be configured.

Step S302, obtaining a VF list based on SR-IOV corresponding to each network interface.

In the present application, the network interfaces of the servers may be identified on the Master and the Worker node, that is, the host server described in the present application, and a VF (Virtual Function) may be created according to the configuration of each network interface, so as to form a VF list based on SR-IOV.

For example, taking an Intel 82599 network card as an example, how to create the VF on the CentOS 7 operating system is illustrated, and the network interface for creating the VF is denoted as ens1: when the command "echo 64>/sys/class/net/ens1/device/sriov _ numvfs" is executed, 64 VFs are created on the network interface ens1, and the numbers of the VFs are 0, 1, 2, 3,. And 63 in sequence.

In this application, the method for selecting a target VF from each VF list may include: according to the VF number of each VF list, selecting a target VF from each VF list:

(1) The network interface with the largest number of remaining usable VFs in the VF list may be selected, and one of the usable VFs may be randomly chosen from. (2) If a plurality of network interfaces exist and the number of the remaining available VFs in the VF list is the largest and equal, selecting the network interface with the largest VF number from the network interfaces, and then randomly selecting one available VF from the network interfaces; (3) If there are multiple network interfaces, and the remaining available VFs in the VF lists are the most and equal, and the VF numbers are also equal, then randomly choose one network interface from them, and then randomly choose one available VF from them.

For example, four network interfaces of ens0, ens1, ens2, and ens3 are configured in the server where the Worker1 node is located, and there are four VF lists correspondingly, where the VF list of ens0 has 4 available VFs, the VF list of ens1 has 8 available VFs, the VF list of ens2 has 16 available VFs, and the VF list of ens3 has 32 available VFs, so that one VF in the VF list of ens3 may be randomly selected as the static IP setting VF of the Pod to be configured.

In this application, the method for creating the target virtual interface corresponding to the target VF in the network namespace corresponding to the Pod to be configured may include: and creating a blank virtual interface in the network namespace corresponding to the Pod to be configured, connecting the blank virtual interface to the target VF, and taking the blank virtual interface as the target virtual interface.

In this application, the method for configuring the target virtual interface according to the target static IP parameter may include: and configuring the IP address and the gateway of the target virtual interface according to the target static IP parameters, and then configuring the virtual local area network name of the target VF according to the target static IP parameters.

In this application, after configuring the target virtual interface according to the target static IP parameter, the method may further include: marking the target VF as an allocated state; and marking the target static IP resource in a bound state.

In order that those skilled in the art may more fully understand the present application, reference will now be made to a full embodiment.

Please refer to fig. 4.

Fig. 4 shows a schematic diagram of a network configuration in an embodiment according to the present application. In FIG. 4, for a Kubernets cluster 400, a static IP resource may be added, and the static IP resource IP-01 may be as follows: the network type is sriov, the VLAN ID is 100, the IP address is 10.89.10.1, the mask length is 24, the gateway is 10.89.10.254, and the static IP name is IP-01.

In writing the yacl metadata document for Pod1, the key-value pair "network, mingyangtech, com, cn/static-IP: IP-01" will be specified in metadata.

And adding a static IP management module, monitoring Pod creation and deletion events in the Kubernetes cluster through the static IP management module, sensing the creation and deletion of the Pod in the cluster, allocating a VF (variable frequency) for the Pod when the Pod is created and setting a static IP address according to the configuration of the static IP address in the Pod, and recovering the allocated VF and the static IP address when the Pod is deleted.

The static IP management module checks whether the key "network.

If the key is not included, the Pod does not have the requirement of setting the static IP address, and the processing is finished.

The value of the key "network, mingyangtech, com, cn/static-ip", i.e., ip-01", is obtained from Pod1 metadata.

A database in the kubernets cluster is looked up for the presence of a static IP resource named "IP-01". If there is no such static IP resource, the process ends.

It is checked whether the static IP resource IP-01 has bound Pod. If the object has bound Pod, the process ends.

And acquiring a host server Worker1 of the Pod1, and then acquiring an available VF list on the host server Worker1 according to the IP address of the host server Worker 1. The host server Worker1 may be configured with four network interfaces of ens0, ens1, ens2, and ens3, where the VF list of ens0 has 4 available VFs, the VF list of ens1 has 5 available VFs, the VF list of ens2 has 3 available VFs, and the VF list of ens3 has 1 available VF, so that VF1 may be randomly selected from the 5 available VFs in the VF list of ens1 and allocated to Pod1 for use.

Next, a blank virtual interface is created in a network namespace allocated to the Pod by the host server Worker1, the blank virtual interface is connected to the VF1, and the blank virtual interface is used as a target virtual interface. And configures the IP address to be 10.89.10.1/24 and the gateway to be 10.89.10.254 for the target virtual interface, and sets the VLAN ID of VF1, i.e. the virtual local area network name, to be 100.

And finally, marking the VF1 as an allocated state, marking the static IP resource IP-01 as a bound state, finishing the creation of the Pod1 and finishing the static IP setting aiming at the Pod 1.

An apparatus embodiment of the present application will be described with reference to the accompanying drawings.

Please refer to fig. 5.

Fig. 5 shows a schematic diagram of a kubernets cluster network configuration apparatus according to an embodiment of the present application, and the apparatus 500 may include: a first acquisition unit 501, an access unit 502, a second acquisition unit 503, a creation unit 504, and a configuration unit 505.

The specific configuration of the kubernets cluster network configuration device may be: a first obtaining unit 501, configured to obtain a static IP name recorded in a metadata document of the Pod to be configured; an accessing unit 502, configured to access a database of the kubernets cluster, to obtain a target static IP resource corresponding to the static IP name, where the target static IP resource includes a target static IP parameter; a second obtaining unit 503, configured to obtain at least one SR-IOV-based VF list of the Pod hosting server to be configured, and select a target VF from each VF list; a creating unit 504, configured to create a target virtual interface corresponding to the target VF in the network namespace corresponding to the Pod to be configured; a configuring unit 505, configured to configure the target virtual interface and the target VF according to the target static IP parameter, so as to complete network configuration of the Pod to be configured.

Please refer to fig. 6.

FIG. 6 illustrates a schematic structural diagram of a computer system suitable for use in implementing the electronic device of an embodiment of the present application.

It should be noted that the computer system 600 of the electronic device shown in fig. 6 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present application.

As shown in fig. 6, the computer system 600 includes a Central Processing Unit (CPU) 601, which can perform various appropriate actions and processes, such as executing the methods described in the above embodiments, according to a program stored in a Read-Only Memory (ROM) 602 or a program loaded from a storage portion 608 into a Random Access Memory (RAM) 603. In the RAM 603, various programs and data necessary for system operation are also stored. The CPU 601, ROM 602, and RAM 603 are connected to each other via a bus 604. An Input/Output (I/O) interface 605 is also connected to bus 604.

The following components are connected to the I/O interface 605: an input portion 606 including a keyboard, a mouse, and the like; an output portion 607 including a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, a speaker, and the like; a storage section 608 including a hard disk and the like; and a communication section 609 including a Network interface card such as a LAN (Local Area Network) card, a modem, or the like. The communication section 609 performs communication processing via a network such as the internet. A driver 610 is also connected to the I/O interface 605 as needed. A removable medium 611 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 610 as necessary, so that a computer program read out therefrom is mounted into the storage section 608 as necessary.

In particular, according to embodiments of the present application, the processes described above with reference to the flow diagrams may be implemented as computer software programs. For example, embodiments of the present application include a computer program product comprising a computer program embodied on a computer-readable medium, the computer program comprising program code for performing the method illustrated by the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network through the communication section 609, and/or installed from the removable medium 611. When the computer program is executed by a Central Processing Unit (CPU) 601, various functions defined in the system of the present application are executed.

It should be noted that the computer readable medium shown in the embodiments of the present application may be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a Read-Only Memory (ROM), an Erasable Programmable Read-Only Memory (EPROM), a flash Memory, an optical fiber, a portable Compact Disc Read-Only Memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present application, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In this application, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the foregoing.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. Each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units described in the embodiments of the present application may be implemented by software or hardware, and the described units may also be disposed in a processor. Wherein the names of the elements do not in some way constitute a limitation on the elements themselves.

As another aspect, the present application also provides a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the network configuration method of the kubernets cluster described in the above embodiments.

As another aspect, the present application also provides a computer-readable medium, which may be contained in the electronic device described in the above embodiments; or may exist separately without being assembled into the electronic device. The computer readable medium carries one or more programs, and when the one or more programs are executed by the electronic device, the electronic device is enabled to implement the network configuration method of the kubernets cluster described in the above embodiments.

It should be noted that although in the above detailed description several modules or units of the device for action execution are mentioned, such a division is not mandatory. Indeed, the features and functionality of two or more modules or units described above may be embodied in one module or unit, according to embodiments of the application. Conversely, the features and functions of one module or unit described above may be further divided into embodiments by a plurality of modules or units.

Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein may be implemented by software, or by software in combination with necessary hardware. Therefore, the technical solution according to the embodiments of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a usb disk, a removable hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which can be a personal computer, a server, a touch terminal, or a network device, etc.) to execute the method according to the embodiments of the present application.

Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains.

It will be understood that the present application is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the application is limited only by the appended claims.

Claims

1. A network configuration method of a Kubernetes cluster is characterized by comprising the following steps:

acquiring a static IP name recorded in the metadata document of the Pod to be configured;

accessing a database of the Kubernetes cluster, and acquiring a target static IP resource corresponding to the static IP name, wherein the target static IP resource comprises a target static IP parameter;

acquiring at least one SR-IOV-based VF list of the Pod host server to be configured, and selecting a target VF from each VF list;

creating a target virtual interface corresponding to the target VF in a network namespace corresponding to the Pod to be configured;

and configuring the target virtual interface and the target VF according to the target static IP parameters so as to complete the network configuration of the Pod to be configured.

2. The method of claim 1, wherein prior to accessing the database of the kubernets cluster, the method further comprises:

creating at least one static IP resource, wherein each static IP resource corresponds to a static IP name;

and writing each static IP resource into the database of the Kubernetes cluster.

3. The method of claim 1, wherein before obtaining at least one SR-IOV-based VF list of the Pod hosting server to be configured, the method further comprises:

adding an SR-IOV management module in the Kubernetes cluster;

creating at least one VF on each hosting server through the SR-IOV management module;

and registering the identification information corresponding to each VF to the Kubernets cluster through the SR-IOV management module.

4. The method of claim 1, wherein the obtaining at least one SR-IOV-based VF list of the Pod hosting server to be configured comprises:

identifying at least one network interface of the Pod hosting server to be configured;

and obtaining a VF list based on SR-IOV corresponding to each network interface.

5. The method of claim 1, wherein selecting the target VF from the respective VF lists comprises:

and selecting the target VF from each VF list according to the VF number of each VF list.

6. The method of claim 1, wherein the creating a target virtual interface corresponding to the target VF in a network namespace corresponding to the Pod to be configured comprises:

and creating a blank virtual interface in the network namespace corresponding to the Pod to be configured, connecting the blank virtual interface to the target VF, and taking the blank virtual interface as the target virtual interface.

7. The method of claim 1, wherein the configuring the target virtual interface and the target VF according to the target static IP parameters comprises:

configuring an IP address and a gateway of the target virtual interface according to the target static IP parameters;

and configuring the virtual local area network name of the target VF according to the target static IP parameter.

8. The method of claim 1, wherein after configuring the target virtual interface according to the target static IP parameters, the method further comprises:

marking the target VF as an allocated state;

and marking the target static IP resource in a bound state.

9. A kubernets cluster network configuration apparatus, the apparatus comprising:

a first obtaining unit, configured to obtain a static IP name recorded in a metadata document of the Pod to be configured;

the access unit is used for accessing a database of the Kubernetes cluster and acquiring a target static IP resource corresponding to the static IP name, wherein the target static IP resource comprises a target static IP parameter;

a second obtaining unit, configured to obtain at least one SR-IOV-based VF list of the Pod host server to be configured, and select a target VF from each VF list;

a creating unit, configured to create a target virtual interface corresponding to the target VF in a network namespace corresponding to the Pod to be configured;

and the configuration unit is configured to configure the target virtual interface and the target VF according to the target static IP parameters, so as to complete network configuration of the Pod to be configured.

10. An electronic device, comprising one or more processors and one or more memories having stored therein at least one program code, the at least one program code being loaded into and executed by the one or more processors to perform operations performed by the network configuration method for a kubernets cluster of any of claims 1 to 8.