A command identifying a workload for execution within a cluster architecture is received. Responsive to the command, the workload is deployed to a plurality of different runtime engines on one or more compute nodes within the cluster architecture, wherein the plurality of different runtime engines comprise a container-based runtime engine and a virtual machine (VM)-based runtime engine. Performance metrics are received from each of the plurality of different runtime engines corresponding to execution of the workload.

TECHNICAL FIELD

Aspects of the present disclosure relate to the execution of workloads in orchestrated environments and, more particularly, to determining the performance of a given workload in multiple runtime engines of an orchestrated cluster.

BACKGROUND

A container orchestration engine (such as the Red Hat™ OpenShift™ module) may be a platform for developing and running applications and may allow applications, and the data centers that support them, to expand from just a few machines and applications to thousands of machines that serve millions of clients. Orchestration engines comprise a control plane and a cluster of compute nodes on which workloads may be scheduled. In some cases, an orchestration engine may manage pods and/or container applications. A pod may refer to the most basic (smallest) compute unit that can be defined, deployed, and managed by the control plane (e.g., one or more containers deployed together on a single host). The control plane may include a scheduler that is responsible for determining placement of new application onto nodes within the cluster. The scheduler may attempt to find a node that is a good fit for the application based on configured policies and predicates.

DETAILED DESCRIPTION

In computer systems supporting development and execution of application services, virtual machines and/or containers may be used. As an example, a virtual machine (“VM”) may be a robust simulation of an actual physical computer system utilizing a hypervisor to allocate physical resources to the virtual machine. As another example, containers are active components executing on an operating system of a host system that provide an environment for applications to run, while being isolated from other components of the host system. Multiple containers may execute on a single operating system kernel and share the resources of the hardware upon which the operating system is running.

Container-based virtualization systems may be lighter weight than systems using virtual machines with hypervisors, while virtual machines may provide more isolation and/or hardware control. Containers may allow widespread, parallel deployment of computing power for specific tasks. For example, a container may be instantiated to process a specific task and terminated after the task is complete. In large scale implementations, container orchestrators (e.g., Kubernetes™) may be used that manage the deployment and scheduling of large numbers of containers across multiple compute nodes. One example of a container orchestration platform is the Red Hat™ OpenShift™ platform built around Kubernetes.

Orchestrator platforms may employ cluster infrastructures. Cluster infrastructures may include a number of workloads providing services (e.g., applications provided using containers and/or VMs, also referred to as the data plane) and a control plane that manages the execution and/or distribution of the workloads on one or more compute nodes. In a cluster infrastructure, the compute nodes, which may include physical hosts, processors on a physical host, or virtual machines, may be configured as resources for execution of the workloads using the containers and/or VMs of the cluster. The orchestrator platform may move the workload between and among the compute nodes as part of managing the execution of the workload. The control plane of the cluster infrastructure may perform the scheduling and/or load balancing of the containers and/or VMs, and their associated workloads, among the compute nodes.

Within a cluster, there are different types of runtime engines that may be used to execute a workload. For example, some workloads may be deployed as containers within the clusters, some workloads may be deployed as VMs, and other workloads may be deployed as VMs within containers, to name only a few examples. Each of the runtime engines may have different advantages and disadvantages, as will be described further herein.

However, each of the runtime engines may also have additional complexities that may need to be managed and/or understood by a system administrator. In may be difficult for a system administrator to get an accurate picture of the performance of a given workload in the different runtime engines. Not only are the configurations for the different runtime engines complex, but they also may utilize different types of workloads, which may make comparisons between the runtime engines difficult. Variations in performance between runtime engines increase the risk for production issues that may be caused due to misconfiguration of the runtime engine. Minor issues can cause a delay in the delivery and/or performance of an application due to slowness or errors, and major issues can cause a redesign of an entire workload implementation, which can be very expensive both in terms of time and resources.

The present disclosure addresses the above-noted and other deficiencies by providing a framework that is configured to execute a common workload across multiple runtime engines. The framework may automatically deploy the workload to a plurality of runtime engines, with attention to the types of configuration used by the given runtime engine. While running on the various runtime engines, metrics may be maintained which are indicative of the performance of the workload on the respective runtime engine.

In some embodiments, the metrics may be made available in an automated dashboard, so that the performance of the workload on the various runtime engines may be compared. In some embodiments, the workload may include one or more benchmarks that may help characterize the configuration of the runtime engine in areas such as processing performance, networking, memory, and/or storage. In some embodiments, the workload may be, or include, a customized workload from a user that may include unique operations that may be compared between runtime engines.

Embodiments of the present disclosure may provide a fully automated containerized framework that can run against a cluster of an orchestration platform (e.g., OpenShift/Kubernetes) by one command line without substantive additional configuration by the user. Embodiments of the present disclosure may simplify the ability to add custom workloads using minimal configuration that identifies the customized elements within a workload. Embodiments of the present disclosure may provide reliable comparisons between different types of runtime configurations that may be useful for determining deployment decisions since each of the different runtime engines may utilize a substantially identical workload. Embodiments of the present disclosure may provide reliable workload scale testing by running the workload against several different nodes at the same time.

Embodiments of the present disclosure may provide a technological solution that reduces a variance in the execution of container workloads by avoiding or minimizing disruptions caused by improper, or inefficient, configuration. By allowing for a performance of the workload to be compared across multiple runtime engines, a performance of the workload within a cluster environment may be improved. In addition, by comparing a given workload across different runtime engines, an amount of resources (e.g., network, memory, processor) may be reduced as compared to inefficient configurations. In addition, by automating the comparison of the workload execution, in some cases concurrently, an amount of computing resources needed to perform such a comparison may be reduced, along with an administrative overhead to perform such a comparison.

FIG.1is a schematic block diagram that illustrates an example system100, according to some embodiments of the present disclosure.FIG.1and the other figures may use like reference numerals to identify like elements. A letter after a reference numeral, such as “130A,” indicates that the text refers specifically to the element having that particular reference numeral. A reference numeral in the text without a following letter, such as “130,” refers to any or all of the elements in the figures bearing that reference numeral.

As illustrated inFIG.1, the system100includes a control computing device110, and a plurality of node computing devices130. In some embodiments, system100may be a container cluster, though the embodiments of the present disclosure are not limited to such a configuration. InFIG.1, a first node computing device130A, a second node computing device130B, and a third node computing device130C are illustrated, but the embodiments of the present disclosure are not limited to three node computing devices130.

The computing devices110and130may be coupled to each other (e.g., may be operatively coupled, communicatively coupled, may communicate data/messages with each other) via network140. Network140may be a public network (e.g., the internet), a private network (e.g., a local area network (LAN) or wide area network (WAN)), or a combination thereof. In one embodiment, network140may include a wired or a wireless infrastructure, which may be provided by one or more wireless communications systems, such as a WiFi™ hotspot connected with the network140and/or a wireless carrier system that can be implemented using various data processing equipment, communication towers (e.g., cell towers), etc. In some embodiments, the network140may be an L3 network. The network140may carry communications (e.g., data, message, packets, frames, etc.) between the control computing device110and the node computing devices130.

Each computing device110,130may include hardware such as processing device122(e.g., processors, central processing units (CPUs), memory124(e.g., random access memory124(e.g., RAM), storage devices (e.g., hard-disk drive (HDD), solid-state drive (SSD), etc.), and other hardware devices (e.g., sound card, video card, etc.).

Processing device122may include a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets or processors implementing a combination of instruction sets. Processing device122may also include one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like.

Memory124may include volatile memory devices (e.g., random access memory (RAM)), non-volatile memory devices (e.g., flash memory) and/or other types of memory devices. In certain implementations, memory124may be non-uniform access (NUMA), such that memory access time depends on the memory location relative to processing device122. In some embodiments, memory124may be a persistent storage that is capable of storing data. A persistent storage may be a local storage unit or a remote storage unit. Persistent storage may be a magnetic storage unit, optical storage unit, solid state storage unit, electronic storage units (main memory), or similar storage unit. Persistent storage may also be a monolithic/single device or a distributed set of devices. Memory124may be configured for long-term storage of data and may retain data between power on/off cycles of the computing devices110,130.

Each computing device110,130may comprise any suitable type of computing device or machine that has a programmable processor including, for example, server computers, desktop computers, laptop computers, tablet computers, smartphones, set-top boxes, etc. In some examples, each of the computing devices110,130may comprise a single machine or may include multiple interconnected machines (e.g., multiple servers configured in a cluster). The computing devices110,130may be implemented by a common entity/organization or may be implemented by different entities/organizations. For example, control computing device110may be operated by a first company/corporation and one or more node computing devices130may be operated by a second company/corporation.

In some embodiments, the control computing device110may implement a control plane (e.g., as part of a container orchestration engine) of a container cluster including the node computing devices130. The control plane may perform scheduling and/or load-balancing operations on a plurality of pods134. Further detail on the structure of the pods134and the scheduling operations of the control plane will be described herein. In some embodiments, the node computing devices130may each implement a compute node119(e.g., as part of the container orchestration engine). The compute nodes119may execute one of the plurality of pods134, as will be described further herein.

In some embodiments, a container orchestration engine117(also referred to herein as container host engine117), such as the Red Hat™ OpenShift™ module, may execute on the control computing device110and the node computing devices130. The container host engine117may be a platform for developing and running containerized applications and may allow applications and the data centers that support them to expand from just a few machines and applications to thousands of machines that serve millions of clients. Container host engine117may provide an image-based deployment module for creating and executing workloads162.

A workload162may be stored by the container host engine117or a registry server, such as repository150. In some embodiments, the workload162may contain one or more applications163. The applications163may include computer instructions that perform one or more tasks on the node computing devices130. For example, the application163may be configured to be stored in memory124and executed by the processing device122.

In some embodiments, the workload162may be formed and/or stored as an image file. As an example, the workload162may be a container image built from a Dockerfile. The workload162may contain application code, libraries, tools, dependencies, and/or other files used to make an application163run. In some embodiments, the workload162may include one or more base layers. Base layers may define the runtime environment as well as the packages and utilities necessary for the application163to run. The base layers may include static snapshots of the configuration of the application163and may be read-only layers that are not modified during execution of the application163and/or workload162.

An example deployment of the container host engine117may include the control plane on one or more control computing devices110and a cluster of compute nodes119, including compute nodes119A,119B,119C on one or more node computing devices130. The compute nodes119may run the aspects of the container host engine117that are utilized to launch and manage containers154, pods134, VMs155, and other objects. For example, a compute node119may be a physical server that provides the processing capabilities required for running containers154and/or VMs155in the environment. A compute node119may also be implemented as a virtual server, logical container, or GPU, for example.

The basic units that the container host engine117may work with are called pods134. A pod134may refer to one or more containers154and/or VMs155deployed together on a single node computing device130, and is the smallest compute unit that can be defined, deployed, and managed. There are numerous different scenarios when a new pod134may be created. For example, a serverless function may need to scale, and one or more new pods134may be created and deployed to additional compute nodes119of node computing devices130to manage requests for serverless functions provided by containers154and/or VMs155contained within the pods134. InFIG.1, the first node computing device130A is illustrated executing a first pod134A, the second node computing device130B is illustrated executing a second pod134B, and the third node computing device130C is illustrated executing a third pod134C.

Many application instances can be running in containers154and/or VMs155on a compute node119without visibility into other processes, files, network, etc. of other containers154and/or VMs155of the compute node119. In some embodiments, each container154and/or VM155may provide a single function (often called a “micro-service”) or component of the application163, such as a web server or a database. In this way, the container host engine117provides a function-based architecture of smaller, decoupled units that work together.

The control plane of the control computing device110may also run a workload scheduling engine161that may be responsible for determining placement of (i.e., scheduling) of workloads162and/or new pods134onto compute nodes119within the system100. For example, a workload162may be associated with a pod134, which may then be scheduled within the system100. The workload scheduling engine161may read data from the workload162and/or pod134and attempt to find a compute node119that is a good fit based on configured policies. Once a suitable compute node119is found, the workload scheduling engine161may create a binding for the pod134that ties the pod134to the particular compute node119. The workload scheduling engine161may consider the resource needs of a pod134(and/or its associated workload162), such as processing devices122and/or memory124, along with the health of the system100, when making scheduling decisions about the pod134to an appropriate compute node119.

In some embodiments of the present disclosure, the workload scheduling engine161may be configured to deploy and/or execute a same workload162on a plurality of runtime engines170. As used herein, deploying a workload162may include transmitting the workload162to a compute node119of a node computing device130for execution of the workload162. In some embodiments, deployment of the workload162may include communication from the control computing device110to the node computing device130over network140(e.g., using the container host engine117). As used herein, a runtime engine170refers to a configuration of services and/or infrastructure within a pod134that may be used to execute an application163of a workload162. Different runtime engines170may execute a same workload162differently. InFIG.1, three runtime engines170are illustrated, though the embodiments of the present disclosure are not limited to this configuration. InFIG.1, the first node computing device130A is illustrated executing a first runtime engine170A in the first pod134A, the second node computing device130B is illustrated executing a second runtime engine170B in the second pod134B, and the third node computing device130C is illustrated executing a third runtime engine170C in the third pod134C.

FIG.2is a block diagram that illustrates a workload162executing in a plurality of different runtime engines170, according to some embodiments of the present disclosure.FIG.2illustrates additional detail of the first runtime engine170A, the second runtime engine170B, and the third runtime engine170C ofFIG.1. A description of elements ofFIG.2that have been previously described will be omitted for brevity.

Referring toFIGS.1and2, the first runtime engine170A may be a container-based runtime engine170A. For example, the first runtime engine170A may be configured to execute the workload162within a pod134A on a compute node119A that may include hardware (e.g., processing devices, memory, storage devices, other devices, etc.). A container154A may execute as part of the compute node119A (e.g., under control of a host operating system of a node computing device130A. In one embodiment, the container154A may be an isolated set of resources allocated to executing the workload162and may be process independent from other applications, software, and/or processes of the compute node119A. The container154A may also be referred to as a software container154A. In some embodiments, the compute node119A may use namespaces to isolate the resources of the containers154from each other. The container154A may share the kernel, libraries, and binaries of the compute node119A with other containers154that are executing on the compute node119A.

In one embodiment, the runtime engine170A may allow different containers154to share the host OS (e.g., the OS kernel, binaries, libraries, etc.) of the compute node119A. For example, the runtime engine170A may multiplex the binaries and/or libraries of the host OS between multiple containers154. The runtime engine170A may also facilitate interactions between the container154A and the resources of the compute node119A. For example, the runtime engine170A may manage requests from container154to access a memory (e.g., a RAM) of the node computing device130of the compute node119A. In another example, the runtime engine170A may manage requests from the container154to access certain libraries/binaries of the compute node119A. In other embodiments, the runtime engine170A may also be used to create, remove, and manage containers154. In one embodiment, the runtime engine170A may be a component of the host operating system (e.g., Red Hat™ Enterprise Linux) of the compute node119A. In some embodiments, the first runtime engine170A may be based on Kubernetes and/or OpenShift environments.

The second runtime engine170B may be a runtime engine170B incorporating a VM155in a container154B. The second runtime engine170B may also use the container154B in a manner similar to that of the first runtime engine170A. However, the second runtime engine170B may execute a VM155including a guest OS214within a container154B, and isolate the workload162within the VM155. In one embodiment, the VM155may be a software implementation of a machine (e.g., a software implementation of a computing device) that includes its own operating system (the guest OS214), including its own kernel, and executes application programs, applications, software. VM155may be, for example, a hardware emulation, a full virtualization, a para-virtualization, and an operating system-level virtualization VM155. For example, the guest OS214of the VM155may further isolate the workload162from other containers154and/or processes on the compute node119B.

As part of executing the container154B, the compute node119B may execute the VM with its guest OS214, which, in turn, executes the workload162. Thus, the pod134B may be configured to receive a VM image and/or workload162, including a configuration for the VM155, and execute the workload162within the pod134B. The second runtime engine170B may offer additional isolation for the workload162as compared to the first runtime engine170A. In some embodiments, the second runtime engine170B may be based on a KUBEVIRT™ implementation. KubeVirt is an open source project for running a VM based Kubernetes deployment which utilizes custom resource definitions (CRD) to create a virtual machine instance (VMI). With the CRD mechanism, Kube Virt can customize additional operations to adjust for behavior that may not be available in a typical container154.

The third runtime engine170C may be a runtime engine170C incorporating a container154C in a VM155. In one embodiment, the VM155may be a software implementation of a machine (e.g., a software implementation of a computing device) that includes its own operating system (referred to as guest OS214), including its own kernel, and executes application programs, applications, software. VM155may be, for example, a hardware emulation, a full virtualization, a para-virtualization, and an operating system-level virtualization VM155.

VM155may execute guest software that uses an underlying emulation of the physical resources (e.g., virtual processors and guest memory). As illustrated inFIG.2, the VM155of the third runtime engine170C may include the container154C that may execute the workload162. In some embodiments, the compute node119C may expose resources such as a real or emulated processor(s), real or emulated memory, and/or real or emulated storage of the corresponding node computing device130by way of an emulator.

In some embodiments, the pod134C may be configured to receive a workload162, including a configuration for the workload162. The pod134C may be configured to generate the VM155, with its associated guest OS214, and execute the workload162within a container154C within the VM155. The guest OS214may be and/or include a reduced OS kernel and OS infrastructure. This may allow the guest OS214to launch more quickly than traditional VMs, while also using fewer system resources. In some embodiments, the third runtime engine170C may be based on a Kata Container implementation. Kata Containers are an open source project for running a containerized VMs which utilizes a container runtime interface (CRI) to implement a reduced VM to execute a container154.

FIG.2illustrates some of the differences between a container-based first runtime engine170A, a second runtime engine170B incorporating a VM in a container, and a third runtime engine170C incorporating a container in a VM. Each runtime engine170offers different benefits, including isolation and speed of instantiation. For example, while the third runtime engine170C (container in a VM) may offer the most isolation for the workload162, it may be slower to start and/or require more resources to deploy. The first runtime engine170A may be lighter weight, but may rely primarily on namespaces to isolate the workload162from other aspects of the compute node119. The second runtime engine170B may offer improved isolation while remaining relative light weight, but its ultimate performance may depend on the workload162.

Referring back toFIG.1, embodiments of the present disclosure may allow for a same workload162to be sent to each of the runtime engines170so that performance of the runtime engines170may be compared against one another. In some embodiments, the execution of the workload162on the different runtime engines170may be performed concurrently.

For example, in some embodiments, a same workload162may be deployed to each of the first runtime engine170A, the second runtime engine170B, and the third runtime engine170C. In some embodiments, the workload162may be transmitted to each of the runtime engines by the workload scheduling engine161of the control computing device110. In some embodiments, the workload scheduling engine161may modify the workload162so as to be compatible for the different runtime engines170. For example, the workload scheduling engine161may include the workload162within a container154A for the first runtime engine170A, within a container154B including a VM155with a guest OS214(seeFIG.2) for the second runtime engine170, and as part of a VM155including a guest OS214executing a container154C (seeFIG.2) for the third runtime engine170C.

In some embodiments, the workload162may be stored in a repository150accessible to the network140. In some embodiments, the workload scheduling engine161may be configured to access and retrieve the workload162from the repository150. For example, as part of running the workload162, the workload scheduling engine161may be configured to detect a workload162to be run from a provided command105, and to access the repository150dynamically over the network140to retrieve the workload162for deployment to the runtime engines170.

In some embodiments, the command105may be provided by a user of the system100, but the embodiments of the present disclosure are not limited to such a configuration. In some embodiments, the command105may be an automated command that run periodically, such as every day and/or every week. The command105may specify the workload162to be executed, one or more of the runtime engines170to be utilized for the workload162, and other configuration options to be used to facilitate the execution of the workload162, such as authorization credentials.

In some embodiments, the workload162may be provided to the workload scheduling engine161by a client and/or user of the system100. For example, a user may provide a customized workload162to the workload scheduling engine161. Providing a customized workload162may include providing the workload162as an image file (including, e.g., base layers supporting execution of the application163), along with configuration files that may be used to configure the different runtime engines170.

For example, a user may first create a workload162containing an application163to be executed. Creating the workload162may include embedding the application163into an image file, including supporting libraries and/or configuration infrastructure. In some embodiments, applications like Docker may be used to generate a workload162from an instruction script, such as a Dockerfile.

In some embodiments, the user may provide configuration information for each of the first runtime engine170A, the second runtime engine170B, and the third runtime engine170C. For example, for the first runtime engine170A and the third runtime engine170C, generating a customized workload162may include providing a configuration file. In some embodiments, the configuration file may be based on YAML (YAML Ain′t Markup Language). The configuration file may specify the workload162to be utilized and provide additional configuration options that may be utilized to execute the containers154of the first and third runtime engines170A,170C. For the second runtime engine170B, generating a customized workload162may also include providing a configuration file. In some embodiments, the configuration file may be based on YAML. The configuration file may specify the workload162to be utilized and as well as a pointer and/or reference to an image of a VM155to be utilized by the second runtime engine170B to execute the workload162.

In some embodiments, while executing the workload162, the runtime engines may provide performance metrics195to a metrics store190. The metric store190may be accessible to the network140, though the embodiments of the present disclosure are not limited to such a configuration. In some embodiments, the performance metrics195may be provided to the control computing device110.

The performance metrics195may track performance of the runtime engine170and/or the compute node119during execution of the workload162. For example, in some embodiments, the performance metrics195may include data related to memory usage, storage usage, processor usage and/or utilization, system latency, interrupts, I/O throughput, and the like. The list of performance metrics195is merely an example and is not intended to limit the embodiments of the present disclosure.

In some embodiments, the application163of the workload162can be, or include, a benchmark application163. The benchmark application163may be configured to stress certain subsystems (e.g., memory, processor, storage) of the compute node119. In some embodiments, the benchmark application163may be configured to emulate a particular type of application, such as a database or web server, to provide performance metrics195indicating the performance of a particular runtime engine170with respect to that type of application.

In some embodiments, the workload scheduling engine161may transmit the workload162to the plurality of different runtime engines170responsive to a single command105. (InFIG.1, a first runtime engine170A is illustrated on the first node computing device170A, a second runtime engine170B is illustrated on the second node computing device170B, and a third runtime engine170C is illustrated on the third node computing device170C. Thus, rather than having to individually configure different images for different runtime engines170, a single command105may generate performance metrics195from a number of different runtime engines170. In some embodiments, the workload scheduling engine161may be configured to transmit the workload162to the plurality of different runtime engines170on a regular basis, such as every night or every week.

FIG.3is a block diagram that illustrates an example automated flow300of the system100, according to some embodiments of the present disclosure. A description of elements ofFIG.3that have been previously described will be omitted for brevity.

Referring toFIG.3as well as the other figures, the automated flow300may, in some embodiments, include the workload scheduling engine161retrieving the workload162from the repository150. In some embodiments, the workload162may be provided directly to the workload scheduling engine161(e.g., by a user and/or client). In some embodiments, retrieving the workload162may be performed responsive to a command105to concurrently execute the workload162on a plurality of different runtime engines170.

The workload scheduling engine161may distribute the workload162to a plurality of different runtime engines170. For example, the workload scheduling engine161may send the workload162to a first container-based runtime engine170A, to a second runtime engine170B incorporating a VM155in a container154B, and to a third runtime engine170C incorporating a container154C in a VM155. The first container-based runtime engine170A, the second runtime engine170B, and the third runtime engine170C may be similar to the first, second, and third runtime engines170A,170B,170C described herein with respect toFIGS.1and2. In some embodiments, the workload scheduling engine161may prepare the workload162in a format compatible with the respective runtime engine170to which the workload162is being distributed. For example, the workload scheduling engine161may include and/or add VM components, such as operating system components, to the workload162for compatibility with the second runtime engine170B incorporating the VM155in the container154B and/or the third runtime engine170C incorporating the container154C in the VM155.

In some embodiments, the first container-based runtime engine170A, the second runtime engine170B incorporating the VM155in the container154B, and the third runtime engine170C incorporating the container154C in the VM155may execute on different compute nodes119(seeFIG.1) within the system100, though the embodiments of the present disclosure are not limited to such a configuration. In some embodiments, the first container-based runtime engine170A, the second runtime engine170B incorporating the VM155in the container154B, and the third runtime engine170C incorporating the container154C in the VM155may execute on a same compute node119and/or node computing device130(seeFIG.1).

For example, the workload scheduling engine161may select the runtime engines170to which the workload162will be distributed by analyzing available compute nodes119of a cluster (e.g., a Kubernetes cluster). In some embodiments, the workload scheduling engine161may select runtime engines170on different physical node computing devices130. In some embodiments, the workload scheduling engine161may select the different physical node computing devices130such that they have similar levels of resources so that performance between the node computing devices130can be compared. In some embodiments, the workload scheduling engine161may execute each of the runtime engines170on a same node computing device130.

The first container-based runtime engine170A, the second runtime engine170B incorporating the VM155in the container154B, and the third runtime engine170C incorporating the container154C in the VM155may execute the workload162. In some embodiments, the execution may be performed concurrently, but the embodiments of the present disclosure are not limited to such a configuration. In some embodiments, the execution of the workload162may be performed on different ones of the first container-based runtime engine170A, the second runtime engine170B incorporating the VM155in the container154B, and the third runtime engine170C incorporating the container154C in the VM155at different times.

Based on the execution of the workload162, each of the first container-based runtime engine170A, the second runtime engine170B incorporating the VM155in the container154B, and the third runtime engine170C incorporating the container154C in the VM155may provide performance metrics195to the metrics store190. For example, the first container-based runtime engine170A may generate first performance metrics195A while executing the workload162, the second runtime engine170B incorporating the VM155in the container154B may generate second performance metrics195B while executing the workload162, and the third runtime engine170C incorporating the container154C in the VM155may generate third performance metrics195C while executing the workload162. The performance metrics195may indicate an impact of the execution of the workload162on the respective runtime engine170.

In some embodiments, the performance metrics195of the metrics store190may be used to generate a dashboard310. The dashboard310may provide a user interface, such as a graphical user interface (GUI) that illustrates the performance of the workload162on different ones of the runtime engines170. In some embodiments, the dashboard310may include graphs of different elements of the performance metrics195compared across different ones of the runtime engines170. In some embodiments, the dashboard310may include a heatmap that identifies areas of high or low performance during the execution of the workload162.

In some embodiments, the performance metrics195and/or the dashboard310may be used to compare performance of the workload162across the runtime engines170. Since a same workload162is used for each of the runtime engines170the comparison may be judging similar characteristics for similar types of operations. Thus, the comparison of the different runtime engines170may be comparable, like-for-like, comparison of the performance metrics195. In some embodiments, the performance metrics195and/or the dashboard310may be used to select one of the plurality of runtime engines170for deployment of the workload162, or for the deployment of a similar workload within the system100.

As illustrated inFIG.3, embodiments of the present disclosure provide a streamlined mechanism for comparing runtime engines170. The runtime engines170can be compared in a real-world environment using embodiments of the present disclosure that generate performance metrics195that may show benchmark results for each of the runtime engines170. The performance metrics195may be directly comparable since they are generated by the same workload162. By using the workload scheduling engine161to control the distribution of the workload162to different types of runtime engines170, embodiments of the present disclosure reduce an amount of resources needed to compare runtime engines170, and provide greater technical accuracy for the comparison of the runtime engines170, yielding a more accurate comparison and resulting deployment.

FIG.4is a flow diagram of a method400for scheduling a software container, in accordance with some embodiments of the present disclosure. Method400may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, a processor, a processing device, a central processing unit (CPU), a system-on-chip (SoC), etc.), software (e.g., instructions running/executing on a processing device), firmware (e.g., microcode), or a combination thereof. In some embodiments, the method400may be performed by a computing device (e.g., computing device110illustrated inFIG.1).

With reference toFIG.4, method400illustrates example functions used by various embodiments. Although specific function blocks (“blocks”) are disclosed in method400, such blocks are examples. That is, embodiments are well suited to performing various other blocks or variations of the blocks recited in method400. It is appreciated that the blocks in method400may be performed in an order different than presented, and that not all of the blocks in method400may be performed.

Referring simultaneously toFIGS.1to3as well, the method400begins at block410, in which a command is received identifying a workload for execution within a cluster architecture. In some embodiments, the workload may correspond to the workload162as described herein with respect toFIGS.1to3. In some embodiments, the command may correspond to the command105as described herein with respect toFIGS.1to3. In some embodiments, the workload comprises a performance benchmark application.

At block420, responsive to the command, the workload is deployed to a plurality of different runtime engines on one or more compute nodes within the cluster architecture. The plurality of different runtime engines may include a container-based runtime engine and a VM-based runtime engine. In some embodiments, the plurality of different runtime engines may correspond to the runtime engines170described herein with respect toFIGS.1to3. For example, the container-based runtime engine may be similar, at least, to the first and second runtime engines170A,170B, and the VM-based runtime engine may be similar, at least, to the second and third runtime engines170B,170C, as described herein with respect toFIGS.1to3. In some embodiments, the one or more compute nodes may correspond to the compute nodes119described herein with respect toFIGS.1to3. In some embodiments, deploying the workload to the plurality of different runtime engines on the one or more compute nodes within the cluster architecture includes executing the workload on each of the plurality of different runtime engines concurrently.

In some embodiments, the plurality of different runtime engines further include a runtime engine incorporating a VM within a container. For example, the runtime engine incorporating the VM within the container may be similar, at least to the second runtime engine170B, as described herein with respect toFIGS.1to3. In some embodiments, deploying the workload to the plurality of different runtime engines on the one or more compute nodes within the cluster architecture includes deploying the workload to a respective pod executing on the one or more compute nodes. In some embodiments, the pod may correspond to the pod134described herein with respect toFIGS.1to3. In some embodiments, the runtime engine is to execute the workload within a container of the respective pod, the container comprising the VM.

At block430, performance metrics are received from each of the plurality of different runtime engines corresponding to execution of the workload. In some embodiments, the performance metrics may correspond to the performance metrics195described herein with respect toFIGS.1to3.

In some embodiments, the workload is a first workload, and the method400further includes deploying a second workload to one of the plurality of different runtime engines based on the performance metrics. In some embodiments, the method400further includes generating a heatmap that illustrates a performance of each of the plurality of different runtime engines based on the performance metrics. In some embodiments, the method400further includes receiving the workload and a plurality of configuration files corresponding to the workload, wherein the plurality of configuration files indicate configuration options for each of the plurality of different runtime engines.

FIG.5is a component diagram of an example of a device architecture500, in accordance with embodiments of the disclosure. The device architecture500includes computing device110having processing device122and memory124, as described herein with respect toFIGS.1to4.

The computing device110may receive a command105identifying a workload162for execution within a cluster architecture. The workload162may include an application163, which may be a performance benchmark application in some embodiments, as described herein with respect toFIGS.1to4.

The computing device110may, responsive to the command105, deploy the workload162to a plurality of different runtime engines170A,170C on one or more compute nodes119within the cluster architecture. The plurality of different runtime engines170A,170C may include a container-based runtime engine170A and a VM-based runtime engine170C. The deployment of the workload162may be performed similarly to the operations described herein with respect toFIGS.1to4.

The computing device110may receive performance metrics195from each of the plurality of different runtime engines170A,170C corresponding to execution of the workload162. In some embodiments, the performance metrics195may be used to evaluate the performance of each of the different runtime engines170A,170C. In some embodiments, a deployment of subsequent workloads162may be adjusted based on the performance metrics195. For example, responsive to the performance metrics195, subsequent workloads162(e.g., a second workload162) having an execution profile similar to the workload162used to generate the performance metrics195may be deployed and/or assigned to one of the different runtime engines170A,170C having the best performance, as indicated by the performance metrics195.

The device architecture500ofFIG.5provides a technological capability to dynamically compare performance of the execution of the workload162of different runtime engines170A,170C, including runtime engines170that include configurations that are implemented through the use of containers154and configurations that are implemented through the use of VMs155. As further described herein, runtime engines, such as runtime engine170B described with respect toFIGS.1to4, may also be used that combine containers154and VMs155. Embodiments of the present disclosure provide a single scheduling interface that can execute multiple types of runtime engine configurations and collect performance metrics195responsive to the execution. Embodiments of the present disclosure allow for the performance of different runtime engines170to be compared, while reducing the resources required to make such a comparison.

Embodiments of the present disclosure may provide one framework for cluster deployment, workload execution, and results visualization. Embodiments of the present disclosure may also provide a fully automated containerized framework that can be executed against a cluster by a single command line105without requiring a precondition install. Embodiments of the present disclosure may also simplify a way for a user to provide a workload162(such as a dockerfile) while other aspects of configuration of the runtime engines170are managed for the user. Embodiments of the present disclosure may also provide a reliable comparison of at least three runtime engines170, while also providing workload scale testing by running the workload162against a plurality of compute nodes119concurrently.

The example computing device600may include a processing device (e.g., a general purpose processor, a PLD, etc.)602, a main memory604(e.g., synchronous dynamic random access memory (DRAM), read-only memory (ROM)), a static memory606(e.g., flash memory and a data storage device618), which may communicate with each other via a bus630.

Computing device600may further include a network interface device608which may communicate with a network620. The computing device600also may include a video display unit610(e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device612(e.g., a keyboard), a cursor control device614(e.g., a mouse) and an acoustic signal generation device616(e.g., a speaker). In one embodiment, video display unit610, alphanumeric input device612, and cursor control device614may be combined into a single component or device (e.g., an LCD touch screen).

Data storage device618may include a computer-readable storage medium628on which may be stored one or more sets of instructions625that may include instructions for a component (e.g., workload scheduling engine161discussed herein) for carrying out the operations described herein, in accordance with one or more aspects of the present disclosure. Instructions625may also reside, completely or at least partially, within main memory604and/or within processing device602during execution thereof by computing device600, main memory604and processing device602also constituting computer-readable media. The instructions625may further be transmitted or received over a network620via network interface device608.