“云原生”(Cloud Native)一词在 2019 年被技术界广泛使用，但是却没有关于这个词一个特别明确的定义。主要的困惑在于，“云原生”与您的应用程序部署到的环境几乎没有关系，该术语同样适用于私有云和公共云。该术语更多的是指应用程序和体系结构的特征。
在 Cloud Native Computing Foundation (CNCF 云原生计算基金会) 对该术语的最新定义中我们可以找到一些相关信息：
云原生技术使组织能够在现代、动态环境(例如公共云，私有云和混合云)中构建和运行可扩展应用程序。容器、服务网格、微服务、不变的基础结构和声明性API 就是这种方法的例证。
这些技术使松散耦合的系统具有弹性，可管理性和可监控。结合强大的自动化功能，它们使工程师能够以最小的工作量频繁且可预测地进行重大的更改。
那么，存储是云原生意味着什么呢?简而言之，它必须以与云原生生态系统中其他所有事物相同的动态，API 驱动的方式运行。有两个相关的指标可以确定一个存储系统是否云原生，它们是：
- 是否专为 Kubernetes 打造
- 是否兼容亚马逊的 S3 API
下面我们将更详细地解读这些指标。
云原生存储是对象存储
现代应用程序体系结构基于对象存储，默认情况下，S3 是云的 API 语言。因为对象存储是唯一一种旨在处理云本机应用程序生成的数据量的存储，并且提供公司可以负担得起的价格以及用户期望的速度运行 —— 它在现代存储中占主导地位。与块文件存储系统相比，对象存储的其他属性包括出色的分发特性，更好的弹性和更高的可用性。
这都是云原生应用程序期望的属性。
Amazon S3 API 是对象存储的事实上的标准，每个对象存储软件供应商都宣称自己对 S3 API 兼容。AWS S3 实际上是二进制兼容的。适用于所有的场景，要么完全不适用。
也就是说，S3 API 基本上可以满足绝大多数的场景，其中包括你可能不会想到的极端情况。这是开源软件具有显着优势的领域。考虑到应用程序、操作系统和硬件体系结构的规模和多样性，可以表明他们已经看到了大多数极端情况，而且能很好的满足这些场景。
这对应用程序创建者来说很重要，因为你需要针对那些供应商来测试你的应用程序。而开源使您可以轻松评估和测试供应商的方案，如果测试通过，很可能是云原生的。如果不是，则不是。
专为 Kubernetes 设计
“云原生”的第二个标准是使用利用外部容器编排平台的分布式架构。这意味着架构必须对 Kubernetes 友好。在容器编排方面，Kubernetes已经是显而易见的行业赢家，因此将其构建为与 Kubernetes 协同工作对于将存储解决方案视为云原生是至关重要的。
存储对 Kubernetes 友好意味着什么?我们认为有六个主要标准。
1. 让 Kubernetes 编排存储节点
Kubernetes 是一个功能强大的编排器，可用于处理计算和存储编排。像 MinIO 这样的真正云原生存储方案与 Kubernetes 集成在一起，允许操作员使用 Kubernetes 界面管理存储，而 Kubernetes 可以处理从存储提供到卷放置的所有事务。
2. 多租户
多租户允许多个客户使用一个应用程序的单个实例，如果实施正确，则可以减少运营开销，降低成本并降低复杂性，尤其是在规模方面。但是，这也需要严格的资源隔离，以便多个用户可以访问计算资源或存储资源，而不会影响其他用户。真正的云原生存储解决方案将提供足够的资源隔离，以确保多租户架构安全，高可用性和高性能。
在对象存储世界中，意味着 Kubernetes 基础架构需要隔离和管理存储租户。如果 Kubernetes 没有管理基础架构，那么它并不是真正的云原生平台。这使那些具有 CSI 或 Operator 集成功能的设备供应商失去资格。
3. 轻巧
除非存储系统非常轻巧并且能够与应用程序堆栈打包在一起，否则多租户是不可能的。如果存储系统占用太多资源或包含太多API，则无法在同一基础架构上打包许多租户。
4. 可扩展
可扩展性是云原生系统的关键属性之一。Kubernetes 的优点之一是它已在各种规模上得以验证。Kubernetes 也可用于管理存储扩展，但前提是基础存储系统与 Kubernetes 集成，并且将存储供应和取消功能移交给 Kubernetes。
5. API 驱动
通常，Kubernetes 和云原生系统的核心原则之一是通过自动化来尽可能多地进行管理。为了使存储系统真正成为云原生，它必须通过 API 与 Kubernetes 集成，并允许动态的、由 API 驱动的编排。
6. 用户空间
最后的考虑也许是最困难的。为了使对象存储解决方案成为云原生，它必须完全在用户空间中运行且没有内核依赖性。这不是大多数对象存储系统(尤其是硬件设备)构建的方式。但是，如果您想对存储进行容器化并将其部署在任何 Kubernetes 集群上，则必须遵守这些限制。根据定义，这意味着需要内核修补或具有专用硬件的解决方案将不是云原生的。
结论
尽管在某种程度上很简单，但这两个要求“云原生”状态的标准实际上在实践中非常困难。公共云对象存储供应商在对抗它们方面做得很好。实际上，如果 Google 是 Kubernetes 的源头，而 Amazon 是 S3 的源头，则确实可以期望他们这样做。私有云对象存储供应商要通过这些测试要困难得多。虽然有些人声称与S3兼容，但仔细检查却发现并非如此。对于绝大多数传统厂商来说，Kubernetes 根本就不在他们的基因范围之内，甚至常常不在计划之列。因为这里面困难重重。
而 MinIO 是专为云原生工作负载而构建，设计时就考虑了 Kubernetes ，并遵循 Kubernetes 的方式。MinIO 与 S3 兼容，但也可以与 Google、Azure 或私有云一起使用，从而使多云和混合云成为可能。
高性能的云原生对象存储是获得云原生应用程序所需的性能、可靠性和可伸缩性的唯一方法。
