容器彻底改变了开发人员创建和交付应用程序的方式。影响巨大。我们不得不重新思考如何存储、保护、交付和管理数据。软件开发人员很可能需要应对灾难恢复（DR）、数据保护、恢复点目标（RPO）粒度、数据严重性以及其他数据存储和管理问题带来的挑战。
Kubernetes和其他容器环境将所有资源视为服务。这意味着需要一个存储服务层——将其称为数据服务层可能更好，因为该服务层必须提供比简单存储数据多得多的资源能力。
在关于新容器数据服务层的讨论中，有两种主要方法：容器原生方法和容器就绪方法。鉴于市场上信息混杂，观点各异，两者之间的区别有些不清楚。然而，即使是高层次的比较也掩盖了关键的区别。这两种方法都提供了不同的功能，评估哪种解决方案最适合你的需要非常重要。
CNS与CAS
容器挂载（CAS）或容器就绪方法很有吸引力，因为它使用现有的传统存储（通常是外部阵列）通过软件连接到Kubernetes环境。因此，它承诺能够重用存储方面的现有投资，并且可以作为通向容器环境的初始桥梁。对于那些正在进行容器化试验、计划以较小规模进行容器化试验或作为传统单体IT环境附属品的人来说，它可能是有效的。
容器原生存储（CNS）的不同之处在于它是为Kubernetes环境构建的。CNS是一个软件定义的存储解决方案，它本身运行在Kubernetes集群上的容器中。Kubernetes是为容器编排而设计的，内部的一切都是一种资源，每一种资源都由Kubernetes管理和编排。
由于需要额外的资源，Kubernetes增加了更多的存储容量、连接服务和计算服务。它复制和分发应用程序实例。如果有什么东西坏了，Kubernetes会在别的地方重新启动。作为编排层，Kubernetes通常会保证平稳运行。CNS是为编排而构建的，但容器就绪存储或容器挂载存储并不容易编排。
Kubernetes提供了灵活性、更低的运维复杂性和更低的成本，但容器挂载存储增加了摩擦，限制了Kubernetes的全部好处。与Kubernetes主题保持一致，将传统存储挂载到Kubernetes环境就像是将锚抛到了船外。采用Kubernetes的理由是希望/需要统一、简单、自我编排的IT。容器挂载方法所需的分离存储和数据管理无法扩展，无法适应，也无法以Kubernetes所需的速度响应。它可以在由两个或三个节点组成的小型集群中正常工作，但一旦开始扩展，你就会意识到其局限性。
可能更重要的一点是，传统方法将主数据和辅助数据分开。主数据是实时的当前时间数据。辅助数据是受保护的数据（备份或快照），是过去在单个时间点存在的数据副本。在Kubernetes的世界里，整个概念都被颠覆了。在实现容器时，我们完全从头开始重新考虑辅助数据。将旧的数据保护方法（如备份和快照）拖到这个新世界是毫无意义的。
彻底的转变
Kubernetes原生存储重新编写了存储时空连续体，它提供了一个统一的数据服务层，提供了高速、灵活的“主”存储，即当前存在的实时数据。它可以轻松流畅地实现这一点，就像它提供“辅助”存储一样（即时可访问的实时数据克隆，就像它在任何以前的时间点存在一样）。数据在这里或那里的整个概念，无论是当前的还是以前的，都消失了。容器原生存储层提供随时随地对数据的即时访问。Kubernetes可以自由安排所需的内容和时间。
接受这种新的模式似乎很困难，但想象一下，对于一个19世纪的农民来说，掌握联合收割机的概念是多么困难。但不要让一个艰难的范式转变让你陷入过去。面对颠覆性技术，传统供应商长期以来都采取了一个共同的策略：对创新点头，让FUD（恐惧、不确定性和怀疑）推迟采用，然后承诺在创新得到充分测试和证明后提供创新。
这种模式曾经成功地阻碍了创新，同时保护了老牌供应商的收入来源。谢天谢地，今天的云计算优先、DevOps方法使得容器原生被广泛接受为前进的方向。
你的用例是什么？
如今，企业有许多存储选项，它们也比以往任何时候都需要更多的存储。加入容器后，决策可能会变得更加困难。哪种方法最适合你的用例？要回答这个问题，你需要了解容器挂载存储和容器原生存储之间的区别，仔细考虑你的需求和管理能力，做出明智的选择。
