解锁容器持久化存储，阿里云上的Kubernetes存储管理-阿里云开发者社区

解锁容器持久化存储，阿里云上的Kubernetes存储管理

2018-02-26 4984

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 最新动态：阿里云 Kubernetes FlexVolume 数据卷发布，支持云盘、NAS 和 OSS。现在起，可以通过阿里云提供的 FlexVolume 插件，实现Pod和阿里云存储服务的自动绑定和回收策略制定，包括云盘、NAS 和 OSS。

+关注继续查看

容器需要持久化存储

“ 根本不存在无状态化的架构
There is no such thing as a stateless architecture ”

– Jonas Boner
Lightbend创始人兼CTO ，Akka作者

应用程序需要数据， IT方案被创造出来是为了解决商业业务数据的问题。

容器问世之时，它最初的目的是应对无状态化服务。随着容器技术的成熟，越来越多的人希望容器化应用可以直接关联数据。不论是传统的还是新型应用，都需要存储，如文件、块、对象存储的形式，通过文档、关系型数据库或者流媒体等等。

虚拟化技术的 hypervisor 虚拟机器监视器在硬件模拟层上有很多要求，而比起虚拟化技术，容器将应用的可移植性大大提升。应用程序的可移植性，依赖于容器编排系统的互操作性。但是，需要看到的是即使是现代化的云原生应用，存储也是不可缺少的关键模块，因为有了持久化存储，应用程序就可以基于此开发出很多功能。

容器编排系统和运行时通过特定请求来接通存储服务，如 Creat / Remove, Inspect / List, Attach / Detach, Mount / Unmount等。目前看来，业界都是在通过容器编排系统解决存储问题，能否实现此点也成为了工业界的分水岭。

通过 API 方式链接外部存储服务有两种方式：第一种是 in-tree 驱动，由在容器编排系统内部的原生化代码实现；第二种 out-of-tree驱动，由插件实现。前者受制于容器编排系统的发布周期，而后者可能无法提供容器编排系统配套的加强功能。

Kubernetes的存储机制

Docker率先尝试通过 out-of-tree模式解决了如何与外部存储协同的问题，在 1.7 Experimental 版本中创建了Docker Volume Driver接口。

而 Kubernetes 则提供 in-tree 和 out-of-tree两种模式。

In-tree是 Kubernetes 标准版的一部分，已经写入 Kubernetes 代码中。通过基于 Kubernetes 内置 interface 的API命令如 Mount / Unmount, Creat / Delete等进行存储平台的操作。Kuberentes 会在
pod 创建时进行所有相关的必要操作，并且找到相关驱动执行特定 API 背后的所需动作。用户可以充分发挥 Kubernetes 中动态配置和存储类等新特性。唯一的缺点就是，如果存储平台需要 bug 修复或者功能添加的话，需要等待 Kubernetes 的发布周期。一般而言，Kubernetes 的发布周期在3-6个月，这意味着 bug 修复或者持续更新并不能随心所欲。

Out-of-tree 是通过 Flexvolume 接口实现的，Flexvolume 可以使得用户在 Kubernetes 内自己编写驱动或添加自有数据卷的支持。第三方驱动通过数据卷插件路径安装在每个 Kubelet 和 master 节点。这使得存储驱动可以与 Kubernetes 内核代码独立开来，bug 修复和功能更新都不需要等待 Kubernetes 的日程计划。Flexvolume 接口设定认为数据卷的创建和删除都是发生在其外部，因此只有 Attach / Detach 和 Mount / Unmount操作可行，并且也不是在数据卷的全部生命周期可行。