Workload coordinated container snapshotting for migration and rapid scale out

Abstract

A method (500) includes receiving a first request (162) to schedule a first replica pod (124R) on a first node (122) and determining that no snapshots (152) associated with a target workload (190) currently exist. Based on determining that no snapshots currently exist, the method includes initializing the target workload at the first node and receiving a signal (194) indicating that the target workload is in a ready state. The method also includes generating a snapshot of a current state of the target workload based on receiving the signal and receiving a second request (164) to schedule a second replica pod on a second node. The method also includes determining that the snapshot of the current state of the target workload currently exists based on receiving the second request and starting the target workload at the second node using the snapshot of the current state of the target workload.

Description

Workload Coordinated Container Snapshotting for Migration and Rapid Scale OutTECHNICAL FIELD

[0001] This disclosure relates to workload coordinated container snapshotting for migration and rapid scale out.BACKGROUND

[0002] The use of container technologies by cloud computing environments has increased in popularity in recent years. Containerization is a type of virtualization that bundles all components of an application or service together into a single container image such that the application or service may run in isolation from a shared computing system. These container technologies offer the prospect of rapidly scaling applications and services without incurring the large overhead associated with traditional virtualization environments. Thus, applications and services may rapidly scale based on demand by creating additional containers and using the additional created containers to run the applications or services. Creating additional containers, however, often includes using a bootstrap process that is time and resource intensive. Moreover, managing many containers (e g., hundreds of thousands of containers) may become burdensome for cloud computing providers.SUMMARY

[0003] One aspect of the disclosure provides a computer-implemented method that when executed on data processing hardware causes the data processing hardware to perform operations for workload coordinated container snapshotting. The operations include receiving a first request to schedule a first replica pod on a first node of a plurality of nodes. The first request is associated with a target workload. The operations also include determining that no snapshots associated with the target workload currently exist based on receiving the first request. The operations also include initializing the target workload at the first node based on determining that no snapshots associated withthe target workload currently exist. The operations also include receiving a signal indicating that the target workload is in a ready state after initializing the target workload and generating a snapshot of a current state of the target workload based on receiving the signal. The operations also include receiving a second request to schedule a second replica pod on a second node of the plurality of nodes. The second request is associated with the target workload. The operations also include determining that the snapshot of the current state of the target workload currently exists based on receiving the second request and starting the target workload at the second node using the snapshot of the current state of the target workload based on determining that the snapshot of the current state of the target workload currently exists.

[0004] Implementations of the disclosure may include one or more of the following optional features. In some implementations, the operations further include storing the snapshot at a shared storage device and obtaining the snapshot from the shared storage device based on determining that the snapshot currently exists. In some examples, the target workload resides in a container of the first node. In these examples, the operations may further include injecting a predetermined file into the container of the first node. Here, the signal indicating that the target workload is in the ready state is received in response to the target workload accessing the predetermined file injected into the container.

[0005] In some implementations, the operations further include detecting a termination of the target workload, generating another snapshot of the target workload based on detecting the termination of the target workload, and starting the target workload at the second node using the other snapshot of the target workload. The operations may further include detecting the target workload is idle, generating another snapshot of the target workload based on detecting that the target workload is idle, and starting the target workload at the second node using the other snapshot of the target workload. In some examples, the first node and the second node are the same node. In other examples, the first node and the second nodes are different nodes. The operations may further include refreshing an external state of the target workload. In someimplementations, the operations further include communicating with the target workload that the snapshot is complete after generating the snapshot.

[0006] Another aspect of the disclosure provides a system that includes data processing hardware and memory hardware storing instructions that when executed on the data processing hardware causes the data processing hardware to perform operations. The operations include receiving a first request to schedule a first replica pod on a first node of a plurality of nodes. The first request is associated with a target workload. The operations also include determining that no snapshots associated with the target workload currently exist based on receiving the first request. The operations also include initializing the target workload at the first node based on determining that no snapshots associated with the target workload currently exist. The operations also include receiving a signal indicating that the target workload is in a ready state after initializing the target workload and generating a snapshot of a current state of the target workload based on receiving the signal. The operations also include receiving a second request to schedule a second replica pod on a second node of the plurality of nodes. The second request is associated with the target workload. The operations also include determining that the snapshot of the current state of the target workload currently exists based on receiving the second request and starting the target workload at the second node using the snapshot of the current state of the target workload based on determining that the snapshot of the current state of the target workload currently exists.

[0007] Implementations of the disclosure may include one or more of the following optional features. In some implementations, the operations further include storing the snapshot at a shared storage device and obtaining the snapshot from the shared storage device based on determining that the snapshot currently exists. In some examples, the target workload resides in a container of the first node. In these examples, the operations may further include injecting a predetermined file into the container of the first node. Here, the signal indicating that the target workload is in the ready state is received in response to the target workload accessing the predetermined file injected into the container.

[0008] In some implementations, the operations further include detecting a termination of the target workload, generating another snapshot of the target workload based on detecting the termination of the target workload, and starting the target workload at the second node using the other snapshot of the target workload. The operations may further include detecting the target workload is idle, generating another snapshot of the target workload based on detecting that the target workload is idle, and starting the target workload at the second node using the other snapshot of the target workload. In some examples, the first node and the second node are the same node. In other examples, the first node and the second nodes are different nodes. The operations may further include refreshing an external state of the target workload. In some implementations, the operations further include communicating with the target workload that the snapshot is complete after generating the snapshot.

[0009] The details of one or more implementations of the disclosure are set forth in the accompanying drawings and the description below. Other aspects, features, and advantages will be apparent from the description and drawings, and from the claims.DESCRIPTION OF DRAWINGS

[0010] FIGS. 1 A and IB are schematic views of an example system executing a snapshot operator.

[0011] FIG. 2 is a schematic view of a sequence diagram for scaling up a slow starting workload.

[0012] FIG. 3 is a schematic view of a sequence diagram for workload migration.

[0013] FIG. 4 is a schematic view of a sequence diagram for resuming an idle workload.

[0014] FIG. 5 is a flowchart of an example arrangement of operations for a computer- implemented method of workload coordinated container snapshotting.

[0015] FIG. 6 is a schematic view of an example computing device that may be used to implement the systems and methods described herein.

[0016] Like reference symbols in the various drawings indicate like elements.DETAILED DESCRIPTION

[0017] The use of container technologies by cloud computing environments has increased in popularity in recent years. Containerization is a type of virtualization that bundles all components of an application or service together into a single container image such that the application or service may run in isolation from a shared computing system. These container technologies offer the prospect of rapidly scaling applications and services without incurring the large overhead associated with traditional virtualization environments. Thus, applications and services may rapidly scale based on demand by creating additional containers and using the additional created containers to run the applications or services. Creating additional containers, however, often includes using a bootstrap process that is time and resource intensive. Moreover, managing many containers (e g., hundreds of thousands of containers) may become burdensome for cloud computing providers.

[0018] Referring to FIG. 1, in some implementations, a system 100 includes a cloud computing system 140 having scalable elastic resources 142. The resources 142 may include computing resources (e.g., data processing hardware) 144 and / or storage resources. The cloud computing system 140 may correspond to a distributed system, such as a cloud computing environment. The cloud computing system 140 includes a plurality of nodes 122, 122a-n that execute containerized applications and / or other workloads. For instance, a node 122 may include a physical computer or a virtual machine. In some configurations, one or more nodes 122 are grouped into a corresponding cluster of nodes 122 that each execute a corresponding portion of a workload.

[0019] Each node 122 of the plurality of nodes includes one or more pods 124, 124a- n. Pods 124 represent a unit of replication for workloads. For instance, deploying a workload may include defining a number of replicas of the workload to execute. Here, each replica of the workload may be encapsulated by one of the pods 124. After deploying the workload, the number of pods 124, and thus the number of replicas of the workload, may be scaled up or down based on a demand of the workload. Thus, some pods 124 may be replica pods 124, 124R that replicate another one of the pods 124. Tothat end, replica pods 124R may be used to scale up a slow starting workload, migrate a workload to another node 122, and / or resume an idle workload.

[0020] In the example shown, a first node 122a has one or more first pods 124a, 124aa-an and a second node 122b has one or more second pods 124b, 124ba-bn. Pods 124 are the most basic deployable unit within one of the nodes 122 or cluster of nodes 122. Moreover, each pod 124 encapsulates one or more containers 126, 126a-n each configured to execute a workload. As such, each workload operates in a containerized manner at one of the containers 126. Continuing with the example shown, each first pod 124a includes one or more first containers 126a, 126aa-an and each second pod 124b includes one or more second containers 126b, 126ba-bn.

[0021] Container-level snapshotting snapshots a current state of a workload and associated metadata such that the snapshot may later be used to restore or scale the workload. However, determining an optimal time to snapshot containers is not straightforward and requires bespoke integration. To that end, the cloud computing system 140 includes a snapshot operator 130 that is configured to manage generating and using snapshots 152 for containerized workloads. Notably, the snapshot operator 130 may use the snapshots 152 to scale workloads, migrate workloads, and / or restore idle workloads. In some examples, the snapshot operator 130 includes an orchestrator 160, a runtime container 170, and a snapshot agent 180. The orchestrator 160 is configured to manage the replica pod 124R by scheduling the replica pods 124R on the one or more nodes 122. In some instances, the orchestrator 160 schedules replica pods 124R based on receiving a workload deployment request (e.g., from a user device communicating via a network with the cloud computing system 140). Here, the orchestrator 160 may forward the workload deployment request to the runtime container 170. In other instances, the orchestrator 160 schedules replica pods 124R automatically and without any additional input from a user. That is, the orchestrator 160 may monitor a workload demand for a particular workload and determine that the particular workload needs to execute additional replica pods 124R to satisfy the workload demand.

[0022] Referring now specifically to FIG. 1A, in a first example system 100, 100a, the orchestrator 160 may generate a first request 162 to schedule a first replica pod 124R,124Ra on one of the nodes 122 (e g., the first node 122a) of the plurality of nodes 122. The first request 162 is associated with a target workload 190. The target workload 190 may correspond to a particular application (e.g., containerized application) or service that executes on the cloud computing system 140. For instance, the first request 162 may request to deploy another replica pod 124R for the target workload 190. Alternatively, the first request 162 may request to deploy an initial replica pod 124R for the target workload. The orchestrator 160 transmits the first request 162 to the runtime container 170. The runtime container 170 is configured to determine whether to deploy the first replica pod 124Ra by initializing and bootstrapping the target workload 190 or by using a corresponding snapshot 152 associated with the target workload 190. The runtime container 170 deploys the first replica pod 124Ra using the corresponding snapshot 152 whenever such snapshot 152 exists due to the time and computation efficiency gains compared to initializing and bootstrapping the target workload 190.

[0023] Based on receiving the first request 162, the runtime container 170 transmits a query 172 to the snapshot agent 180 to determine whether any snapshots 152 associated with the target workload 190 currently exist. That is, when a snapshot 152 associated with the target workload 190 does exist, the snapshot operator 130 may start the target workload 190 using the existing snapshot 152. On the other hand, when no snapshots 152 associated with the target workload 190 exist, the snapshot operator 130 may initialize and bootstrap the target workload 190. The snapshot agent 180 determines whether any snapshots 152 associated with the target workload 190 exist by communicating with a data store 150 that stores a plurality of snapshots 152, 152a-n.The data store 150 may be overlain on the memory hardware 146 of the cloud computing device. As such, the data store 150 represents a shared storage device accessible by each of the plurality of nodes 122.

[0024] The snapshot agent 180 obtains the plurality of snapshots 152 the data store 150 and determines that no snapshots 152 associated with the target workload 190 currently exist. No snapshots 152 may exist for the target workload 190 because the target workload 190 has not been initialized yet or the target workload 190 has been initialized but no snapshots have been taken yet. Thereafter, the snapshot agent 180transmits a first notification 182 to the runtime container 170 indicating that no snapshots 152 associated with the target workload 190 currently exist. Based on receiving the first notification 182, the runtime container 170 transmits an initialization request 174 to the target workload 190 that causes the target workload 190 to initialize and bootstrap at the requested one of the nodes 122. For instance, the target workload 190 may initialize at one of the containers 126 within one of the pods 124 of the requested node 122. In some configurations, no particular node 122 is requested by the first request 162 and the runtime container 170 identifies a particular node 122, pod 124, and container 126 to initialize the target workload 190 at.

[0025] In some implementations, the target workload 190 resides in a container 126 of the node 122 where the target workload 190 is initialized. The runtime container 170 may inject the target workload 190 with a predetermined file (e.g., well known file) 192. For example, the predetermined file 192 may correspond to “ / dev / snapshot.” In particular, the runtime container 170 may inject the predetermined file 192 into the container 126 of the node 122 where the target workload 190 was initialized. Injecting the target workload 190 with the predetermined file 192 allows the target workload 190 to signal to the runtime container 170 when the target workload 190 has finished initialization and is ready for snapshotting. For instance, the target workload 190 may access (i.e., touch) predetermined file 192 which notifies the runtime container 170 that the target workload is in a ready state (e.g., ready for snapshotting). That is, the runtime container 170 may monitor the predetermined file 192 to determine when the target workload 190 is ready for snapshotting. Advantageously, using the predetermined file 192 provides bi-directional coordination between the runtime container 170 and the target workload 190 which is easy to integrate with any application, framework, and programming language.

[0026] After the target workload 190 initializes, the runtime container 170 receives a first signal 194 from the target workload 190 indicating that the target workload 190 is in the ready state. That is, the first signal 194 informs the runtime container 170 that the target workload 190 has finished initialization and is ready for snapshotting. The signal 194 may indicate that the target workload 190 accessed the predetermined file 192.Based on receiving the first signal 194, the runtime container 170 communicates with the snapshot agent 180 that the target workload 190 is in the ready state and the snapshot agent 180 generates a corresponding snapshot 152 of a current state of the target workload 190 and metadata associated with the target workload 190. Thus, the snapshot 152 is sufficient to restore the target workload 190 on another node 122 or another pod 124 within the same node 122. The snapshot agent 180 stores the corresponding snapshot 152 at the data store 150.

[0027] The runtime container 170 may communicate with the target workload 190 that the corresponding snapshot 152 of the target workload 190 is complete and that the target workload 190 should continue processing. That is, the target workload 190 may cease processing while the snapshot agent 180 generates the snapshot 152 and resume processing once the snapshot 152 is complete. The runtime container may communicate with the target workload 190 that the corresponding snapshot 152 is complete by accessing the predetermined file 192. After the snapshot 152 is complete, the target workload 190 determines that one or more replicas of the target workload 190 may exist and refresh an external state of the target workload 190. Refreshing the external state of the target workload 190 updates the host the target workload 190 is operating on. For example, the target workload 190 may be running on another node 122, another pod 124, and / or another container 126.

[0028] Referring now to FIG. IB, in a second example system 100, 100b, after generating the snapshot 152 for the target workload 190, the snapshot operator 130 may deploy one or more replica pods 124R of the target workload 190 using the snapshot 152 instead of initializing and bootstrapping the target workload 190. To that end, the orchestrator 160 may generate a second request 164 to schedule a second replica pod 124R, 124Rb on one of the nodes 122 (e.g., the second node 122b) of the plurality of nodes 122. The second node 122b may be the same node 122 or a different node 122 as the first node 122a requested by the first request 162 (FIG. 1A). The second request 164 is similarly associated with the target workload 190. For instance, the second request 164 may request to deploy yet another replica pod 124R for the target workload 190. The orchestrator 160 transmits the second request 164 to the runtime container 170. Theruntime container 170 is configured to determine whether to deploy the second replica pod 124Rb by initializing and bootstrapping the target workload 190 or by using a corresponding snapshot 152 associated with the target workload 190. The runtime container 170 deploys the first replica pod 124Ra using the corresponding snapshot 1 2 whenever such snapshot 152 exists due to the time and computation efficiency gains compared to initializing and bootstrapping the target workload 190.

[0029] Based on receiving the second request 164, the runtime container 170 transmits the query 172 to the snapshot agent 180 to determine whether any snapshots 152 associated with the target workload 190 currently exists. Here, the snapshot agent 180 obtains the plurality of snapshots 152 from the data store 150 and determines that corresponding snapshot 152 associated with the target workload 190 currently exists. Thereafter, the snapshot agent 180 transmits a second notification 184 which includes the corresponding snapshot 152 associated with the target workload 190 to the runtime container 170. Based on receiving the second notification 184, the runtime container 170 transmits a deployment request 176 to the target workload 190 that causes the target workload 190 to start or deploy at the requested one of the nodes 122 from the second request 164. Here, the target workload 190 starts at the requested one of the nodes 122 using the corresponding snapshot 152.

[0030] For instance, the target workload 190 may start at a different container 126 within the same pod 124 and same node 122 the target workload 190 was initialized. Alternatively, the target workload 190 may initialize at a different container and a different pod 124 within the same node 122 (or different node 122) the target workload 190 was initialized. In some configurations, no particular node 122 is requested by the second request 164 and the runtime container 170 identifies a particular node 122, pod 124, and container 126 to start the target workload 190.

[0031] The runtime container 170 may communicate with the target workload 190 that the second replica pod 124Rb has been started at the second node 122b and that the target workload should continue processing at the first node 122a. The runtime container 170 may communicate with the target workload 190 by accessing the predetermined file 192 indicating that the second replica pod 124Rb has been started on another node. Afterthe second replica pod 124Rb has been started, the target workload 190 determines that it may no longer be unique and refresh the external state of the target workload 190. Refreshing the external state of the target workload 190 updates the host the target workloadl90 is operating on. For example, the target workload 190 may be running on another node 122, another pod 124, and / or another container 126.

[0032] FIG. 2 illustrates a sequence diagram 200 for steps of scaling up a slow starting workload. For instance, a target workload 190 may initially be deployed with a single replica pod 124R at a first node 122a and then, based on increased demand, the snapshot operator 130 may deploy additional replica pods 124R on one or more other nodes 122. The Y-axis of the sequence diagram 200 represents time increasing from top to bottom to provide an order to the steps. The steps begin at the top of the Y-axis (i.e., the earliest point in time) and proceed in order down the Y-axis. The parallel vertical lines represent the orchestrator 160, the snapshot agent 180, the runtime container 170, and the target workload 190.

[0033] At step 210, the orchestrator 160 transmits the first request 162 to the runtime container 170 to schedule the first replica pod 124Ra on one of the plurality of nodes 122 (e.g., the first node 122a). The first request 162 is associated with the target workload 190. For instance, the first request 162 may request to deploy an initial replica pod 124R of a plurality of replica pods 124R for the target workload 190. At step 212, the runtime container 170 checks the snapshot agent 180 for a snapshot 152 (e.g., via the query 172) associated with the target workload 190 based on receiving the first request 162. At step 214, the snapshot agent 180 determines that no snapshots 152 (e.g., no compatible snapshots 152) associated with the target workload 190 exist and notifies the runtime container 170 that no snapshots 152 exist. Since the first request 162 may be associated with the initial replica pod 124R for the target workload 190, no snapshots 152 exist due to the target workload 190 not being deployed yet. At step 216, the runtime container 170 transmits the initialization request 174 to the target workload 190 that causes the target workload 190 to initialize at the one of the plurality of nodes 122. At step 218, after the target workload 190 initializes, the target workload 190 transmits the first signal 194 to the runtime container 170 indicating that the target workload 190 is in a readystate. When the target workload 190 is in the ready state, the target workload 190 is ready for the snapshot agent 180 to take a snapshot 152. Transmitting the first signal 194 may include the target workload 190 accessing the predetermined file 192 which indicates to the runtime container 170 that the target workload 190 is ready for snapshotting.

[0034] At step 220, based on receiving the first signal 194, the runtime container 170 communicates with the snapshot agent 180 that the target workload 190 is in the ready state. At step 222, the snapshot agent 180 generates a corresponding snapshot 152 of the current state of the target workload 190 and metadata associated with the target workload 190. Thus, the snapshot operator 130 may use the corresponding snapshot 152 to restore the target workload 190 at the same node 122 or another node 122. The snapshot agent 180 stores the corresponding snapshot 152 at the data store 150 (e.g., shared storage device). At step 224, the runtime container 170 communicates with the target workload 190 to indicate that the snapshot 152 is complete and the target workload may continue operating. The runtime container 170 may communicate with the target workload 190 by accessing the predetermined fde 192. Notably, after generating the corresponding snapshot 152 of the target workload 190, the target workload 190 may be started (e.g., by deploying additional replica pods 124R) using the corresponding snapshot 152 rather than initializing the target workload 190.

[0035] At step 226, the orchestrator 160 transmits the second request 164 to the runtime container 170 to schedule the second replica pod 124Rb on one of the plurality of nodes 122. The one of the plurality of nodes 122 specified by the second request 164 may be the same node or a different node than the one of the plurality of nodes 122 specified by the first request 162. At step 228, the runtime container 170 checks the snapshot agent 180 for a snapshot 152 associated with the target workload 190 based on receiving the second request 164. At step 230, the snapshot agent 180 determines the snapshot 152 of the current state of the target workload 190 currently exists and transmits the snapshot 152 to the runtime container 170. At step 232, the runtime container 170 starts the target workload 190 at the one of the plurality of nodes 122 using the snapshot 152. That is, the runtime container 170 deploys the second replica pod 124ba at the oneof the plurality of nodes 122 using the snapshot 152. At step 234, the runtime container 170 communicates with the target workload 190 that the target workload 190 has been started on the node 122 specified by the second request 164 and that the target workload 190 may continue operating at the first node 122a. Here, the runtime container may communicate with the target workload 190 by accessing the predetermined file 192.

[0036] FIG. 3 illustrates a sequence diagram 300 for steps of workload migration. For instance, during operation of a target workload 190 on a node 122, a node failure may occur such that the target workload 190 needs to be migrated to operate on another node 122. The steps begin at the top of the Y-axis (i.e., the earliest point in time) and proceed in order down the Y-axis. The parallel vertical lines represent the orchestrator 160, the snapshot agent 180, the runtime container 170, and the target workload 190.

[0037] At step 310, the orchestrator 160 detects a termination of the target workload 190 and transmits the termination detection to the snapshot agent 180. For example, the termination of the target workload 190 may be caused by a node failure of the node 122 the target workload 190 is operating on. At step 312, the snapshot agent 180 may generate a corresponding snapshot 152 of a current state of the target workload 190 and metadata associated with the target workload 190 based on receiving the termination detection. As such, the corresponding snapshot 152 represents the state of the target workload at, or just before, the termination occurred. At step 314, the orchestrator 160 transmits a request to the runtime container 170 to schedule a replica pod 124R of the target workload 190 on another one of the nodes 122. Here, the orchestrator 160 is requesting to migrate the target workload 190 from the failed node 122 to another node 122. At step 316, the runtime container 170 checks the snapshot agent 180 for a snapshot 152 associated with the target workload 190. At step 318, the snapshot agent 180 identifies the snapshot 152 of the target workload 190 generated responsive to the termination detection and transmits the snapshot 152 to the runtime container 170. At step 320, the runtime container 170 starts the target workload 190 using the snapshot 152 on another node 122 rather than re-initializing the target workload 190. After the target workload 190 starts, the target workload 190 may refresh its external state indicating to the other nodes 122 which node the target workload 190 is operating at now.

[0038] FIG. 4 illustrates a sequence diagram 400 for steps of resuming an idle workload. For instance, a target workload 190 may only operate on a node 122 during the week and remain idle on the weekend. In these instances, the snapshot operator 130 may terminate the target workload 190 to free up the node 122 and generate a snapshot 152 for the target workload 190 based on detecting the target workload 190 is idle (e.g., at the end of a week). Thereafter, when the target workload 190 resumes operation (e.g., at the beginning of the next week), the snapshot operator 130 may start the target workload 190 on the same node 122 it was previously operating on or a different node 122. The Y-axis of the sequence diagram 400 represents time increasing from top to bottom to provide an order to the steps. The steps begin at the top of the Y-axis (i.e., the earliest point in time) and proceed in order down the Y-axis. The parallel vertical lines represent the orchestrator 160, the snapshot agent 180, the runtime container 170, and the target workload 190.

[0039] At step 410, the orchestrator 160 detects that the target workload 190 is idle and transmits the idle detection to the snapshot agent 180. For example, the target workload 190 may only operate at particular times or days. Thus, rather than leaving the node the target workload 190 operates on idle, the snapshot operator 130 may terminate the target workload 190 such that the node 122 the target workload 190 was operating on may be used by other workloads. At step 412, the snapshot agent 180 generates a corresponding snapshot 152 of a current state of the target workload 190 and metadata associated with the target workload 190 based on receiving the idle detection. As such, the corresponding snapshot 152 represents the state of the target workload at, or just before, the target workload went idle. At step 414, the orchestrator 160 transmits a request to the runtime container 170 to schedule a replica pod 124R of the target workload 190 on one of the nodes 122. That is, when the target workload 190 is no longer idle, the orchestrator 160 may resume operation of the target workload 190 by redeploying the target workload 190 on one of the nodes 122. Notably, the target workload 190 may resume on the node 122 it was previously operating on or a different node 122. At step 416, the runtime container 170 checks the snapshot agent 180 for a snapshot 152 associated with the target workload 190. At step 418, the snapshot agent180 identifies the snapshot 152 of the target workload 190 generated responsive to the idle detection and transmits the snapshot 152 to the runtime container 170. At step 420, the runtime container 170 starts the target workload 190 using the snapshot 152 on one of the nodes 122 rather than re-initializing the target workload 190. After the target workload 190 starts, the target workload 190 may refresh its external state indicating to the other nodes 122 which node the target workload 190 is operating at now.

[0040] FIG. 5 is a flowchart of an example arrangement of operations for a computer- implemented method 500 for workload coordinated container snapshotting. The method 500 may execute on data processing hardware 610 (FIG. 6) using instructions stored on memory hardware 620 (FIG. 6) that may reside on the cloud computing system 140 of FIG. 1 corresponding to a computing device 600 (FIG. 6).

[0041] At operation 502, the method 500 includes receiving a first request 162 to schedule a first replica pod 124Ra on a first node 122a of a plurality of nodes 122. The first request 162 is associated with a target workload 190. At operation 504, the method 500 includes determining that no snapshots 152 associated with the target workload 190 currently exist based on receiving the first request 162. At operation 506, the method 500 includes initializing the target workload 190 at the first node 122a based on determining that no snapshot 152 associated with the target workload 190 currently exist. At operation 508, the method 500 includes receiving a signal 194 indicating that the target workload is in a ready state after initializing the target workload 190. At operation 510, the method 500 includes generating a snapshot 152 of a current state of the target workload 190 based on receiving the signal 194. At operation 512, the method 500 includes receiving a second request 164 to schedule a second replica pod 124Rb on a second node 122b of the plurality of nodes 122. The second request 164 is associated with the target workload 190. At operation 514, the method 500 includes determining that the snapshot 152 of the current state of the target workload 190 currently exists based on receiving the second request 164. At operation 516, the method 500 includes starting the target workload 190 at the second node 122b using the snapshot 152 of the current state of the target workload 190 based on determining that the snapshot 152 of the current state of the target workload 190 currently exists.

[0042] FIG. 6 is a schematic view of an example computing device 600 that may be used to implement the systems and methods described in this document. The computing device 600 is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The components shown here, their connections and relationships, and their functions, are meant to be exemplary only, and are not meant to limit implementations of the inventions described and / or claimed in this document.

[0043] The computing device 600 includes a processor 610, memory 620, a storage device 630, a high-speed interface / controller 640 connecting to the memory 620 and high-speed expansion ports 650, and a low speed interface / controller 660 connecting to a low speed bus 670 and a storage device 630. Each of the components 610, 620, 630, 640, 650, and 660, are interconnected using various busses, and may be mounted on a common motherboard or in other manners as appropriate. The processor 610 can process instructions for execution within the computing device 600, including instructions stored in the memory 620 or on the storage device 630 to display graphical information for a graphical user interface (GUI) on an external input / output device, such as display 680 coupled to high speed interface 640. In other implementations, multiple processors and / or multiple buses may be used, as appropriate, along with multiple memories and types of memory. Also, multiple computing devices 600 may be connected, with each device providing portions of the necessary operations (e.g., as a server bank, a group of blade servers, or a multi-processor system).

[0044] The memory 620 stores information non-transitorily within the computing device 600. The memory 620 may be a computer-readable medium, a volatile memory unit(s), or non-volatile memory unit(s). The non-transitory memory 620 may be physical devices used to store programs (e.g., sequences of instructions) or data (e.g., program state information) on a temporary or permanent basis for use by the computing device 600. Examples of non-volatile memory include, but are not limited to, flash memory and read-only memory (ROM) / programmable read-only memory (PROM) / erasable programmable read-only memory (EPROM) / electronically erasable programmable readonly memory (EEPROM) (e.g., typically used for firmware, such as boot programs).Examples of volatile memory include, but are not limited to, random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), phase change memory (PCM) as well as disks or tapes.

[0045] The storage device 630 is capable of providing mass storage for the computing device 600. In some implementations, the storage device 630 is a computer- readable medium. In various different implementations, the storage device 630 may be a floppy disk device, a hard disk device, an optical disk device, or a tape device, a flash memory or other similar solid state memory device, or an array of devices, including devices in a storage area network or other configurations. In additional implementations, a computer program product is tangibly embodied in an information carrier. The computer program product contains instructions that, when executed, perform one or more methods, such as those described above. The information carrier is a computer- or machine-readable medium, such as the memory 620, the storage device 630, or memory on processor 610.

[0046] The high speed controller 640 manages bandwidth-intensive operations for the computing device 600, while the low speed controller 660 manages lower bandwidthintensive operations. Such allocation of duties is exemplary only. In some implementations, the high-speed controller 640 is coupled to the memory 620, the display 680 (e.g., through a graphics processor or accelerator), and to the high-speed expansion ports 650, which may accept various expansion cards (not shown). In some implementations, the low-speed controller 660 is coupled to the storage device 630 and a low-speed expansion port 690. The low-speed expansion port 690, which may include various communication ports (e.g., USB, Bluetooth, Ethernet, wireless Ethernet), may be coupled to one or more input / output devices, such as a keyboard, a pointing device, a scanner, or a networking device such as a switch or router, e.g., through a network adapter.

[0047] The computing device 600 may be implemented in a number of different forms, as shown in the figure. For example, it may be implemented as a standard server 600a or multiple times in a group of such servers 600a, as a laptop computer 600b, or as part of a rack server system 600c.

[0048] Various implementations of the systems and techniques described herein can be realized in digital electronic and / or optical circuitry, integrated circuitry, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include implementation in one or more computer programs that are executable and / or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.

[0049] These computer programs (also known as programs, software, software applications or code) include machine instructions for a programmable processor, and can be implemented in a high-level procedural and / or object-oriented programming language, and / or in assembly / machine language. As used herein, the terms “machine-readable medium” and “computer-readable medium” refer to any computer program product, non- transitory computer readable medium, apparatus and / or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and / or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term “machine-readable signal” refers to any signal used to provide machine instructions and / or data to a programmable processor.

[0050] The processes and logic flows described in this specification can be performed by one or more programmable processors, also referred to as data processing hardware, executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit). Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both. The essential elements of a computer are a processor forperforming instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks. However, a computer need not have such devices. Computer readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[0051] To provide for interaction with a user, one or more aspects of the disclosure can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube), LCD (liquid crystal display) monitor, or touch screen for displaying information to the user and optionally a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input. In addition, a computer can interact with a user by sending documents to and receiving documents from a device that is used by the user; for example, by sending web pages to a web browser on a user's client device in response to requests received from the web browser.

[0052] A number of implementations have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the disclosure. Accordingly, other implementations are within the scope of the following claims.

Claims

WHAT IS CLAIMED IS:

1. A computer-implemented method (500) executed on data processing hardware (610) that causes the data processing hardware (610) to perform operations comprising: receiving a first request (162) to schedule a first replica pod (124Ra) on a first node (122a) of a plurality of nodes (122), the first request (162) associated with a target workload (190); based on receiving the first request (162), determining that no snapshots (152) associated with the target workload (190) currently exist; based on determining that no snapshots (152) associated with the target workload (190) currently exist, initializing the target workload (190) at the first node (122a); after initializing the target workload (190), receiving a signal (194) indicating that the target workload (190) is in a ready state; based on receiving the signal (194), generating a snapshot (152) of a current state of the target workload (190); receiving a second request (164) to schedule a second replica pod (124Rb) on a second node (122b) of the plurality of nodes (122), the second request (164) associated with the target workload (190); based on receiving the second request (164), determining that the snapshot (152) of the current state of the target workload (190) currently exists; and based on determining that the snapshot (152) of the current state of the target workload (190) currently exists, starting the target workload (190) at the second node (122b) using the snapshot (152) of the current state of the target workload (190).

2. The computer-implemented method (500) of claim 1, wherein the operations further comprise: storing the snapshot (152) at a shared storage device (150); and based on determining that the snapshot (152) currently exists, obtaining the snapshot (152) from the shared storage device (150).

3. The computer-implemented method (500) of claims 1 or 2, wherein the target workload (190) resides in a container (126) of the first node (122a).

4. The computer-implemented method (500) of claim 3, wherein: the operations further comprise injecting a predetermined file (192) into the container (126) of the first node (122a); and the signal (194) indicating that the target workload (190) is in the ready state is received in response to the target workload (190) accessing the predetermined file (192) injected into the container (126).

5. The computer-implemented method (500) of any of claims 1-4, wherein the operations further comprise: detecting a termination of the target workload (190); based on detecting the termination of the target workload (190), generating another snapshot (152) of the target workload (190); and starting the target workload (190) at the second node (122b) using the other snapshot (152) of the target workload (190).

6. The computer-implemented method (500) of any of claims 1-5, wherein the operations further comprise: detecting that the target workload (190) is idle, based on detecting that the target workload (190) is idle, generating another snapshot (152) of the target workload (190); and starting the target workload (190) at the second node (122b) using the other snapshot (152) of the target workload (190).

7. The computer-implemented method (500) of any of claims 1-6, wherein the first node (122a) and the second node (122b) are the same node (122).

8. The computer-implemented method (500) of any of claims 1—7, wherein the first node (122a) and the second node (122b) are different nodes (122).

9. The computer-implemented method (500) of any of claims 1-8, wherein the operations further comprise refreshing an external state of the target workload (190).

10. The computer-implemented method (500) of any of claims 1-9, wherein the operations further comprise, after generating the snapshot (152), communicating with the target workload (190) that the snapshot (152) is complete.

11. A system (100) comprising: data processing hardware (610); and memory hardware (620) in communication with the data processing hardware (610), the memory hardware (620) storing instructions that when executed on the data processing hardware (610) cause the data processing hardware (610) to perform operations comprising: receiving a first request (162) to schedule a first replica pod (124Ra) on a first node (122a) of a plurality of nodes (122), the first request (162) associated with a target workload (190); based on receiving the first request (162), determining that no snapshots (152) associated with the target workload (190) currently exist; based on determining that no snapshots (152) associated with the target workload (190) currently exist, initializing the target workload (190) at the first node (122a); after initializing the target workload (190), receiving a signal (194) indicating that the target workload (190) is in a ready state; based on receiving the signal (194), generating a snapshot (152) of a current state of the target workload (190);receiving a second request (164) to schedule a second replica pod (124Rb) on a second node (122b) of the plurality of nodes (122), the second request (164) associated with the target workload (190); based on receiving the second request (164), determining that the snapshot (152) of the current state of the target workload (190) currently exists; and based on determining that the snapshot (152) of the current state of the target workload (190) currently exists, starting the target workload (190) at the second node (122b) using the snapshot (152) of the current state of the target workload (190).

12. The system (100) of claim 11, wherein the operations further comprise: storing the snapshot (152) at a shared storage device (150); and based on determining that the snapshot (152) currently exists, obtaining the snapshot (152) from the shared storage device (150).

13. The system (100) of claims 11 or 12, wherein the target workload (190) resides in a container (126) of the first node (122a).

14. The system (100) of claim 13, wherein: the operations further comprise injecting a predetermined file (192) into the container (126) of the first node (122a); and the signal (194) indicating that the target workload (190) is in the ready state is received in response to the target workload (190) accessing the predetermined file (192) injected into the container (126).

15. The system (100) of any of claims 11-14, wherein the operations further comprise: detecting a termination of the target workload (190); based on detecting the termination of the target workload (190), generating another snapshot (152) of the target workload (190); andstarting the target workload (190) at the second node (122b) using the other snapshot (152) of the target workload (190).

16. The system (100) of any of claims 11-15, wherein the operations further comprise: detecting that the target workload (190) is idle, based on detecting that the target workload (190) is idle, generating another snapshot (152) of the target workload (190); and starting the target workload (190) at the second node (122b) using the other snapshot (152) of the target workload (190).

17. The system (100) of any of claims 11-16, wherein the first node (122a) and the second node (122b) are the same node (122).

18. The system (100) of any of claims 11-17, wherein the first node (122a) and the second node (122b) are different nodes (122).

19. The system (100) of any of claims 11-18, wherein the operations further comprise refreshing an external state of the target workload (190).

20. The system (100) of any of claims 11-19, wherein the operations further comprise, after generating the snapshot (152), communicating with the target workload (190) that the snapshot (152) is complete.

Images