如今，在云计算领域，越来越多的IT组织正在构建混合云和多云环境以支撑其业务运行。从容器的角度来看，我们知道，容器应用程序从一开始就内置了非常可观的可移动性、灵活性和效率。但是对于容器数据来说，它的移动性又如何?如何构建一个数据框架来优化公有云，并为容器应用程序及其数据提供真正的移动性?
容器和块存储
容器流行的原因很大一部分来自于Docker公司，该公司向我们介绍了容器运行时、应用程序库和多节点(服务器)配置的框架。很快，Docker就被Kubernetes——谷歌的开源容器平台所纳入。
这两个平台都使用基于块的存储来为容器数据提供持久性。最初，假定容器是无状态的，就需要使用应用程序复制和冗余来维护对持久数据的访问。但这被证明是不切实际的，而且大家都认为我们需要某种形式的持久性存储，即使是对于短期存在的容器也是如此。
块存储速度快，为应用程序提供低延迟。在容器部署中，块存储设备使用本地文件系统进行格式化并映射到容器中。根据使用要求，块存储设备可以在容器的生命周期内继续使用，或者仅在容器运行时使用。
如果容器中的应用程序任务是可重新启动的，那么块存储只需为容器数据提供可伸缩的快速存储。通过可重新启动，意味着应用程序组件可以用新格式化的空块设备进行实例化。
然而，当我们走出这些简单的界限时，存储必须提供更多能力。例如，如果一个容器由于硬件或软件故障而需要重新启动，那么在现有块存储设备上重用数据可能是可行的，而不是从另一个源重新创建数据。如果应用程序的一部分必须移动到另一个物理位置，那么容器数据可能也必须移动。
构建一个数据平面框架
为了实现数据和应用程序迁移，我们需要为数据平面构建一个框架。基于此，数据将比任何单独的容器寿命更长，并且需要跨多个数据中心和位置移动，这意味着可能还需要在公有云和本地位置之间移动。一个很好的例子是，需要将数据复制到公有云中，从而为测试/开发环境提供原料。
对象存储是构建数据框架的多种方法之一。它本质上是可移动的，可以通过使用http(s)协议的广域网进行访问。对象存储提供了跨距离复制的能力，并且可以轻松地跨平台工作。对象存储的主要挑战是如何实现良好的安全性，并将数据映射到应用程序层次结构，例如，使用bucket和文件夹映射到应用程序名称。
将块和文件存储添加到容器框架更加复杂。与文件存储相比，块存储具有更低的延迟和更大的吞吐量，但现在情况已经不同了。使用诸如NVMe这样的新型媒介，初创公司正在构建高性能、可伸缩的文件系统，这些系统既可以在场所中工作，也可以在公有云中工作。
本地块存储(如AWS的弹性计算云)的另一个挑战是，这些设备只能连接到本地容器或虚拟实例。没有直接的方法将公有云中的块存储复制到不同的提供商或本地位置中。
数据抽象
如果数据可移植性是必要的，那么比较好的选择是构建一个独立的数据平面，它不依赖于公有云提供商的本地存储。目前也存在提供扩展块和文件存储的产品，这些产品可以跨越单个或多个地理位置。这包括合并公有云和私有云。
一些扩展产品可以在多个位置上显示单个数据视图，而其他产品使用快照来复制数据。这意味着需要复制数据并设置相应的进程，以确保可以跟踪和管理较新的副本。当使数据在大范围内可用时，将会有延迟问题。
API扮演的角色，以及更多的挑战
生态系统开发人员已经开始添加用于存储的API。Kubernetes有容器存储接口(CSI)，它公开了一组用于创建和将卷附加到容器的功能。CSI确保存储被成功映射到可以跨多个物理服务器部署的Pod中的容器。
Docker使用卷插件来实现与CSI相同的功能。然后，用户可以从存储硬件和软件部署卷驱动程序，以确保将数据正确地从存储映射到容器。
另外，涉及到与容器数据相关的存储、多个容器部署以及平台间无缝数据迁移时，我们仍然面临这许多挑战。例如，AWS Fargate只支持弹性云计算中的外部卷。
