Intelligent POD route for a cluster

Abstract

A method includes deploying an intelligent route service on nodes of a cluster executing a cluster protocol. Each node includes pods that executes an instance of an application. The intelligent route service provides routing information between the pods and an external node. The method includes starting a container network interface ( "CNI" ) connector on the external node without a container engine or cluster components. The method includes transmitting an access request to the intelligent route service configured to request access by an external application running on the external node to the instances of the application. The method includes receiving CNI configuration information from the intelligent route service with configuration information of the cluster and routing information to the pods. The method includes establishing a communication channel between the external application and the instances of the application. The communication channel facilitates the external application executing tasks on the instances of the application.

Description

INTELLIGENT POD ROUTE FOR A CLUSTERFIELD

[0001] The subject matter disclosed herein relates to container clusters and more particularly relates to communication between an external node running an external application and a cluster of pods executing an instance of an application.BACKGROUND

[0002] Servers and other computing devices often run containers. The containers often include pods executing applications. A server or other computing device, each of which may be called a node, runs one or more containers and the pods and / or containers may be grouped into a cluster running a cluster protocol, such as a  cluster. In some instances, a computing device external to the cluster, which may be called an external node, runs an application ( “external application” ) that needs to access the pods of the cluster.

[0003] As an example, a system management application is used to communicate with servers of a datacenter or other location with managed servers. Typically, each server includes a baseboard management controller ( “BMC” ) and the system management application communicates with the BMC of a server over a management network separate from a main data network. The system management application performs various management task via the BMC of a server.

[0004] Prior to use, the system management application must be tested. However, a large bank of servers each with a BMC available for testing the system management application is cost prohibitive, so a common method of testing the system management application is to simulate the servers and BMCs on computing devices where software simulating the servers and BMCs runs typically in containers. The computing devices may be servers, desktop computers, or the like. Each simulated server and associated BMC is often running within a pod within a container of a computing device, which is often called a node. The pods and nodes are often grouped in a cluster and communicate using a cluster protocol. Often a large number of servers and associated BMCs are simulated using a cluster of nodes where each node typically includes several pods. BRIEF SUMMARY

[0005] A method for intelligent pod routing for a cluster is disclosed. An apparatus and a system also perform the functions of the method. The method includes deploying an intelligent route service on each of one or more nodes of a cluster. The one or more nodes each include a physical computing device. The cluster enables the one or more nodes to communicate using a cluster protocol. Each node includes one or more pods. Each pod of the one or more pods  executes an instance of an application. The intelligent route service provides routing information between the one or more pods and an external node located external to the cluster. The method includes starting a container network interface ( “CNI” ) connector on the external node. The CNI connector includes an agent free from a container engine and cluster components. The method includes transmitting an access request to the intelligent route service. The access request is configured to request access by an external application running on the external node to the instances of the application of the one or more pods. The method includes receiving CNI configuration information from the intelligent route service. The CNI configuration information includes configuration information of the cluster and routing information to the one or more pods. The method includes establishing a communication channel between the external application and the instances of the application of the one or more pods through the CNI connector. The communication channel facilitates the external application executing tasks directed to the instances of the application of the one or more pods.

[0006] An apparatus for intelligent pod routing for a cluster includes two or more nodes each with a processor, and non-transitory computer readable storage media storing code. The code is executable by at least one processor of the two or more nodes to perform operations that include deploying an intelligent route service on each of one or more nodes of a cluster. The cluster enables the one or more nodes to communicate using a cluster protocol. Each node includes one or more pods. Each pod of the one or more pods executes an instance of an application. The intelligent route service provides routing information between the one or more pods and an external node located external to the cluster. The external node and the one or more nodes of the cluster include the two or more nodes. The operations include starting a CNI connector on the external node. The CNI connector includes an agent free from a container engine and cluster components. The operations include transmitting an access request to the intelligent route service. The access request is configured to request access by an external application running on the external node to the instances of the application of the one or more pods. The operations include receiving CNI configuration information from the intelligent route service. The CNI configuration information includes configuration information of the cluster and routing information to the one or more pods. The operations include establishing a communication channel between the external application and the instances of the application of the one or more pods through the CNI connector. The communication channel facilitates the external application executing tasks directed to the instances of the application of the one or more pods.

[0007] A system for intelligent pod routing for a cluster includes an external node executing an external application and one or more nodes of a cluster. The one or more nodes  each include a physical computing device. The cluster enables the one or more nodes to communicate using a cluster protocol. Each node includes one or more pods and each pod of the one or more pods executes an instance of an application. The external node is located external to the one or more nodes of the cluster. The external node includes a processor and memory storing code. The code is executable by at least one processor of the external node to perform operations that include deploying an intelligent route service on each of the one or more nodes of the cluster. The intelligent route service provides routing information between the one or more pods and the external node. The operations include starting a CNI connector on the external node. The CNI connector includes an agent free from a container engine and cluster components. The operations include transmitting an access request to the intelligent route service. The access request is configured to request access by the external application running on the external node to the instances of the application of the one or more pods. The operations include receiving CNI configuration information from the intelligent route service. The CNI configuration information includes configuration information of the cluster and routing information to the one or more pods. The operations include establishing a communication channel between the external application and the instances of the application of the one or more pods through the CNI connector. The communication channel facilitates the external application executing tasks directed to the instances of the application of the one or more pods.BRIEF DESCRIPTION OF THE DRAWINGS

[0008] A more particular description of the embodiments briefly described above will be rendered by reference to specific embodiments that are illustrated in the appended drawings. Understanding that these drawings depict only some embodiments and are not therefore to be considered to be limiting of scope, the embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:

[0009] Figure 1 is a schematic block diagram illustrating a system for establishing a communication channel between an external node and a cluster of nodes executing pods that execute one or more instances of an application, according to various embodiments;

[0010] Figure 2 is a schematic block diagram illustrating another system for establishing a communication channel between an external node and a cluster of nodes executing pods that execute one or more instances of an application where a container network interface ( “CNI” ) plugin is used with a routing database, according to various embodiments;

[0011] Figure 3 is a schematic block diagram illustrating another system for establishing a communication channel between an external node and a cluster of nodes executing pods that  execute one or more instances of an application where a cluster application programming interface ( “API” ) is used to transmit a CNI configuration, according to various embodiments;

[0012] Figure 4 is a schematic block diagram illustrating an apparatus for establishing a communication channel between an external node and a cluster of nodes executing pods that execute one or more instances of an application and where the apparatus executes on the external node, according to various embodiments;

[0013] Figure 5 is a schematic block diagram illustrating an apparatus for establishing a communication channel between an external node and a cluster of nodes executing pods that execute one or more instances of an application where the apparatus executes on a cluster, according to various embodiments; and

[0014] Figure 6 is a schematic flow chart diagram illustrating a method for establishing a communication channel between an external node and a cluster of nodes executing pods that execute one or more instances of an application, according to various embodiments.DETAILED DESCRIPTION

[0015] As will be appreciated by one skilled in the art, aspects of the embodiments may be embodied as a system, method or program product. Accordingly, embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc. ) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit, ” “module” or “system. ” Furthermore, embodiments may take the form of a program product embodied in one or more computer readable storage devices storing machine readable code, computer readable code, and / or program code, referred hereafter as code. The storage devices, in some embodiments, are tangible, non-transitory, and / or non-transmission.

[0016] Many of the functional units described in this specification have been labeled as modules, in order to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom very large scale integrated ( “VLSI” ) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as a field programmable gate array ( “FPGA” ) , programmable array logic, programmable logic devices or the like.

[0017] Modules may also be implemented in code and / or software for execution by various types of processors. An identified module of code may, for instance, comprise one or more physical or logical blocks of executable code which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be  physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module.

[0018] Indeed, a module of code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different computer readable storage devices. Where a module or portions of a module are implemented in software, the software portions are stored on one or more computer readable storage devices.

[0019] Any combination of one or more computer readable medium may be utilized. The computer readable medium may be a computer readable storage medium. The computer readable storage medium may be a storage device storing the code. The storage device may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable) , or electrical signals transmitted through a wire.

[0020] More specific examples (a non-exhaustive list) of the storage device would include the following: 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” or Flash memory) , 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 context of this document, 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.

[0021] Code for carrying out operations for embodiments may be written in any combination of one or more programming languages including an object oriented programming language such as Python, Ruby, R, Java, Java Script, Smalltalk, C++, C sharp, Lisp, Clojure, PHP, or the like, and conventional procedural programming languages, such as the "C" programming language, or the like, and / or machine languages such as assembly languages. The code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone  software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network ( “LAN” ) or a wide area network ( “WAN” ) , or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider) .

[0022] Reference throughout this specification to “one embodiment, ” “an embodiment, ” or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, appearances of the phrases “in one embodiment, ” “in an embodiment, ” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment, but mean “one or more but not all embodiments” unless expressly specified otherwise. The terms “including, ” “comprising, ” “having, ” and variations thereof mean “including but not limited to, ” unless expressly specified otherwise. An enumerated listing of items does not imply that any or all of the items are mutually exclusive, unless expressly specified otherwise. The terms “a, ” “an, ” and “the” also refer to “one or more” unless expressly specified otherwise.

[0023] Furthermore, the described features, structures, or characteristics of the embodiments may be combined in any suitable manner. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of embodiments. One skilled in the relevant art will recognize, however, that embodiments may be practiced without one or more of the specific details, or with other methods, components, materials, and so forth. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of an embodiment.

[0024] Aspects of the embodiments are described below with reference to schematic flowchart diagrams and / or schematic block diagrams of methods, apparatuses, systems, and program products according to embodiments. It will be understood that each block of the schematic flowchart diagrams and / or schematic block diagrams, and combinations of blocks in the schematic flowchart diagrams and / or schematic block diagrams, can be implemented by code. This code may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the schematic flowchart diagrams and / or schematic block diagrams block or blocks.

[0025] The code may also be stored in a storage device that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the storage device produce an article of manufacture including instructions which implement the function / act specified in the schematic flowchart diagrams and / or schematic block diagrams block or blocks.

[0026] The code may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the code which execute on the computer or other programmable apparatus provide processes for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0027] The schematic flowchart diagrams and / or schematic block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of apparatuses, systems, methods and program products according to various embodiments. In this regard, each block in the schematic flowchart diagrams and / or schematic block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions of the code for implementing the specified logical function (s) .

[0028] 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. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more blocks, or portions thereof, of the illustrated Figures.

[0029] Although various arrow types and line types may be employed in the flowchart and / or block diagrams, they are understood not to limit the scope of the corresponding embodiments. Indeed, some arrows or other connectors may be used to indicate only the logical flow of the depicted embodiment. For instance, an arrow may indicate a waiting or monitoring period of unspecified duration between enumerated steps of the depicted embodiment. It will also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and code.

[0030] The description of elements in each figure may refer to elements of proceeding figures. Like numbers refer to like elements in all figures, including alternate embodiments of like elements.

[0031] As used herein, a list with a conjunction of “and / or” includes any single item in the list or a combination of items in the list. For example, a list of A, B and / or C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C or a combination of A, B and C. As used herein, a list using the terminology “one or more of” includes any single item in the list or a combination of items in the list. For example, one or more of A, B and C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C or a combination of A, B and C. As used herein, a list using the terminology “one of” includes one and only one of any single item in the list. For example, “one of A, B and C” includes only A, only B or only C and excludes combinations of A, B and C.

[0032] A method for intelligent pod routing for a cluster is disclosed. An apparatus and computer program product also perform the functions of the method. The method includes deploying an intelligent route service on each of one or more nodes of a cluster. The one or more nodes each include a physical computing device. The cluster enables the one or more nodes to communicate using a cluster protocol. Each node includes one or more pods. Each pod of the one or more pods executes an instance of an application. The intelligent route service provides routing information between the one or more pods and an external node located external to the cluster. The method includes starting a container network interface ( “CNI” ) connector on the external node. The CNI connector includes an agent free from a container engine and cluster components. The method includes transmitting an access request to the intelligent route service. The access request is configured to request access by an external application running on the external node to the instances of the application of the one or more pods. The method includes receiving CNI configuration information from the intelligent route service. The CNI configuration information includes configuration information of the cluster and routing information to the one or more pods. The method includes establishing a communication channel between the external application and the instances of the application of the one or more pods through the CNI connector. The communication channel facilitates the external application executing tasks directed to the instances of the application of the one or more pods.

[0033] In some embodiments, the one or more nodes include a master node and one or more worker nodes. The master node includes an intelligent route head service and the one or more worker nodes each include an intelligent route actor service. The CNI connector of the external node is connected to the master node and the intelligent route actor service of the worker nodes communicate with the intelligent route head service to provide access to the one or more pods by the external node. In other embodiments, the intelligent route service includes a firewall configured to allow access from the external node to the one or more pods of the one or more nodes of the cluster. In other embodiments, the CNI configuration information enables the  external application to access the one or more pods and / or the CNI configuration information includes node identifier ( “ID” ) information for the one or more nodes and / or pod ID information of the one or more pods.

[0034] In some embodiments, the one or more nodes of the cluster each include a CNI plugin and the CNI connector includes logic compatible with the CNI plugin on the nodes of the cluster. The CNI plugins of the external node and the one or more nodes of the cluster access a routing database that includes routing information of the CNI configuration information. In other embodiments, the CNI plugin includes one of a FlannelTM plugin, a MACvlan plugin, a Calico plugin, an IPvlan plugin, and a Multus plugin and the routing database includes one of an database, a database, a zookeeperTM database, a database, a badgerDB database, a bolt database, and a Memcached database. In other embodiments, the intelligent route service creates a virtual node representing the external node and a node of the one or more nodes includes a cluster application programming interface ( “API” ) , wherein the CNI connector receives the CNI configuration information from the cluster API, wherein the virtual node maps to the external node within the CNI configuration information.

[0035] In some embodiments, the cluster protocol includes one of Web Services ( “AWS” )  Azure Container InstancesTM,  Cloud RunTM, Google Kubernetes EngineTM Amazon Elastic Kubernetes ServiceTM ( “EKSTM” ) , Azure Kubernetes ServiceTM,  Container Platform,  and In other embodiments, the instance of the application of the one or more pods simulates a server with a baseboard management controller ( “BMC” ) and the external application is a server management application and the servers and BMCs of the one or more pods simulate physical servers and BMCs managed by the server management application connected to the BMCs over a management network.

[0036] An apparatus for intelligent pod routing for a cluster includes two or more nodes each with a processor, and non-transitory computer readable storage media storing code. The code is executable by at least one processor of the two or more nodes to perform operations that include deploying an intelligent route service on each of one or more nodes of a cluster. The cluster enables the one or more nodes to communicate using a cluster protocol. Each node includes one or more pods. Each pod of the one or more pods executes an instance of an application. The intelligent route service provides routing information between the one or more pods and an external node located external to the cluster. The external node and the one or more nodes of the cluster include the two or more nodes. The operations include starting a CNI connector on the external node. The CNI connector includes an agent free from a container engine and cluster components. The operations include transmitting an access request to the  intelligent route service. The access request is configured to request access by an external application running on the external node to the instances of the application of the one or more pods. The operations include receiving CNI configuration information from the intelligent route service. The CNI configuration information includes configuration information of the cluster and routing information to the one or more pods. The operations include establishing a communication channel between the external application and the instances of the application of the one or more pods through the CNI connector. The communication channel facilitates the external application executing tasks directed to the instances of the application of the one or more pods.

[0037] In some embodiments, the one or more nodes include a master node and one or more worker nodes. The master node includes an intelligent route head service and the one or more worker nodes each include an intelligent route actor service. The CNI connector of the external node is connected to the master node and the intelligent route actor service of the worker nodes communicate with the intelligent route head service to provide access to the one or more pods by the external node. In other embodiments, the intelligent route service includes a firewall configured to allow access from the external node to the one or more pods of the one or more nodes of the cluster. In other embodiments, the CNI configuration information enables the external application to access the one or more pods and / or the CNI configuration information includes node ID information for the one or more nodes and / or pod ID information of the one or more pods.

[0038] In some embodiments, the one or more nodes of the cluster each include a CNI plugin and the CNI connector includes logic compatible with the CNI plugin on the nodes of the cluster. The CNI plugins of the external node and the one or more nodes of the cluster access a routing database that includes routing information of the CNI configuration information. In other embodiments, the CNI plugin includes one of a FlannelTM plugin, a MACvlan plugin, a Calico plugin, an IPvlan plugin, and a Multus plugin and the routing database includes one of an database, a database, a zookeeperTM database, a database, a badger database, a bolt database, and a Memcached database. In other embodiments, the intelligent route service creates a virtual node representing the external node and a node of the one or more nodes includes a cluster API. The CNI connector receives the CNI configuration information from the cluster API and the virtual node maps to the external node within the CNI configuration information.

[0039] In some embodiments, the cluster protocol includes one of Web Services ( “AWS” )  Azure Container InstancesTM,  Cloud RunTM, Google Kubernetes EngineTM ( “GKETM” ) , Amazon Elastic Kubernetes ServiceTM  ( “EKSTM” ) , Azure Kubernetes ServiceTM,  Container Platform,  and In other embodiments, the instance of the application of the one or more pods simulates a server with a BMC and the external application is a server management application and the servers and BMCs of the one or more pods simulate physical servers and BMCs managed by the server management application connected to the BMCs over a management network.

[0040] A system for intelligent pod routing for a cluster includes an external node executing an external application and one or more nodes of a cluster. The one or more nodes each include a physical computing device. The cluster enables the one or more nodes to communicate using a cluster protocol. Each node includes one or more pods and each pod of the one or more pods executes an instance of an application. The external node is located external to the one or more nodes of the cluster. The external node includes a processor and memory storing code. The code is executable by at least one processor of the external node to perform operations that include deploying an intelligent route service on each of the one or more nodes of the cluster. The intelligent route service provides routing information between the one or more pods and the external node. The operations include starting a CNI connector on the external node. The CNI connector includes an agent free from a container engine and cluster components. The operations include transmitting an access request to the intelligent route service. The access request is configured to request access by the external application running on the external node to the instances of the application of the one or more pods. The operations include receiving CNI configuration information from the intelligent route service. The CNI configuration information includes configuration information of the cluster and routing information to the one or more pods. The operations include establishing a communication channel between the external application and the instances of the application of the one or more pods through the CNI connector. The communication channel facilitates the external application executing tasks directed to the instances of the application of the one or more pods.

[0041] In some embodiments, the one or more nodes include a master node and one or more worker nodes. The master node includes an intelligent route head service and the one or more worker nodes each include an intelligent route actor service. The CNI connector of the external node is connected to the master node and the intelligent route actor service of the worker nodes communicate with the intelligent route head service to provide access to the one or more pods by the external node. The master node includes a firewall configured to allow access from the external node to the one or more pods of the one or more nodes of the cluster. In other embodiments, the CNI configuration information enables the external application to access the one or more pods and / or the CNI configuration information includes node ID information for the  one or more nodes and / or pod ID information of the one or more pods. In some embodiments, the CNI connector includes a CNI plugin on the external node and the one or more nodes of the cluster each comprise a CNI plugin, and the CNI plugins of the external node and the one or more nodes of the cluster access a routing database that includes routing information of the CNI configuration information. In other embodiments, the intelligent route service creates a virtual node representing the external node and a node of the one or more nodes includes a cluster API. The CNI connector receives the CNI configuration information from the cluster API and the virtual node maps to the external node within the CNI configuration information.

[0042] Figure 1 is a schematic block diagram illustrating a system 100 for establishing a communication channel between an external node 104 and a cluster 112 of nodes 114 executing pods 116 that execute one or more instances of an applications, according to various embodiments. The system 100 includes a communication apparatus 102 executing on an external node 104. The external node 104 is executing an external application 106 and includes a container network interface ( “CNI” ) connector 108 that includes a CNI configuration and routing information to nodes 114 and pods 116 of a cluster 112. The external node 104 is a computing device executing the external application 106 that has a need to communicate with the pods 116. In some examples, the pods 116 execute instances of a single application. In some embodiments, the applications are different. In other embodiments, the instances of the application executing on the pods 116 are configured differently. In some embodiments, the external node 104 is a laptop computer and connects to the pods 116 for debugging applications running on the pods 116. In another example, the external node 104 includes an external application 106 that provides a service to the applications running on some or all of the pods 116. In various embodiments, the external node 104 runs on a physical computing device that may include a rack-mounted server, a desktop computer, a workstation, a laptop computer, or the like.

[0043] In some embodiments, the external application 106 communicates with the pods 116 for testing the instances of the application running on the pods 116. In some examples, the external application 106 is a server management application and the pods 116a, 116b, 116c (generically “116” ) execute software emulating servers and an associated baseboard management controller ( “BMC” ) for each server. In some embodiments, the server management application is the XClarity AdministratorTM by In other embodiments, the server management application is by another company. In some embodiments, the BMC is an controller ( “XCC” ) by or a controller with similar functionality. In some embodiments, the BMC monitors internal physical variables in servers, such as temperature, humidity, power supply voltage, fan speeds, communication parameters, operating system ( “OS” ) functions, and the like and communicates measurements and other data to the external application 106. Typically, the  servers each include a BMC. In some embodiments, the BMC measures and stores power consumption data, utilization data, operational data and other metering data of the server in which the BMC resides.

[0044] The pods 116, in some embodiments, execute within a container within a node 114a, 114b (generically “114” ) . A node 114 is a computing device, such as a rack-mounted server, a desktop computer, a workstation, or the like and may include one or more processors with one or more cores. Processor capacity, memory, and the like may be used to determine how many pods 116 execute on a node 114. Two nodes 114 and three pods 116 are depicted for convenience, but one of skill in the art will recognize that a cluster 112 may include many more nodes 114 and even up to thousands of pods 116. Where the pods emulate servers and BMCs, the number of servers / BMCs emulated via the pods 116 may be in the range of 1000 to 10,000, or possibly higher.

[0045] The system 100 of Figure 1 is depicted with veth0 / veth1 docker0, and eth0, which are network layers within the cluster protocol. Other systems will include other networking layers or layers with a different name. Veth0 and veth1 are a virtual ethernet layer for each pod 116 where a node 114 includes multiple pods 116. In some embodiments, veth0, veth1, etc. connect to the applications running on the pods 116. Where the pods 116 simulate servers and BMCs, in some embodiments, each vethX component simulates a BMC and may be numbered to indicate a separate instance within a node 114. Docker0, in some embodiments, is a network bridge used to route traffic among the pods 116 of a node 114. In some embodiments, for example for a node 114 with a single pod 116, docker0 may not be installed. In some embodiments, eth0 is a container of a node 114. In other embodiments, eth0 is a virtual router and works in conjunction with a physical network interface card ( “NIC” ) of the nodes 114 and / or external node 104 to transmit packets. Note that a single box is depicted in Figure 1 that represents a container ( “eth0” ) as well as the physical computing device of the node 114 or the external node 104.

[0046] Each node 114 of the cluster 112 includes cluster components, which include the software elements used by the container of the node 114. Existing solutions include installing cluster components on the external node 104 to make the external node 104 similar to other nodes 114a, 114b of the cluster 112. A difficulty in the external application 106 accessing the pods 116 in the cluster 112 is that the external node 104 lacks a mechanism to access the subnet of the cluster 112. One mechanism to overcome this difficulty is to make the external node 104 another node in the cluster 112 by fully loading the external node 104 with cluster components to run the cluster protocol on the external node 104.

[0047] However, loading the cluster components on the external node 104 is undesirable due to amount of storage used, having to fully install the cluster components, and the like. The embodiments described herein allow the external node 104 and the external application 106 to access the nodes 114 of the cluster 112 without installing the cluster components. Instead, the external node 104 includes the CNI connector 108, which is a lightweight agent that is run in a non-container node. In some embodiments, the CNI connector 108 implements logic similar to a CNI plugin to be able to join a CNI network to connect with the nodes 114 of the cluster 112. Note that CNI or container network interface is a specification that is followed by various CNI plugins, such as a FlannelTM, a MACvlan, a Calico, an IPvlan, a Multus, or the like. The CNI connector 108 uses CNI configuration information and route information to join a CNI network and connect with the pods 116.

[0048] The external node 104 includes a communication apparatus 102 configured to, in some embodiments, deploy an intelligent route service on each of one or more nodes 114 of a cluster 112 where the cluster 112 enables the one or more nodes 114 to communicate using a cluster protocol. The communication apparatus 102, in some embodiments, starts the CNI connector 108 on the external node 104 and transmits an access request to the intelligent routing service of the nodes 114 where the access request is requesting access by the external application 106 running on the external node 104 to the instances of the application of the one or more pods 116, such as simulated BMCs. In some embodiments, the communication apparatus 102 receives CNI configuration information from the intelligent route service where the CNI configuration information includes configuration information of the cluster 112 and routing information to the one or more pods 116. In some embodiments, the communication apparatus 102 establishes a communication channel between the external application 106 and the instances of the application of the pods 116 through the CNI connector 108. The communication channel then facilitates the external application 106 executing tasks directed to the instances of the application running on the pods 116.

[0049] The nodes 114 include a cluster setup apparatus 118 configured to, in some embodiments, install the intelligent route service on the nodes 114 of the cluster 112 in response to the communication apparatus 102 deploying the intelligent route service. In other embodiments, the cluster setup apparatus 118 sets up CNI configuration information, which includes cluster information about the cluster 112, routing information of the pods 116 and nodes 114, internet protocol ( “IP” ) address information, and other information used by the CNI connector 108 to enable communication between the external application 106 and the pods 116. In some embodiments, the cluster setup apparatus 118 is configured to receive the access request from the external node 104 and responds by transmitting the CNI configuration information to  the external node 104. In some embodiments, the cluster setup apparatus 118 includes creating a simulated node to be used by a cluster API to send the CNI configuration information to the external node 104.

[0050] The veth0, veth1, and docker0 of the nodes 114 include an IP address with a  / 24, which indicates that the network portion of the IP address includes the first three numbers and the last number designates the identifier ( “ID” ) of the host (e.g., node 114) . Note that the external node has a docker0 with an IP address of 172.16.3.1 / 24 so that the network portion is 172.16.3. The first node 114a has a docker0 with an IP address of 172.16.1.1 / 24 and each of the pods 116 have an IP address of 172.16.1.2 / 24 and 172.16.1.3 / 24 respectively. The second node 114b includes a pod with an IP address of 172.16.2.0 / 24. Thus, the external node 104 and two nodes 114 of the cluster 112 all have different subnet masks. The nodes 114 of the cluster 112 are able to communicate using the cluster components. The CNI connector 108 facilitates communication between the external application 106 and the pods 116 of the cluster 112 even though the subnet mask of the docker0 of the external node 104 has a different subnet mask than the pods 116 and docker0 of the cluster 112.

[0051] The external node 104 and nodes 114 of the cluster 112 also include an IP address for communication outside the nodes. The IP address of the external node is 10.240.100.1, the first node 114a has an IP address of 10.240.210.100, and the second node 114b has an IP address of 10.240.202.100. Communication between the nodes is facilitated using a routing table and other network routing methods and devices. In some embodiments, the external node 104 and the nodes 114 of the cluster 112 each include a firewall and packets traversing the firewall are then routed internally using the IP addresses of the docker0, veth0, and veth1 via the cluster protocol. The address of https:  / / 172.16.1.2 / redfish / v1 includes information for a packet to get to the first pod 116a of the first node 114a from the external node 104.

[0052] The external node 104 is connected to the cluster 112 over a computer network. In various embodiments, the computer network may be wired or may include a wireless connection. The computer network may include various equipment, such as a switch, a router, a network server, or the like. In some embodiments, the computer network is a LAN or a similar network type. In some embodiments, the computer network includes multiple networks. In some embodiments, the computer network is wired using copper wire or may include a fiber network. One of skill in the art will recognize other ways to create a computer network to connect the external node 104 to the nodes 114 of the cluster.

[0053] The cluster 112, in some embodiments, includes a network that is a private network separate from the computer network connecting the external node 104. In some embodiments, the cluster 112 includes networking equipment that allows the cluster 112 to be on  a subnet that is not accessible to the external node 104 without the CNI connector 108 and other accommodations discussed herein.

[0054] Figure 2 is a schematic block diagram illustrating another system 200 for establishing a communication channel between an external node 104 and a cluster 112 of nodes 114 executing pods 116 that execute one or more instances of an application where a CNI plugin 210 is used with a routing database 206, according to various embodiments. The system 200 includes a communication apparatus 102 in an external node 104 and a cluster 112 with nodes 114, as with the system 100 of Figure 1. One node 114a is designated as a master node 114a and another node 114b is designated as a worker node 114b. Only one worker node 114b is depicted for convenience, but in other typical embodiments, the cluster 112 will include more than one worker node 114b. In some embodiments, where the system 200 (or the system 100 of Figure 1) includes multiple nodes 114, one node (e.g., 114a) is designated as the master node 114a and other nodes are designated as worker nodes 114 and the external node 104 is configured to communicate with the master node 114a. In some embodiments, the system 200 may include multiple master nodes 114a, each connected to multiple worker nodes 114b.

[0055] The external node 104 is depicted in the system 200 of Figure 2 to include an external application virtual machine ( “VM” ) 202 that runs the external application 106 and the CNI connector 108 and includes a routing table 203. In other embodiments, the external application 106, CNI connector 108, etc. run on a container instead of a VM on the external node 104. In other embodiments, the external application 106, CNI connector 108, etc. run on the external node 104 without a container or VM. The routing table 203 of the external node 104 includes information that the CNI connector 108 is able to use to route packets between the external application 106 and the particular pods 116 of the cluster 112. The 172.16.3.1 / 24 address is not shown in the external node 104, but would be included in the routing table 203.

[0056] In some embodiments, the master node 114a and the worker node 114b include the intelligent route service in the form of an intelligent route head service 204 in the master node 114 and an intelligent route actor service 205 in the worker node 114b. In some embodiments, the intelligent route actor service 205 communicates routing information to the intelligent route head service 204. In some embodiments, the intelligent route head service 204 stores the routing information in a routing database 206. In various embodiments, the routing database includes an  database, a database, a zookeeperTM database, a database, a badger database, a bolt database, or a Memcached database.

[0057] The pods 116 of the cluster 112 are depicted in a pod network 208, which is a virtual network inside the container of the nodes 114. Each pod network 208, in some embodiments, includes a separate namespace. The nodes 114 of the cluster 112 each include a  CNI plugin 210 and the CNI connector 108 is able to communicate using the CNI plugin protocol. In various embodiments, the CNI plugin 210 includes a FlannelTM plugin, a MACvlan plugin, a Calico plugin, an IPvlan plugin, a Multus plugin, or the like. In some embodiments, the intelligent route head service 204 collects CNI configuration information associated with the CNI plugin 210, route information of the nodes 114 and pods 116 and requests the intelligent route actor services 205 to set correct firewall rules for forwarding (e.g. firewall / forwarding 212) . In some embodiments, the intelligent route head service 204 updates the CNI configuration information based on the newly joining external node 104 to the cluster 112 by using the routing database 206. The external node 104 includes the communication apparatus 102 and the nodes 114 of the cluster 112 include the cluster setup apparatus 118.

[0058] The lines and circled numbers of the system 200 of Figure 2 indicate action associated with setting up a communication channel between the external application 106 of the external node 104 and the pods 116 of the cluster 112. A first step (circled number 1) is to deploy the intelligent route service in the form of the intelligent route head service 204 and the intelligent route actor service 205 in the nodes 114 of the cluster 112. The intelligent route head service 204 then collects the CNI configuration information, such as the route information of the pods 116, the IP address of the nodes 114, the IP address of the pods 116, the IP address of the docker0, etc.

[0059] The second step (circle number 2) includes starting the CNI connector 108 on the external node 104 where, in some embodiments, the CNI connector 108 includes an agent free from a container engine and cluster components, meaning that the agent does not include a container engine or any cluster components. The third step (arrow with the circled 3 from the CNI connector 108 to the intelligent route head service 204) is to transmit an access request to the intelligent route head service 204 that requests access by the external application 106 running on the external node 104 to the instances of the application of the one or more pods 116. The access request is directed to the intelligent route head service 204 for access to the instances of the application, such as simulated servers and BMCs, applications providing a service, applications to be debugged, etc. in a specific namespace.

[0060] Step 4 (circled 4 by the arrow from the intelligent route head service 204 to the intelligent route actor service 205) is for the intelligent route head service 204 to collect the CNI configuration information from the intelligent route actor service 205, to ask the intelligent route actor service 205 to set firewall rules for forwarding, and to use the routing database 206 to store the CNI configuration information. The intelligent route head service 204 may also set up a firewall limiting traffic outside the cluster 112. The routing information will be used to limit the  external application 106 on CNI connector 108 side to access only the pods 116 in the specific name space of the cluster 112.

[0061] The fifth step (arrow and circled 5) includes the intelligent route head service 204 transmitting the CNI configuration information to the CNI connector 108. The sixth step (circled 6 in the routing table 203) includes the CNI connector 108 joining the cluster 112 and starting a CNI plugins 210 and updating the routing table 203 of the external node 104 with information from the received CNI configuration. The seventh step (arrow with circled 7) includes establishing a communication channel between the external application 106 and the pods 116, which allows the external application 106 to issue commands to the instances of the application of the pods 116.

[0062] Figure 3 is a schematic block diagram illustrating another system 300 for establishing a communication channel between an external node 104 and a cluster 112 of nodes 114 executing pods that execute one or more instances of an application where a cluster application programming interface ( “API” ) 304 is used to transmit a CNI configuration, according to various embodiments. The system 300 of Figure 3 is similar to the system 200 of Figure 2 except that the routing database 206 is not present, the cluster has a simulated node 302 and the master node 114a includes a cluster API 304.

[0063] The steps of the system 300 of Figure 3 are slightly different. A first step (circled number 1) is to deploy the intelligent route service in the form of the intelligent route head service 204 and the intelligent route actor service 205 in the nodes 114 of the cluster 112. The intelligent route head service 204 then collects the CNI configuration information, such as the route information of the pods 116, the IP address of the nodes 114, the IP address of the pods 116, the IP address of the docker0, etc.

[0064] The second step (circle number 2) includes starting the CNI connector 108 on the external node 104 where the CNI connector 108 includes an agent free from a container engine and cluster components. The third step (arrow with the circled 3 from the CNI connector 108 to the intelligent route head service 204) is to transmit an access request to the intelligent route head service 204 that requests access by the external application 106 running on the external node 104 to the instances of the application of the one or more pods 116. The access request is directed to the intelligent route head service 204 for access to the instances of the application executing on the pods 116 in a specific namespace.

[0065] Step 4 (circled 4 by the arrow from the intelligent route head service 204 to the intelligent route actor service 205) is for the intelligent route head service 204 to collect the CNI configuration information from the intelligent route actor service 205, to ask the intelligent route actor service 205 to set firewall rules for forwarding, and to use the routing database 206 to store  the CNI configuration information. The intelligent route head service 204 may also set up a firewall limiting traffic external to the cluster 112. The routing information will be used to limit the external application 106 on CNI connector 108 side to access only the pods 116 in the specific name space of the cluster 112. Step 4 differs from the system 200 of Figure 2 in that step 4 also includes creation of the simulated node 302 on the cluster 112. The simulated node 302 is a logical resource for mapping the external node 104 to let the cluster API 304 know how to manage the CNI configuration information.

[0066] The fifth step (arrow and circled 5) includes the cluster API 304 transmitting the CNI configuration information to the CNI connector 108. The sixth step (circled 6 in the routing table 203) also differs from the system 200 of Figure 2 in that step 6 includes the CNI connector 108 joining the cluster 112 as the simulated node 302 and starting a CNI plugins 210 and updating the routing table 203 of the external node 104 with information from the received CNI configuration. The seventh step (arrow with circled 7) includes establishing a communication channel between the external application 106 and the pods 116, which allows the external application 106 to issue commands to the instances of the application of the pods 116.

[0067] Figure 4 is a schematic block diagram illustrating an apparatus 400 for establishing a communication channel between an external node 104 and a cluster 112 of nodes 114 executing pods 116 that execute one or more instances of an application and where the apparatus 400 executes on the external node 104, according to various embodiments. The apparatus 400 includes a communication apparatus 102 with a route service module 402, a CNI connector module 404, an access request module 406, a CNI configuration module 408, and a communication channel module 410, which are described below. In some embodiments, the apparatus 400 is implemented with executable code stored on computer readable storage media. In other embodiments, at least a portion of the apparatus 400 is implemented using a programmable hardware device and / or hardware circuits.

[0068] The apparatus 400 includes a route service module 402 configured to deploy an intelligent route service (e.g., 204, 205) on each of one or more nodes 114 of a cluster 112. The one or more nodes 114 each include a physical computing device, such as a rack-mounted server, a desktop computer, a workstation, a mainframe computer, or the like. The cluster 112 enables the one or more nodes 114 to communicate using a cluster protocol, which may include  Web Services ( “AWS” )  Azure Container InstancesTM,  Cloud RunTM, Google Kubernetes EngineTM ( “GKETM” ) , Amazon Elastic Kubernetes ServiceTM ( “EKSTM” ) , Azure Kubernetes ServiceTM,  Container Platform,  or the like.

[0069] In some embodiments, each node 114 includes one or more pods 116. Each pod 116 of the one or more pods 116 executes an instance of an application. The intelligent route service 204, 205 provides routing information between the one or more pods 116 and an external node 104 located external to the cluster 112. In some embodiments, each node 114 includes a container and the pods 116, the intelligent route service 204, 205, veth0, veth1, docker0, eth0, etc. execute within the container. In other embodiments, each node 114 includes a virtual machine and the pods 116, intelligent route service 204, 205, etc. execute in the virtual machine.

[0070] In some embodiments, the intelligent route service 204, 205 is a service that keeps track of IP addresses of the pods 116, nodes 114, docker0, veth0, veth1, and the like. In some embodiments, the intelligent route service 204, 205 tracks information about the cluster 112, such as which nodes 114 are in the cluster 112, cluster protocol information, and the like. In other embodiments, the intelligent route service 204, 205 creates the CNI configuration information in a format suitable for transmission to the CNI connector 108. In some embodiments, the intelligent route service 204, 205 updates configuration information, routing information, etc. when changes are made to the cluster 112. In some embodiments, the intelligent route service 204, 205 includes a firewall configured to allow access from the external node 104 to the one or more pods 116 of the one or more nodes 114 of the cluster 112. In some embodiments, the route service module 402 designates one node 114a as a master node and other nodes as worker nodes 114b and sets up an intelligent route head service 204 on the master node 114a and intelligent route actor services 205 on the worker nodes 114b.

[0071] The apparatus 400 includes a CNI connector module 404 configures to start a CNI connector 108 on the external node 104. In some embodiments, the CNI connector is an agent free from a container engine and cluster components. In the embodiments, the CNI connector 108 enables the external node 104 to connect to the nodes 114 and pods 116 of the cluster 112 without fully installing cluster components, a container engine, and the like. In some embodiments, the CNI connector 108 implements logic similar to whatever CNI plugin 210 is running on the cluster 112. For example, if the CNI plugin 210 is FlannelTM, the CNI connector 108 includes logic compatible with FlannelTM so that the external node 104 is able to communicate with the pods 116 of the nodes 114 of the cluster 112 using the FlannelTM protocol, commands, etc.

[0072] The apparatus 400 includes an access request module 406 configured to transmit an access request to the intelligent route service 204, 205. The access request is configured to request access by the external application 106 running on the external node 104 to the instances of the application of the one or more pods 116. In some examples, the access request includes a general request to access the pods 116 of the cluster 112. In other embodiments, the access  request includes IP addresses of specific pods 116 in the cluster 112. One of skill in the art will recognize other ways to formulate the access request that will be effective in seeking access to the pods 116 of the cluster 112.

[0073] The apparatus 400 includes a CNI configuration module 408 configured to receive CNI configuration information from the intelligent route service 204, 205. The CNI configuration information includes configuration information of the cluster 112 and routing information to the one or more pods 116. In other embodiments, the CNI configuration information includes sufficient to enable the external application 106 to access the one or more pods 116. In other embodiments, the CNI configuration information includes node ID information for the one or more nodes 114 and / or pod ID information of the one or more pods 116. In other embodiments, the CNI configuration information includes information about the cluster 112, such as a cluster ID, which cluster protocol is used by the cluster 112, and the like so that the external application 106 is able to access the pods 116 of the cluster 112. In some embodiments, the CNI configuration module 408 stores all or a portion of the CNI configuration information in a routing table 203 at the external node 104, which may be accessed by the CNI connector 108 and / or the external application 106 to access the pods 116 of the cluster 112.

[0074] The apparatus 400 includes a communication channel module 410 configured to establish a communication channel between the external application 106 and the applications of the pods 116 through the CNI connector 108. In some embodiments, establishing the communication channel includes enabling bidirectional communications between the pods 116 and the external application 106 without having to repeatedly send an access request. In other embodiments, the access request module 406 sends an access request each time the external application 106 seeks access to a different pod (e.g., 116a) .

[0075] The communication channel facilitates the external application 106 executing tasks directed to the external application 106. For example, testing the external application 106 may include issuing various management commands and tasks to one or more pods 116, which in turn respond. A testing routine, in some embodiments, is able to assess responses to management tasks to determine operability of the external application 106. In some embodiments, testing routine is in the form of a monitoring layer that is able to monitor the service management application 106 and pods 116, communications, etc. and is able to analyze commands and responses to determine whether or not the external application 106 is able to pass various tests, procedures, certifications, and the like.

[0076] Figure 5 is a schematic block diagram illustrating an apparatus 500 for establishing a communication channel between an external node 104 and a cluster 112 of nodes 114 executing pods 116 that execute one or more instances of an application where the apparatus  500 executes on a cluster 112, according to various embodiments. The apparatus 500 includes a cluster setup apparatus 118 with a route service module 402, a CNI configuration setup module 502, a request receiver module 504, a CNI configuration transmit module 506, and / or a simulated node setup module 508, which are discussed below. In some embodiments, the apparatus 500 is implemented with executable code stored on computer readable storage media. In other embodiments, at least a portion of the apparatus 500 is implemented using a programmable hardware device and / or hardware circuits.

[0077] In some embodiments, the apparatus 500 includes a route service module 402 configured to deploy an intelligent route service 204, 205 on each of one or more nodes 114 of a cluster 112. In some embodiments, the route service module 402 is substantially similar to the route service module 402 of the apparatus 400 of Figure 4 and acts to deploy the intelligent route services 204, 205 on the nodes 114 of the cluster 112 in response to a request, command, etc. from the route service module 402 of the communication apparatus 102 of the external node 104. In some embodiments, elements of the route service module 402 are distributed between the communication apparatus 102 and the cluster setup apparatus 118.

[0078] The apparatus 500, in some embodiments, includes a CNI configuration setup module 502 configured to enable the intelligent route services 204, 205 to gather routing information, identifiers for the pods 116, nodes 114, etc., cluster information about the cluster 112, and the like to put together the CNI configuration information to be sent to the external node 104 and to be used in routing packets within the cluster 112. In some embodiments, the CNI configuration setup module 502 is part of the intelligent route services 204, 205. In other embodiments, the CNI configuration setup module 502 uses information from the intelligent route services 204, 205 to assemble what is needed to send to the external node 104.

[0079] The apparatus 500 includes, in some embodiments, a request receiver module 504 configured to receive the access request from the access request module 406 and / or the CNI connector 108 and reads the access request. In some embodiments, the apparatus 500 includes a CNI configuration transmit module 506 configured to transmit the CNI configuration information to the external node 104 in response to the request receiver module 504 receiving a proper access request from the external node 104. In some embodiments, the CNI configuration transmit module 506 retrieves the CNI configuration information from one or more of the intelligent route services 204, 205. In other embodiments, the CNI configuration transmit module 506 retrieves the CNI configuration information from the routing database 206.

[0080] In some embodiments, the apparatus 500 includes a simulated node setup module 508 configured to create the simulated node 302. In some embodiments, the simulated node setup module 508 creates the simulated node 302 in response to the access request from the  external node 104. In some embodiments, the simulated node setup module 508 uses information about the external node 104, CNI connector 108, and / or the external application 106 to create the simulated node 302. In other embodiments, the simulated node setup module 508 uses another trigger to start creation of the simulated node 302.

[0081] Figure 6 is a schematic flow chart diagram illustrating a method 600 for establishing a communication channel between an external node 104 and a cluster 112 of nodes 114 executing pods 116 that execute one or more instances of an application, according to various embodiments. The method 600 begins and deploys 602 an intelligent route service 204, 205 on each of one or more nodes 114 of a cluster 112. The one or more nodes 114 each include a physical computing device, such as a rack-mounted server, a desktop computer, or the like. The cluster 112 enables the one or more nodes 114 to communicate using a cluster protocol, such as AWS, Fargate, or the like. Each node 114 includes one or more pods 116 where each pod 116 of the one or more pods 116 executes an instance of an application. The intelligent route service provides routing information between the one or more pods 116 and an external node 104 located external to the cluster 112.

[0082] In some embodiments, the intelligent route services 204, 205 of the cluster 112 gather routing information, cluster information, identifiers, etc. to create CNI configuration information. In some embodiments, the CNI configuration information is stored in a routing database 206, which is used by CNI plugins 210 in the nodes 114 of the cluster 112.

[0083] The method 600 starts 604 a CNI connector 108 on the external node 104 where the CNI connector 108 includes an agent free from (e.g., does not include) a container engine and cluster components. The method 600 transmits 606 an access request to the intelligent route service 204, 205. The access request is configured to request access by an external application 106 running on the external node 104 to the instances of the application of the one or more pods 116. In some embodiments, at least one of the intelligent route services 204, 205 or CNI plugins 210 transmits the CNI configuration information in response to receiving the access request. In other embodiments, the cluster 112 includes a cluster API 304 and a simulated node 302 and the cluster API 304 transmits the CNI configuration information to the external node 104. The method 600 receives 608 the CNI configuration information and establishes 610 a communication channel between the external application 106 and the applications of the pods 116 through the CNI connector 108. In some embodiments, the communication channel facilitates the external application 106 executing tasks directed to the applications executing on the pods 116. The method 600, in some embodiments, tests 612 the external application 106, and the method 600 ends. In various embodiments, all or a portion of the method 600 is implemented  using the route service module 402, the CNI connector module 404, the access request module 406, the CNI configuration module 408, and / or the communication channel module 410.

[0084] Embodiments may be practiced in other specific forms. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

1.A method comprising:deploying an intelligent route service on each of one or more nodes of a cluster, the one or more nodes each comprising a physical computing device, the cluster enabling the one or more nodes to communicate using a cluster protocol, each node comprising one or more pods, each pod of the one or more pods executing an application, the intelligent route service providing routing information between the one or more pods and an external node located external to the cluster;starting a container network interface ( “CNI” ) connector on the external node, the CNI connector comprising an agent free from a container engine and cluster components;transmitting an access request to the intelligent route service, the access request requesting access by an external application running on the external node to the applications of the one or more pods;receiving CNI configuration information from the intelligent route service, the CNI configuration information comprising configuration information of the cluster and routing information to the one or more pods; andestablishing a communication channel between the external application and the applications of the one or more pods through the CNI connector, the communication channel facilitating the external application executing tasks directed to the applications of the one or more pods.2.The method of claim 1, wherein the one or more nodes comprise a master node and one or more worker nodes, wherein the master node comprises an intelligent route head service and the one or more worker nodes each comprise an intelligent route actor service,  wherein the CNI connector of the external node is connected to the master node and the intelligent route actor service of the worker nodes communicate with the intelligent route head service to provide access to the one or more pods by the external node.3.The method of claim 1, wherein the intelligent route service comprises a firewall configured to allow access from the external node to the one or more pods of the one or more nodes of the cluster.4.The method of claim 1, wherein the CNI configuration information enables the external application to access the one or more pods and / or the CNI configuration information comprises node identifier ( “ID” ) information for the one or more nodes and / or pod ID information of the one or more pods.5.The method of claim 1, wherein the one or more nodes of the cluster each comprise a CNI plugin and the CNI connector comprises logic compatible with the CNI plugin on the nodes of the cluster, wherein the CNI plugins of the external node and the one or more nodes of the cluster access a routing database comprising routing information of the CNI configuration information.6.The method of claim 5, wherein the CNI plugin comprises one of a FlannelTM plugin, a MACvlan plugin, a Calico plugin, an IPvlan plugin, and a Multus plugin and wherein the routing database comprises one of an database, a database, a zookeeperTM database, a database, a badger database, a bolt database, and a Memcached database.7.The method of claim 1, wherein the intelligent route service creates a virtual node representing the external node and wherein a node of the one or more nodes comprises a  cluster application programming interface ( “API” ) , wherein the CNI connector receives the CNI configuration information from the cluster API, wherein the virtual node maps to the external node within the CNI configuration information.8.The method of claim 1, wherein the cluster protocol comprises one of Web Services ( “AWS” )  Azure Container InstancesTM,  Cloud RunTM, Google Kubernetes EngineTM ( “GKETM” ) , Amazon Elastic Kubernetes ServiceTM ( “EKSTM” ) , Azure Kubernetes ServiceTM,  Container Platform,  and 9.The method of claim 1, wherein the instance of the application of the one or more pods simulate a server with a baseboard management controller ( “BMC” ) and the external application is a server management application and wherein the servers and BMCs of the one or more pods simulate physical servers and BMCs managed by the server management application connected to the BMCs over a management network.10.An apparatus comprising:two or more nodes each comprising a processor; andnon-transitory computer readable storage media storing code, the code being executable by at least one processor of the two or more nodes to perform operations comprising:deploying an intelligent route service on each of one or more nodes of a cluster, the cluster enabling the one or more nodes to communicate using a cluster protocol, each node comprising one or more pods, each pod of the one or more pods executing an instance of an application, the intelligent route service providing routing information between the one or more pods and an external node located external to the cluster, the external node and the one or more nodes of the cluster comprising the two or more nodes;starting a container network interface ( “CNI” ) connector on the external node, the CNI connector comprising an agent free from a container engine and cluster components;transmitting an access request to the intelligent route service, the access request requesting access by an external application running on the external node to the instances of the application of the one or more pods;receiving CNI configuration information from the intelligent route service, the CNI configuration information comprising configuration information of the cluster and routing information to the one or more pods; andestablishing a communication channel between the external application and the instances of the application of the one or more pods through the CNI connector, the communication channel facilitating the external application executing tasks directed to the instances of the application of the one or more pods.11.The apparatus of claim 10, wherein the one or more nodes comprise a master node and one or more worker nodes, wherein the master node comprises an intelligent route head service and the one or more worker nodes each comprise an intelligent route actor service, wherein the CNI connector of the external node is connected to the master node and the  intelligent route actor service of the worker nodes communicate with the intelligent route head service to provide access to the one or more pods by the external node.12.The apparatus of claim 10, wherein the intelligent route service comprises a firewall configured to allow access from the external node to the one or more pods of the one or more nodes of the cluster.13.The apparatus of claim 10, wherein the CNI configuration information enables the external application to access the one or more pods and / or the CNI configuration information comprises node identifier ( “ID” ) information for the one or more nodes and / or pod ID information of the one or more pods.14.The apparatus of claim 10, wherein the one or more nodes of the cluster each comprise a CNI plugin and the CNI connector comprises logic compatible with the CNI plugin on the nodes of the cluster, wherein the CNI plugins of the external node and the one or more nodes of the cluster access a routing database comprising routing information of the CNI configuration information, wherein the CNI plugin comprises one of a FlannelTM plugin, a MACvlan plugin, a Calico plugin, an IPvlan plugin, and a Multus plugin and wherein the routing database comprises one of an database, a database, a zookeeperTM database, a database, a badger database, a bolt database, and a Memcached database.15.The apparatus of claim 10, wherein the intelligent route service creates a virtual node representing the external node and wherein a node of the one or more nodes comprises a cluster application programming interface ( “API” ) , wherein the CNI connector receives the CNI configuration information from the cluster API, wherein the virtual node maps to the external node within the CNI configuration information.16.The apparatus of claim 10, wherein the cluster protocol comprises one of Web Services ( “AWS” )  Azure Container InstancesTM,  Cloud RunTM, Google Kubernetes EngineTM ( “GKETM” ) , Amazon Elastic Kubernetes ServiceTM ( “EKSTM” ) , Azure Kubernetes ServiceTM,  Container Platform,  and 17.The apparatus of claim 10, wherein the instances of the application of the one or more pods simulate a server with a baseboard management controller ( “BMC” ) and the external application is a server management application and wherein the servers and BMCs of the one or more pods simulate physical servers and BMCs managed by the server management application connected to the BMCs over a management network.18.A system comprising:an external node executing an external application; andone or more nodes of a cluster, the one or more nodes each comprising a physical computing device, the cluster enabling the one or more nodes to communicate using a cluster protocol, each node comprising one or more pods, each pod of the one or more pods executing an instance of an application, wherein the external node is located external to the one or more nodes of the cluster,wherein the external node comprises a processor and memory storing code, the code being executable by at least one processor of the external node to perform operations comprising:deploying an intelligent route service on each of the one or more nodes of the cluster, the intelligent route service providing routing information between the one or more pods and the external node;starting a container network interface ( “CNI” ) connector on the external node, the CNI connector comprising an agent free from a container engine and cluster components;transmitting an access request to the intelligent route service, the access request requesting access by the external application running on the external node to the instances of the application of the one or more pods;receiving CNI configuration information from the intelligent route service, the CNI configuration information comprising configuration information of the cluster and routing information to the one or more pods; andestablishing a communication channel between the external application and the instances of the application of the one or more pods through the CNI connector, the communication channel facilitating the external application executing tasks directed to the instances of the application of the one or more pods.19.The system of claim 18, wherein the one or more nodes comprise a master node and one or more worker nodes, wherein the master node comprises an intelligent route head service and the one or more worker nodes each comprise an intelligent route actor service, wherein the CNI connector of the external node is connected to the master node and the intelligent route actor service of the worker nodes communicate with the intelligent route head service to provide access to the one or more pods by the external node, wherein the master node comprises a firewall configured to allow access from the external node to the one or more pods of the one or more nodes of the cluster.20.The system of claim 18, wherein the CNI configuration information enables the external application to access the one or more pods and / or the CNI configuration information comprises node identifier ( “ID” ) information for the one or more nodes and / or pod ID information of the one or more pods, and wherein one of:the CNI connector comprises a CNI plugin on the external node and the one or more nodes of the cluster each comprise a CNI plugin, wherein the CNI plugins of the external node and the one or more nodes of the cluster access a routing database comprising routing information of the CNI configuration information; andthe intelligent route service creates a virtual node representing the external node and wherein a node of the one or more nodes comprises a cluster application programming interface ( “API” ) , wherein the CNI connector receives the CNI configuration information from the cluster API, wherein the virtual node maps to the external node within the CNI configuration information.

Images