Comparison of container storage architectures: Kubernetes, Docker, and Mesos Compare-Alibaba Cloud Developer Community

This article is about comparison of container storage architectures: Kubernetes, Docker, and Mesos Compare [Editor's words] container storage is an indispensable topic for containers. For stateless Docker containers, container data is automatically cleared when the container restarts, some static data can be directly written to death through configuration files or during Container build. However, we cannot access data that can change in real time, such as databases and log files. This topic describes the storage methods of Docker and the comparison of the main storage methods. [3-day brain-burning Docker-based CI/CD actual combat training camp | Beijing station] This training focuses on Docker-based CI/CD actual combat. The specific contents include: overview of continuous integration and continuous delivery (CI/CD); Introduction of continuous integration system; CI/CD practice of client and server; Introduction of CI and CD in development process; Gitlab and CI, CD tools; Use of Gitlab CI and Drone and sharing of practical experience.
“There is no such thing as a stateless architecture” -- Jonas Boner
any application needs data support, which is the cornerstone of our business. At first, one of the main purposes of containers was to solve stateless services. However, in the short term, with the maturity of technology, the need to allow containerized applications to directly access data is also increasing. Both modern applications and traditional applications need different types of storage, such as files, blocks, or instrumental file storage objects, relational databases, streaming media files, etc. Virtual machines can also manage applications, but this method has certain requirements for hardware simulation. Containers can ensure that the portability of applications is far greater than the implementation of virtualization. The portability of practical applications also depends on the interoperability of container orchestration tools. For current native cloud applications, storage is also a key component, because applications can use persistent storage platforms and further develop feature functions based on their features. Pass Clinton Kitson's blog: understanding the original cloud application storage for more information. Container coordinator and runtime initiate specific requests to storage services, such as create/delete, check/list, attach/detach, install/uninstall, and other operations. This is a unique attempt to solve the storage problem between container coordinators, but there are also differences in the industry. There are two types of external storage orchestration request APIs: The first is the in-tree driver, which directly compiles the native code to the container coordinator; The second is the out-of-tree, with the help of external plug-ins. Each method has its own advantages and disadvantages: the in-tree driver is subject to the release cycle of the container coordinator; the out-of-tree plug-in driver may not provide the enhanced feature set bound to the container coordinator.


Docker solved the problem of external storage for the first time by creating a Docker Volume driver interface in the experimental version 1.7. Docker version 1.13 introduces the plug-in model , that is Docker Store . Search for directories /run/docker/plugins , Docker discovers and can use the UNIX plug-in (.sock file), which is an example of using the out-of-tree model. UNIX sockets (Unix domain socket) files must be run on the same Docker host. However, if the remote access URL is specified, the plug-in can also run on different hosts through spec and json configuration files. Centralizing storage functions is also one of the plug-in responsibilities. This operation accepts JSON and RPC HTTP requests. The out-of-tree model provides a complete Volume lifecycle and orchestration for Docker CLI. However, advanced storage functions such as snapshots or replication have not been exposed to Docker CLI.


Mesos does not support local storage until v0.23. Mesos-Module-Dvdi this is the solution proposed for this problem, then its features are merged into Mesos until Mesos 1.0 or later. DVDCLI the Docker Volume Driver CLI is packaged and encapsulated into Mesos, allowing any Docker Volume Driver to be used in all Mesos containers. Mesos-Module-Dvdi, local storage is implemented by using the DVDCLI being implemented. Similar to Docker, the framework communicates with DVDCLI in JSON format, and also uses JSON/RPC to communicate with Docker Volume Driver Interface over HTTP. As mentioned earlier, because it uses the Docker Volume driver, it is an out-of-tree plug-in with the same Volume lifecycle and restrictions as Docker CLI.


the unique feature of Kubernetes is that it is driven by both in-tree and out-of-tree. We are already in Kubernetes storage "And" new storage features in Kubernetes 1.6 "These two articles describe in detail, let's review again: the in-tree driver comes from Kubernetes source code and is also part of its standard release. These drivers can expose APIs to the storage platform based on the interfaces provided by the Kubernetes, such as Mount/Umount, Create/Delete, Kubernetes perform all functions, and execute specific API calls to the driver to perform the required operations. This can also make full use of Kubernetes features, such as dynamically supplied storage classes. This also has disadvantages. If there are system bugs or some platform features need to be added, it depends on the release cycle of the Kubernetes. The release cycle may mean 3-6 months of waiting for repair, continuous maintenance, round code, and other processes. The Out-of-tree driver uses the Flexvolume interface. Flexvolume allows users to write their own drivers and add support for their volumes to the Kubernetes. The vendor driver must be installed on each Kubelet node and master node. The path of the Volume plug-in is as follows: usr/libexec/kubernetes/kubelet-plugins/volume/exec/<vendor~driver>/ . This allows drivers to run outside the core Kubernetes code, and can release updates or fix bugs based on their own time node tables. You can create and delete a Volume based on an external plug-in Flexvolume the API. Therefore, Flexvolume only use the Attach/Detach and Mount/Unmount functions, rather than the lifecycle of the entire Volume.

Current total almost

by combining all the storage functions, we can see that this is a very fragmented space, and each of the three has its own advantages. All of this means that storage providers need to create multi-level encapsulation integration to support the entire container ecosystem. Container storage the CSI project is at an early stage, but will eventually become a key factor in the success of storage and containers. At the same time, we have integrated all functions and integrated storage methods for each container coordinator function. We know that current and future containerized applications depend on storage, and this solution is suitable for every scenario: Docker and Mesos REX-Ray , FlexREX and Kubernetes,Docker in REX- RAY plug-in , Kubernetes local ScaleIO driver program.

Original link: Container Storage Architectures: How Does Kubernetes, Docker, and Mesos Compare? (Translation: ylzhang)

the original text was published: 2017-08-11

author: ylzhang

this article is from, a partner of Yunqi community. For more information, see

Original title: comparison of container storage architectures: Kubernetes, Docker, and Mesos Compare

Selected, One-Stop Store for Enterprise Applications
Support various scenarios to meet companies' needs at different stages of development

Start Building Today with a Free Trial to 50+ Products

Learn and experience the power of Alibaba Cloud.

Sign Up Now