Migration of storage for workloads between desktop and cloud environments

Data storage of workloads is migrated from a local computing environment to a cloud computing environment. The workloads are first executed in a runtime environment that have been deployed within a first virtual machine running in the local computing environment, according to a blueprint that defines a data storage path for the workloads. The data storage of the workloads is migrated by copying contents of a first file, which corresponds to a virtual disk of the first virtual machine, to a second file, modifying the blueprint to change the data storage path to a path that specifies a file path to the second file, and deploying a runtime environment within a second virtual machine running in the cloud computing environment, according to the modified blueprint. After transitioning the data storage of the workloads in this manner, the workloads are executed in the runtime environment deployed within the second virtual machine.

BACKGROUND

Kubernetes® (commonly stylized as k8s) is becoming more common in industries for automating application deployment, scaling, and management. Kubernetes workloads generally run in a cloud environment, but many users tend to initially run the workloads locally on a desktop, and then upload the workloads to the cloud environment. However, the transition of the workloads between local and cloud environments is currently difficult to achieve because of differences in storage devices used in the two environments.

SUMMARY

According to one or more embodiments, data storage of workloads is migrated from a local computing environment (e.g., desktop) to a cloud computing environment. The workloads are first executed in a runtime environment (e.g., Kubernetes runtime environment) that have been deployed within a first virtual machine running in the local computing environment, according to a blueprint that defines a data storage path for the workloads. The data storage of the workloads is migrated by copying contents of a first file, which corresponds to a virtual disk of the first virtual machine, to a second file, modifying the blueprint to change the data storage path to a path that specifies a file path to the second file, and deploying a runtime environment within a second virtual machine running in the cloud computing environment, according to the modified blueprint. After transitioning the data storage of the workloads in this manner, the workloads are executed in the runtime environment deployed within the second virtual machine.

Further embodiments include, without limitation, a non-transitory computer-readable storage medium that includes instructions for a processor to carry out the above method, and a computer system that includes a processor programmed to carry out the above method.

DETAILED DESCRIPTION

FIG. 1illustrates a local user terminal100(more generally referred to as a local computing environment) in which a Kubernetes workload is executed and from which data storage of the Kubernetes workload is migrated to a cloud computing environment150according to one or more embodiments. As depicted inFIG. 1, local user terminal100(e.g., a notebook, laptop, or desktop computer) includes a hardware platform (hardware)102, which contains conventional components of a computer system including a processor (not shown), RAM (not shown), and storage103, e.g., hard disk drive or solid state drive, a host operating system (OS)104, and a hosted hypervisor106, which supports an execution space in which local VM108runs. One or more local VMs may be instantiated in the execution space supported by hosted hypervisor106but only one is shown to simplify the description. In one embodiment, hosted hypervisor106provisions a virtual disk for local VM108as a virtual disk image file (e.g., VMDK file) in storage103, such that all input/output (I/O) operations issued by local VM108to its virtual disk are processed as file I/O operations performed on the virtual disk image file.

Local VM108includes a guest OS114and a container runtime environment provisioned by a container engine115, which is running on top of guest OS114. As depicted inFIG. 1, a plurality of containers are deployed in the container runtime environment, and an application is running in each container. For example, application120is running in container118. In each node of a Kubernetes cluster, a plurality of containers are managed as a single unit, e.g., a pod116, by a kubelet, which is depicted more generally inFIG. 1as a node agent122.FIG. 1also depicts network proxy123, which is a network proxy (e.g., kube-proxy) that runs on each node of the Kubernetes cluster to enable network communication to and from a pod of that node, e.g., pod116.

Local user terminal100communicates with cloud computing environment150via a network140. Cloud computing environment150includes a plurality of hosts, which are physical servers hosting virtual machines, and a storage152that is accessible by the hosts. Storage152may be any one of a storage array connected to the hosts through a storage area network (SAN), network-attached storage, or a virtual SAN.

FIG. 2illustrates in more detail host151that is configured with virtual machines in which Kubernetes workloads are executed. As depicted inFIG. 2, host151includes a hardware platform (hardware)202, which contains conventional components of a computer system including a storage interface (e.g., host bus adapter) or a network interface (e.g., network interface controller) through which I/O operations are transmitted to storage152. Host151further includes a hypervisor204(more generally referred to as virtualization software), which supports an execution space in which cloud VMs are instantiated.

A Kubernetes cluster typically includes multiple nodes.FIG. 2depicts just one node of the Kubernetes cluster deployed in cloud VM206. Cloud VM206includes a guest OS208and a container runtime environment provisioned by a container engine209, which is running on top of guest OS208. As depicted inFIG. 2, a plurality of containers are deployed in the container runtime environment, and an application is running in each container. For example, application214is running in container218. Also executing in cloud VM206is a node agent216which manages all of the containers in pod210as a single unit. In addition, network proxy217enables network communication to and from pod210.

FIG. 3illustrates an example of a blueprint used to provision a Kubernetes cluster at local user terminal100and a blueprint used to provision a Kubernetes cluster in the virtual machines running in cloud computing environment150. The blueprint used to provision a Kubernetes cluster typically is configured as a yaml file.

A local yaml file302is the blueprint used to provision a Kubernetes cluster at local user terminal100. It is an example of a yaml file associated with pod116provisioned in local user terminal100. Local yaml file302defines a data storage path304for pod116. In particular, data storage path304includes “hostPath” which indicates the path to a file or directory in a file system managed by host OS104inFIG. 2.

A cloud yaml file306is the blueprint used to provision a Kubernetes cluster in the virtual machines running in cloud computing environment150. It is an example of a yaml file associated with pod210provisioned in cloud VM206. Cloud yaml file306defines a data storage path308for pod201. In particular, data storage path308includes “volumePath” which indicates the path to a file or directory in a file system managed hypervisor204inFIG. 3.

FIG. 4is a flowchart of a method for switching a Kubernetes context from local user terminal100to cloud computing environment150, and the method illustrates how a data storage of workloads executed in a local computing environment is migrated to a cloud computing environment.

The method begins in step404, where a user executes an installation script within local VM108to deploy a Kubernetes cluster in accordance with a yaml file (see, e.g., local yaml file302inFIG. 3). For example, the deployed Kubernetes cluster may be a single-node Kubernetes cluster with pod116, node agent122, and network proxy123depicted inFIG. 1. Then, in step406, the installation script mounts the VMDK file, which is currently stored in storage103and backing the virtual disk of local VM108, to the “hostPath” given by the yaml file. Hereafter, all of the I/O operations generated as workloads are run in the deployed Kubernetes cluster (step408) are issued to the virtual disk of the local VM108and converted to file operations performed on the VMDK file by host OS104.

The arrow from408to410represents a switch in context Kubernetes context from local user terminal100to cloud computing environment150, and a handoff of the yaml file from local user terminal100to cloud computing environment150. That is, the user now wants to run workloads in a Kubernetes cluster that is deployed in cloud computing environment150. For example, the Kubernetes cluster deployed in cloud computing environment150may be a single-node Kubernetes cluster with pod210, node agent216, and network proxy217depicted inFIG. 2. To switch the context, the user runs a storage migration script on a cloud platform management server (not shown). The storage migration script in step410uploads the VMDK file stored in storage103to storage152. Then, in step412, the storage migration script modifies the yaml file to include a “volumePath” (see, e.g., cloud yaml file306inFIG. 3) and sets the path to the uploaded VMDK file to be the “volumePath” in the yaml file. In step414, the storage migration script deploys a Kubernetes cluster in accordance with the yaml file. Hereafter, all of the I/O operations generated as workloads are run in the deployed Kubernetes cluster (step416) are issued to the virtual disk of cloud VM206and converted to file operations performed on the uploaded VMDK file by hypervisor204.

FIG. 5is a flowchart of a method for switching a Kubernetes context from cloud computing environment150to local user terminal100, and the method illustrates how a data storage of workloads executed in a cloud computing environment is migrated to a local computing environment.

The method begins in step504, where the user executes an installation script on the cloud platform management server to deploy a Kubernetes cluster in accordance with a yaml file (see, e.g., cloud yaml file308inFIG. 3). For example, the deployed Kubernetes cluster may be a single-node Kubernetes cluster with pod210, node agent216, and network proxy217depicted inFIG. 2. Hereafter, all of the I/O operations generated as workloads are run in the deployed Kubernetes cluster (step506) are issued to the virtual disk of cloud VM206and converted to file operations performed on the VMDK file by hypervisor204.

The arrow from506to508represents a switch in context Kubernetes context from cloud computing environment150to local user terminal100, and a handoff of the yaml file from cloud computing environment150to local user terminal100. That is, the user now wants to run workloads in a Kubernetes cluster that is to be deployed in local user terminal100. To switch the context, the user runs a storage migration script in local VM108. The storage migration script in step508downloads the VMDK file stored in storage152to storage103. Then, in step510, the storage migration script modifies the yaml file to include a “hostPath” (see, e.g., local yaml file302inFIG. 3) and sets the path to the downloaded VMDK file to be the “hostPath” in the yaml file. In step512, the storage migration script mounts the downloaded VMDK file to be the virtual disk of local VM108. Then, in step514, the storage migration script deploys a Kubernetes cluster in accordance with the yaml file. Hereafter, all of the I/O operations generated as workloads are run in the deployed Kubernetes cluster (step516) are issued to the virtual disk of the local VM108and converted to file operations performed on the downloaded VMDK file by host OS104.

One or more embodiments of the present invention may be implemented as one or more computer programs or as one or more computer program modules embodied in one or more computer readable media. The term computer readable medium refers to any data storage device that can store data which can thereafter be input to a computer system. Computer readable media may be based on any existing or subsequently developed technology for embodying computer programs in a manner that enables them to be read by a computer. Examples of a computer readable medium include a hard drive, NAS, read-only memory (ROM), RAM (e.g., flash memory device), Compact Disk (e.g., CD-ROM, CD-R, or CD-RW), Digital Versatile Disk (DVD), magnetic tape, and other optical and non-optical data storage devices. The computer readable medium can also be distributed over a network coupled computer system so that the computer readable code is stored and executed in a distributed fashion.