云原生的存储系统应该满足什么条件？

“云原生”(cloud native)一词在 2019 年被技术界广泛使用，但是却没有关于这个词一个特别明确的定义。主要的困惑在于，“云原生”与您的应用程序部署到的环境几乎没有关系，该术语同样适用于私有云和公共云。该术语更多的是指应用程序和体系结构的特征。
专为 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. 用户
结论尽管在某种程度上很简单，但这两个要求“云原生”状态的标准实际上在实践中非常困难。公共云对象存储供应商在对抗它们方面做得很好。实际上，如果 google 是 kubernetes 的源头，而 amazon 是 s3 的源头，则确实可以期望他们这样做。私有云对象存储供应商要通过这些测试要困难得多。虽然有些人声称与s3兼容，但仔细检查却发现并非如此。对于绝大多数传统厂商来说，kubernetes 根本就不在他们的基因范围之内，甚至常常不在计划之列。因为这里面困难重重。
而 minio 是专为云原生工作负载而构建，设计时就考虑了 kubernetes ，并遵循 kubernetes 的方式。minio 与 s3 兼容，但也可以与 google、azure 或私有云一起使用，从而使多云和混合云成为可能。
高性能的云原生对象存储是获得云原生应用程序所需的性能、可靠性和可伸缩性的唯一方法。


广告点击优化16条算法调整规则
新站导航如何优化更利于蜘蛛爬行带来自然搜索？
外贸营销常出现的问题有哪些
网站设计开发的细节总结
做好这几点能让你的网站更有质量
用户模型建立在精细化运营中的关键点
企业互联网营销离不开网站优化，那网站优化主要能做哪些工作?
如何判断网站整体质量的好与差