Accelerating containerized applications with cache

Abstract

Embodiments of the present disclosure relate to accelerating containerized applications with a cache. In some embodiments, a computer-implemented method includes receiving, by a cache system plug-in, a request to create a persistent volume for a container application instance; configuring, by the cache system plug-in, a local cache volume on the host computing device; configuring a remote storage volume on the remote storage device by the cache system plug-in; selecting, by a policy manager of the cache system plug-in, a cache policy for the container application instance; creating, by the cache system plug-in and from the cache manager, a virtual block device associated with the local cache volume, the remote storage volume, and the cache policy; and providing the virtual block device for use by the container application instance as a persistent volume.

Description

Background Art

[0001] Applications can be containerized to provide portability, flexibility, scalability, etc. Container applications are often configured with a temporary repository that can store data associated with the container. However, such a temporary repository is usually not persisted after the container is terminated. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Certain embodiments discussed herein will be described with reference to the drawings listed below. However, the drawings illustrate only certain aspects or implementations of the embodiments described herein by way of example and are not meant to limit the scope of the claims.

[0003] Figure 1 A block diagram illustrating an example system for implementing a caching framework for persistent volumes for containerized applications according to one or more embodiments disclosed herein;

[0004] Figure 2 illustrates a block diagram of an example cache system plug-in according to one or more embodiments disclosed herein;

[0005] Figure 3 An overview of an example method for creating a cache-enabled persistent volume for a container application instance according to one or more embodiments disclosed herein is illustrated;

[0006] Figure 4 illustrates an example scenario for deploying an instance of a container application with a persistent volume according to one or more embodiments of the present disclosure;

[0007] Figure 5 A block diagram of a computing device according to one or more embodiments of the present disclosure is illustrated. DETAILED DESCRIPTION

[0008] Computing resources (e.g., processors, network devices, storage devices, accelerators, etc.) can be used by a logical instance of an application (e.g., a container). For example, a container can be deployed on a host computing device and executed using a portion of the computing resources of the computing device. Some containers are configured to use a temporary repository, which can be provided for an instance of a container and destroyed when the container instance terminates. However, there are scenarios where a container may desire a persistent repository. A persistent repository for a container can store data that persists even after a particular instance of the container is terminated. As an example, some database applications, message broker applications, logging applications, etc. may be stateful, and therefore data written or read by a container instance that implements such an application may need to be persisted beyond the lifecycle of a particular container instance.

[0009] Some container platforms (e.g., Kubernetes) may allow a user to specify a persistent volume for a container during container configuration. A request to create a persistent volume for a container may be received by an application programming interface (API) server executed in the control plane of the container platform. The API server may provide a request to a storage controller executed as part of the control plane of the container platform. The storage controller may then determine on which host computing device the container will be deployed and request to create a persistent volume for the container on that host. However, instances of containers may not always be deployed on the same host computing device, which means that new instances of containers deployed on different hosts may not be able to access data from persistent volumes. Alternatively, persistent volumes may be created on a remote storage device that can be accessed by any number of host computing devices in the container ecosystem (e.g., over a network) and provided to the container as a persistent volume, regardless of which host the instance of the container is deployed on. However, using a remote repository for persistent volumes may bring additional latency (e.g., network latency) to all reads and writes of persistent volumes, which may have a negative impact on the performance of container applications.

[0010] In order to at least solve the aforementioned problem of deploying containers with persistent volumes, the embodiments disclosed herein provide technology for implementing a caching framework for persistent volumes of containers.

[0011] In one or more embodiments, an entity (e.g., a user, a software entity, etc.) requests to configure a container to have a persistent volume. The request can be part of an initial configuration of a container within a container ecosystem managed by a container platform (e.g., Kubernetes), or to add a persistent volume to a previously configured container. The request can be received, for example, by an API server of a container platform with which the entity configuring the persistent volume interacts. In one or more embodiments, a request for a persistent volume for a container is provided from the API server to a cache system controller that is implemented in the control plane of the container platform and registered with the API server. In one or more embodiments, the cache system controller determines on which host computing device the container will be deployed (or has been deployed). In one or more embodiments, the cache system controller sends a request to a cache system plug-in executing on an identified host to create a cache-enabled persistent volume for the container.

[0012] In one or more embodiments, in response to the request, the cache system plug-in creates two volumes on the physical storage device. In one or more embodiments, one volume is created on the remote storage device and the other volume is created on a local storage device (e.g., flash memory, persistent memory, etc.) of the host computing device to act as a cache for the persistent volume. In one or more embodiments, the cache system plug-in then provides information about the two volumes to a cache manager (e.g., Open Cache Acceleration Software (Open CAS)) also executing on the host computing device in the request (e.g., via a command line operation) for the cache manager to create a virtual block device.

[0013] In one or more embodiments, the cache manager creates a virtual block device that includes a remote storage device volume and a local cache volume. In one or more embodiments, the virtual block device and the local cache storage volume and the remote storage volume associated with the virtual block device are provided as a persistent volume for the container. In one or more embodiments, from the perspective of the entity requesting the persistent volume, the container platform, and the container, the persistent volume can be viewed as a single persistent volume associated with the container.

[0014] In one or more embodiments, the cache system plug-in includes a policy manager. In one or more embodiments, the policy manager is configured to select a cache policy to apply to a persistent volume. In one or more embodiments, the policy is configured to cause a cache manager executed on a host computing device to enforce a cache policy for a container. In one or more embodiments, the cache policy determines what data corresponding to the container is cached in the cache volume, and when the data is evicted from the cache volume or otherwise written to a remote storage volume. The cache policy may include a cache mode (e.g., write-through, write-back, write-around, write-invalidate, write-only, pass-through, etc.), a cache eviction algorithm (e.g., least recently used, least frequently used, first-in-first-out, most recently used, etc.), and a container termination plan (e.g., flushing data from a cache volume to a remote storage volume when a container instance is terminated).

[0015] In one or more embodiments, the policy manager of the cache system plug-in is configured to access or otherwise be able to obtain information about how the container application is likely to perform I / O, such as performing more writes than reads, expected I / O patterns, etc., which can be referred to as historical data related to the container application. In one or more embodiments, when the container is first deployed, the historical data may include information that relates the type of application (e.g., a database application) to the expected I / O pattern for such application (e.g., more writes than reads). In one or more embodiments, the policy optimizer uses such information to select an initial cache policy for the container application instance deployed on the host. In one or more embodiments, various types of applications implemented in the container instance can be associated with a specific cache policy by default. In one or more embodiments, when a persistent volume is created, a cache policy is applied to the persistent volume and does not change during the life cycle of the container application instance.

[0016] However, over time, other instances of the container application or similar container applications may be deployed within the container ecosystem. Therefore, in one or more embodiments, a cache manager executing on a host computing system is configured to monitor the I / O patterns of containers executing on the host computing system. The I / O pattern information may be provided to a cache system plug-in, or may be provided from a cache system plug-in on a host computing device to a cache system controller of the container platform. Data about the I / O patterns of the container instance may be added to historical data, which may be used by the (multiple) policy managers of the cache system plug-in when selecting a cache policy to apply to a persistent volume of the container instance. Therefore, in one or more embodiments, over time, historical data about the I / O patterns of the container increases and may be used to select appropriate cache policies for future deployments of instances of the same or similar containers on host computing devices in the container ecosystem.

[0017] In one or more embodiments, information about virtual block devices (e.g., local volumes, remote volumes, cache policies, etc.) is provided from the cache manager to the cache system plug-in. In one or more embodiments, the cache system plug-in provides the information about the virtual block devices to the cache system controller. The cache system controller can then store the virtual block device information as part of the configuration information of the container in a container data repository (e.g., an etcd key-value repository in Kubernetes).

[0018] In one or more embodiments, after a virtual block device corresponding to a local storage volume as a cache and a remote storage volume as a backend storage volume has been created as a persistent volume for a container application instance, the container application can use the persistent volume to perform I / O operations (e.g., read, write, etc.). The cache manager can perform I / O operations according to the configured cache policy. In one or more embodiments, when a container application instance on a host computing device is terminated, data in the cache of the container application instance that has not yet been committed to remote storage can be committed in this way, thereby allowing data to be persisted after the container application instance is terminated, which can allow other instances of the container application to access the data. In one or more embodiments, the local cache storage volume is implanted on a persistent storage device (e.g., a persistent memory device, a flash memory device, etc.), which allows data stored in the local cache volume to be persisted after the container application instance is terminated, a system failure, etc., for example, if the local cache is instead implemented in a non-persistent and / or volatile memory device (such as, for example, a dynamic random access memory (DRAM) device), this may be impossible.

[0019] Certain embodiments of the present disclosure can improve the performance of container application instances with persistent volumes by implementing a cache system to cache data on a local higher performance storage volume and using a remote storage volume as the backend storage for the persistent volume. One or more embodiments disclosed herein can avoid at least some of the latency associated with performing I / O operations on remote storage while also allowing data for container applications to be persisted and available regardless of which host computing device the instance of the container application is deployed on.

[0020] Figure 1 A block diagram of an example system for implementing a cache framework for persistent volumes of containerized applications according to one or more embodiments disclosed herein is illustrated. Figure 1As shown in , the system may include a container ecosystem 100. The container ecosystem 100 may include an API server 104, a cache system controller 106, a container ecosystem data repository 108, a remote storage device 134, and any number of nodes (e.g., node A 110, node N 122). Each node may include a cache system plug-in (e.g., cache system plug-in A 116 of node A 110, cache system plug-in N 128 of node N 122), a cache manager (e.g., cache manager A 118 of node A 110, cache manager N 130 of node N 122), and a local storage device (e.g., local storage device A 120 of node A 110, local storage device N 132 of node N 122). Any number of containers may be executed on a node (e.g., container A 112 of node A 110, container N 124 of node N 122). A container may be configured with any number of persistent volumes (eg, persistent volume A 114 for container A 112, persistent volume N 126 for container N 124). Each of these components is described below.

[0021] In one or more embodiments, the container ecosystem 100 is a collection of any number of computing devices. In one or more embodiments, as used herein, a computing device may be any single computing device, a group of computing devices, a portion of one or more computing devices, or any other physical, virtual, and / or logical grouping of computing resources. In one or more embodiments, a computing device is any device, a portion of a device, or any group of devices capable of electronically processing instructions, and may include, but is not limited to, any of the following: one or more processors (e.g., components including circuit systems), memory (e.g., random access memory (RAM)), (multiple) input and output devices, non-volatile storage hardware (e.g., solid-state drive (SSD), persistent memory (Pmem) device, hard disk drive (HDD) (not shown)), one or more physical interfaces (e.g., network ports, storage ports), any number of other hardware components (not shown), and / or any combination thereof.

[0022] Examples of computing devices include, but are not limited to, servers (e.g., blade servers in blade server chassis, rack servers in racks, etc.), desktop computers, mobile devices (e.g., laptops, smartphones, personal digital assistants, tablets, automotive computing systems, and / or any other mobile computing devices), storage devices (e.g., disk drive arrays, Fibre Channel storage devices, Internet Small Computer System Interface (iSCSI) storage devices, tape storage devices, flash storage arrays, network attached storage devices, etc.), network devices (e.g., switches, routers, multilayer switches, etc.), virtual machines, virtualized computing environments, logical containers (e.g., for one or more applications), Internet of Things (IoT) devices, arrays of computing resource nodes, supercomputing devices, data centers or any portion thereof, and / or any other type of computing device having the above requirements. In one or more embodiments, any or all of the foregoing examples may be combined to create a system of such devices, or may be divided into separate logical devices, which may be collectively referred to as computing devices. Other types of computing devices may be used without departing from the scope of the embodiments described herein, such as, for example Figure 5 The computing device shown in and described below.

[0023] In one or more embodiments, the storage and / or memory of a computing device or system of computing devices may be and / or include one or more data storage repositories for storing any number of data structures that store any number of data (e.g., information). In one or more embodiments, a data storage repository is any type of storage unit and / or device (e.g., a file system, a database, a collection of tables, RAM, and / or any other storage mechanism or medium) for storing data. In addition, a data storage repository may include multiple different storage units and / or devices. Multiple different storage units and / or devices may or may not be of the same type or located at the same physical location.

[0024] In one or more embodiments, any repository and / or memory of a computing device or system of computing devices may be considered, in whole or in part, to be a non-transitory computer-readable medium that stores software and / or firmware.

[0025] Such software and / or firmware may include instructions that, when executed by one or more processors (not shown) and / or other hardware (e.g., circuitry) of a computing device and / or system of computing devices, cause the one or more processors and / or other hardware components to perform operations in accordance with one or more embodiments described herein.

[0026] The software instructions may be in the form of computer-readable program code for executing the methods, processes, etc. of the embodiments described herein, and as an example, the software instructions may be stored in whole or in part, temporarily or permanently, on a non-transitory computer-readable medium, such as a compact disk (CD), a digital versatile disk (DVD), a storage device, a floppy disk, a tape storage, a flash memory storage, a physical memory, or any other non-transitory computer-readable medium.

[0027] The container ecosystem 100 may include any number of computing devices, which may be collectively referred to as computing devices as used herein. All or any portion of the computing devices may be computing devices of the same type or different types.

[0028] In one or more embodiments, the container ecosystem 100 is managed by a container platform (not shown), such as, for example, Kubernetes. In one or more embodiments, the container platform includes a control plane (not shown). The control plane of the container platform may include various components (e.g., one or more API servers, controllers, schedulers, etc.) for managing the container ecosystem 100. The control plane may be implemented, for example, on one or more master nodes, each of which may be a computing device (as discussed above).

[0029] In one or more embodiments, the container ecosystem 100 includes an API server 104. In one or more embodiments, the API server 104 is a computing device of the container ecosystem 100 and executes in the control plane of the container platform. In one or more embodiments, the API server 104 is configured to interact with entities (e.g., users) seeking to configure various aspects of the container ecosystem 100. As an example, the API server 104 can be configured to receive requests (e.g., to configure a container, deploy a container instance, terminate a container, configure storage for a container, configure networking for a container, view information about the container ecosystem or any part thereof, etc.), and to service the request or provide the request to other entities that can service the request. Although Figure 1 The container ecosystem 100 is shown as including a single API server 104 , but the container ecosystem 100 may include any number of API servers without departing from the scope of the embodiments disclosed herein.

[0030] In one or more embodiments, the container ecosystem 100 includes a container ecosystem data repository 108. In one or more embodiments, the container ecosystem data repository 108 is any type of data repository for storing any number of data structures that store any number of data (e.g., information). In one or more embodiments, the data repository is any type of storage unit and / or device for storing data (e.g., a file system, a database, a collection of tables, RAM, and / or any other storage mechanism or medium). In addition, the data repository may include multiple different storage units and / or devices. Multiple different storage units and / or devices may or may not be of the same type or located in the same physical location. In one or more embodiments, the container ecosystem data repository 108 is implemented as part of the control plane of the container platform of the container ecosystem 100. As an example, the container ecosystem data repository 108 may be an etcd key-value repository of the Kubernetes container platform. The container ecosystem data repository 108 may be included in and / or operably connected to one or more master nodes (e.g., API server 104) that implement the control plane of the container platform or any part thereof. In one or more embodiments, the container ecosystem data repository 108 is configured to store all or any portion of the data of the container ecosystem (e.g., configuration data of containers, data associated with clusters, pods, etc. of the container platform, etc.). Figure 1 The container ecosystem 100 is shown as including a single container ecosystem data repository 108 , but the container ecosystem 100 may include any number of container ecosystem data repositories without departing from the scope of the embodiments disclosed herein.

[0031] In one or more embodiments, the container ecosystem 100 includes a cache system controller 106. In one or more embodiments, the cache system controller 106 is any hardware, software, firmware, or any combination thereof configured to at least partially manage persistent volumes associated with containers in the container ecosystem 100. In one or more embodiments, the cache system controller 106 is all or any part of a computing device (as discussed above). In one or more embodiments, the cache system controller 106 is included in the control plane of the container platform of the container ecosystem 100. The cache system controller may be included in a computing device (e.g., one or more master nodes) that also includes all or any part of other components of the control plane, such as, for example, an API server 104 and / or a container ecosystem data repository 108. In one or more embodiments, the cache system controller 106 is separate from and operably connected to other components of the control plane. In one or more embodiments, the cache system controller 106 is configured to receive requests related to persistent volumes of containers in the container ecosystem 100 (e.g., provided by the API server 104 from an entity interacting with the API server 104). For example, an entity may submit a request to configure a container with a persistent volume to API server 104. API server 104 may determine that the request is related to a persistent volume and pass the portion of the request related to the persistent volume to cache system controller 106 to service the request.

[0032] In one or more embodiments, the container ecosystem 100 includes any number of nodes (e.g., Node A 110, Node N 122). In one or more embodiments, the nodes (e.g., 110, 122) are computing devices (as discussed above). In one or more embodiments, the nodes (e.g., 110, 122) are configured to host one or more instances of one or more containers. As an example, Figure 1 Node A 110 hosting an instance of container A 112 and node N 1222 hosting an instance of container N 124 are shown. Figure 1 The container ecosystem 100 is shown as including two nodes ( 110 , 122 ), but the container ecosystem 100 may include any number of nodes without departing from the scope of the embodiments disclosed herein.

[0033] In one or more embodiments, a container (e.g., container A 112, container N 124) is any type of application and various dependencies of the application (e.g., libraries, runtime, etc.) that are packaged together to be deployed as a container instance on a computing device, such as, for example, node A 110 and node N 122. The containers (e.g., 112, 124) can be configured by an entity (e.g., a user, a software entity, etc.). As an example, such configuration can occur at least in part via an interaction between an entity desiring to deploy the container and the API server 104. Additional configuration of the container can be performed by other parts of the container platform control plane, such as, for example, a network controller or a cache system controller 106. Any number of instances of a particular container can be deployed on any number of nodes in the container ecosystem 100. Although Figure 1 Each node (110, 122) is shown as including a single instance of a container (112, 124), but a node may include any number of instances of any number of containers without departing from the scope of the embodiments disclosed herein. In one or more embodiments, although Figure 1 Not shown, but each node (e.g., 110, 122) of container ecosystem 100 can be operably connected to API server 104, which can at least partially orchestrate the deployment of instances of containers on the nodes.

[0034] In one or more embodiments, a container (e.g., 112, 124) may be configured with a persistent volume (e.g., persistent volume A 114, persistent volume N 126). In one or more embodiments, a persistent volume is any type of storage repository that is configured to be associated with one or more instances of a container (e.g., 112, 124). A persistent volume (e.g., 114, 126) may be configured for a container (e.g., 112, 124) at the initial configuration time of the container, or added to the configuration of the container at a later time. A given container may be configured with any number of associated persistent volumes without departing from the scope of the embodiments disclosed herein. In one or more embodiments, a persistent volume (e.g., 114, 126) may be a storage resource that stores data after termination of a particular container instance associated with the persistent volume. In one or more embodiments, a request to configure a persistent volume for a container may be provided to a cache system controller 106, which may interact with one or more cache system plug-ins (discussed further below) to provide a persistent volume to an instance of a container.

[0035] In one or more embodiments, all or any portion of the nodes (e.g., 110, 122) of the container ecosystem 100 may include a cache system plug-in (e.g., cache system plug-in A 116, cache system plug-in N 128). In one or more embodiments, the cache system plug-in (116, 128) is any hardware, software, firmware, or any combination thereof configured to interact with the cache system controller 106 to service requests to provide persistent volumes (e.g., 114, 126) for container instances (e.g., 112, 124). In one or more embodiments, the cache system plug-in (e.g., 116, 128) is executed on the nodes (e.g., 110, 122) of the container ecosystem 100. In one or more embodiments, each cache system plug-in (e.g., 116, 128)) is operably connected to the cache system controller 106.

[0036] In one or more embodiments, the nodes (e.g., 110, 122) of the container ecosystem 100 include local storage devices (e.g., local storage device A 120 of node A 110, local storage device N 132 of node N 122). The local storage devices (e.g., 120, 132) can be any type of storage device local to the node. In one or more embodiments, the local storage device is a higher performance type of storage device relative to other storage devices available to the node. As an example, the local storage device (e.g., 120, 132) can be a persistent memory device, a flash memory device, etc. that has higher performance than other storage devices (e.g., a hard drive) available to the node. Although Figure 1 The nodes (110, 122) are shown as including a single local storage device (120, 132) per node, but a node may include any number of local storage devices without departing from the scope of the embodiments disclosed herein.

[0037] In one or more embodiments, the container ecosystem 100 includes a remote storage device 134. The remote storage device 134 can be any type of storage device (e.g., an iSCSI storage library, a Fibre Channel storage library, a NAS device, etc.) that is configured to be remotely accessible (e.g., via a network) to the nodes (e.g., 110, 122) of the container ecosystem 100. The remote storage device 134 can be operably connected to all or any portion of the nodes (e.g., 110, 122) of the container ecosystem 100. Although Figure 1 The container ecosystem 100 is shown as including a single remote storage device 134 , but the container ecosystem 100 may include any number of remote storage devices without departing from the scope of the embodiments disclosed herein.

[0038] In one or more embodiments, the cache system plug-in (e.g., 116, 128) is configured to receive a request to create a persistent volume for an instance of a container (e.g., 112, 124). In one or more embodiments, in response to receiving such a request from the cache system controller 106, the cache system plug-in (e.g., 116, 128) is configured to create two volumes; one located on a local storage device (e.g., 120, 132) of the node on which the cache system plug-in is executed, which the cache system plug-in will use as a cache for the persistent volume; and the other located on a remote storage device 134. The two volumes can each be any portion of the storage available on or for the respective device. The size of the volume can be specified in the request received from the cache system controller 106.

[0039] In one or more embodiments, a node (e.g., 110, 122) of the container ecosystem 100 includes a cache manager (e.g., cache manager A 118, cache manager N 130). In one or more embodiments, a cache manager (e.g., 118, 130) is any hardware, software, firmware, or any combination thereof configured to at least partially manage a repository of persistent volumes of a container instance to be used as a cache. An example of a cache manager is Open CAS. Other cache managers may be used without departing from the scope of the embodiments disclosed herein. In one or more embodiments, a cache manager (e.g., 118, 130) is configured to receive information about volumes created by a cache system plug-in (e.g., 116, 128) in order to create a virtual block device containing these volumes. As an example, a cache system plug-in (e.g., 116, 128) may provide information about volumes created on a local storage device (e.g., 120, 132) to be used as cache storage and volumes created on a remote storage device 134 to be used as a backend repository. The cache manager (e.g., 118, 130) can then use this information to create a virtual block device that will be used by the instance of the container as a persistent volume (e.g., 114, 126). In one or more embodiments, information about the virtual block device can be provided from the cache manager (e.g., 118, 130) to the cache system plug-in (e.g., 116, 128), which in turn can provide the information to the cache system controller 106 to store it in the container ecosystem data store 108 as part of the configuration information for the container.

[0040] In one or more embodiments, a cache manager (e.g., 118, 130) is configured to implement a cache policy for a persistent volume that includes a volume as a cache on a local storage device and a volume as a backend repository on a remote storage device. In one or more embodiments, the cache policy determines what data corresponding to a container is cached in the cache volume and when the data is evicted from the cache volume or otherwise written to the remote storage volume. The cache policy may include a cache mode (e.g., write-through, write-back, write-around, write-invalidate, write-only, pass-through, etc.) and a cache eviction algorithm (e.g., least recently used, least frequently used, first-in-first-out, most recently used, etc.). In one or more embodiments, read requests and write requests issued by a container instance (e.g., 112, 124) to its associated persistent volume (e.g., 114, 126) are serviced by the cache manager (e.g., 118, 130) according to the cache policy configured for the persistent volume. As an example, a write request to write data to a persistent volume can be made by a container (e.g., 112, 124), and the cache manager (e.g., 118, 130), based on a write-through cache mode of the cache policy, can write the data to the cache (for quick retrieval if a read is requested) and to a backend repository to store the data more persistently.

[0041] In one or more embodiments, a cache policy implemented for a persistent volume (e.g., 114, 116) may be selected by a cache system plugin (116, 128) and provided to a cache manager (118, 130). In one or more embodiments, a cache policy for a persistent volume (114, 126) is selected by a cache system plugin (e.g., 116, 128) and implemented by a cache manager (118, 130) when creating a persistent volume (114, 126) for a container (e.g., 112, 124).

[0042] In one or more embodiments, a cache manager (e.g., 118, 130) is configured to monitor the I / O behavior of instances of containers (e.g., 112, 124) executed on nodes (e.g., 110, 122). In one or more embodiments, information about the I / O behavior of a container instance can be added to historical data of the I / O behavior of other instances of the same or similar containers. In one or more embodiments, such historical data can be used by a cache system plug-in (e.g., 116, 128) to be used when the cache system plug-in selects a cache policy for a persistent volume of a container instance. As an example, when a container is first deployed, the historical data can include information relating the type of application (e.g., a database application) to the expected I / O pattern of such application (e.g., more writes than reads). In one or more embodiments, a policy optimizer uses such information to select an initial cache policy for a container application instance deployed on a host. In one or more embodiments, various types of applications implemented in a container instance can be associated with a specific cache policy by default.

[0043] In one or more embodiments, over time, I / O behavior data of container instances (assuming a cache manager) is added to historical data for a particular type of container (e.g., the same or similar application to be deployed as a container instance), and when a new instance of a container is deployed, the cache system plug-in (e.g., 116, 128) can re-evaluate the updated historical data to select a cache policy for persistent volumes of the new instance of the container, which can be different from the cache policy used for the initial deployment of the container instance and associated persistent volumes. The historical data for a particular type of container can be stored globally within the container ecosystem 100 and made available to the cache system plug-in (e.g., 116, 128) when the cache system plug-in selects a cache policy to apply to persistent volumes (e.g., 114, 126) of instances of containers (e.g., 112, 124).

[0044] Although Figure 1 A specific configuration of components is shown, but other configurations may be used without departing from the scope of the embodiments described herein. Figure 1 Some components are shown as part of the same device, but any component may be grouped into a collection of one or more components that may exist and execute as part of any number of separate and operably connected devices. As another example, a single component may be configured to perform the operations performed by Figure 1 The embodiments disclosed herein should not be limited to all or any part of the functionality performed by the multiple components shown in FIG. Figure 1 Configuration of the components shown in .

[0045] Figure 2 1 illustrates a block diagram of an example cache system plug-in according to one or more embodiments disclosed herein. Figure 1 As shown in FIG. 2 , cache system plug-in 200 includes volume provisioner 202, device manager 204, and policy manager 206. Each of these components is described below.

[0046] In one or more embodiments, the cache system plug-in 200 and Figure 1 The cache system plug-in A 116 and / or cache system plug-in N 128 shown and described above are the same or substantially similar.

[0047] In one or more embodiments, the cache system plug-in 200 includes a volume provisioner 202. In one or more embodiments, the volume provisioner 202 is any hardware, software, firmware, or any combination thereof configured to provision storage volumes on a storage device. As an example, when the cache system plug-in 200 receives a request from a cache system controller (e.g., Figure 1 When a cache system controller 106 as shown in and described above receives a request to create a cache-enabled persistent volume for an instance of a container, the volume provisioner 202 may begin servicing the request by: servicing the request on a local storage device (e.g., Figure 1 The volume is provisioned on a local storage device 120 and 132 as shown in and described above to act as a cache for persistent volumes, and on a remote storage device (e.g., Figure 1 The volume is provisioned on a remote storage device 134 as shown in and described above to act as the backend storage for the persistent volume. Figure 2 The cache system plug-in 200 is shown as including only a single volume provisioner 202, but the cache system plug-in may include any number of volume provisioners without departing from the scope of the embodiments disclosed herein. As an example, there may be separate volume provisioners for certain types of storage devices (e.g., one volume provisioner for local storage devices, a second volume provisioner for iSCSI storage devices, etc.)

[0048] In one or more embodiments, the cache system plug-in 200 includes a policy manager 206. In one or more embodiments, the policy manager 206 is any hardware, software, firmware, or any combination thereof configured to select a cache policy for a persistent volume configured for a container by the cache system plug-in 200. In one or more embodiments, the policy manager 206 includes or otherwise has access to historical data about the I / O behavior of container applications. In one or more embodiments, the policy manager 206 is configured to select an initial cache policy for a persistent volume when an instance of a particular container is first deployed.

[0049] As an example, a container may be used for a particular type of application, and the application may be associated with an expected I / O behavior. In such a scenario, policy manager 206 may select a cache policy for a persistent volume that is associated with the expected I / O behavior of the type of application deployed in the container instance. In one or more embodiments, as the container ecosystem (e.g., Figure 1 The historical data of I / O behavior of container instances in the container ecosystem (as shown in FIG. 1 ) is stored by a cache manager of the container ecosystem (e.g., Figure 1 The policy manager 206 may use the updated historical data to select an appropriate cache policy for an instance of a container being deployed, as enhanced by the I / O behavior observed by the cache manager 118 and cache manager N 130 shown in FIG. 1 . As an example, when a container is first deployed, an initial cache policy for an instance of the container may be selected based on the type of application that the container will execute. However, the actual I / O behavior of the container instance may be different from the expected I / O behavior. The actual I / O behavior is monitored by the cache manager and added to the historical data for the container so that future deployments of the container may have a different cache policy selected by the policy manager for the container instance being deployed.

[0050] In one or more embodiments, the cache system plug-in includes a device manager 204. In one or more embodiments, the device manager 204 is any hardware, software, firmware, or any combination thereof configured to obtain volume information from the volume provisioner 202, cache policy selections from the policy manager 206, and communicate with the cache manager to instantiate persistent volumes for instances of containers deployed on the node. In one or more embodiments, the device manager provides the foregoing information to the cache manager so that the cache manager can create a virtual block device to provide persistent volumes for the container instances and apply cache policies when the container instances write to and read from the persistent volumes. In one or more embodiments, the device manager 204 is configured to provide information about the persistent volumes back to the cache system controller to be stored as part of the configuration information for the container instances (e.g., Figure 1 ).

[0051] Figure 3 An overview of an example method for creating a cache-enabled persistent volume for a container application instance according to one or more embodiments disclosed herein is illustrated. The method may be at least partially provided by a container ecosystem (e.g., Figure 1 ) of the container ecosystem 100 shown in FIG. 1 , such as a cache system controller (e.g., Figure 1), a cache system plug-in (e.g., Figure 1 The cache system plug-ins 116 and 128 shown in or Figure 2 ), and / or a cache manager (e.g., Figure 1 Cache managers 118 and 130)) shown in are executed.

[0052] Although Figure 1 The various steps in the flowcharts shown in are presented and described sequentially, but some or all of the steps may be performed in a different order, some or all of the steps may be combined or omitted, and some or all of the steps may be combined or omitted. Figure 3 The other steps are executed in parallel.

[0053] In step 300, the method includes receiving a request to create a persistent volume for a container application instance. The request may be received by a cache system plug-in from a cache system controller. As an example, a user may interact with an API server of a container platform to request deployment of a container application with a persistent volume. The API server may send a request to the cache system controller to create a persistent volume for an instance of a container application. The cache system controller may then identify a node in the container ecosystem on which the container application instance will be deployed, and request the cache system plug-in executed on the identified node to create a persistent volume for the container application instance. The request may specify any relevant information related to the persistent volume (e.g., the desired storage size of the persistent volume).

[0054] In step 302, the method includes deploying or deploying a container application instance (e.g., Figure 1 112) of a container ecosystem (e.g., Figure 1 Nodes in the container ecosystem 100 shown in FIG. Figure 1 Node A 110) shown in FIG. Figure 1 In one or more embodiments, in response to the request received by the cache system plug-in in step 300, the cache system plug-in (e.g., Figure 2 200) of a volume provisioner (e.g., Figure 2 ) provisions volumes on a local storage device of a node to be used as a cache for persistent volumes. The local cache volume may be all or any portion of the storage available on the local storage device. In one or more embodiments, the local storage device is a higher performance storage device such as, for example, a persistent memory device (e.g., Optane TMDCPMem devices), flash memory devices, etc.

[0055] In step 304, the method includes configuring a remote storage volume on a remote storage device. In one or more embodiments, the remote storage volume is used as a backend storage volume for a persistent volume. The remote storage volume can be all or any portion of the storage space available on the remote storage device. The remote storage volume can be configured on a single remote storage device, or can be a logical volume on any number of remote storage devices. The one or more remote storage devices can be any type of storage device. In one or more embodiments, the remote storage device on which the remote storage volume is configured is operably connected (e.g., via a network) to a node on which a container application instance for which a persistent volume is configured is deployed.

[0056] In step 306, the method includes selecting a cache policy for the persistent volume based on historical data associated with the container application type. In one or more embodiments, the cache policy is determined by a policy manager (e.g., Figure 2 ) is selected by the policy manager 206 shown in . In one or more embodiments, the cache policy determines what data corresponding to the container is cached in the local cache volume, and when data is evicted from the cache volume or otherwise written to the remote storage volume. The cache policy may include a cache mode (e.g., write-through, write-back, write-around, write-invalidate, write-only, pass-through, etc.), a cache eviction algorithm (e.g., least recently used, least frequently used, first-in-first-out, most recently used, etc.), and a container termination plan (e.g., flushing data from the cache volume to the remote storage volume when the container instance terminates). Certain types of applications may typically exhibit certain types of I / O behavior. Therefore, when a container application instance is first deployed, and there is not yet a large amount of historical data about the I / O behavior that the instance of the container application will perform, the policy manager may be configured to select a cache policy for the expected I / O behavior that is appropriate for the application type of the container application. However, when (e.g., by Figure 1 When the cache manager A 118 shown in ) observes the I / O behavior of the instance of the container application, and the observed I / O behavior is added to the historical data about the I / O behavior corresponding to the container application, the appropriate cache policy can be different from the initial cache policy applied to the initial deployment of the container application. In one or more embodiments, each time an instance of the container application is deployed on a node in the container ecosystem, the policy manager of the cache system plug-in can evaluate the historical I / O behavior data corresponding to the container application and select the most appropriate cache policy for such I / O behavior.

[0057] In step 308, the method includes requesting the cache manager to create a virtual block device using information associated with the local cache volume created in step 302 and the remote storage volume created in step 304 and the cache policy selected in step 306. In one or more embodiments, the request is made by a device manager (e.g., Figure 2 In one or more embodiments, the virtual block device contains two volumes and is provided to the container application instance as a persistent volume, and the cache manager applies the selected cache policy to I / O operations on the persistent volume from the container application instance. In one or more embodiments, information related to the virtual block device is provided back to the cache system plug-in, which can then relay the information to the cache system controller. The cache system controller can then store the information as part of the configuration information associated with the container application instance (e.g., in Figure 1 ).

[0058] In step 310, the method includes applying a cache policy to an I / O operation on a persistent volume. In one or more embodiments, the container application instance writes data to the persistent volume and reads data from the persistent volume. In one or more embodiments, when performing reads and writes, the cache manager writes the data to the local cache volume and / or the remote storage volume based on the cache policy, and performs the read by checking the requested data in the cache. In one or more embodiments, if the data exists in the cache, the data is read from the cache, otherwise the data is read from the remote storage volume. Therefore, in one or more embodiments, the performance of container applications using persistent volumes is improved because I / O operations using local cache volumes can be performed without incurring latency overhead associated with I / O operations on remote storage volumes. At the same time, in one or more embodiments, the data is ultimately stored on the remote storage volume and remains persistent even after the container application instance is terminated, and because the remote storage volume is accessible by other nodes in the container ecosystem, even other instances of container applications deployed on other nodes can access the data.

[0059] In step 312, the method includes monitoring I / O behavior of the container application instance. In one or more embodiments, the cache manager monitors the I / O behavior of the container application instance. The cache manager can provide information related to the monitored I / O behavior to the cache system plug-in.

[0060] In step 314, the method includes updating historical I / O behavior data of the container application instance based on the monitored I / O behavior information. In one or more embodiments, when deploying other instances of the container application or similar container applications, the updated historical I / O behavior information can then be used by the cache system plug-in policy manager to select an appropriate cache policy for the new instance of the container application.

[0061] Figure 4 An example scenario for deploying an instance of a container application with a persistent volume according to one or more embodiments of the present disclosure is illustrated. Figure 4 The examples shown in and discussed below are highly simplified examples intended for explanation purposes only and are not intended to limit the scope of the embodiments described herein. A person of ordinary skill in the art having the benefit of this disclosure will appreciate that such scenarios may include, for example, Figure 4 Many more nodes, containers, storage devices, etc. are shown in FIG. Additionally, while this example illustrates certain aspects of the embodiments described herein, all possible aspects of such embodiments may not be illustrated in this particular example.

[0062] Consider a scenario where a user 402 seeks to deploy a container instance with a persistent volume. The user interacts with an API server 404 of the container ecosystem 400. The API server 404 parses the request and determines that it includes a request for a persistent volume. The API server 404 requests the cache system controller 406 to configure the persistent volume.

[0063] The cache system controller 406 determines that an instance of the container is to be deployed on a node 410 of the container ecosystem 400. Therefore, the cache system controller 406 sends a request to a cache system plugin 416 executing on the node 410 to configure a persistent volume for the container 412.

[0064] The cache system plug-in 416 includes a volume provisioner that provisions local cache volumes 422 on local storage devices 420 of the node 410. The volume provisioner also provisions remote storage volumes 426 on iSCSI storage devices 424 that are accessible by the node 410 via a network.

[0065] The cache system plug-in 416 also includes a policy manager. The policy manager obtains historical I / O behavior data related to the container application being deployed, and selects an appropriate cache policy for the persistent volume based on the historical I / O behavior information.

[0066] The cache system plug-in 416 also includes a device manager that uses a command line interface to interact with Open CAS 418 to request the creation of virtual block devices corresponding to the local cache volume 422 and the remote storage volume 426, which are then provided to the container 412 as a persistent volume 414. The device manager also causes Open CAS 418 to apply the selected cache policy to the persistent volume 414. The information corresponding to the persistent volume is then provided from the cache system plug-in 416 to the cache system controller 406, which stores the information in the container ecosystem data store 408.

[0067] Container 412 begins performing I / O operations on persistent volume 414. Open CAS applies the selected cache policy to the I / O operations and also monitors the I / O behavior of container 412. Information about the I / O behavior is added to historical I / O behavior information about the container application of which container 412 is an instance.

[0068] After a period of time, container 412 is terminated. At this time, any data from the local cache volume that has not yet been written to remote storage volume 426 is written to remote storage volume 426. The next time an instance of the container application is deployed in container ecosystem 400, the updated historical I / O behavior data is evaluated by the policy manager of the cache system plug-in, and a cache policy is selected, which may be different from the cache policy selected for container 412.

[0069] Figure 5 A block diagram of a computing device according to one or more embodiments of the present disclosure is illustrated. As discussed above, the embodiments described herein may be implemented using a computing device. For example, Figure 1 All or any part of the components shown in can be implemented at least in part using one or more computing devices. Computing device 500 may include one or more computer processors 502, non-persistent storage 504 (e.g., volatile memory, such as random access memory (RAM), cache memory, etc.), persistent storage 506 (e.g., hard disk, optical drive such as compact disk (CD) drive or digital versatile disk (DVD) drive, flash memory, etc.), communication interface 512 (e.g., Bluetooth interface, infrared interface, network interface, optical interface, etc.), input device 510, output device 508, and many other elements (not shown) and functionality. Each of these components is described below.

[0070] In one or more embodiments, the computer processor(s) 502 may be an integrated circuit for processing instructions. For example, the computer processor(s) may be one or more cores or micro-cores of a processor. The processor 502 may be a general-purpose processor configured to execute program code included in software executed on the computing device 500. The processor 502 may be a special-purpose processor in which certain instructions are incorporated into the processor design. Although Figure 5 Only one processor 502 is shown, but computing device 500 may include any number of processors without departing from the scope of the embodiments disclosed herein.

[0071] The computing device 500 may also include one or more input devices 510, such as a touch screen, a keyboard, a mouse, a microphone, a touchpad, an electronic pen, a motion sensor, or any other type of input device. The input device 510 may allow a user to interact with the computing device 500. In one or more embodiments, the computing device 500 may include one or more output devices 508, such as a screen (e.g., a liquid crystal display (LCD), a plasma display, a touch screen, a cathode ray tube (CRT) display, a projector, or other display device), a printer, an external storage device, or any other output device. One or more of the output devices may be the same or different from the (multiple) input devices. The (multiple) input and output devices may be locally or remotely connected to the (multiple) computer processors 502, the non-persistent storage device 504, and the persistent storage device 506. There are many different types of computing devices, and the (multiple) input and output devices mentioned above may take other forms. In some cases, a multi-mode system may allow a user to provide multiple types of input / output to communicate with the computing device 500.

[0072] Additionally, the communication interface 512 can facilitate connecting the computing device 500 to a network (not shown) (e.g., a local area network (LAN), a wide area network (WAN) such as the Internet, a mobile network, or any other type of network) and / or to another device, such as another computing device. The communication interface 512 can use a wired and / or wireless transceiver to perform or facilitate receiving and / or transmitting wired or wireless communications, including using an audio jack / plug, a microphone jack / plug, a universal serial bus (USB) port / plug, Ports / plugs, Ethernet ports / plugs, Fiber optic ports / plugs, Proprietary wired ports / plugs, Wireless signal transmission, BLE wireless signal transmission, The communication interface 512 may include one or more global navigation satellite system (GNSS) receivers or transceivers used to determine the location of the computing device 500 based on one or more signals received from one or more satellites associated with one or more GNSS systems. GNSS systems include, but are not limited to, the U.S.-based GPS, the Russian-based Global Navigation Satellite System (GLONASS), the China-based BeiDou Navigation Satellite System (BDS), and the European-based Galileo GNSS. There is no restriction to operation on any particular hardware arrangement, and therefore as improved hardware or firmware arrangements are developed, the basic features herein may be readily substituted for those.

[0073] The term computer-readable medium includes, but is not limited to, portable or non-portable storage devices, optical storage devices, and various other media capable of storing, containing or carrying (multiple) instructions and / or data. Computer-readable media may include non-transient media in which data may be stored and do not include carrier waves and / or transient electronic signals that are propagated wirelessly or by wired connections. Examples of non-transient media may include, but are not limited to, disks or tapes, optical storage media such as CDs or DVDs, flash memory, memory, or memory devices. Computer-readable media may store thereon codes and / or machine-executable instructions, which may represent a combination of a process, function, subroutine, program, routine, subroutine, module, software package, class, or any instruction, data structure, or program statement. A code segment may be coupled to another code segment or hardware circuit by transmitting and / or receiving information, data, independent variables, parameters, or memory contents. Information, independent variables, parameters, data, etc. may be transmitted, forwarded, or emitted via any suitable means (including memory sharing, message passing, token passing, network transmission, etc.).

[0074] All or any portion of the components of computing device 500 may be implemented in a circuit system. For example, the components may include and / or may be implemented using electronic circuits or other electronic hardware, which may include one or more programmable electronic circuits (e.g., microprocessors, GPUs, DSPs, CPUs, and / or other suitable electronic circuits), and / or may include and / or be implemented using computer software, firmware, or any combination thereof to perform the various operations described herein. In some aspects, computer-readable storage devices, media, and memories may include cables or wireless signals containing bitstreams, etc. However, when referred to, non-transient computer-readable storage media explicitly exclude media such as energy, carrier signals, electromagnetic waves, and the signals themselves.

[0075] In the above description, many details are set forth as examples of the embodiments described herein. Those skilled in the art (who also benefit from this detailed description) will appreciate that one or more of the embodiments described herein may be practiced without these specific details, and that a variety of changes or modifications may be made without departing from the scope of the embodiments described herein. Certain details known to those of ordinary skill in the art may be omitted to avoid obscuring the description.

[0076] Specific details are provided in the above description to provide a thorough understanding of the various aspects and examples provided herein. However, it will be appreciated by those of ordinary skill in the art that these aspects can also be practiced without these specific details. For clarity of explanation, in some cases, the present technology may be presented as including functional blocks, which may include devices, device components, steps or routines in methods embodied in software or a combination of hardware and software. In addition to those shown in the figures and / or described herein, additional components may also be used. For example, circuits, systems, networks, processes and other components may be shown as components in block diagram form, so as not to obscure various aspects with unnecessary details. In other cases, well-known circuits, processes, algorithms, structures and techniques may be shown without unnecessary details, so as to avoid obscuring various aspects.

[0077] Various aspects can be described above as a process or method, which is depicted as a flow chart, a flow chart, a data flow diagram, a structure diagram or a block diagram. Although a flow chart can describe an operation as a sequential process, many operations can be performed in parallel or simultaneously. In addition, the order of the operations can be rearranged. When the operation of the process is completed, the process terminates, but may have additional steps that are not included in the figure. The process can correspond to a method, a function, a process, a subroutine, a subprogram, etc. When the process corresponds to a function, its termination can correspond to the function returning to the calling function or the main function.

[0078] The processes and methods according to the above examples can be implemented using computer executable instructions stored or otherwise available from a computer readable medium. Such instructions may include, for example, instructions and data that cause or otherwise configure a general-purpose computer, a special-purpose computer, or a processing device to perform a specific function or group of functions. Some of the computer resources used may be accessed via a network. Computer executable instructions may be, for example, binary, intermediate format instructions, such as assembly language, firmware, source code, etc. Examples of computer readable media that can be used to store instructions, information used, and / or information created during the method according to the described examples include disks or optical disks, flash memory, USB devices provided with non-volatile memory, networked storage devices, and the like.

[0079] In the above description of the accompanying drawings, in the various embodiments described herein, any component described with respect to the accompanying drawings may be equivalent to one or more identical or similarly named and / or numbered components described with respect to any other accompanying drawings. For the sake of brevity, the description of these components may not be repeated for each accompanying drawing. Therefore, each embodiment of the components of each drawing is incorporated by reference and is assumed to be optionally present in each other figure with one or more identical or similarly named and / or numbered components. In addition, according to the various embodiments described herein, any description of the components in the drawings should be interpreted as an optional embodiment, which can be implemented in addition to, in combination with, or in place of the embodiments described with respect to the corresponding one or more identical or similarly named and / or numbered components in any other figure.

[0080] Throughout the application, ordinal numbers (e.g., first, second, third, etc.) may be used as adjectives for elements (i.e., any noun in the application). The use of ordinal numbers does not imply or create any particular order of elements, nor does it limit any element to being only a single element, unless explicitly disclosed, such as by using the terms "before," "after," "single," and other such terms. Instead, ordinal numbers are used to distinguish elements. For example, a first element is different from a second element, and a first element may encompass more than one element and be after (or before) a second element in the ordering of the elements.

[0081] As used herein, the phrase operably connected or operable connection means that there is a direct or indirect connection between elements / components / devices that allows the elements to interact with each other in some manner. For example, the phrase "operably connected" can refer to any direct connection (e.g., a direct wired connection between two devices or components) or indirect connection (e.g., a wired and / or wireless connection between any number of devices or components that connect operably connected devices). Therefore, any path by which information can propagate can be considered an effective connection.

[0082] Although the embodiments discussed herein have been described with respect to a limited number of embodiments, those skilled in the art having benefit of this detailed description will appreciate that other embodiments can be designed which do not depart from the scope of the embodiments as disclosed herein. Accordingly, the scope of the embodiments described herein should be limited only by the appended claims.

Claims

1. A system comprising: one or more processors; as well as One or more non-transitory computer-readable media storing instructions that, when executed by the one or more processors, cause the one or more processors to: Receive a request to create a persistent volume for a container application instance; configuring a local cache volume on a host computing device; Configure remote storage volumes on remote storage devices; Selecting a cache strategy for the container application instance; creating a virtual block device associated with the local cache volume, the remote storage volume, and the cache policy; and The virtual block device is provided for use by the container application instance as the persistent volume.

2. The system of claim 1, wherein the request is received by the cache system plug-in from a cache system controller.

3. The system of claim 2, wherein: The cache system plug-in is executed on a node of the container ecosystem, and The cache system controller executes in a control plane of the container ecosystem.

4. The system of claim 1 , wherein the instructions, when executed by the one or more processors, further cause the one or more processors to: An input / output (I / O) operation of the container application instance is performed on the persistent volume according to the cache policy.

5. The system of claim 1 , wherein the instructions, when executed by the one or more processors, further cause the one or more processors to: Monitoring the input / output (I / O) behavior of the container application instance; and The monitored I / O behavior is provided to a cache system controller for updating historical I / O behavior data for a container application corresponding to the container application instance.

6. The system of claim 1 , wherein the instructions, when executed by the one or more processors, further cause the one or more processors to: Information associated with the virtual block device is provided to a cache system controller to be stored as configuration information associated with the container application instance.

7. The system of claim 1, wherein the cache policy comprises a cache mode and an eviction algorithm.

8. A computer-implemented method comprising: The cache system plug-in receives a request to create a persistent volume for the container application instance; configuring, by the cache system plug-in, a local cache volume on a host computing device; The cache system plug-in configures a remote storage volume on a remote storage device; The policy manager of the cache system plug-in selects a cache policy for the container application instance; creating, by the cache system plug-in from a cache manager, a virtual block device associated with the local cache volume, the remote storage volume, and the cache policy; and The virtual block device is provided for use by the container application instance as the persistent volume.

9. The computer implemented method of claim 8, wherein the request is received by the cache system plug-in from a cache system controller.

10. The computer-implemented method of claim 9, wherein: The cache system plug-in is executed on a node of the container ecosystem, and The cache system controller executes in a control plane of the container ecosystem.

11. The computer-implemented method of claim 8, further comprising: An input / output (I / O) operation of the container application instance is performed on the persistent volume according to the cache policy.

12. The computer-implemented method of claim 8, further comprising: Monitoring input / output (I / O) behavior of the container application instance; as well as The monitored I / O behavior is provided to the cache system controller for updating historical I / O behavior data for the container application corresponding to the container application instance.

13. The computer-implemented method of claim 8, further comprising: Information associated with the virtual block device is provided to a cache system controller to be stored as configuration information associated with the container application instance.

14. The computer implemented method of claim 8, wherein the cache policy comprises a cache mode and an eviction algorithm.

15. A non-transitory computer-readable medium storing a program for execution by one or more processors, the program comprising instructions for: Receive a request to create a persistent volume for a container application instance; configuring a local cache volume on a host computing device; Configure remote storage volumes on remote storage devices; Selecting a cache strategy for the container application instance; creating a virtual block device associated with the local cache volume, the remote storage volume, and the cache policy; and The virtual block device is provided for use by the container application instance as the persistent volume.

16. The non-transitory computer-readable medium of claim 15, wherein the request is received by a cache system plug-in from a cache system controller.

17. The non-transitory computer readable medium of claim 16, wherein: The cache system plug-in is executed on a node of the container ecosystem, and The cache system controller executes in a control plane of the container ecosystem.

18. The non-transitory computer readable medium of claim 15, wherein the program includes further instructions for: An input / output (I / O) operation of the container application instance is performed on the persistent volume according to the cache policy.

19. The non-transitory computer readable medium of claim 15, wherein the program includes further instructions for: Monitoring the input / output (I / O) behavior of the container application instance; and The monitored I / O behavior is provided to the cache system controller for updating historical I / O behavior data for the container application corresponding to the container application instance.

20. The non-transitory computer readable medium of claim 15, wherein the program includes further instructions for: Information associated with the virtual block device is provided to a cache system controller to be stored as configuration information associated with the container application instance.

Images