CAS 存储

容器附加存储 (Container Attached Storage, CAS) 是一种由 Kubernetes 编排的基于微服务存储控制器的软件存储体系。 其存储控制器作为 Kubernetes 集群的一部分在容器中进行管理和运行。这就让 CAS 具有可移植性，可以在任何 Kubernetes 平台上运行， 包括任何云平台、裸金属服务器或传统共享存储系统。关键的是数据本身也可以通过容器访问，而不是存储在非平台共享的横向扩展存储系统中。 由于 CAS 利用微服务架构，将存储解决方案与绑定到物理存储设备的应用程序保持密切关联，从而减少了 I/O 访问时间。

CAS 这种模式非常符合分布式数据的趋势，也适合采用微型松散耦合工作负载的小型自治团队。例如，一个团队可能需要 Postgres 来提供微服务， 而另一个团队的研发数据可能依赖于 Redis 和 MongoDB。一些用例可能对性能要求较高，一些可能在 20 分钟内消失，一些是写入/读取密集型等等。 在一个大型企业中，随着规模的增长，企业越来越信任各团队自行选择所用的工具，各团队所依赖技术的差异性将越来越大。

CAS 意味着开发人员可以在工作时不必担心企业存储体系结构的底层需求。对于 CAS 来说，云盘与 SAN、裸机或虚拟机并没有什么不同。 开发人员和平台 SRE 工程师没必要开会决定下一个存储供应商，也没必要反复讨论如何设置才能支持用例。开发人员保持自治， 可以使用 Kubernetes 集群可用的任何存储来启动本身的 CAS 容器。

CAS 反映了一个更广泛的解决方案趋势，其中许多方案均是 CNCF 的项目，以 Kubernetes 和微服务为基础进行构建，形成繁荣的云原生生态体系。 如今 CNCF 的云原生生态体系包含了安全、DNS、网络、网络策略管理、消息传输、跟踪、日志等众多项目。

CAS 的优势

敏捷性

CAS 中的每个存储卷都有一个容器化存储控制器和相应的容器化副本。因此，围绕这些组件的资源维护和调整是真正敏捷化的。 Kubernetes 的滚动升级功能实现了存储控制器和存储副本的无缝升级。CPU 和内存等资源可以使用容器 cgroup 进行优化。

存储策略的粒度

对存储软件进行容器化，并将存储控制器专用于每个卷，可以实现存储策略的最大粒度。使用 CAS 体系结构，您可以按卷配置所有存储策略。 此外，您可以监视每个卷的存储参数，并动态更新存储策略，以实现每个工作负载的预期结果。随着卷存储策略中粒度的增加，对存储吞吐量、IOPS 和延迟的控制也会增加。

避免绑定

避免被云服务商绑定是许多 Kubernetes 用户的共同目标。然而，有状态应用的数据通常仍然依赖于云服务商及其技术，或者依赖于底层的传统共享存储系统 NAS 或 SAN。 而使用 CAS 方法后，存储控制器可以在每个工作负载的后台进行数据迁移，使得实时迁移变得更简单。 换句话说，CAS 的控制粒度以无中断的方式简化了有状态工作负载从一个 Kubernetes 集群到另一个集群的迁移。

原生云

CAS 将存储软件容器化，并使用 Kubernetes CRD 来表示底层存储资源，如磁盘和存储池。这种模式使存储能够无缝地集成到其他云主机的工具中。 可以使用 Prometheus、Grafana、Fluentd、Weavescope、Jaeger 等云主机工具来调配、监控和管理存储资源。

另外，CAS 中卷的存储和性能是可伸缩的。由于每个卷都有自己的存储控制器，因此可以在节点存储容量的允许范围内弹性伸缩。 随着给定 Kubernetes 集群中容器应用数量的增加，会添加更多节点，从而提高存储容量和性能的总体可用性，使存储可用于新的应用容器。

更小的影响范围

由于 CAS 体系结构是按工作负载划分的，并且组件是松散耦合的，所以 CAS 的影响范围比典型的分布式存储体系结构小得多。

CAS 可以通过从存储控制器到存储副本的同步复制来提供高可用性。维护副本所需的元数据简化为副本节点的信息以及有关副本状态的信息。 如果某个节点出现故障，存储控制器将通过第二个或第三个副本在正运行且数据可用的节点上轮转。 因此使用 CAS 时，影响范围要小得多，影响仅局限在该节点上有副本的卷。