容器附加存储（CAS）通过利用容器环境本身提供持久存储，将数据映射到应用的方式提供新范例。随着容器（尤其是K8s）成为重要的应用交付平台，CAS开始进入大众视线。
容器持久性
在过去的五年中，随着K8s成为领先的容器编排平台，应用容器化发生了快速变化。最初引入容器时，我们认为不需要持久存储，通过基于应用的弹性（包括在应用层进行数据复制和镜像）获取持久性。
随着容器环境的发展，对传统数据库软件等应用进行了容器化，推动了对在单个容器的生命周期内长期存储数据的需求。由于许多原因，这种变化是不可避免的。
首先，基于应用的弹性使用导致了相当大的开销，需要在容器基础设施周围复制数据并去掉基于主机的I/O。
其次，许多应用平台可能不具有复制功能，如果只维护一个镜像副本，数据会面临极大的风险。
第三，企业需要数据持久性作为合规性和审计要求的一部分。存储层的持久性提供了实现数据保护和安全控制的能力。
实操
最初，持久性存储是通过绑定到运行容器的服务器的卷，LUN或目录再映射到该容器。这种方法效率极低且缺乏灵活性。随着时间的积累，容器存储接口（CSI）已经成为一种标准方法，让存储供应商能够开发用于将存储映射到容器的插件，允许容器生态系统本身通过一个进程动态请求存储，这个过程使得提供持久卷所需的特定平台的步骤变得模糊了。
CAS
容器附加存储（CAS）是一个软件平台，能利用容器生态系统为容器提供存储，可以简单类比一下超融合（HCI）。 在HCI环境中，每个服务器节点都运行专用的虚机进行存储，或在节点上运行的虚机管理程序中实现横向扩展存储层。
No SAN
与之前的HCI一样，CAS消除了对专用SAN的需求，或者说至少不再是我们认为的当前形式下的共享存储。如果容器平台是通过虚机交付，那就太好了，因为每个虚机都可以使用附加存储（无论最终是否由SAN提供）。这个存储被抽象化，并与CAS数据分为不同的卷。
在裸金属环境里，本地磁盘资源被抽象为容器卷，而CAS软件则维护有关如何划分物理存储容量的元数据和状态信息。此时，元数据存储变得很关键。大多数供应商建议将元数据存储与运行应用的容器集群分开。
在未来十年中，对CAS的预测
成熟期——最明显的演变可能会是新功能开发。与现有的成熟存储解决方案相比，CAS解决方案还有很长的路要走，许多解决方案在数据保护等数据服务方面存在差距。CAS产品还需要利用诸如持久性存储之类的新介质。
数据移动性——当前的CAS解决方案尚未完全解决混合存储所需的数据移动性挑战。
安全性——CAS解决方案尚未解决安全性带来的长期挑战。与之前的Fibre-Channel或iSCSI一样，安全控制功能薄弱或根本不存在，没有真正的验证或审核。这是因为这些协议的设计基于模拟安全网络中的本地磁盘。
性能管理——CAS解决方案需要提供更多的实时性能分析功能。
CAS面临的许多挑战都源于CSI的使用，CSI实质上是在模拟光纤通道和iSCSI网络的存储连接功能。当前的设计甚至呼应了30年前首次开发的大型机SMS（存储管理子系统）功能。绝对需要重新考虑将应用数据映射到容器的方式。
混合存储
与HCI不同，如Kubernetes之类的容器集群可能是一时的。这个属性代表了如何管理长期数据存储的独特挑战。一种解决方案是将传统SAN与CAS合并。SAN组件可跨多个集群提供弹性，并通过永久性元数据存储提供一个元数据存储位置。
总结
CAS本质上是软件定义存储的一种形式，将主导存储行业。 CAS从长远来看似乎是充当容器生态系统的抽象和映射层。未来的成功可能要寄托在提供数据感知能力上，而不只是依靠另一个附件协议。容器附加存储无疑是未来十年要持续关注的领域。
