CN112202615B

CN112202615B - Multi-CNI cooperative work system and method

Info

Publication number: CN112202615B
Application number: CN202011063938.XA
Authority: CN
Inventors: 蓝维洲; 朱晖; 胡心悦
Original assignee: Shanghai Daoke Network Technology Co ltd
Current assignee: Shanghai Daoke Network Technology Co ltd
Priority date: 2020-09-30
Filing date: 2020-09-30
Publication date: 2021-08-31
Anticipated expiration: 2040-09-30
Also published as: CN112202615A

Abstract

The invention discloses a multi-CNI cooperative work system and a method, wherein the system comprises a Kubelet, a Kubernets API Server, a father CNI, a child CNI and a host, the configuration file of the father CNI comprises information data of a plurality of child CNIs, the binary executable file and the configuration file path of the child CNI are required to be registered in the configuration file of the father CNI, and the host is respectively connected with the Kubelet, the Kubernets API Server, the father CNI and the child CNI in a creation mode to realize data interaction; the method comprises the steps 1-4, when called by the Kubelet, the CNI plug-in registered under the scheduler can be automatically called according to the specific requirements of the application, the required CNI IP address is distributed to the CNI plug-in, and the communication among the applications and the hosts is realized through the route maintenance among the CNIs and the route among the hosts.

Description

Multi-CNI cooperative work system and method

Technical Field

The invention relates to the field of multi-CNI cooperative work based on a Kubernetes container cloud platform, in particular to a multi-CNI cooperative work system and a multi-CNI cooperative work method.

Background

The network of the container cloud platform is a cornerstone of the platform, the container group IP is a foundation for providing services for the outside by applications, and in the existing kubernets native container cloud network solution, only a single kind of network interface support is provided, for example:

MACVLAN: the MACVLAN allows a plurality of virtual network interfaces to be configured on one network interface of the host, the network interfaces have independent MAC addresses, and can also be configured with IP for communication, and a virtual machine or a container network under the MACVLAN and the host share the same broadcast domain in the same network segment;

IP VLAN: the IP VLAN is similar to the MACVLAN, and multiple virtual network interfaces are virtualized from one host interface, and an important difference is that all virtual interfaces have the same MAC address and have different IP addresses because all virtual interfaces share the MAC address;

PTP: the PTP plugin creates a point-to-point connection for the container and host through VETHPAIR: the VETH PAIR has one end in the container network name space and the other end on the host, and can enable the PTP-connected containers to communicate by configuring the IP address and route of the host;

reference material: com/containerinnectingworking/plugins;

in the open source scheme, there are several methods for realizing multi-CNI integration by a third party CNI, such as:

Multus-CNI is a Container Network Interface (CNI) plug-in to kubernets that can attach multiple network interfaces to Pod, typically, in kubernets, each Pod has only one network interface (except for loopback) -through Multus, a multi-homed Pod with multiple interfaces can be created, which is realized by Multus as a "meta plug-in", and one CNI plug-in can call multiple other CNI plug-ins;

CNI-Genie: CNI-Genie enables container organizers (Kubernets, Mesos) to seamlessly connect to host-installed CNI plug-in options, including native CNI plug-ins such as bridge, macvlan, IP vlan, loopback, etc., or any third party plug-ins such as Calico, Romana, Weave-net, etc.; typically, the orchestrator binds only one CNI plug-in, e.g., for Kubernets, kubelelet binds only one CNI plug-in delivered to kubelelet at startup, if there is no CNI-Genie, which allows multiple CNI plug-ins to co-exist at runtime;

knitter is a CNI plug-in used for supporting a plurality of network interfaces in Kubernetes Pod and providing the capability of attaching a Pod (such as VNF in Pod) to a high-performance network, and the Knitter can also allow a user to specify a custom network according to own infrastructure and support operation in public cloud, private cloud and mixed cloud;

in the existing container cloud platform cluster, Pod is generally deployed in the form of a single CNI, such as Calico or Flannel, or in the existing open-source technology, such as Multus-CNI, CNI-Genie or Knitter mentioned above;

for a single CNI form to deploy Pod, the Pod deployment of users is increasingly unable to meet, for example, a user wants to use various network products or multiple CNI plug-ins in the same cluster, based on the requirements of performance, application, workload placement, etc., the user may be interested in using different CNI plug-ins for different application groups, and the network capabilities that different CNI plug-ins can provide are different, the user may have various requirements in port mapping, NAT, tunneling, host port/interface interruption, etc., and these capabilities are not always capable of being provided by a single CNI plug-in, and the effect of using multi-CNI integration is as shown in fig. 4;

although the above several integrated schemes of multiple CNIs can solve the deficiency that a single CNI deploys Pod, none of the exceptions in the implementation manners of these CNIs is that a network interface of multiple CNI plug-ins is injected into a network container of the Pod to implement multiple CNI support, so that a default CNI needs to be specified as a default route outlet of the container network, and thus the Pod needs to face the problem of routing selection, which increases the difficulty in use, and the Pod deployed in this manner needs to have interfaces of different child CNIs to access to corresponding child CNI networks, so that the Pod needs to occupy IP address resources of each CNI to implement communication, and the principle of implementing multiple CNIs shown in fig. 5;

under the existing large-scale cluster deployment, a single network mode cannot meet the requirement of increasingly-increased container deployment in various forms, and the existing third-party multi-CNI integration scheme has the defects of complex routing and excessive IP address occupation, so that the routing relation under the coordination of multiple CNIs needs to be greatly simplified, the cooperative work among the CNIs is realized, the operation and maintenance are convenient, and a large number of precious CNI IP addresses can be saved.

The prior Chinese patent application CN111371627A discloses a method for setting multiple IPs for a Pod in Kubernetes, the realized function is to provide multiple IPs for the Pod through a single CNI plug-in, the realization method can meet the same problems as Multus-CNI, CNI-Genine and the like, namely, multiple IPs can be configured for one Pod, which causes the waste of IP resources, and a plurality of routing relations also need to be configured in the Pod, which causes the complex routing relation;

the existing Chinese patent application CN111147297A discloses a Kubernetes multilayer network plane construction method, which is an implementation mode combining Multus-CNI and Macvlan, and specifically describes the purpose of distributing a plurality of IPs for Pod by integrating Macvlan into Multus-CNI.

Disclosure of Invention

The invention provides a multi-CNI cooperative work system, which can automatically call CNI plug-ins registered under a scheduler according to specific requirements of applications when the multi-CNI cooperative work is used in a single cluster, allocate required CNI IP addresses for the CNI plug-ins, and realize communication among applications and between the applications and hosts through route maintenance among CNIs and routes among hosts so as to solve the defects caused by the prior art.

The invention also provides a multi-CNI cooperative working method.

In order to solve the technical problems, the invention provides the following technical scheme:

a multi-CNI cooperative work system comprises a Kubernets platform, a father CNI, a plurality of child CNIs and a host, wherein a configuration file of the father CNI contains information data of all the child CNIs, binary executable files and configuration file paths of the child CNIs need to be registered in the configuration file of the father CNI first, the Kubernets platform comprises a Kubelet and a Kubernets API Server, and the host is respectively connected with the Kubelet, the Kubernets API Server, the father CNI and the child CNIs to realize data interaction;

the Kubelet is used for perceiving and creating a Pod, and is also used for searching the parent CNI, reading the configuration file of the parent CNI, and transmitting the relevant configuration in the Pod to the parent CNI in the form of an environment variable and the read configuration file of the parent CNI in the form of standard input, and because the parent CNI does not read the configuration file information therein, the Kubelet is required to read the configuration file in the parent CNI and then transmit the configuration file to the parent CNI;

the parent CNI acquires the layout description in the Pod through the Kubernets API Server, the parent CNI perceives the child CNI required by the Pod according to the layout description in the Pod, and the parent CNI is further used for searching the binary executable file and the configuration file path of the child CNI in the received configuration file of the parent CNI and transmitting the configuration file of the child CNI and the environment variable transmitted to the parent CNI by the Kubelet to the binary executable file in the child CNI;

the child CNI is used for receiving the configuration file of the child CNI transmitted by the parent CNI and the environment variable transmitted to the parent CNI by the Kubelet, acquiring the IP address of the child CNI through the service end of the child CNI, and binding the IP address to the Pod. In the above multi-CNI cooperative work system, the Pod receives the IP address, after the network card in the Pod is bound to the IP address, binding result data transmitted to the parent CNI is generated, and the parent CNI receives and transmits the binding result data to the kubel.

In the above multi-CNI cooperative work system, the parent CNI transmits the configuration file of the child CNI and the environment variable transmitted from the kubel to the parent CNI to the binary executable file in the child CNI by simulating the way in which the kubel calls the parent CNI.

In the above multi-CNI cooperative system, the parent CNI is a CNI scheduler.

The terms are explained herein as follows:

the Kubernetes platform, K8s for short, is an abbreviation formed by replacing 8 characters "ubernet" with 8, is an open source, is used for managing containerized application platforms on a plurality of hosts in a cloud platform, aims to ensure that the containerized application is simple and efficient to deploy (powerfull), and provides a mechanism for application deployment, planning, updating and maintenance;

kubelet is the primary "Node agent" running on each Node; a Node is called a Node or a Node, and refers to an end point of a network connection or a connection point of two (or more) lines; the node may be a processor, a controller, or a workstation. A "node agent" is a lightweight process that is required on every computer that hosts a Server instance, including the computers that host the Domain Administration Server (DAS). The node agent may:

1) server instances are started, stopped, created, and deleted as directed by the domain management server.

2) The failed server instance is restarted.

3) A log file view of the failed server is provided.

4) The local configuration system information base of each server instance is synchronized with the central system information base of the domain management server. Each local system information base contains only information related to that server instance or node agent.

The Kubernets API Server is a data bus and a data center of the whole system of a Kubernets platform, is a front end for providing REST operation and a cluster sharing state, and interacts with other components through the front end;

CNI is an abbreviation of Container network ktnterface, which is a k8s network interface of a generic Container network plug-in, and is mainly used for interfacing the network plug-in and a kubel Container runtime management tool (mainly embodied in the creation and deletion process of Pod;

pod is the minimum/simplest basic unit created or deployed by Kubernetes, one Pod represents a process running on a cluster, and one Pod encapsulates one application container (or multiple containers are available), storage resources, an independent network IP address, and policy options for managing and controlling the operation mode of the container. Pod represents one unit of deployment: kubernets, an instance of a single application that may share a resource consisting of a single container or multiple containers;

environment variables (environment variables) generally refer to parameters used in an operating system to specify the operating system's operating environment. The environment variables comprise parameters such as CNI _ COMMAND, CNI _ CONTAINERID, CNI _ NETNS, CNI _ PATH, CNI _ ARGS and the like; wherein, CNI _ COMMAND indicates that the call is to bind or unbind the IP address; CNI _ content, which is a unique identifier for each container within the cluster; CNI _ NETNS, which represents the network namespace path for the container; CNI _ PATH, which represents the PATH of the CNI that needs to execute the operation; the CNI _ ARGS contains some attributes of the container contained in the kubernets platform, such as a name, a name space where the container is located and the like.

The CNI scheduler is a manager for comprehensively managing and scheduling CNIs with complete functions, and can be used for scheduling the CNIs required to be used according to requirements to execute operations of the CNIs, such as allocating and unbinding IP addresses.

In a second aspect, a working method of a multi-CNI cooperative working system includes the following steps:

step 1: sensing a Kubelet on a host and creating a Pod on the node;

step 2: the Kubelet searches and reads the configuration file in the parent CNI, and transmits the relative configuration of Pod and the configuration file of the parent CNI to the parent CNI executable file;

and step 3: the parent CNI acquires the layout description of the Pod through a Kubernets API Server, the parent CNI perceives the child CNI which needs to be used according to the layout description of the Pod, the parent CNI searches the binary executable file and the configuration file path of the child CNI in the configuration file transmitted to the parent CNI by the Kubelet, and the parent CNI transmits the configuration file and the Kubelet of the child CNI to the environment variable of the parent CNI to the binary executable file in the child CNI;

and 4, step 4: after receiving the parameters of the parent CNI, the child CNI binary executable file acquires the usable IP address from the service end of the child CNI, and the child CNI binds the acquired IP address to the card of the Pod.

In the above working method, in step 4, after the obtained IP address is successfully bound to the network card of the Pod by the child CNI, the binding result between the network card in the Pod and the IP address is transmitted to the parent CNI, and the parent CNI transmits the binding result to the kubel.

In the above working method, the parent CNI transmits the configuration file of the child CNI and the environment variable of the parent CNI from the Kubelet to the binary executable file in the child CNI by simulating the way in which the Kubelet calls the parent CNI.

In the above working method, the parent CNI is a CNI scheduler;

at present, most of the common single CNI plug-in traffic passes through a host (such as a flannel, a calico), a route is configured on the host to ensure the communication between all the Pod on the CNI, and the hosts in a cluster have a routing relation to ensure the communication, so that all the sub-CNIs only need to pass through the default route between all the hosts to realize the communication between the PODs of different sub-CNI IP addresses; compared with the existing multi-CNI integration scheme, such as Multus and Genie, the invention uses the characteristic that the sub-CNIs configure the route on the host machine, and realizes that the flow among the sub-CNIs is forwarded by the host machine to communicate, so that a network card corresponding to each different CNI in a Pod and an IP address of the network type are not required to be established and distributed for each different CNI, but a network IP address of the CNI required to be used is distributed for the Pod in the Pod, and a simple default route is used; when the sub CNIs need to communicate with each other, the flow in the Pod is forwarded to the host machine through the default route, and the communication between the sub CNIs and the Pod is realized through the route forwarding on the host machine;

the CNI maintains the routing relation on the host by using a routing synchronization rule, and realizes the communication between the CNI and the Pod, and the communication between different CNIs and different pods can be realized because the flow of the Pod flows through a network protocol stack of the host;

writing an integrated total CNI scheduling plug-in, and inserting a binary executable file path and a configuration file path of a sub CNI plug-in to be used into a configuration file of the CNI plug-in to register the CNI; in a cloud platform, communication among the Pods deployed by different CNI plug-ins is realized by three-layer forwarding on a host; and acquiring the CNI plug-in required to be used through the layout file of the application, and calling the target CNI through a method of the transparent proxy to complete the process of creating the network.

In a third aspect, a multi-CNI cooperative apparatus includes at least one processor and a memory coupled to the at least one processor, the memory storing executable instructions that when executed by the at least one processor cause the method described above to be implemented.

In a fourth aspect, a chip, comprises: and the processor is used for calling and running the computer program from the memory so that the equipment provided with the chip executes the method.

The technical scheme provided by the multi-CNI cooperative work system and method of the invention has the following technical effects:

under a unified CNI scheduling framework, more network environments including a traditional physical network, an SDN network, a public cloud and the like can be adapted, more applications are deployed on a virtual subnet, the number of IP addresses required by a real subnet is reduced, the corresponding IP address management cost is reduced, and the method is suitable for large-scale cluster operation and maintenance; the same set of CNI solution can be adapted to more production network environments, and the learning cost of operation and maintenance is reduced; under the same CNI scheduling framework, the method reduces the difficulty for realizing network functions such as multi-cluster communication, network Policy, QOS flow control and the like; the method is convenient for integrating the existing CNI (as long as the requirement of the routing passing through the host machine is met), can realize the rapid integration and unloading of multiple CNIs, and is convenient and rapid for not introducing too much development;

compared with the prior patent applications with publication numbers of CN111371627A and CN111147297A, the technical scheme provided by the invention has the following advantages: under a unified CNI scheduling framework, more network environments including a traditional physical network, an SDN network, a public cloud and the like can be adapted, more applications are deployed on a virtual subnet, the number of IP addresses required by a real subnet is reduced, the corresponding IP address management cost is reduced, and the method is suitable for large-scale cluster operation and maintenance; the same set of CNI solution can be adapted to more production network environments, and the learning cost of operation and maintenance is reduced; under the same CNI scheduling framework, the method reduces the difficulty for realizing network functions such as multi-cluster communication, network Policy, QOS flow control and the like; the method is convenient to integrate the existing CNI (as long as the requirement that the route passes through the host is met), can realize the rapid integration and unloading of multiple CNIs, and is convenient and rapid without introducing too much development.

Drawings

FIG. 1 is a schematic structural diagram of a multi-CNI cooperative system according to the present invention;

FIG. 2 is a schematic flow chart illustrating a specific usage status of a multi-CNI cooperative system according to the present invention;

FIG. 3 is a schematic diagram of a communication structure between each sub-CNI and Pod in the multi-CNI cooperative system according to the present invention;

FIG. 4 is a graph of the effects of integration using multiple CNIs;

fig. 5 is a schematic diagram of Pod implementation of multiple CNIs.

Detailed Description

In order to make the technical means, the inventive features, the objectives and the effects of the invention easily understood and appreciated, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the specific drawings, and it is obvious that the described embodiments are a part of the embodiments of the present invention, but not all of the embodiments.

All other embodiments, which can be obtained by a person skilled in the art without any inventive step based on the embodiments of the present invention, are within the scope of the present invention.

It should be understood that the structures, ratios, sizes, and the like shown in the drawings and described in the specification are only used for matching with the disclosure of the specification, so as to be understood and read by those skilled in the art, and are not used to limit the conditions under which the present invention can be implemented, so that the present invention has no technical significance, and any structural modification, ratio relationship change, or size adjustment should still fall within the scope of the present invention without affecting the efficacy and the achievable purpose of the present invention.

In addition, the terms "upper", "lower", "left", "right", "middle" and "one" used in the present specification are for clarity of description, and are not intended to limit the scope of the present invention, and the relative relationship between the terms and the terms is not to be construed as a scope of the present invention.

A preferred embodiment of the present invention provides a multi-CNI cooperative work system and method, which can adapt to more network environments under a unified CNI scheduling framework, including a traditional physical network, an SDN network, a public cloud, etc., and deploy more applications on a virtual subnet, thereby reducing the number of IP addresses required by a real subnet, reducing the corresponding IP address management cost, and being suitable for large-scale cluster operation and maintenance; the same set of CNI solution can be adapted to more production network environments, and the learning cost of operation and maintenance is reduced; under the same CNI scheduling framework, the method reduces the difficulty for realizing network functions such as multi-cluster communication, network Policy, QOS flow control and the like; the method is convenient to integrate the existing CNI (as long as the requirement that the route passes through the host is met), can realize the rapid integration and unloading of multiple CNIs, and is convenient and rapid without introducing too much development.

As shown in fig. 1-2, a multi-CNI cooperative system includes a kubernets platform, a parent CNI, a plurality of child CNIs, and a host, where a configuration file of the parent CNI includes information data of all child CNIs, binary executable files and configuration file paths of the child CNIs need to be registered in the configuration file of the parent CNI, the kubernets platform includes a Kubelet and a kubernets API Server, and the host establishes connections with the Kubelet, the kubernets API Server, the parent CNI, and the child CNIs respectively to implement data interaction;

the Kubelet is used for sensing and creating the Pod, searching the parent CNI, reading the configuration file of the parent CNI, and transmitting the relevant configuration in the Pod to the parent CNI in the form of environment variables and the read configuration file of the parent CNI in the form of standard input, and because the parent CNI cannot read the configuration file information in the parent CNI, the Kubelet is required to read the configuration file in the parent CNI and then transmit the configuration file to the parent CNI;

the parent CNI acquires the arrangement description in the Pod through a Kubernets API Server, the parent CNI perceives the child CNI required by the Pod according to the arrangement description in the Pod, the parent CNI is also used for searching the binary executable file and the configuration file path of the child CNI in the received configuration file of the parent CNI, and transmitting the configuration file and the Kubelet of the child CNI to the environment variable of the parent CNI, wherein the environment variable comprises CNI _ COMMAND and represents that the call is a binding or unbinding IP address; CNI _ content, which is a unique identifier for each container within the cluster; CNI _ NETNS, which represents the network namespace path for the container; CNI _ PATH, which represents the PATH of the CNI that needs to execute the operation; the CNI _ ARGS comprises some attributes of the container in the kubernets platform, such as a name, a name space where the container is located and the like;

the child CNI is used for receiving the configuration file of the child CNI transmitted by the parent CNI and the environment variable transmitted to the parent CNI by the Kubelet, acquiring the IP address of the child CNI through the service end of the child CNI, and binding the IP address to Pod.

In the above multi-CNI cooperative work system, after the Pod receives the IP address, the network card in the Pod is bound with the IP address to generate binding result data transmitted to the parent CNI, and the parent CNI receives and transmits the binding result data to the kubel.

In the above multi-CNI cooperative work system, the parent CNI transmits the configuration file of the child CNI and the environment variable of the parent CNI from the kubel to the binary executable file in the child CNI by simulating the kubel to call the parent CNI.

In the above multi-CNI cooperative system, the parent CNI is a CNI scheduler.

step 1: sensing a Kubelet on a host and creating a Pod on the node;

and step 3: the parent CNI acquires the layout description of the Pod through a Kubernets API Server, and makes the parent CNI perceive the child CNI which needs to be used according to the annotation applied in the layout description, such as dce.

After the obtained IP address is successfully bound to the network card of the Pod by the child CNI in the step 4, the binding result of the network card and the IP address in the Pod is transmitted to the parent CNI, and the parent CNI transmits the binding result to the Kubelet.

And the parent CNI transmits the configuration file of the child CNI and the environment variable of the Kubelet to the parent CNI to a binary executable file in the child CNI in a mode of simulating the Kubelet to call the parent CNI.

Wherein, the father CNI is a CNI scheduler;

as shown in fig. 3, the CNI uses a routing synchronization rule to maintain its own routing relationship on the host, so as to implement communication between the CNI and Pod, because the traffic of Pod flows through the network protocol stack of the host, communication between different CNIs and pods can be implemented;

When in specific use, firstly, a normally running Kubernetes cluster is provided; installing a supported child CNI such as Calico in a kubernets cluster; registering a binary executable path and a configuration file of a sub-CNI in a Kubernetes cluster in a configuration file provided by the method; when the method is used, the CNI plug-in type to be used needs to be specified on the corresponding layout file, the CNI type to be used needs to be specified by using the keyword dce. After deployment, after the Pod is dispatched to the host machine by kubernets, the kubelelet on the host machine can firstly call the CNI binary executable file provided by the method through the primary configuration of the CNI, and the CNI binary executable file used by the method can query the layout file of the Pod to be dispatched according to the environment variable transmitted by the kubelelet and through the kube-API server address provided by the configuration file, so that the similar Pod layout file can be obtained. According to the CNI type to be used and the configuration file path of the related CNI pointed by the configuration file specified in the layout file, the binary executable file in the method reads the configuration file information of the calling CNI, transmits the environment variable introduced by the kubel to the CNI plug-in to be used, completes the binding operation of the IP address, and transmits the return of the CNI to kubernets (the method can be regarded as a transparent proxy).

A multi-CNI cooperative apparatus comprising at least one processor and a memory coupled to the at least one processor, the memory storing executable instructions that when executed by the at least one processor cause the method to be implemented.

For example, the memory may include random access memory, flash memory, read only memory, programmable read only memory, non-volatile memory or registers, or the like;

the processor may be a Central Processing Unit (CPU) or the like, or a Graphics Processing Unit (GPU) memory may store executable instructions;

the processor may execute execution instructions stored in the memory to implement the various processes described herein.

It will be appreciated that the memory in this embodiment can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory;

the non-volatile memory may be a ROM (Read-only memory), a PROM (programmable Read-only memory), an EPROM (erasable programmable Read-only memory), an EEPROM (electrically erasable programmable Read-only memory), or a flash memory.

The volatile memory may be a RAM (random access memory) which functions as an external cache;

by way of illustration and not limitation, many forms of RAM are available, such as SRAM (staticaram, static random access memory), DRAM (dynamic RAM, dynamic random access memory), SDRAM (synchronous DRAM ), DDRSDRAM (double data rate SDRAM, double data rate synchronous DRAM), ESDRAM (Enhanced SDRAM, Enhanced synchronous DRAM), SLDRAM (synchlink DRAM, synchronous link DRAM), and DRRAM (directrrambus RAM, direct memory random access memory). The memory described herein is intended to comprise, without being limited to, these and any other suitable types of memory.

In some embodiments, the memory stores elements, upgrade packages, executable units, or data structures, or a subset thereof, or an extended set thereof: operating systems and applications;

the operating system includes various system programs, such as a framework layer, a core library layer, a driver layer, and the like, and is used for implementing various basic services and processing hardware-based tasks;

the application programs comprise various application programs and are used for realizing various application services. The program for implementing the method of the embodiment of the present invention may be included in the application program.

Those of skill in the art would understand that the elements and algorithm steps of the examples described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of software and electronic hardware;

whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the technical solution;

skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the embodiments of the present application, the disclosed system, apparatus and method may be implemented in other ways;

for example, the division of a unit or a module is only one logic function division, and there may be another division manner in actual implementation;

for example, a plurality of units or modules or components may be combined or may be integrated into another system;

in addition, functional units or modules in the embodiments of the present application may be integrated into one processing unit or module, or may exist separately and physically.

It should be understood that, in the various embodiments of the present application, the sequence numbers of the processes do not mean the execution sequence, and the execution sequence of the processes should be determined by the functions and the inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a machine-readable storage medium;

therefore, the technical solution of the present application may be embodied in the form of a software product, which may be stored in a machine-readable storage medium and may include several instructions to cause an electronic device to execute all or part of the processes of the technical solution described in the embodiments of the present application;

the storage medium may include various media that can store program codes, such as ROM, RAM, a removable disk, a hard disk, a magnetic disk, or an optical disk.

In conclusion, the multi-CNI cooperative work system and method provided by the invention can adapt to more network environments under a unified CNI scheduling framework, include the traditional physical network, SDN network, public cloud and the like, deploy more applications on the virtual sub-network, reduce the number of IP addresses required by the real sub-network, reduce the corresponding IP address management cost, and are suitable for large-scale cluster operation and maintenance; the same set of CNI solution can be adapted to more production network environments, and the learning cost of operation and maintenance is reduced; under the same CNI scheduling framework, the method reduces the difficulty for realizing network functions such as multi-cluster communication, network Policy, QOS flow control and the like; the method is convenient to integrate the existing CNI (as long as the requirement that the route passes through the host is met), can realize the rapid integration and unloading of multiple CNIs, and is convenient and rapid without introducing too much development.

Specific embodiments of the invention have been described above. It is to be understood that the invention is not limited to the particular embodiments described above, in that devices and structures not described in detail are understood to be implemented in a manner common in the art; various changes or modifications may be made by one skilled in the art within the scope of the claims without departing from the spirit of the invention, and without affecting the spirit of the invention.

Claims

1. A multi-CNI cooperative work system is characterized by comprising a Kubernets platform, a father CNI, a child CNI and a host, wherein a configuration file of the father CNI comprises information data of all the child CNIs, binary executable files and configuration file paths of the child CNI need to be registered in the configuration file of the father CNI, the Kubernets platform comprises a Kubelet and a Kubernets API Server, and the host is respectively connected with the Kubelet, the Kubernets API Server, the father CNI and the child CNI to realize data interaction;

the Kubelet is used for sensing and creating a Pod, searching the parent CNI, reading the configuration file of the parent CNI, and transmitting the relevant configuration in the Pod to the parent CNI in the form of an environment variable and the read configuration file of the parent CNI in the form of standard input;

the child CNI is used for receiving the configuration file of the child CNI transmitted by the parent CNI and the environment variable transmitted to the parent CNI by the Kubelet, acquiring the IP address of the child CNI through the service end of the child CNI, and binding the IP address to the Pod.

2. The system of claim 1, wherein the Pod receives the IP address, after the network card in the Pod binds to the IP address, the Pod generates binding result data to be transmitted to the parent CNI, and the parent CNI receives and transmits the binding result data to the kubel.

3. The system of claim 2, wherein the parent CNI transmits the configuration file of the child CNI and the environment variables transmitted by the kubel to the parent CNI to the binary executable file in the child CNI by simulating the way the kubel invokes the parent CNI.

4. A multi-CNI cooperative system according to any one of claims 1-3, wherein the parent CNI is a CNI scheduler.

5. A method of operating the multi-CNI cooperative system according to any one of claims 1 to 4, comprising the steps of:

step 1: sensing a Kubelet on a host and creating a Pod on the node;

6. The working method of claim 5, wherein in step 4, after the obtained IP address is successfully bound to a network card of a Pod by the child CNI, the binding result between the network card in the Pod and the IP address is transmitted to the parent CNI, and the parent CNI transmits the binding result to the Kubelet.

7. The method of claim 6, wherein said parent CNI transmits said child CNI's configuration file and said Kubelet's environment variables to said parent CNI into a binary executable file within said child CNI by simulating said Kubelet's invocation of said parent CNI.

8. The method of operation of any of claims 5-7, wherein the parent CNI is a CNI scheduler.

9. A multi-CNI cooperative apparatus comprising at least one processor and a memory coupled to the at least one processor, the memory storing executable instructions that when executed by the at least one processor cause the method of any of claims 5 to 8 to be implemented.

10. A chip, comprising: a processor for calling and running the computer program from the memory so that the device in which the chip is installed performs: the method of any one of claims 5 to 8.