Pod management method, equipment and media based on SR-IOV

Abstract

The present invention discloses a Pod management method, device and medium based on SR-IOV, the method comprising: in response to a Pod management instruction, obtaining a list of available virtual functions VF in a target node where a Pod to be managed is located, the list of available VFs including at least one VF; determining a network resource object of the Pod to be managed, the network resource object including a target network address of the Pod to be managed; managing the target VF in the network command space of the Pod to be managed, and updating the network address of the Pod to be managed and the target VF in the list of available VFs, the target VF being a VF in the at least one VF that supports the use of the Pod to be managed. The present invention can solve the problems of unavailable services and long delays when the existing Pod is accessed using an iptables-based Service.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a Pod management method, device and medium based on SR-IOV. Background Art

[0002] In the open source application Kubernetes, the most direct way to access the running instance Pod corresponding to the application is to directly access the container in the Pod. However, when the application corresponds to multiple Pods, how to achieve load balancing and session persistence, and how to deal with changes in the network address, also known as the Internet Protocol (IP) address, due to Pod migration are all problems. To solve the above problems, Kubernetes introduced the Service resource.

[0003] Service provides a unified access address for a group of Pods with the same functions, and supports load balancing, which can distribute requests evenly to each Pod. The underlying implementation mechanism of Service is the iptables tool, which implements traffic forwarding and load balancing based on iptables.

[0004] However, in practice, it is found that due to the defects of iptables itself, such as performance problems and expansion problems, when using the Service, there are problems such as unavailability of other services and long data forwarding delay. Therefore, it is urgent to provide a better Pod management solution. Summary of the invention

[0005] The embodiments of the present application provide a Pod management method, device and medium based on SR-IOV, thereby solving the technical problems such as service unavailability and long delay when using iptables-based Service to access Pod in the prior art.

[0006] On the one hand, the present application provides a Pod management method based on SR-IOV through an embodiment of the present application, which is applied to a master node of a Kubernetes cluster, and the method includes:

[0007] In response to the Pod management instruction, obtain a list of available virtual functions VF in the target node where the Pod to be managed is located, wherein the list of available VFs includes at least one VF, and the VF is created for the target node using SR-IOV;

[0008] Determine a network resource object of the Pod to be managed, wherein the network resource object includes a target network address of the Pod to be managed;

[0009] The target VF is managed in the network command space of the Pod to be managed, and the network address of the Pod to be managed and the target VF in the available VF list are updated, wherein the target VF is a VF in the at least one VF that supports the use of the Pod to be managed.

[0010] Optionally, the Pod management instruction is a Pod creation instruction, and before managing the target VF in the network command space of the Pod to be managed, the method further includes:

[0011] According to the VF selection algorithm, select the target VF from the at least one VF, the target VF being a VF in the network interface where the number of remaining VFs is greater than a first threshold;

[0012] The managing the target VF in the network command space of the Pod to be managed, and updating the network address of the Pod to be managed and the target VF in the available VF list includes:

[0013] In the network command space of the Pod to be managed, create a virtual interface associated with the target VF, and configure the network address of the virtual interface as the target network address;

[0014] Mark the target VF as allocated and update the available VF list;

[0015] In the network resource object, the target network address is added to a list of allocated network addresses.

[0016] Optionally, the Pod management instruction is a Pod deletion instruction, and managing the target VF in the network command space of the Pod to be managed, and updating the network address of the Pod to be managed and the target VF in the available VF list includes:

[0017] In the network command space of the Pod to be managed, delete the virtual interface associated with the target VF;

[0018] Deleting the target network address from a list of allocated network addresses in the network resource object;

[0019] The target VF is marked as unallocated, and the available VF list is updated.

[0020] Optionally, obtaining a list of available virtual functions VF in the target node where the Pod to be managed is located includes:

[0021] Get the target node where the Pod to be managed is located;

[0022] According to the network address of the target node, an available VF list in the target node is obtained.

[0023] Optionally, determining the network resource object of the Pod to be managed includes:

[0024] According to the network resource object name in the Pod field label, find out the network resource object of the Pod to be managed.

[0025] Optionally, before obtaining the available virtual function VF list in the target node where the Pod to be managed is located, the method further includes:

[0026] Select at least one network interface in the target node, and use SR-IOV to create at least one VF for each of the network interfaces, where the VF is used for data transmission of the Pod to be managed;

[0027] Generate the available VF list according to the at least one created VF;

[0028] Register the available VF list in the Kubernetes cluster.

[0029] Optionally, the available VF list includes the at least one network interface, the at least one VF, and a driver type of each of the network interfaces.

[0030] Optionally, before determining the network resource object of the Pod to be managed, the method further includes:

[0031] The network resource object is created, wherein the network resource object includes at least one of the following: network type, network prefix and mask length, network address allocation range, and a pre-configured default gateway.

[0032] On the other hand, the present application provides a Pod management device based on SR-IOV through an embodiment of the present application, which is applied to the master node of the Kubernetes cluster, and the device includes: an acquisition module, a determination module and a processing module, wherein:

[0033] The acquisition module is used to obtain, in response to the Pod management instruction, a list of available virtual functions VF in the target node where the Pod to be managed is located, wherein the available VF list includes at least one VF, and the VF is created for the target node using SR-IOV;

[0034] The determination module is used to determine the network resource object of the Pod to be managed, wherein the network resource object includes the target network address of the Pod to be managed;

[0035] The processing module is used to manage the target VF in the network command space of the Pod to be managed, and update the network address of the Pod to be managed and the target VF in the available VF list, wherein the target VF is a VF in the at least one VF that supports the use of the Pod to be managed.

[0036] For the contents not introduced or described in the embodiments of the present application, please refer to the relevant introduction in the aforementioned method embodiments, which will not be repeated here.

[0037] On the other hand, the present application provides a terminal device through an embodiment of the present application, and the terminal device includes: a processor, a memory, a communication interface and a bus; the processor, the memory and the communication interface are connected through the bus and complete communication with each other; the memory stores executable program code; the processor runs a program corresponding to the executable program code by reading the executable program code stored in the memory, so as to execute the SR-IOV-based Pod management method as described above.

[0038] On the other hand, the present application provides a computer-readable storage medium through an embodiment of the present application, wherein the computer-readable storage medium stores a program, and when the program runs on a terminal device, the SR-IOV-based Pod management method as described above is executed.

[0039] One or more technical solutions provided in the embodiments of the present application have at least the following technical effects or advantages: the present application can respond to the Pod management instruction, obtain the available virtual function VF list in the target node where the Pod to be managed is located, the available VF list includes at least one VF, and the VF is created for the target node using SR-IOV; determine the network resource object of the Pod to be managed, and the network resource object includes the target network address of the Pod to be managed; manage the target VF in the network command space of the Pod to be managed, and update the network address of the Pod to be managed and the target VF in the available VF list, and the target VF is the VF in the at least one VF that supports the use of the Pod to be managed. In the above scheme, the present application can conveniently and efficiently manage the corresponding target VF of the Pod to be managed of the target node according to the available VF list in the target node and the network resource object of the Pod, so as to use the target VF to achieve fast and efficient data transmission, thereby improving data transmission speed and efficiency. At the same time, it also solves the technical problems of service unavailability and long delay when using iptables-based Service to access Pod in the prior art. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0041] Figure 1 It is a flow chart of a Pod management method based on SR-IOV provided in an embodiment of the present application.

[0042] Figure 2 It is a structural diagram of a Pod management device based on SR-IOV provided in an embodiment of the present application.

[0043] Figure 3 It is a structural diagram of a terminal device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0044] In the process of submitting this application, the applicant found that the Service had the following problems when used:

[0045] 1. Rule matching delay problem. Each Service's VIP (virtual IP) corresponds to an iptables rule (chain). The iptables rule matching is linear, and the time complexity of rule matching is O(n), where n is the number of iptables rules. If there are many Service configurations, there will also be many iptables rules, resulting in a higher rule matching delay, which slows down the forwarding of network data packets.

[0046] 2. Rule update delay problem. The iptables rule update method is full update, not incremental update. Even if you add or delete a rule, all iptables rules will be modified as a whole.

[0047] 3. Availability issues: When a Service changes, the iptables rules are fully updated, causing the connection to be disconnected, making other services unavailable.

[0048] To solve the above problems, the embodiments of the present application provide a Pod management method, device and medium based on SR-IOV.

[0049] The technical solution of the embodiment of the present application is to solve the above technical problems, and the overall idea is as follows:

[0050] A Pod management method based on SR-IOV is applied to a master control node of a Kubernetes cluster, and the method includes:

[0051] In response to the Pod management instruction, obtain a list of available virtual functions VF in the target node where the Pod to be managed is located, wherein the list of available VFs includes at least one VF, and the VF is created for the target node using SR-IOV;

[0052] Determine a network resource object of the Pod to be managed, wherein the network resource object includes a target network address of the Pod to be managed;

[0053] The target VF is managed in the network command space of the Pod to be managed, and the network address of the Pod to be managed and the target VF in the available VF list are updated, wherein the target VF is a VF in the at least one VF that supports the use of the Pod to be managed.

[0054] In order to better understand the above technical solution, the above technical solution will be described in detail below in conjunction with the accompanying drawings and specific implementation methods.

[0055] First of all, the term "and / or" in this article is only a description of the association relationship of the associated objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article generally indicates that the associated objects before and after are in an "or" relationship.

[0056] The present application provides a Pod management method based on Single Root I / O Virtualization (SR-IOV), which uses SR-IOV to virtualize a physical network interface (physical network card) into several virtual functions (Virtual Function, VF). Then, a dedicated VF is allocated to the Pod for forwarding Pod network data packets. In this way, the Pod can achieve high-speed forwarding of network data packets without problems such as service unavailability.

[0057] See also Figure 1 , is a flow chart of a Pod management method based on SR-IOV provided in an embodiment of the present application. Figure 1 The method shown is applied to the master node of the Kubernetes cluster, and the method includes the following implementation steps:

[0058] S101, in response to a Pod management instruction, obtaining a list of available virtual functions (VFs) in a target node where a Pod to be managed is located. The list of available VFs includes at least one VF, and the VF is created for the target node using SR-IOV.

[0059] The Pod management instructions described in this application can be generated by user triggering, or can be received from other devices. The Pod management instructions can be Pod creation instructions and / or Pod deletion instructions. This application can execute Pod creation instructions to create corresponding VFs for the Pod to be managed, and can also execute Pod deletion instructions to delete the VFs created in association with the Pod to be managed.

[0060] In a specific implementation, the present application may first obtain the target node where the Pod to be managed is located, for example, determining the host server (i.e., the target node) where the Pod is located based on the Pod host server information. Further, the present application may obtain the available VF list in the target node based on the network IP address of the target node. The available VF list includes at least one VF that allows the target node to be available.

[0061] Optionally, before step S101, the master node of the Kubernetes cluster may pre-create corresponding VFs for different target nodes in the present application, and register the created VFs in the Kubernetes cluster. Specifically, the present application may select at least one (i.e., one or more) network interfaces in the target node (server), and use SR-IOV on the network interface to create at least one VF for each of the network interfaces. The VF is used to forward data packets in the Pod network. It is understandable that many physical network cards currently produced by manufacturers support SR-IOV, such as Intel 82599, E800, X700 series network cards, etc., Mellanox ConnectX-4, ConnectX-5, ConnectX-6 series network cards, etc. Different types of network cards / network interfaces may have different ways of creating VFs thereon, and the number of VFs supported for creation thereon may also be different.

[0062] Taking the network interface Intel X710 as an example, this application marks the network interface used to create the VF as ens1. The specific implementation method of creating the VF on Intel X710 is as follows:

[0063] 1. Execute the creation command "echo 16> / sys / class / net / ens1 / device / sriov_numvfs" to create 16 VFs on the network interface ens1. The VF numbers are: 0, 1, 2..., 15.

[0064] 2. This application adds the above creation command to the end of the / etc / profile file to ensure that the target node can recreate the VF when it is restarted.

[0065] Optionally, at least one VF created in the target node can form a corresponding VF list. Further, the present application can register each VF in the VF list to the Kubernetes cluster through the VF registration module. During registration, the following information can be provided for each target node (specifically, a working node in the Kubernetes cluster): the network IP address of the target node, such as "172.16.102.16"; the VF list, which may include any one or more of the following information: the at least one network interface, which may specifically be the name of the network interface, such as "ens1"; the at least one VF, which may specifically be a VF number configuration, and its format may be, for example, " <singlevf> ， <firstvf> - <lastvf> ， <singlevf> ， <singlevf> ， <firstvf> - <lastvf>"; The driver type of each of the network interfaces. Wherein, SingleVF represents a single VF number, FirstVF represents the first VF number in the VF number interval, and LastVF represents the last VF number in the VF number interval.

[0066] S102: Determine a network resource object of the Pod to be managed, where the network resource object includes a target network address of the Pod to be managed.

[0067] This application can find the network resource object of the Pod to be managed according to the name of the network resource (Network) object in the Pod field label. Specifically, for example, this application will find the corresponding Network object based on the value of the network.mingyangtech.com.cn / network field in the Pod metadata.annotations label, that is, the name of the Network object (such as sriov-network-01). Optionally, the network resource object includes any one or more of the following: network type, network prefix and mask length, network address allocation range, and pre-configured default gateway.

[0068] Optionally, before step S102, the present application may pre-create a Network object and introduce a new custom CRD resource Network in the Kubernetes cluster. The Network object represents a network and is used to define information such as the network type, network prefix and mask length, network IP address allocation range, and default gateway.

[0069] For example, see Table 1 below which describes a Network object that can be used to create a network.

[0070] Table 1

[0071]

[0072]

[0073] A network is created by Table 1 above. The network type is sriov, the network prefix is ​​192.168.1.0, the mask length is 24, the IP address allocation range is 192.168.1.100-192.168.1.200, and the default gateway is 192.168.1.1.

[0074] It should be noted that in Table 1 above, if you need to create a high-speed network based on SR-IOV for the Pod, you need to specify the name of the Network object "network.mingyangtech.com.cn / network:sriov-network-01" in the metadata.annotations tag when writing the yaml file (the yaml file used to create the Pod).

[0075] S103, managing the target VF in the network command space of the Pod to be managed, and updating the network address of the Pod to be managed and the target VF in the available VF list. The target VF is an interface in the at least one VF that supports the use of the Pod to be managed.

[0076] In a specific implementation, when the Pod management instruction is a Pod creation instruction, the present application may select a target VF from at least one VF according to a VF selection algorithm before step S103, and the target VF may be a VF in a network interface with the largest number of remaining VFs in the target node (for example, greater than a first threshold). The present application does not limit the specific implementation method of selecting the target VF. Specifically, for example, it may include at least one of the following: the present application may select the network interface with the largest number of remaining available VFs, and then randomly select an available VF from the network interface as the target VF; if the target node has several network interfaces, and there are multiple network interfaces with the largest and equal number of remaining available VFs, then any one of the target network interfaces with the largest number of VFs (for example, greater than the second threshold) may be selected from the multiple network interfaces as the target VF; if the target node has several network interfaces, and there are multiple network interfaces with the largest and equal number of remaining available VFs, and the number of VFs in each of the multiple network interfaces is also the same, then one of the available VFs may be randomly / arbitrarily selected from the multiple network interfaces as the target VF.

[0077] Further in step S103, the present application may create a virtual interface associated with the target VF in the network command space of the Pod to be managed, and configure the network address of the virtual interface as the target network address; mark the target VF as allocated, and update the available VF list; in the network resource object, add the target network address to the allocated network address list.

[0078] For example, the specific implementation process of this application to execute the Pod creation instruction is as follows:

[0079] S11. Obtain the target node information of the (to be managed) Pod host and determine the target node where the Pod is located.

[0080] S12. Obtain a list of available VFs on the target node according to the network IP address of the target node. When there are multiple available VFs in the VF available list, select a target VF from the multiple available VFs according to the VF selection algorithm and allocate it to the Pod to be managed. Specifically, for example, the application may record the allocated target VF as VF1, with a value such as (ens1, 0). Where ens1 represents the network interface and 0 represents the VF number.

[0081] S13. According to the value of the network.mingyangtech.com.cn / network field in the Pod metadata.annotations, that is, the name of the Network object (such as sriov-network-01), find the corresponding Network object. Then, according to the network definition in the Network object, assign a network IP address to the Pod to be managed, and record the assigned Pod IP address as ip1.

[0082] S14. In the network namespace assigned to the Pod, create a virtual interface associated with VF1 and configure its IP address as ip1.

[0083] S15. VF1 is marked as allocated, indicating that VF1 has been used and no longer belongs to the available VF list. In the Network object, ip1 is added to the corresponding network address IP list, indicating that ip1 is no longer allocated.

[0084] In another specific embodiment, when the Pod management instruction is a Pod deletion instruction, the present application may delete the virtual interface associated with the target VF in the network command space of the Pod to be managed; delete the target network address from the list of allocated network addresses in the network resource object; mark the target VF as unallocated, and update the available VF list.

[0085] For example, the specific implementation process of this application to execute the Pod deletion instruction is as follows:

[0086] S21. Obtain the target node information of the (to be managed) Pod host, determine the target node where the Pod is located, assume that the VF used by the Pod is marked as VF2, and assume that the network IP address allocated by the Pod is marked as ip2.

[0087] S22. In the network namespace allocated for the Pod, delete the virtual interface associated with VF2.

[0088] S23. According to the value of the network.mingyangtech.com.cn / network field in the Pod metadata.annotations, that is, the name of the Network object (such as sriov-network-01), the corresponding Network object is found. Then, the IP address (ip2) of the Pod is deleted from the allocated IP list of the Network object, indicating that the IP address (ip2) can be allocated again.

[0089] S24. Mark VF2 as unallocated, indicating that VF2 belongs to the available VF list and can be allocated again.

[0090] By implementing the embodiment of the present application, the present application can respond to the Pod management instruction, obtain the available virtual function VF list in the target node where the Pod to be managed is located, the available VF list includes at least one VF, and the VF is created for the target node using SR-IOV; determine the network resource object of the Pod to be managed, the network resource object includes the target network address of the Pod to be managed; manage the target VF in the network command space of the Pod to be managed, and update the network address of the Pod to be managed and the target VF in the available VF list, the target VF is the VF that supports the use of the Pod to be managed in the at least one VF. In the above scheme, the present application can conveniently and efficiently manage the corresponding target VF of the Pod to be managed of the target node according to the available VF list in the target node and the network resource object of the Pod, so as to use the target VF to achieve fast and efficient data transmission, thereby improving data transmission speed and efficiency. At the same time, it also solves the technical problems such as unavailable services and long delays when using iptables-based Service to access Pod in the prior art.

[0091] Based on the same inventive concept, another embodiment of the present application provides an apparatus and a terminal device corresponding to the Pod management method based on SR-IOV in the embodiment of the present application.

[0092] See also Figure 2 Schematic diagram of a Pod management device based on SR-IOV provided in an embodiment of the present application. Figure 2 The device 20 shown is applied to the master node of the Kubernetes cluster, and the device includes: an acquisition module 201, a determination module 202 and a processing module 203, wherein:

[0093] The acquisition module 201 is used to obtain, in response to the Pod management instruction, a list of available virtual functions VF in the target node where the Pod to be managed is located, wherein the available VF list includes at least one VF, and the VF is created for the target node using SR-IOV;

[0094] The determination module 202 is used to determine the network resource object of the Pod to be managed, wherein the network resource object includes the target network address of the Pod to be managed;

[0095] The processing module 203 is used to manage the target VF in the network command space of the Pod to be managed, and update the network address of the Pod to be managed and the target VF in the available VF list, wherein the target VF is a VF in the at least one VF that supports the use of the Pod to be managed.

[0096] For the contents not introduced or described in the embodiments of the present application, please refer to the relevant introduction in the aforementioned method embodiments, which will not be repeated here.

[0097] Please refer to 3, which is a schematic diagram of the structure of a terminal device provided in an embodiment of the present application. Figure 3 The terminal device 30 shown includes: at least one processor 301, a communication interface 302, a user interface 303 and a memory 304. The processor 301, the communication interface 302, the user interface 303 and the memory 304 can be connected via a bus or other means. The embodiment of the present invention takes the connection via a bus 305 as an example.

[0098] The processor 301 may be a general-purpose processor, such as a central processing unit (CPU).

[0099] The communication interface 302 may be a wired interface (eg, an Ethernet interface) or a wireless interface (eg, a cellular network interface or a wireless LAN interface) for communicating with other terminals or websites. In an embodiment of the present invention, the communication interface 302 is specifically used to obtain information such as Pod management instructions.

[0100] The user interface 303 may be a touch panel, including a touch screen and a touch screen, for detecting operation instructions on the touch panel, a physical button or a mouse, or a display screen for outputting and displaying images or data.

[0101] The memory 304 may include a volatile memory, such as a random access memory (RAM); the memory may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD) or a solid-state drive (SSD); the memory 304 may also include a combination of the above-mentioned types of memory. The memory 304 is used to store a set of program codes, and the processor 301 is used to call the program codes stored in the memory 304 to perform the following operations:

[0102] In response to the Pod management instruction, obtain a list of available virtual functions VF in the target node where the Pod to be managed is located, wherein the list of available VFs includes at least one VF, and the VF is created for the target node using SR-IOV;

[0103] Determine a network resource object of the Pod to be managed, wherein the network resource object includes a target network address of the Pod to be managed;

[0104] The target VF is managed in the network command space of the Pod to be managed, and the network address of the Pod to be managed and the target VF in the available VF list are updated, wherein the target VF is a VF in the at least one VF that supports the use of the Pod to be managed.

[0105] Optionally, the Pod management instruction is a Pod creation instruction, and before managing the target VF in the network command space of the Pod to be managed, the method further includes:

[0106] According to the VF selection algorithm, select the target VF from the at least one VF, the target VF being a VF in the network interface where the number of remaining VFs is greater than a first threshold;

[0107] The managing the target VF in the network command space of the Pod to be managed, and updating the network address of the Pod to be managed and the target VF in the available VF list includes:

[0108] In the network command space of the Pod to be managed, create a virtual interface associated with the target VF, and configure the network address of the virtual interface as the target network address;

[0109] Mark the target VF as allocated and update the available VF list;

[0110] In the network resource object, the target network address is added to a list of allocated network addresses.

[0111] Optionally, the Pod management instruction is a Pod deletion instruction, and managing the target VF in the network command space of the Pod to be managed, and updating the network address of the Pod to be managed and the target VF in the available VF list includes:

[0112] In the network command space of the Pod to be managed, delete the virtual interface associated with the target VF;

[0113] Deleting the target network address from a list of allocated network addresses in the network resource object;

[0114] The target VF is marked as unallocated, and the available VF list is updated.

[0115] Optionally, obtaining a list of available virtual functions VF in the target node where the Pod to be managed is located includes:

[0116] Get the target node where the Pod to be managed is located;

[0117] According to the network address of the target node, an available VF list in the target node is obtained.

[0118] Optionally, determining the network resource object of the Pod to be managed includes:

[0119] According to the network resource object name in the Pod field label, find out the network resource object of the Pod to be managed.

[0120] Optionally, before obtaining the available virtual function VF list in the target node where the Pod to be managed is located, the method further includes:

[0121] Select at least one network interface in the target node, and use SR-IOV to create at least one VF for each of the network interfaces, where the VF is used for data transmission of the Pod to be managed;

[0122] Generate the available VF list according to the at least one created VF;

[0123] Register the available VF list in the Kubernetes cluster.

[0124] Optionally, the available VF list includes the at least one network interface, the at least one VF, and a driver type of each of the network interfaces.

[0125] Optionally, before determining the network resource object of the Pod to be managed, the method further includes:

[0126] The network resource object is created, wherein the network resource object includes at least one of the following: network type, network prefix and mask length, network address allocation range, and a pre-configured default gateway.

[0127] Since the terminal device introduced in this embodiment is a terminal device used to implement the method in the embodiment of the present application, based on the method introduced in the embodiment of the present application, a person skilled in the art can understand the specific implementation of the terminal device in the embodiment and its various variations, so how the terminal device implements the method in the embodiment of the present application is not described in detail here. As long as a person skilled in the art implements the terminal device used in the method in the embodiment of the present application, it belongs to the scope of protection of this application.

[0128] One or more technical solutions provided in the embodiments of the present application have at least the following technical effects or advantages: the present application can respond to the Pod management instruction, obtain the available virtual function VF list in the target node where the Pod to be managed is located, the available VF list includes at least one VF, and the VF is created for the target node using SR-IOV; determine the network resource object of the Pod to be managed, and the network resource object includes the target network address of the Pod to be managed; manage the target VF in the network command space of the Pod to be managed, and update the network address of the Pod to be managed and the target VF in the available VF list, and the target VF is the VF in the at least one VF that supports the use of the Pod to be managed. In the above scheme, the present application can conveniently and efficiently manage the corresponding target VF of the Pod to be managed of the target node according to the available VF list in the target node and the network resource object of the Pod, so as to use the target VF to achieve fast and efficient data transmission, thereby improving data transmission speed and efficiency. At the same time, it also solves the technical problems of service unavailability and long delay when using iptables-based Service to access Pod in the prior art.

[0129] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0130] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0131] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0132] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0133] Although the preferred embodiments of the present invention have been described, those skilled in the art may make other changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present invention.

[0134] Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include these modifications and variations.< / lastvf> < / firstvf> < / singlevf> < / singlevf> < / lastvf> < / firstvf> < / singlevf>

Claims

1. A Pod management method based on SR-IOV, characterized in that: Applied to a master control node of a Kubernetes cluster, the method includes: In response to the Pod management instruction, obtain a list of available virtual functions VF in the target node where the Pod to be managed is located, wherein the available VF list includes at least one VF, and the VF is created for the target node using SR-IOV; the Pod management instruction includes a Pod creation instruction and a Pod deletion instruction; Determine a network resource object of the Pod to be managed, wherein the network resource object includes a target network address of the Pod to be managed; According to the VF selection algorithm, a target VF is selected from the at least one VF, where the target VF is a VF in the network interface where the number of remaining VFs is greater than a first threshold; Managing the target VF in the network command space of the Pod to be managed, and updating the network address of the Pod to be managed and the target VF in the available VF list, wherein the target VF is a VF in the at least one VF that supports the use of the Pod to be managed; The step of managing the target VF in the network command space of the Pod to be managed and updating the network address of the Pod to be managed and the target VF in the available VF list includes: In the network command space of the Pod to be managed, create a virtual interface associated with the target VF, and configure the network address of the virtual interface as the target network address; Mark the target VF as allocated and update the available VF list; In the network resource object, adding the target network address to a list of allocated network addresses; The step of managing the target VF in the network command space of the Pod to be managed and updating the network address of the Pod to be managed and the target VF in the available VF list includes: In the network command space of the Pod to be managed, delete the virtual interface associated with the target VF; Deleting the target network address from a list of allocated network addresses in the network resource object; The target VF is marked as unallocated, and the available VF list is updated.

2. The method according to claim 1, characterized in that The step of obtaining a list of available virtual functions VF in the target node where the Pod to be managed is located includes: Get the target node where the Pod to be managed is located; According to the network address of the target node, an available VF list in the target node is obtained.

3. The method according to claim 1, characterized in that Determining the network resource object of the Pod to be managed includes: According to the network resource object name in the Pod field label, find out the network resource object of the Pod to be managed.

4. The method according to any one of claims 1 to 3, characterized in that Before obtaining the available virtual function VF list in the target node where the Pod to be managed is located, the method further includes: Select at least one network interface in the target node, and use SR-IOV to create at least one VF for each of the network interfaces, where the VF is used for data transmission of the Pod to be managed; Generate the available VF list according to the at least one created VF; Register the available VF list in the Kubernetes cluster.

5. The method according to claim 4, characterized in that The available VF list includes the at least one network interface, the at least one VF, and a driver type of each of the network interfaces.

6. The method according to any one of claims 1 to 3, characterized in that Before determining the network resource object of the Pod to be managed, the method further includes: The network resource object is created, wherein the network resource object includes at least one of the following: network type, network prefix and mask length, network address allocation range, and a pre-configured default gateway.

7. A terminal device, characterized in that: The terminal device includes: a processor, a memory, a communication interface and a bus; the processor, the memory and the communication interface are connected through the bus and communicate with each other; the memory stores executable program code; the processor runs a program corresponding to the executable program code by reading the executable program code stored in the memory, so as to execute the SR-IOV-based Pod management method as described in any one of claims 1 to 6 above.

8. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a program, and when the program is run on a terminal device, the SR-IOV-based Pod management method as described in any one of claims 1 to 6 is executed.

Images