DYNAMIC SUPPORT CONTAINERS FOR CONTAINERIZED APPLICATIONS

A computer system provides dynamic support containers for containerized applications. A pod is instantiated comprising one or more containers and a sidecar container, wherein execution of the sidecar container is temporarily suspended after initialization. It is determined that a container of the one or more containers requires additional computing resources. In response to determining that the container requires additional computing resources, execution of the sidecar container is resumed and the sidecar container is provided with instructions to perform a computing task of the container. In response to determining that the computing task is complete, execution of the sidecar container is suspended. Embodiments of the present invention further include a method and program product for providing dynamic support containers for containerized applications in substantially the same manner described above.

BACKGROUND

1. Technical Field

Present invention embodiments relate to cloud computing and virtualization, and more specifically, to dynamic support containers for containerized applications.

2. Discussion of the Related Art

Operating system-level virtualization is a computing paradigm in which a kernel supports the existence of multiple isolated instances called containers. A containerized application refers to an application that can be distributed across multiple containers, with each container performing specific tasks. In the context of cloud computing, containerized applications tend to reduce the hardware requirements of servers because sharing an operating system kernel across containers reduces the number of individual operating systems that need to be supported. Additionally, containerized applications are scalable, as multiple instances of an application can be instantiated on demand. However, while scalability can be achieved by providing multiple instances of an application, scaling within an application itself can be difficult to achieve.

SUMMARY

According to one embodiment of the present invention, a computer system provides dynamic support containers for containerized applications. A pod is instantiated comprising one or more containers and a sidecar container, wherein execution of the sidecar container is temporarily suspended after initialization. It is determined that a container of the one or more containers requires additional computing resources. In response to determining that the container requires additional computing resources, execution of the sidecar container is resumed and the sidecar container is provided with instructions to perform a computing task of the container. In response to determining that the computing task is complete, execution of the sidecar container is suspended. Embodiments of the present invention further include a method and program product for providing dynamic support containers for containerized applications in substantially the same manner described above.

Accordingly, present invention embodiments provide the benefit of reducing the amount of computing resources utilized by containerized applications, thereby improving their efficiency. In some embodiments, the sidecar container is suspended by saving a state of the sidecar container. Thus, the sidecar container can resume execution based on the same state in which the sidecar container was previously suspended. In some embodiments, the computing task is selected from a group of: a report generation task, a backup task, a log transfer task, a user-initiated task, and an optimization task. Thus, particular tasks can be defined or identified that will be offloaded to the sidecar container, enabling main containers to commit resources to their assigned tasks. In some embodiments, the sidecar container executes a script to perform the computing task, and the script includes instructions to suspend the sidecar container in response to completing the computing task. Thus, the sidecar container will automatically suspend execution when the sidecar container is not needed. In some embodiments, an amount of computing resources is reserved to make the computing resources available to the sidecar container when execution of the sidecar container is resumed. By reserving computing resources, present invention embodiments ensure that the sidecar container can resume execution. In some embodiments, the reserved amount of computing resources is used to perform low-priority actions while execution of the sidecar container is suspended, and the low-priority actions are interrupted when execution of the sidecar container is resumed. Thus, the reserved resources can actually be used for other tasks, thereby increasing the efficiency of the containerized applications. In some embodiments, a liveness probe is used to verify that execution of the sidecar container is suspended. The liveness probe can confirm that a sidecar container is suspended, and if not, actions can be taken to suspend the sidecar container.

DETAILED DESCRIPTION

Present invention embodiments relate to cloud computing and virtualization, and more specifically, to dynamic support containers for containerized applications. A containerized application is typically administrated by a container orchestration system, which controls the configuration, deployment, execution, and other management aspects of containerized applications. A container orchestration system, or orchestrator, may launch a containerized application by instantiating the composite containers from stored images.

Some container orchestrators, such as Kubernetes, make distinctions between types of containers. Typically, there are “main” containers that are designed to focus on a particular task (or set of tasks), and support containers, also referred to as “sidecar” containers, which are coupled to main containers and can perform supplemental tasks to support the other containers. A pod refers to a group of main containers, and optionally, one or more sidecar containers, that function cohesively as an application. When some set of conditions are met, a main container can offload a task to a sidecar container, thus enabling the main container to continue to dedicate resources toward its intended task while the sidecar container handles the assigned operations. However, sidecar containers consume computing resources throughout runtime, despite not being used during much of a containerized application's execution.

Accordingly, present invention embodiments provide dynamic sidecar containers that can be suspended when not necessary, thus providing the practical application of reducing the computing resources (e.g., processing resources, memory resources, network resources, etc.) used by a containerized application. In contrast to conventional sidecar containers, dynamic sidecar containers only consume system resources during actual use, thus increasing the overall efficiency of containerized applications. Additionally, since fewer sidecar containers are active at any given moment for a grouping of containerized applications, a customer's total number of licenses in concurrent use is reduced, thus enabling the same results to be achieved without requiring the purchase of additional licenses. Furthermore, present invention embodiments can reserve computing resources for dynamic sidecar containers to ensure that the resources are available when a dynamic sidecar container is required again. Computing resources can be reserved in a manner that enables other computing and/or networking tasks to be performed while still maintaining the system resources for usage by the dynamic sidecar container when necessary. Thus, the embodiments presented herein improve the field of virtualization and cloud computing by increasing the efficiency of containerized applications and reducing the overall computing resource requirements of containerized applications.

In some embodiments, the sidecar container is suspended by saving a state of the sidecar container. Thus, the sidecar container can resume execution based on the same state in which the sidecar container was previously suspended. In some embodiments, the computing task is selected from a group of: a report generation task, a backup task, a log transfer task, a user-initiated task, and an optimization task. Thus, particular tasks can be defined or identified that will be offloaded to the sidecar container, enabling main containers to commit resources to their assigned tasks. In some embodiments, the sidecar container executes a script to perform the computing task, and the script includes instructions to suspend the sidecar container in response to completing the computing task. Thus, the sidecar container will automatically suspend execution when the sidecar container is not needed. In some embodiments, an amount of computing resources is reserved to make the computing resources available to the sidecar container when execution of the sidecar container is resumed. By reserving computing resources, present invention embodiments ensure that the sidecar container can resume execution. In some embodiments, the reserved amount of computing resources is used to perform low-priority actions while execution of the sidecar container is suspended, and the low-priority actions are interrupted when execution of the sidecar container is resumed. Thus, the reserved resources can actually be used for other tasks, thereby increasing the efficiency of the containerized applications. In some embodiments, a liveness probe is used to verify that execution of the sidecar container is suspended. The liveness probe can confirm that a sidecar container is suspended, and if not, actions can be taken to suspend the sidecar container.

It should be noted that references throughout this specification to features, advantages, or similar language herein do not imply that all of the features and advantages that may be realized with the embodiments disclosed herein should be, or are in, any single embodiment of the invention. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present invention. Thus, discussion of the features, advantages, and similar language, throughout this specification may, but do not necessarily, refer to the same embodiment.

These features and advantages will become more fully apparent from the following drawings, description and appended claims, or may be learned by the practice of embodiments of the invention as set forth hereinafter.

Present invention embodiments will now be described in detail with reference to the Figures.FIG.1is a block diagram depicting a computing environment100for a containerized application in accordance with an embodiment of the present invention. As depicted, computing environment100includes a client device105, an application server120, and a network155. It is to be understood that the functional division among components of computing environment100have been chosen for purposes of explaining present invention embodiments and is not to be construed as a limiting example.

Client device105includes a network interface (I/F)106, at least one processor107, and a memory110. Memory110may include a client module115. Client device105may include a laptop computer, a tablet computer, a netbook computer, a personal computer (PC), a desktop computer, a personal digital assistant (PDA), a smart phone, a thin client, or any programmable electronic device capable of executing computer readable program instructions. Network interface106enables components of client device105to send and receive data over a network, such as network155. In general, client device105enables an end user to access servers, such as application server120, in order to perform computing tasks like designing containerized applications, modifying containerized applications, executing containerized applications, and the like. Client device105may include internal and external hardware components, as depicted and described in further detail with respect toFIG.5.

Client module115may include one or more modules or units to perform various functions of present invention embodiments described below. Client module115may be implemented by any combination of any quantity of software and/or hardware modules or units, and may reside within memory110of client device105for execution by a processor, such as processor107.

Client module115enables a user to access application server120in order to perform operations relating to containerized applications. In some embodiments, client module115enables a user to upload or select virtualization images for containers (e.g., indicating states of software and/or hardware, etc.) that will be included in a containerized application. In some embodiments, client module115transmits commands, based on user input, to cause settings or configurations of a containerized application to be modified. Additionally or alternatively, client module115may transmit instructions to cause a containerized application to be instantiated, to cause a containerized application to perform a particular computing task, and the like. In some embodiments, client module115enables a user to specify certain instructions or tasks that should be performed by main containers (e.g., containers140A-140N) and/or sidecar containers (e.g., sidecar container145).

Application server120includes a network interface (I/F)121, at least one processor122, memory125, and a database150. Memory125may include an orchestrator module130, and a pod135that includes one or more containers140A-140N and at least one sidecar container145. Application server120may include a laptop computer, a tablet computer, a netbook computer, a personal computer (PC), a desktop computer, a personal digital assistant (PDA), a smart phone, a thin client, a rack-mounted server, or any programmable electronic device capable of executing computer readable program instructions. Network interface121enables components of application server120to send and receive data over a network, such as network155. In general, application server120hosts containerized applications by storing images of containers (e.g., indicating states of software and/or hardware, etc.), instantiating containers, supporting the execution of containers, and any other functions necessary to support containerized applications. In some embodiments, application server120is a cloud computing server that provides on-demand computing power without necessarily relying on direct active management by an end user. Application server120may include internal and external hardware components, as depicted and described in further detail with respect toFIG.5.

Orchestrator module130, pod135, containers140A-140N, and sidecar container145may include one or more modules or units to perform various functions of present invention embodiments described below. Orchestrator module130, pod135, containers140A-140N, and sidecar container145may be implemented by any combination of any quantity of software and/or hardware modules or units, and may reside within memory125of application server120for execution by a processor, such as processor122.

Orchestrator module130may be an orchestration system for containerized applications that performs conventional or other orchestration tasks, such as automating deployment, scaling, and operations of containerized applications. In some embodiments, orchestrator module130manages images of containerized application by storing the images in one or more databases (e.g., database150). Orchestrator module130can instantiate image files to create containers that can, alone or in combination, constitute a containerized application.

Orchestrator module130may orchestrate containerized applications based on instructions received from client applications, such as client module115of client device105. Orchestrator module130may instantiate containerized applications, pass instructions from client module115to containerized applications, and terminate containerized applications. Orchestrator module130may suspend or resume the execution of sidecar container145in accordance with present invention embodiments.

While a containerized application can be achieved using a single container, multiple-container applications may also be managed by orchestrator module130. In particular, orchestrator module130may organize, manage, and/or control execution of multiple containers in a grouping referred to as a pod. A pod can correspond to a single containerized application. In the depicted embodiment, pod135includes one or more containers140A-140N and at least one sidecar container145; in various embodiments, orchestrator module130may orchestrate one or more pods simultaneously.

Pod135may be a basic scheduling unit that provides a grouping of containerized components. Pod135may include one or more containers, such as containers140A-140N and sidecar container145. Pod135may provide a level of organization over containers, as each pod can be assigned its own Internet Protocol (IP) address, and pod135may access local disk directories or network disks on behalf of hosted containers. In some embodiments, pod135corresponds to a stand-alone containerized application that is managed by orchestrator module130.

Containers140A-140N may each perform some tasks or combination of tasks to support execution of a containerized application. For example, one container may perform database queries, another container may process data, and another container may write results of processing to a database. Further included in pod135is sidecar container145, which covers event-based high load tasks. Based on the design of a containerized application, orchestrator module130provides tasks to sidecar container145when certain conditions are met, such as a data backup occurring, a user requesting a particular processing job, or a report being generated.

Unlike containers140A-140N, which persist in memory125during runtime of the application associated with pod135, sidecar container145may be suspended when not performing computing tasks in order to free up computing resources. Orchestrator module130may suspend sidecar container145by obtaining a state of sidecar container145during execution and saving the state to a persistent storage, such as database150. Thus, the space in memory125occupied by sidecar container145may be freed, and network interface121and processor122likewise no longer have to support sidecar container145when sidecar container145is not necessary.

Database150may include any non-volatile storage media known in the art. For example, database150can be implemented with a tape library, optical library, one or more independent hard disk drives, or multiple hard disk drives in a redundant array of independent disks (RAID). Similarly, data in database150may conform to any suitable storage architecture known in the art, such as a file, a relational database, an object-oriented database, and/or one or more tables. In some embodiments, database150may store data corresponding to containerized applications, including image files for containers, pod descriptions (e.g., descriptions of which containers are included in a pod), data stored by, generated by, or otherwise used by containerized applications, state data corresponding to suspended sidecar containers, and the like.

Network155may include a local area network (LAN), a wide area network (WAN) such as the Internet, or a combination of the two, and includes wired, wireless, or fiber optic connections. In general, network155can be any combination of connections and protocols known in the art that will support communications between client device105and application server120via their respective network interfaces in accordance with embodiments of the present invention.

FIGS.2A-2Care block diagrams depicting a runtime environment200in accordance with an embodiment of the present invention. As depicted,FIGS.2A-2Cillustrate a same containerized application at different times of execution.

As shown inFIG.2A, runtime environment200includes a pod135, as well as orchestrator module130and database150. Pod135includes containers140A-140N and a sidecar container145. Database150stores images210, which are the executable data files from which orchestrator module130instantiates pod135and its contents (i.e., containers140A-140C and sidecar container145). At the time of execution depicted inFIG.2A, container140A has offloaded a computing task to sidecar container145.

With reference now toFIG.2B, runtime environment200is depicted at a time in which there is no computing task being performed by a sidecar. Accordingly, orchestrator module130suspends execution of sidecar container145, and saves the state of sidecar container145to database150as sidecar state data220. Thus, there is no sidecar container currently encapsulated by pod135at the time of execution depicted inFIG.2B. Orchestrator module130may reserve computing resources for sidecar container145when sidecar container145is suspended such that the computing resources necessary for execution of sidecar container145are available when sidecar container145is resumed. In some embodiments, orchestrator module130may make available the reserved computing resources to low-priority tasks that can be interrupted, such as background computing tasks. Additionally or alternatively, the reserved computing resources can be used for a data backup task, a data analysis task, a data cleansing task, an error-checking task, an indexing task, and the like.

With reference now toFIG.2C, runtime environment200is depicted at a time in which another container, container140B, has encountered a condition that requires offloading of a computing task. Accordingly, orchestrator module130resumes execution of sidecar container145using the saved state data in database150. In the depicted embodiment, sidecar state data220has been purged from database150after resuming executing of sidecar container145; however, in some embodiments, sidecar state data220may be retained temporarily or permanently.

FIG.3is a block diagram depicting an execution timeline300in accordance with an embodiment of the present invention. Initially, one or more container images305and sidecar container image310are used to instantiate a corresponding one or more containers and sidecar container at operation315. After instantiating the sidecar container, the sidecar container may initialize and perform other startup actions, and then may suspend execution (e.g., “sleep”) at operation320. In contrast, the one or more containers continue executing to provide a containerized application.

The containerized application may encounter a particular condition at event325in which one of the containers requires offloading of a computing task to a sidecar container. In response, the sidecar container may resume execution and perform processing at operation330.

When processing is completed, the sidecar container may return the results at operation335. In some embodiments, a sidecar container includes a script that executes to perform a desired computing task, and the script ends by executing instructions to cause the sidecar container to return the results and to suspend execution. Thus, a sidecar container may automatically suspend execution at the completion of any task. The script may further cause the sidecar container to transmit instructions to an orchestrator to cause the orchestrator to save a state of the sidecar container. After the results are returned at operation335, the containerized application itself may perform additional computing tasks and, when completed, terminate at operation340.

FIG.4is a flow chart depicting a method400of providing a containerized application in accordance with an embodiment of the present invention.

A pod corresponding to a containerized application is instantiated at operation410. A container orchestration system, such as orchestrator module130, may instantiate a pod based on a description of the pod that includes the images of the constituent containers of the pod. Each image file may be identified and instantiated to provide a running pod that includes one or more containers and a sidecar container. In some embodiments, the container orchestration system is a Kubernetes orchestrator, and the containers can be instantiated using any images, such as Docker images. The pod may include one or more specialized containers, referred to as “init” containers, that run before application containers in a pod to perform setup and other initialization operations.

Execution of the sidecar container is suspended at operation420. Initially, the sidecar container may be instantiated along with the other containers of a pod. Thus, for example, an orchestrator can check to ensure that the pod can execute at full capacity. At some point after the sidecar container is instantiated, the sidecar container may suspend execution, and the orchestrator can save the state of the sidecar container to persistent storage (e.g., database150).

The containerized application executes at operation430. The one or more containers that constitute the containerized application may perform any desired task. For example, a containerized application may provide database management operations. The containerized application may proceed with execution until conditions are met that require a sidecar container.

Operation440determines whether the sidecar container is required. Based on the configuration of the containerized application, certain tasks may be designated as being performed by the sidecar container rather than a main container. Additionally or alternatively, computing tasks may be selected for offloading to a sidecar container when certain runtime conditions are met, like a container using beyond a threshold amount of processing or memory resources.

If the sidecar container is required, then operation450wakes the sidecar container to perform the requested computing task. Otherwise, the containerized application continues to execute at operation430. Upon resuming execution of the sidecar container, instructions are provided to the sidecar container to cause the sidecar container to perform a requested computing task. In some embodiments, the computing task may include a report generation task in which data is processed to produce a report. For example, the results of processing data may be used to populate a template to output a report. In some embodiments, the computing task includes a backup task, which can include operations such as locating data and copying the data to one or more local or network-accessible storage locations. In some embodiments, the computing task includes a log transfer task, which can involve the transferring of a log's contents from one location to another. In some embodiments, the computing task includes a user-initiated task, including a predefined user-initiated task. Thus, for example, unexpected user behavior, or user-initiated tasks that occur rarely, can automatically wake the sidecar container to ensure that the other containers are not overloaded. In some embodiments, the computing task includes an optimization task, such as identifying and remediating a memory leak, freeing up computing resources, and the like.

Execution of the sidecar container is suspended at operation460. Once the sidecar container completes the requested computing tasks, the sidecar container may again suspend execution to free up computing resources. The orchestrator of the containerized application may save a state of the sidecar container to a persistent storage so that the sidecar container can resume execution at a later time. At any point during execution, the orchestrator may verify whether the sidecar container is suspended or not based on a liveness probe. The liveness probe may include a heartbeat signal that is periodically transmitted by the sidecar container during execution. Additionally or alternatively, the liveness probe may be implemented by the orchestrator transmitting requests to the sidecar container. For example, the orchestrator can ping the sidecar container based on the container IP address, which may belong to a local subnet that is managed by the pod (as the pod has its own IP address for communication with the orchestrator and other network-accessible entities). In some embodiments, if the liveness probe indicates that the sidecar container is executing when the sidecar container has completed a computing task and therefore should be suspended, the orchestrator may transmit instructions to force the sidecar container to suspend execution.

Operation470determines whether the computing job of the containerized application is complete. If the computing job is completed, then the containerized application may terminate. Otherwise, execution of the containerized application continues at operation430.

FIG.5is a block diagram depicting components of a computer10suitable for executing the methods disclosed herein. Computer10may implement client device105and/or application server120in accordance with embodiments of the present invention. It should be appreciated thatFIG.5provides only an illustration of one embodiment and does not imply any limitations with regard to the environments in which different embodiments may be implemented. Many modifications to the depicted environment may be made.

As depicted, the computer10includes communications fabric12, which provides communications between computer processor(s)14, memory16, persistent storage18, communications unit20, and input/output (I/O) interface(s)22. Communications fabric12can be implemented with any architecture designed for passing data and/or control information between processors (such as microprocessors, communications and network processors, etc.), system memory, peripheral devices, and any other hardware components within a system. For example, communications fabric12can be implemented with one or more buses.

Memory16and persistent storage18are computer readable storage media. In the depicted embodiment, memory16includes random access memory (RAM)24and cache memory26. In general, memory16can include any suitable volatile or non-volatile computer readable storage media.

One or more programs may be stored in persistent storage18for execution by one or more of the respective computer processors14via one or more memories of memory16. The persistent storage18may be a magnetic hard disk drive, a solid state hard drive, a semiconductor storage device, read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, or any other computer readable storage media that is capable of storing program instructions or digital information.

The media used by persistent storage18may also be removable. For example, a removable hard drive may be used for persistent storage18. Other examples include optical and magnetic disks, thumb drives, and smart cards that are inserted into a drive for transfer onto another computer readable storage medium that is also part of persistent storage18.

Communications unit20, in these examples, provides for communications with other data processing systems or devices. In these examples, communications unit20includes one or more network interface cards. Communications unit20may provide communications through the use of either or both physical and wireless communications links.

I/O interface(s)22allows for input and output of data with other devices that may be connected to computer10. For example, I/O interface22may provide a connection to external devices28such as a keyboard, keypad, a touch screen, and/or some other suitable input device. External devices28can also include portable computer readable storage media such as, for example, thumb drives, portable optical or magnetic disks, and memory cards.

Software and data used to practice embodiments of the present invention can be stored on such portable computer readable storage media and can be loaded onto persistent storage18via I/O interface(s)22. I/O interface(s)22may also connect to a display30. Display30provides a mechanism to display data to a user and may be, for example, a computer monitor.

Data relating to dynamic support containers for containerized applications (e.g., image data, pod descriptions (e.g., descriptions of which containers are included in a pod), data stored by, generated by, or otherwise used by containerized applications, state data corresponding to suspended sidecar containers, etc.) may be stored within any conventional or other data structures (e.g., files, arrays, lists, stacks, queues, records, etc.) and may be stored in any desired storage unit (e.g., database, data or other repositories, queue, etc.). The data transmitted between client device105and/or application server120may include any desired format and arrangement, and may include any quantity of any types of fields of any size to store the data. The definition and data model for any datasets may indicate the overall structure in any desired fashion (e.g., computer-related languages, graphical representation, listing, etc.).

Data relating to dynamic support containers for containerized applications (e.g., image data, pod descriptions (e.g., descriptions of which containers are included in a pod), data stored by, generated by, or otherwise used by containerized applications, state data corresponding to suspended sidecar containers, etc.) may include any information provided to, or generated by, client device105and/or application server120. Data relating to dynamic support containers for containerized applications may include any desired format and arrangement, and may include any quantity of any types of fields of any size to store any desired data. The data relating to dynamic support containers for containerized applications may include any data collected about entities by any collection mechanism, any combination of collected information, and any information derived from analyzing collected information.

It will be appreciated that the embodiments described above and illustrated in the drawings represent only a few of the many ways of improving the performance and efficiency of containerized applications.

The software of the present invention embodiments (e.g., communications software, server software, client module115, orchestrator module130, pod135, containers140A-140N, sidecar container145, etc.) may be available on a non-transitory computer usable medium (e.g., magnetic or optical mediums, magneto-optic mediums, floppy diskettes, CD-ROM, DVD, memory devices, etc.) of a stationary or portable program product apparatus or device for use with stand-alone systems or systems connected by a network or other communications medium.

The present invention embodiments are not limited to the specific tasks or algorithms described above, but may be utilized for any number of applications in the relevant fields, including, but not limited to, providing improved performance of any cloud computing applications.