容器需要持久化存储
“ 根本不存在无状态化的架构
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操作可行，并且也不是在数据卷的全部生命周期可行。
阿里云 Kubernetes 的存储支持
阿里云容器服务全球首批通过 Kubernetes 一致性认证，用户可以通过 in-tree 形式挂载存储。
而对于 out-of-tree，阿里云容器服务支持 Kubernetes Pod 自动绑定阿里云云盘、NAS、OSS存储服务。目前对于静态存储卷和动态存储卷的支持情况如下：
操作指南:
在使用容器过程中，你可能会在日志、数据备份、配置信息等场景中需要用到存储，不如按照上述办法尝试下吧？ 对了，你也可以使用日志服务来应对日志的问题哦！
全面提升，阿里云 Docker / Kubernetes(K8S) 日志解决方案与选型对比
参考文章
Container Storage Architectures: How Does Kubernetes, Docker, and Mesos Compare?
