Shulou(Shulou.com)06/01 Report--

What is the storage method of Kubernetes and Docker containers? many novices are not very clear about this. In order to help you solve this problem, the following editor will explain it in detail. People with this need can come and learn. I hope you can get something.

Currently, container storage is an inseparable topic for containers. For stateless Docker containers, the container data will be automatically cleared when the container is restarted, and some static data can be written directly through the configuration file or during the container build. However, for data that can be changed in real time, such as databases and log files, we cannot access them through this method. Most of the storage of containers supports Volume (data volumes) of Docker or Kubernetes, so we will first introduce the principles of these two Volume.

Container Volume plug-in for Docker

Docker V1.8 officially released the specification of Container Volume plug-in (Volume Plugin), which allows data volumes from third-party vendors to provide data services in the Docker engine, so that external storage can exist independently beyond the life cycle of the container. This means that all kinds of storage devices can be connected to the running platform of Docker container as long as they meet the standard of interface API. The interface specification of Volume Plugin defines 5 operations, as shown in the following table:

The definition of this specification is very concise, and the existing storage can be encapsulated by a simple driver to interface with the Docker container. It can be said that the driver implements the northbound interface with the container engine, while the bottom layer calls the back-end storage function to complete the data access and other tasks. There are many storage solutions that implement additional high-end functions, such as container data volume migration, which are not included in Docker's volume plug-in specification and can be used by storing their own management tools. In the Docker Volume Plugin that has been implemented at present, the back-end storage includes common NFS, CIFS, GlusterFS and block devices.

Container volumes for Kubernetes

Kubernetes is an open source container cluster management platform that can automate the deployment, expansion, and operation and maintenance of container applications. The scheduling unit of Kubernetes is called "Pod" (pod), and each Pod represents an application and contains one or more containers. Pod can be deployed in any node of the cluster, and storage devices can be provided to Pod containers through data volumes (Volume). The underlying Kubernetes supports Docker's container runtime engine. In order not to bind to a specific container technology, Kubernetes does not use Docker's Volume mechanism, but reformulates its own generic data volume plug-in specification to match different container runtimes (such as Docker and rkt).

Data volumes can generally be used throughout the life cycle of Pod, and when Pod is deleted by the platform, data may be retained or removed in different volume implementations. If the data is retained, other Pod can reload the volume's data for use. Data volumes are divided into shared and non-shared types, in which the non-shared type can only be mounted by a node (such as iSCSI,AWS EBS and other network block devices), while the shared type allows multiple Pod on different nodes to be used at the same time (such as NFS,GlusterFS,CephFS and other network file systems, as well as block devices that can support multi-party read and write). For stateful applications, shared volume storage can easily support the migration of containers between nodes in the cluster.

Kubernetes's data volumes can connect external pre-created data volumes to Pod. In the process, Pod cannot configure data volume parameters (such as volume size, IOPS, etc.) because these parameters are preset by the storage that provides data volumes, which is a bit like traditional storage to partition data volumes first and then provide them for application mount use. In order to provide more fine-grained volume management for containers, Kubernetes adds the ability to persist volume PV (Persistent Volume), which uses external storage as a resource pool, which is managed by the platform and provided to the entire cluster. Each PV has some platform-aware storage capacity, such as volume capacity (storage size), read-write access mode (access mode), and so on. When Pod needs storage, you can request the required storage resources from the platform, which is called PVC (Persistent Volume Claim). PVC content includes access mode, capacity size and other information. The platform matches the appropriate resources according to the requested resource attributes (such as volume size, etc.) and allocates them to Pod, and mounts the data volumes to the host where Pod resides for Pod use (as shown in the following figure).

The Persistent Volume function of Kubernetes is still in development. At present, PV only supports the capacity of storage capacity (storage size) (capacity), and may also support storage capacity such as IOPS and throughput in the future, in order to configure richer storage policies. Kubernetes's volume management architecture enables storage to be accessed in a standard way, and exposes the capabilities supported by storage devices through interfaces, thus realizing automatic management in container task scheduling and other aspects.

Flocker

In order to provide file volume storage for container applications, a relatively simple way is to reuse traditional storage and add the corresponding interface to adapt to the container specification. There are many containers that use this approach, such as GlusterFS, NFS, and CIFS volume plug-ins that adapt to Docker. Flocker, described below, is also an open source container volume manager for this model, providing a solution for managing and orchestrating container data volumes in a cluster, and relying on back-end shared block storage to provide the ability of data volumes to span hosts.

As shown in the figure above, Flocker uses the control service as the master controller and provides REST API interfaces to maintain and update the state of the system. Flocker Agent is installed on each node of the cluster and is responsible for ensuring that the local state on each node meets the expected state of the system. If it is found that the local state does not match the expected state, Flocker Agent will take necessary corrective measures to make the data volumes on the node consistent with the configuration of the cluster system (eventual consistency). Flocker Plugin is also deployed on each node, mainly in the form of plug-ins to integrate with Docker, Kubernetes and other container platforms, so that containers can not only use the data volumes provided by Flocker, but also support container migration.

For example, in Kubernetes, when the host on which the Pod is located fails, Kubernetes reschedules (migrates) the Pod to another host, and accordingly, Flocker frees up the data volume of the Pod on the original host and resets it to the Pod in the new host. In this way, when the stateful container migrates the host, its data volume can also move with the container.

The Flocker backend can use a variety of common network block devices, including AWS EBS,OpenStack Cinder,EMC, DELL, NetApp, VMware VSAN/vVOL, etc., these block devices are equipped with drivers, and the data volume can be generated by Flocker (in the form of file directory), connected to any host, and then provided to the container application through the interface of the volume plug-in.

Portworx

Portworx has developed a container-aware software-defined storage system called CDS (Container-Defined Storage). In the CDS storage of Portworx, the architecture of computing and storage fusion is adopted, which aggregates the local storage of all nodes in the cluster into a large resource pool, so that each node not only provides computing power, but also provides local disk as storage, so that containers running in the node can access data directly from the local.

Any storage needs to ensure the integrity and reliability of data. Because Portworx adopts distributed storage architecture, similar to Ceph and VMware Virtual SAN, data replication needs to be carried out among multiple nodes. As shown in the figure above, when the data is written locally, according to the parameters set by the storage, the data can be copied to several other nodes, thus there are multiple copies of data in the cluster, ensuring the availability and reliability of the data. If a node fails or undergoes offline maintenance, the containers on that node can be rescheduled to other nodes by the upper scheduler. Because the data has been replicated to multiple nodes, the container can use local data directly on the new node, improving the efficiency of data access (as shown in the following figure).

Portworx also designs storage policies for container volumes, which can be set dynamically when creating data volumes. These policies are as follows:

By setting the configuration of the above storage attributes, the requirements such as QoS of container volumes can be met dynamically, which is very different from traditional block storage such as SAN: these strategies are configured with the granularity of container volumes and can well meet the needs of container applications, so it is called container-defined storage (Container Defined Storage), which is software-defined storage customized for container applications. At present, Portworx implements the control plane and data plane of software-defined storage in architecture. Although many features are still being improved, we can still see the embryonic form of the next generation of container-oriented software-defined storage.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.