Deploying Application Containers of a Distributed Service

Techniques are disclosed relating to deploying application containers. A computer system may receive a request to deploy an application container onto resources of a target environment such that program code of the application container is executed. The deployment of the application container may be carried out in a mode in which the computer system does not allocate resources for the application container. The computer system may receive a request to deploy a placeholder container in the target environment. The deployment of the placeholder container may be carried out in a different mode in which the computer system allocates resources for the placeholder container. The computer system may cause an allocation of additional resources to the target environment on which to execute program code of the placeholder container. In response to the additional resources being allocated, the computer system may deploy the application container onto the additional resources for execution.

BACKGROUND

Technical Field

This disclosure relates generally to computer systems and, more specifically, to various mechanisms for deploying application containers.

Description of the Related Art

Many companies are now shifting from deploying their applications on a local infrastructure to deploying their applications on a cloud infrastructure provided by a cloud provider, such as Amazon™. The cloud provider often provisions virtual machines (VMs) and external storage to be utilized by applications that are deployed (as application containers) onto those VMs. An application container (or, simply “container”) comprises a set of applications and their dependencies, all of which are packaged into a portable, self-sufficient unit. Once an application container is created, it can be deployed onto a VM such that the application(s) included in the container is executed. In various cases, a large-scale deployment system, such as Kubernetes™, is used to automate the deployment, scaling, and management of application containers across multiple VMs. A large-scale deployment system can maintain information about the resources (e.g., VMs and external storages) available to it and utilize that information to deploy application containers onto those resources.

Modern systems routinely enable users to store a collection of information as a database that is organized in a manner that can be efficiently accessed and manipulated. In many cases, the data of that database is stored within a database store that is implemented and managed by a storage service. A database service typically processes database transactions to read and write data while the storage service works to ensure that the results from those database transactions are stored in the database store in a manner that can be efficiently accessed. The storage service can comprise multiple storage applications that enable data to be accessed more efficiently and that serve to prevent data loss by replicating data.

DETAILED DESCRIPTION

A storage service (e.g., Apache BookKeeper) is one of multiple services that may be moved from a company's local infrastructure onto a cloud infrastructure provided by a cloud provider. In order to deploy that storage service, an orchestration system, such as Kubernetes, can be used to deploy the storage applications that together implement the storage service onto the resources provided by the cloud infrastructure. For example, Kubernetes can interact with cloud computing services (e.g., Amazon Web Services™) to provision a virtual machine (VM) and an external storage (e.g., an Amazon Elastic Block Store (EBS) volume) that is external to the computer system on which the VM executes. Accordingly, Kubernetes can deploy a storage application onto the VM and enable the storage application to use the external storage. In many cases, the VM is also connected to a local storage (e.g., a local disk of the computer system on which the VM executes) that provides quicker access to data than the external storage and thus can be used as a cache. As such, a storage application can store data at the local storage during its operation. An issue arises, however, if the storage application crashes and is not coupled to the VM since Kubernetes is likely to deploy that storage application on a different VM with a different local storage. As a result, the work spent filling the local storage of the former VM is worthless as the storage application is not able to use that local storage anymore. It may thus be desirable to couple a storage application server to a VM.

An application can be coupled to a VM through Kubernetes objects. In the Kubernetes context, a storage volume (e.g., a storage area of a solid-state disk) can be logically represented by a particular type of Kubernetes object that is called a persistent volume object (or simply, a persistent volume). A persistent volume can include information about the underlying storage volume, such as its type, storage size, and access path. An application can be associated with a persistent volume claim (PVC) object (or simply, PVC) that identifies the type and the size of the storage desired by that application-PVCs are another type of Kubernetes object. When Kubernetes identifies a persistent volume that meets the requirements of a PVC, Kubernetes binds the persistent volume to the PVC. Consequently, the application is permitted to use that volume. If that volume is a local storage of a VM, then Kubernetes will deploy the application onto that VM since the application's PVC is bound to the persistent volume representing the local storage.

When an application is being readied for deployment, Kubernetes may create the PVC for the application based on information provided for deploying that application. The PVC can include information specifying storage size, access mode (e.g., rw, ro, etc.), and references to a storage class that controls how to provision an external storage persistent volume. To provision the external storage volume, the Dynamic Volume Provisioner Kubernetes plugin from Amazon Web Services (for example) will communicate with Amazon Web Services in order to provision the external storage volume. The provisioning of a VM is facilitated by Cluster Autoscaler (a Kubernetes service) when there is an application pod in a pending state in which the application awaits to be deployed. The pending state can be indicated by a deployment object that is created for the deployment of that application. To provision the VM, Cluster Autoscaler may communicate with Amazon Web Services (for example) in order to provision the VM, and as part of that process, Amazon Web Services may provision a VM. The provisioned external storage persistent volume may then be mounted to the provisioned VM to make it available to the application via a PVC binding. Note that a persistent volume is created for the external storage by Dynamic Volume Provisioner but not for the local storage that is available in the VM. But as mentioned, it might be desirable to use the local storage as a cache for a storage application of a storage service.

In various embodiments, when a VM is provisioned, a local volume provisioner (LVP) application can be deployed onto that VM to discover its local storage and to create a persistent volume for the local storage. Since it may be desirable for a storage application to use the local volume of a node instead of an external volume, the storage application can be set up to request the local volume by configuring its storage class provisioner field to a certain mode, which can be referred to herein as the “no provisioner” mode. But Cluster Autoscaler does not understand this no provisioner mode and thus does not communicate with the cloud provider to provision a VM. Because a VM is not provisioned, the LVP application cannot be deployed onto the VM to create a persistent volume and thus the PVC of a storage application cannot be bound to the non-existent persistent volume. As a result, that storage application remains in a pending state indefinitely. The present disclosure addresses, among other issues, how to ensure that a VM is provisioned whose local volume can be utilized by an application when the application is to be deployed under the no provisioner mode.

In various embodiments described below, a system comprises a target environment and an orchestration service that can deploy application containers onto resources that are included within the target environment. That orchestration service may receive a request to deploy, for a distributed service (e.g., a storage service), an application container onto a set of resources of the target environment such that the application of the application container is executed to implement at least a portion of that distributed service (e.g., to implement a storage application that supports the storage service). In various embodiments, the orchestration service generates a deployment object that indicates the state of the deployment of the application container. The application container is set to deploy in a first mode (e.g., a no provisioner mode) in which the orchestration service does not allocate resources for the application container's deployment. In various embodiments, the orchestration service receives a request to deploy, for a placeholder service, a placeholder container onto resources of the target environment. The deployment of the placeholder container is carried out in a second mode (e.g., a “provisioner” mode) in which the orchestration service allocates resources for the placeholder container's deployment. Thus, the orchestration service may allocate an additional set of resources (e.g., a VM and an external storage) to the target environment (e.g., by communicating with a cloud provider) on which to execute the placeholder container. In response to the additional set of resources being allocated, the orchestration service deploys the application container of the distributed service onto those additional resources for execution. As discussed in more detail below, the orchestration service may deploy an LVP application onto a VM included in the additional set of resources to create a persistent volume that can be bound to a PVC associated with the application container such that the application container can utilize a local volume of the VM. While storage applications are discussed throughout the present disclosure, these techniques can be applied to other types of applications, such as database applications.

These techniques may be advantageous as they enable an application to be deployed in a particular deployment mode that permits the application to utilize a particular resource (e.g., a local volume that is associated with a VM) even when the particular deployment mode does not facilitate the allocation of that particular resource. For example, a storage application may be designed to utilize the local volume of a VM as a cache, but the deployment of that storage application may not cause the VM and its local volume to be allocated. Accordingly, by using a placeholder application to cause an orchestration service (e.g., Kubernetes) to deploy a VM, a local volume can be made available to the storage application despite its deployment mode. Moreover, a storage service may be allowed to scale up as a placeholder service can be scaled in proportion to the storage service in order to provide additional VMs with local volumes that can be used by new deployments of storage applications of the storage service. An exemplary application of these techniques will now be discussed, starting with reference toFIG.1.

Turning now toFIG.1, a block diagram of a system100is shown. System100includes a set of components that may be implemented via hardware or a combination of hardware and software routines. In the illustrated embodiment, system100includes a target environment110(having resources115) and an orchestration service140. As shown, application containers120and placeholder containers130are deployed onto resources115, and orchestration service140includes deployment objects150that specify a deployment mode152and a state154. In some embodiments, system100is implemented differently than shown. As an example, as discussed in greater detail with respect toFIG.3A, there may be a cloud provider that provisions resources115to target environment110.

System100, in various embodiments, implements a platform service (e.g., a customer relationship management (CRM) platform service) that allows users of that service to develop, run, and manage applications. System100may be a multi-tenant system that provides various functionality to users/tenants hosted by the multi-tenant system. Accordingly, system100may execute software routines from various, different users (e.g., providers and tenants of system100) as well as provide code, web pages, and other data to users, databases, and entities (e.g., a third-party system) that are associated with system100. In various embodiments, system100is implemented using a cloud infrastructure provided by a cloud provider. Thus, orchestration service140, application containers120, and/or placeholder containers130may execute on and use the available cloud resources of the cloud infrastructure (e.g., computing resources, storage resources, network resources, etc.) to facilitate their operation. As an example, an application container120may execute in a virtual environment hosted on server-based hardware included within a datacenter of a cloud provider. But in some embodiments, system100is implemented utilizing local or private infrastructure as opposed to a public cloud.

Target environment110, in various embodiments, is a collection of resources115that are available for implementing services (e.g., a database service, a storage service, etc.). Target environment110may correspond to cloud infrastructure provided by a cloud provider and may be available to a particular tenant (e.g., a company). In some embodiments, target environment110is made available to multiple tenants but provides isolation such that the data of one tenant is not exposed (without authorization) to another tenant. For example, target environment110may correspond to the cloud computing platform provided by Amazon Web Services™, which is made available to multiple tenants. Resources115, in various embodiments, include storage resources, networking resources, and computing resources. As an example, resources115may include VMs executing on hardware of a cloud provider and storage volumes implemented via storage disks provided by that cloud provider. But in some embodiments, target environment110is implemented using a private infrastructure managed by the entity that deploys containers120and130.

An application container120, in various embodiments, comprises an application (e.g., a storage server) and its dependencies, all of which are packaged into a portable, self-sufficient unit. Once an application container120is created, it can be deployed onto a VM such that the container's application is executed. While containers and VMs are discussed in this disclosure, in some embodiments, an application can be installed on a computer system and then executed without virtualization or containerization. In order to deploy a service, in various embodiments, a set of application containers120that include the application(s) for implementing that service are deployed onto resources115. For example, to deploy a distributed storage service, multiple application containers120, each having a storage application, may be deployed onto VMs that are provisioned to target environment110. As discussed below, containers120and130can be deployed using orchestration service140.

A placeholder container130, in various embodiments, is a container whose deployment allows for one or more application containers120to be deployed. A placeholder container130may include an application that provides a service, a dummy application that does not provide any meaningful functionality, or no application at all. In various embodiments, the deployment of a placeholder container130can cause a set of additional resources115to be provisioned to target environment110on which to deploy an application container120. The deployment of a placeholder container130may occur under a first deployment mode152that is different than a second deployment mode152used for an application container120. The difference in their deployment modes152causes resources115to be provisioned for a placeholder container130but not an application container120during their respective deployments.

Orchestration service140, in various embodiments, is a service that can orchestrate the deployment of containers120and130onto resources115. Kubernetes™ is an example of an orchestration service140and is a platform capable of automating the deployment, scaling, and management of containerized applications. These capabilities are facilitated via services of the Kubernetes platform that include, but are not limited to, a controller manager, a scheduler, and an application programming interface (API) service. In the Kubernetes context, the controller manager is responsible for running the controllers that interact with the platform, the scheduler is responsible for ensuring that containers have been assigned to a node (e.g., a VM), and the API service exposes the Kubernetes API to users, controllers, and nodes (e.g., the agents that are running on the nodes) so that they can communicate with the Kubernetes platform and with one another. In various embodiments, deploy application requests142and deploy placeholder requests144are received (e.g., from users) via the API service.

To handle the deployment, scaling, and management of containerized applications, the Kubernetes platform stores entities called objects. One example object is a deployment object150that serves as a “record of intent” describing a desired state for a deployment. For example, a deployment object150may represent a user's request to deploy a service or an application. In various embodiments, a deployment object150identifies an object specification and a state154. An object specification identifies characteristics of the desired state of a deployment, such as the container(s)120or130to be deployed, the resources (e.g., network, storage, etc.) to be made available, and the deployment mode152to be used. While the deployment mode152is shown as part of a deployment object150, in various embodiments, the deployment mode152is specified in a Kubernetes object called a persistent volume claim (PVC). The PVC describes the resources requested for a containerized application and is bound to the relevant deployment object150. Thus, the above contents may be included within a single object (e.g., a deployment object150) or spread across multiple objects (e.g., a deployment object150and a PVC). State154, in various embodiments, identifies the state of the deployment, such as pending or active. During the pending state, a container120or130might be waiting for particular resources115to be available that facilitate the operation of the containers. Once a container120or130has deployed and is active, the state154for that container120/130may be updated to “active.” In some embodiments, state154may specify specific details about a deployment. As an example, if a multi-application service is being deployed onto resources115, then the state154for that deployment may indicate which applications have been deployed and which are still pending.

During operation, orchestration service140may receive a deploy application request142to deploy an application container120. That request may specify characteristics pertaining to that application container120, such as the application to deploy and the resources115to be used by the application. Orchestration service140may create a deployment object150based on the information in the deploy application request142—in some cases, that request provides the deployment object150—and set the state154of that deployment object150to pending. If the resources115that are requested for the application container120are not available in target environment110, then that application container120remains in a pending state. Orchestration service140does not allocate resources115for the application container120if the deployment mode152for the application container120does not facilitate it. Orchestration service140may receive a deploy placeholder request144to deploy a placeholder container130. Accordingly, orchestration service140may create (or receive) a deployment object150for the placeholder container130. If the resources115that are requested for the placeholder container130are not available in target environment110, then orchestration service140may allocate the requested resources115as the deployment mode152for the placeholder container130may facilitate it. Orchestration service140may then deploy the placeholder container130onto those allocated resources115. In many cases, the allocated resources115include resources115requested for application container120. Orchestration service140may detect that the application container120is pending and that its requested resources115are available. As such, orchestration service140may deploy the application container120onto the resources115that were provisioned for the placeholder container130. Accordingly, the deployment of the placeholder container130facilitates the deployment of the application container120.

Turning now toFIG.2, a block diagram of example elements that permit an application container120to be bound to a volume210is shown. In the illustrated embodiment, there is an application120, a volume210, a volume object220, and a volume claim230. While not shown, a volume claim230may be a part of a deployment object150of an application container120, or it may be separate from the deployment object150but still associated with that application container120. For example, a deploy application request142may specify a deployment object150and a separate volume claim230for an application container120.

A volume210, in various embodiments, is a storage area that is usable for storing and accessing data. For example, a volume210may be a storage device (e.g., a disk) formatted to store directories and files—thus a volume210may be associated with a file system. In various embodiments, a volume210is a Non-Volatile Memory Express (NVMe) drive that is available via a VM, although a volume210can correspond to any one of a variety of different storage devices (e.g., a hard disk) and be available through other mechanisms. As such, once deployed on that VM, an application container120may access that volume210through an access path and store its data at the volume210. In some cases, a volume210can be a storage volume that is external to a VM but accessible to an application container120(or a placeholder container130) once deployed on that VM.

A volume object220, in various embodiments, is an object representing a volume210and includes information about the volume210, such as its type, size, access path, etc. In some embodiments, each resource115in target environment110that may be used by orchestration service140is represented by an object understood by orchestration service140. Consequently, volume objects220can allow for orchestration service140to determine what storage resources exist in target environment110and are available for use by containers120and130that have not yet been deployed. When a storage resource115is provisioned to target environment110, in various embodiments, orchestration service140(or, in some cases, a cloud service who may have provisioned the storage resource115) creates a volume object220for that resource115. As discussed in greater detail with respect toFIG.4B, orchestration service140may deploy a provisioner program to create a volume object220for a local volume210of a VM.

A volume claim230, in various embodiments, is an object that corresponds to a request for storage resources (e.g., a volume210). A volume claim230may be specified by a user and linked to a container120or130via the container's deployment object150, which may include the volume claim230or reference it. In various embodiments, a volume claim230identifies the type and the size of the storage resources desired by a container120or130. Consequently, when deploying a container120or130, orchestration service140determines, from its volume objects220, whether there are available volumes210within target environment110that satisfy the requirements specified in a volume claim230corresponding to that container. If there is a set of available volumes210that satisfy that volume claim230, then orchestration service140may bind the set of volume objects220(representing those volumes210) to that volume claim230(e.g., via a reference from a volume object220to the volume claim230and/or vice versa). As a result, the container120/130may utilize the underlying set of volumes210, which it may access using the information (e.g., the access path) specified in the corresponding set of volume objects220.

Turning now toFIGS.3A-C, block diagrams of example elements involved in a process for deploying an application container120into target environment110are shown. InFIG.3A, there is target environment110, orchestration service140, and a resource provisioner service310. The illustrated embodiment might be implemented differently than shown. For example, orchestration service140may implement the functionality of resource provisioner service310and thus resource provisioner service310might not be involved in the illustrated process.

As depicted, orchestration service140receives a deploy placeholder request144. That request144may include a deployment object150A corresponding to the placeholder container130being deployed or information for creating deployment object150A. Orchestration service140stores deployment object150A as shown, although it may be stored externally. Since the placeholder container130has not been deployed, its state154can be set to pending. In various embodiments, orchestration service140routinely checks the states154of deployment objects150to determine if there are any in the pending state. Consequently, orchestration service140may observe that the state154of deployment object150A indicates that the deployment of the placeholder container130is pending. In response, orchestration service140may determine if there are available resources115(e.g., by examining volume objects220) on which to deploy the placeholder container130. If there are sufficient resources115, then orchestration service140may bind the placeholder container130to the desired resources115(e.g., bind deployment object150A to a volume object220) and then deploy it onto those resources115. In various embodiments, if there is not a sufficient amount of available resources115for the placeholder container130, then orchestration service140determines how to proceed with the deployment based on the deployment mode152specified by deployment object150A.

As mentioned, in various embodiments, there are at least two deployment modes152for deploying a container120or130. The first deployment mode may be a dynamic provisioner mode that uses dynamic provisioning plugins implemented by a resource owner (e.g., resource provisioner service310) to provision resources115to target environment110. Orchestration service140(or the resource owner) may further create volume objects220for those resources115. The second deployment mode may be a static provisioner mode that relies on the existence of already provisioned resources115and thus does not cause resources115to be provisioned to target environment110. In various embodiments, placeholder containers130are deployed under the first deployment mode and application containers120are deployed under the second deployment mode. Accordingly, in response to there not being sufficient resources115for the placeholder container130, orchestration service140issues a provision resources request305to resource provisioner service310, as shown.

Resource provisioner service310, in various embodiments, is a service or platform that manages resources115, including the provisioning of resources115to target environment110. Amazon Web Services is an example of resource provisioner service310. Accordingly, target environment110may correspond to the cloud infrastructure that is provided by Amazon Web Services. After receiving a provision resources request305, in various embodiments, resource provisioner service310allocates a node320and an external volume330to target environment110. A node320, in various embodiments, can be hardware or a combination of hardware and software. In the illustrated embodiment, node320includes a local volume327(which may be a type of volume210and implemented by an NVMe drive) and a virtual machine325on which the placeholder container130can be deployed. In various embodiments, an external volume330is a block-level storage device that is external but attached to a node320. Consequently, software that is executing on a node320may access the external volume330attached to that node320to read and write data.

After a node320and an external volume330have been provisioned or as a part of the provisioning process, in various embodiments, a volume object220is created for that external volume330. As shown for example, orchestration service140creates volume object220A for the illustrated external volume330—in some embodiments, resource provisioner service310creates volume object220A. Based on volume object220A being created, orchestration service140determines that the requirements specified within a volume claim320A of the placeholder container130can be satisfied. As a result, orchestration service140binds volume claim230A to volume object220A. Consequently, because the requirements of the placeholder container130are met and it is permitted to access the external volume330as a result of the binding, in various embodiments, orchestration service140deploys the placeholder container130into the provisioned virtual machine325, as shown. Once deployed, the application (if there is one) of the placeholder container130may execute and utilize the provisioned external volume330.

Turning now toFIG.3B. When a node320and an external volume330are provisioned by resource provisioner service310, in various embodiments, that node320includes a virtual machine325and a local volume327(e.g., an NVMe disk) that is coupled to the virtual machine325and is not external to that node320. In order for an application container120to utilize the local volume327, orchestration service140may deploy a local volume provisioner340to the virtual machine325to create a volume object220. Accordingly, local volume provisioner340, in various embodiments, is an application that is executable to create a volume object220for a local volume327. In some embodiments, local volume provisioner340is a part of a set of applications that is deployed onto a new node320whenever that node320is provisioned to target environment110. As shown, orchestration service140deploys local volume provisioner340to the illustrated virtual machine325. Once deployed, local volume provisioner340creates a volume object220B for the illustrated local volume327. As discussed with respect toFIG.3C, orchestration service140may then determine to deploy an application container120onto the illustrated node320as that application container's resource requirements may be satisfied in view of volume object220B. In some embodiments, orchestration service140(or resource provisioner service310) may create a volume object220for a local volume327without using local volume provisioner340.

Turning now toFIG.3C. As shown in the illustrated embodiment, orchestration service140receives a deploy application request142to deploy an application container120to target environment110. The deploy application request142can be received before or after the deploy placeholder request144ofFIG.3A. In some embodiments, a single deploy application request142causes the deployment of an application container120and a placeholder container130thus a deploy placeholder request144may not be received. The deploy application request142may include a deployment object150B for the application container120or other information that enables orchestration service140to generate deployment object150B.

During operation, orchestration service140may observe that deployment object150B indicates a pending state154for the deployment of the application container120. In response, orchestration service140determines whether there exist available resources115(e.g., a node320and a local volume327) for the deployment of the application container120. After volume object220B is created (as discussed inFIG.3B), orchestration service140may determine that the storage resources corresponding to volume object220B satisfy the resource requirements of the application container120. Consequently, in various embodiments, orchestration service140binds a volume claim230B of deployment object150B to volume object220B. As a result, the application container140is permitted to utilize the illustrated local volume327as a storage unit. Since the resources requirements of that application container130are met, orchestration service140deploys the application container120into the provisioned virtual machine325, as shown. Once deployed, the application of the application container120may execute and utilize the local volume327. The application container120can thus utilize the local volume327while the placeholder container130utilizes the external volume330. After deploying the application container120, orchestration service120may update the state154of deployment object150B to indicate that the application container120has been deployed and its deployment is no longer pending.

In many cases, a node320may crash or otherwise fail. Thus, in various embodiments, orchestration service140performs garbage collection in which it reviews containers120and130and their deployment objects150and volume objects220and deletes volume objects220that do not have a backing node320or external volume330anymore. Deleting a volume object220may include deleting the binding between that volume object220and a volume claim230. For example, if the illustrated node320crashes, orchestration service140may delete volume objects220A and220B and their binding to volume claims230A and230B, respectively. In response to deleting those bindings or as a part of deleting those bindings, orchestration service140may update the state154of both deployment objects150A and150B to indicate that the deployment of the placeholder container130and the application container120has returned to the pending state. As a result, in various embodiments, orchestration service140reinitiates the process discussed with respect toFIGS.3A-C—that is, orchestration service140communicates with resource provisioner service310to provision a new node320and a new external volume330, creates the relevant volume objects220and bindings, and again deploys the placeholder container130and the application container120to target environment110.

Turning now toFIG.4, a flow diagram of a method400is shown. Method400is one embodiment of a method that is performed by a computer system (e.g., system100) to deploy an application container (e.g., an application container120). Method400can be performed by executing program instructions that are stored on a computer-readable medium. For example, a computer system having at least one processor may execute program instructions stored in a memory of the computer system to perform method400. Method400may include more or less steps or a different ordering of steps that shown. For example, step430may occur before steps410and420.

Method400begins in step410with the computer system receiving a first request (e.g., a deploy application request142) to deploy, for a distributed service, an application container onto a set of resources (e.g., resources115) of a target environment (e.g., target environment110) such that program code of that application container is executed to implement at least a portion of the distributed service. The distributed service is “distributed” in that the instances of the applications (e.g., storage servers) that collectively implement the distributed service are distributed across multiple systems (e.g., multiple nodes within a data center). The distributed service may be a storage service and thus the application container may implement a storage server that is operable to use a local storage (e.g., a local volume327) of a node (e.g., a node320) of the target environment as a cache for caching data of a database.

In step420, the computer system creates a deployment object (e.g., a deployment object150) that indicates a state (e.g., a state154) of the deployment of the application container. In various embodiments, the deployment of the application container is carried out in a first mode (e.g., a “no provisioner” mode) in which the orchestration service does not allocate resources for the deployment of the application container. In step430, the computer system receives a second request (e.g., a deploy placeholder request144) to deploy, for a placeholder service, a placeholder container (e.g., a placeholder container130) onto the set of resources of the target environment. In various embodiments, the deployment of that placeholder container is carried out in a second mode (e.g., a “provisioner” mode) in which the orchestration service allocates resources for the deployment of the placeholder container.

In step440, the computer system causes an allocation of an additional set of resources to the target environment on which to execute program code of the placeholder container. The additional set of resources may include a node on which to deploy the placeholder container and an external storage (e.g., an external volume330) that is external to the node. Causing the allocation of the additional set of resources may include issuing a set of requests (e.g., provision resource requests305) to a cloud service (e.g., resource provisioner service310) to allocate the node and the external storage to the target environment. The target environment may be a part of cloud infrastructure that is managed by the cloud service. In various embodiments, the node includes a local storage, and the application container is operable to utilize the local storage and the placeholder container is operable to utilize the external storage. The computer system may deploy a local-storage-setup application (e.g., local volume provisioner340) onto the node such that the local-storage-setup application is executed to generate a local storage object (e.g., a volume object220on the local storage) that allows for the application container to utilize the local storage. The computer system may bind the deployment object to the local storage object to cause the computer system to redeploy the application container onto the node in response to the application container crashing. In some embodiments, the application container creates a storage object (e.g., a volume claim230) for the application container and binds the storage object of the application container to the local storage object created by the local-storage-setup application. In other embodiments, the storage object is included in the deployment object and, as a result, the computer system binds the deployment object (via its storage object) to the local storage object, as mentioned above.

In step450, in response to the additional set of resources being allocated, the computer system deploys the application container onto the additional set of resources for execution. The computer system may detect that the deployment object of the application container indicates a pending state for the deployment of the application container. In response to that detecting, the computer system identifies whether there is an available resource in the target environment on which to deploy the application container. The computer system may identify the additional set of resources as available resources for the application container and deploy the application container on the additional set of resources. After the deploying of the application container, the computer system modifies the deployment object to indicate that the application container has been deployed. In various embodiments, the number of placeholder containers deployed is scaled in proportion to a number of application containers. In some cases, the computer system detects that the node has crashed. Thereafter, the computer system may delete a portion (e.g., the binding of a volume claim230to an external volume object220) of a deployment object created for the placeholder container. The deleting may cause the computer system to allocate another set of additional resources to the target environment.

Exemplary Computer System

Turning now toFIG.5, a block diagram of an exemplary computer system500, which may implement system100, orchestration service140, target environment110, resource provisioner service310, and/or node320, is shown. Computer system500includes a processor subsystem580that is coupled to a system memory520and I/O interfaces(s)540via an interconnect560(e.g., a system bus). I/O interface(s)540is coupled to one or more I/O devices550. Although a single computer system500is shown inFIG.5for convenience, system500may also be implemented as two or more computer systems operating together.

Processor subsystem580may include one or more processors or processing units. In various embodiments of computer system500, multiple instances of processor subsystem580may be coupled to interconnect560. In various embodiments, processor subsystem580(or each processor unit within580) may contain a cache or other form of on-board memory.

System memory520is usable store program instructions executable by processor subsystem580to cause system500perform various operations described herein. System memory520may be implemented using different physical memory media, such as hard disk storage, floppy disk storage, removable disk storage, flash memory, random access memory (RAM-SRAM, EDO RAM, SDRAM, DDR SDRAM, RAMBUS RAM, etc.), read only memory (PROM, EEPROM, etc.), and so on. Memory in computer system500is not limited to primary storage such as memory520. Rather, computer system500may also include other forms of storage such as cache memory in processor subsystem580and secondary storage on I/O Devices550(e.g., a hard drive, storage array, etc.). In some embodiments, these other forms of storage may also store program instructions executable by processor subsystem580. In some embodiments, program instructions that when executed implement orchestration service140, application container120, placeholder container130, and/or virtual machine325may be included/stored within system memory520.

I/O interfaces540may be any of various types of interfaces configured to couple to and communicate with other devices, according to various embodiments. In one embodiment, I/O interface540is a bridge chip (e.g., Southbridge) from a front-side to one or more back-side buses. I/O interfaces540may be coupled to one or more I/O devices550via one or more corresponding buses or other interfaces. Examples of I/O devices550include storage devices (hard drive, optical drive, removable flash drive, storage array, SAN, or their associated controller), network interface devices (e.g., to a local or wide-area network), or other devices (e.g., graphics, user interface devices, etc.). In one embodiment, computer system500is coupled to a network via a network interface device550(e.g., configured to communicate over WiFi, Bluetooth, Ethernet, etc.).

The present disclosure includes references to “embodiments,” which are non-limiting implementations of the disclosed concepts. References to “an embodiment,” “one embodiment,” “a particular embodiment,” “some embodiments,” “various embodiments,” and the like do not necessarily refer to the same embodiment. A large number of possible embodiments are contemplated, including specific embodiments described in detail, as well as modifications or alternatives that fall within the spirit or scope of the disclosure. Not all embodiments will necessarily manifest any or all of the potential advantages described herein.