客座文章作者：Evan Powell，CEO @MayaData
或者，云服务怎么会不是云原生的呢？
欧洲KubeCon在很多方面都很平凡。一个惊喜是，因为KubeCon是一个虚构流动，这导致我与各种存储供应商和我的项目的对话比之前的KubeCon更多。KubeCon存储的交换频道招集了许多聪慧的供应商，他们通常单干，试图为最终用户解决问题；我受到了鼓励，试着尽我的一份力来跟上。
这就是本文终点，作为容器附加存储（Container Attached Storage，CAS）定义的原始作者，接下来为更宽泛的社区创立一个博客是有意义的。
引发这次更新的问题来自一个传统存储供应商的工程师，他问--我略微援用一下：“如果涣散耦合对于云原生架构如此重要，这是否意味着，依赖于一个给定的云自身就不是云原生的？换句话说，云服务自身不是云原生的吗？”我不得不答复--是的--但故事还有更多内容。
回顾--什么是CAS？
容器附加存储是一种模式，它十分合乎数据合成的趋势，以及运行小型、涣散耦合的工作负载的小型、自治团队。换句话说，我的团队可能须要为咱们的微服务应用Postgres，而你的团队可能依赖于Redis和MongoDB。咱们的一些用例可能须要性能，一些可能在20分钟内就用完，其余的是写密集型的，其余的是读密集型的等等。在大型组织中，团队依赖的技术，会随着组织规模的增长，和组织越来越信赖团队抉择他们本人的工具，而变得越来越多。Kubernetes反对这种模式--有时被探讨为数据网格（data mesh）和多语言数据（polyglot data）的衰亡--来自ThoughtWorks的Zhamak Dehghani和其他人有相干的探讨。
理解更多对于CAS：
- 早在2018年4月，我在CNCF的网站上创立了CAS一词的博客：
https://www.cncf.io/blog/2018...
- 7月的CNCF网络研讨会，由OpenEBS我的项目负责人Kiran Mova主持：
https://www.cncf.io/webinars/...
这是来自Kiran社区网络研讨会的一张标准图片，并附有一些解释：
CAS意味着开发者，能够在不思考其组织存储架构的底层需要的状况下工作。对于CAS，云磁盘与SAN雷同，SAN与裸机或虚拟主机雷同。咱们没有召开会议来抉择下一个存储供应商，或探讨设置来反对咱们的用例，咱们应用咱们须要的存储或localPV治理来启动咱们本人的CAS容器，而后继续前进。
好的，^^这就是CAS，然而云有什么不是原生云的呢？
Kubernetes的一个被忽视的方面是，它最后创立的目标，是确保咱们能够以云原生形式运行云。让我来解释一下。
在Kubernetes之前，很难发表用意（intent），并晓得将要执行此用意，而不管其部署环境是本地部署，还是A、B或C云。相同，企业被倡议抉择一家次要的云，并且加倍他们与该云的专业知识和关系。
因而，整个组织和他们编写的所有软件都隐式地依赖于该云，因而与云耦合。这种严密耦合通常并不重要，直到它变得重要为止。只有像Netflix这样的组织，他们的零碎架构既能解决AWS的破绽，又能通过混沌工程踊跃地、不懈地验证本人的容错性，能力挺过各种各样的AWS宕机。据揣测，他们转移至多一部分工作负载的能力，比方基于Spinnaker的CI/CD，也有助于他们与AWS协商更好的价格。
简而言之，如果你将云原生定义为可能在底层云中断时存活，那么与云严密耦合自身就是一种反模式。
Kubernetes之所以成为咱们这个时代最重要的开源我的项目之一，局部起因在于它意识到了这种严密耦合的危险和阻抗挑战。而且，对于一个传统的共享所有的存储硬件供应商来说，这里有些敏感，这种逻辑在他们销售的零碎上双倍实用。
如果你想构建涣散耦合的零碎，就像你不能简略地在一个云上，并且只在那个云上运行一样，你也不能假如一个宣称可扩大到数千个节点的存储系统在所有状况下都能工作。
如果咱们承受云原生外围的“构建失败”信条，咱们必须抵赖共享的所有存储将会解体。它的行为形式并不适宜每个团队的工作负载。它将以非Kubernetes原生形式运行，所有这些依赖关系将超出咱们管制的危险引入到咱们的环境中，这对咱们的团队来说是不通明的。
好的，那么CAS有什么新货色呢？
当CAS首次呈现时，它被用于较少工作要害型工作负载，这并不奇怪。很好的例子包含各种“半永久性”工作负载，其中你心愿数据在CI/CD运行期间保留，或者用于一些数据迷信工作，而后你心愿它隐没。对于这些示例，CAS容许工作负载疾速且统一地启动十分重要。第二个也是重要的需要是，无论底层环境如何，CAS的行为形式都是雷同的。
当Kubernetes调度工作负载时，即便是相当典型的32秒的EBS附加工夫，如果运行工夫为5分钟，而你每天运行它几十次，则须要不少工夫。你能够在晚期OpenEBS采纳者列表中看到这种模式，晚期的公共援用往往偏向于持续时间绝对较短的工作负载。
几年前，Kubernetes上的较长持续时间的工作负载以两种形式之一解决。
- 要么通过云中的托管服务，或
- 减少额定弹性级别的NoSql数据库。
一开始咱们认为CAS在这两种状况下都不实用，因为传统的共享存储必定不实用；然而，咱们很快意识到NoSQL数据库和Kafka这样的解决方案，能够在咱们称为动静LocalPV的中央失去帮忙。
通过放弃对底层环境（包含可用的云卷和物理磁盘）的理解，像OpenEBS的LocalPV这样的CAS解决方案，升高了在Kubernetes上运行这些工作负载的操作工作量。CAS解决方案这样做的形式，缩小了对给定底层云或存储系统的锁定或依赖。
第一个新的CAS要求
因而，咱们能够相应地更新CAS定义。咱们当初晓得CAS解决方案须要包含LocalPV反对。同样，帮忙应用LocalPV运行数据应用程序的相干Kubernetes操作器也是如此。
最近，咱们看到许多工作负载都在减少，对于这些工作负载，本地节点性能十分重要。
性能问题同样能够通过应用LocalPV来解决。一个挑战是，许多工作负载当初既须要性能又须要多节点HA。仅仅通过Restic或其余我的项目或产品备份节点是不够的。
思考运行在PostgreSQL或MySql上的高性能工作负载--例如运行在MySql上的Magento。仅仅备份数据是不够的，MySql通常心愿可能立刻拜访另一个节点上的数据。兴许难能可贵的是，许多这些工作负载在云呈现之前就存在了。传统的SQL，如MySql、PostgreSQL和其余SQL，简直总是部署故障转移和正本。有时，这些传统的工作负载甚至能够通过Kafka或相似的形式整合在一起，以交付一个对立的数据网格，就像后面ThoughtWorks的文章中提到的那样。咱们的幻想是为企业提供关注点，比方从所有数据中学习，同时也容许小型独立团队的自治和敏捷性。
第二个新的CAS要求
因而，咱们能够用第二种形式更新CAS定义。咱们当初晓得CAS解决方案须要以LocalPV速度蕴含多节点HA。
这个需要的惟一问题是，到目前为止，可能满足这个需要的解决方案非常少。据我所知，致力于满足这一需要的惟一CAS解决方案是OpenEBS Mayastor；它将在2020年9月达到测试版0.4。
第三和第四项附加的CAS要求
第三个更新在这两个更新之后的逻辑上进行。CAS解决方案在其架构中应该是云原生的。如果咱们想胜利地反对所有类型的工作负载，比方NoSql工作负载的LocalPV，以及对许多性能敏感的PostgreSQL等部署具备弹性的高性能，那么CAS必须提供多种存储数据的办法。
在OpenEBS的状况，该我的项目利用云原生架构提供了不少于4个“数据引擎”（如果计算可用的所有不同格调的LocalPV，会更多）。晚期的CAS解决方案在实质上更加繁多。我认为所有的CAS都须要以Kubernetes作为基底的思维来构建，从而实现可插拔的非单体架构。
最初，开源仿佛是显著的。感性的人可能不批准这一点，因为有一些显著的CAS模式的晚期贡献者依赖于专有软件。然而，专有软件引入了供应商依赖，这与云原生固有的“可移植性”精力相冲突。
综上所述，从成千上万的容器附加存储用户那里，咱们能够自信地说，CAS的定义应该扩大到包含：
- CAS必须反对pass-through模式（咱们在Kubernetes生态系统中称之为LocalPV）
- CAS必须反对LocalPV速度的多节点HA
- CAS软件在架构上应该是云原生的--依据工作负载反对多个数据引擎
- CAS应该是开源的，以防止引入供应商依赖关系。
总结
在过来的几年里，咱们看到了来自更宽泛的云原生社区的大量反馈和反对，这些社区致力于如何在解决数据时最大限度地利用Kubernetes和云原生办法。咱们必须付出能力失去。而且，我比以往任何时候都快乐，因为MayaData将OpenEBS捐献给了CNCF。咱们很天然地将Litmus也捐献给了关注有状态工作负载的混沌工程。咱们十分骄傲的是，依据这篇来自CNCF的DevStats报告，截止到2020年8月底，MayaData是CNCF我的项目的第5大次要贡献者：
https://all.devstats.cncf.io/...
最近，咱们帮忙启动了Data on Kubernetes社区我的项目，在这供应商中立空间中探讨操作人员、数据库、用例等等。来自应用Kubernetes组织的工程师像Optoro和Arista等，以及Kafka/Confluent和Cassandra/DataStax等我的项目进行了发言。欢送并激励所有人与独立组织者取得联系，以任何你想要的形式参加。
CAS当初被看作是把Kubernetes转换成数据立体的要害局部。CAS补充了底层云存储服务、本地CSI可拜访存储，甚至是本地节点中可用的原始磁盘和内存。
咱们应用CAS（特地是OpenEBS）的教训表明，用户曾经相熟了这种模式。CAS的新需要反映了这模型的增长和成熟度。
我对将来几年咱们将走向何方感到兴奋。当咱们在Kubernetes上摸索更多数据密集型的工作负载时，咱们的需要将如何倒退？不论是什么，咱们都渴望和你一起找出答案。咱们在MayaData这里聆听，并持续倒退CAS模式以满足新的需要。
点击浏览网站原文。
CNCF (Cloud Native Computing Foundation)成立于2015年12月，隶属于Linux Foundation，是非营利性组织。
CNCF（云原生计算基金会）致力于培养和保护一个厂商中立的开源生态系统，来推广云原生技术。咱们通过将最前沿的模式民主化，让这些翻新为公众所用。扫描二维码关注CNCF微信公众号。