共计 4375 个字符，预计需要花费 11 分钟才能阅读完成。
客座文章作者：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 微信公众号。
