为什么 Kubernetes 管理的对象存储很重要

前几天，我们和一位备受尊敬的行业分析师谈话，他要求我们解释为什么 Kubernetes 对对象存储如此重要。这让我们思考，这是一个值得我们花费时间和精力讨论的话题，也值得您思考。

从最基本的层面上来说，Kubernetes 的价值在于它能够将基础设施视为代码，为软件栈的有状态和无状态组件提供全面的自动化。

为了获得最大价值，需要将尽可能多的组件视为代码，并进行编排。这意味着将所有内容都放入容器中，包括应用程序、基础设施和数据。

在现代世界中，应用程序是无状态的，并且是容器化的。但是，这些状态必须保存在某个地方。这个地方就是对象存储（而不是传统的块和文件），并且这个对象存储需要在容器中运行。通过这种方式，Kubernetes 可以管理基础设施的自动化，包括有状态和无状态组件。

如果对象存储仍然依赖裸机或公有云存储服务，那么基于 Kubernetes 的基础设施编排带来的益处将大大降低。

另一种理解方式是通过 VMware 的类比。VMware 创造了软件定义数据中心的理念。它是 Kubernetes 的前身（这也是他们将其视为其诞生地）。为了获得 SDDC 的真正价值，您必须虚拟化整个数据中心。如果某些应用程序仍然在裸机上运行，那么 SDDC 的益处就会丧失。

Kubernetes 也是如此。如果您只将 Kubernetes 用于应用程序，那么您只是在挖掘其价值的一小部分。让我们更深入地探讨一下。

首先，在现代模型中，CPU、网络和存储是物理层，需要由 Kubernetes 抽象。它们必须被抽象，以便应用程序和数据存储能够在任何地方以容器的形式运行。特别是，数据存储包括所有持久化服务（数据库、消息队列、对象存储等）。

从 Kubernetes 的角度来看，对象存储与其他任何键值存储或数据库并没有区别。存储层被简化为底层的物理或虚拟驱动器。将持久化数据存储作为容器运行的需求源于混合云的可移植性。将基本服务保留在外部物理设备或公有云中会剥夺 Kubernetes 自动化的优势。

这篇 VMware 博客文章宣布他们构建 Data Persistence 平台的原因，是一个很好的资源。DPp 是对“如何允许现代应用程序发挥其最佳功能，同时为管理员和开发人员提供 VMware 平台的易用性和透明操作？”这个问题的解答。

现代应用程序，特别是那些为在 Kubernetes 上运行而构建的应用程序，旨在自身处理可用性、复制、扩展和加密，使其完全独立于基础设施。反过来，存储需要在容器中运行，以便提供可观察性、数据放置、维护操作和故障处理。

情况并非总是如此。传统上，应用程序依赖于数据库来存储和处理结构化数据，并依赖于存储（例如本地驱动器或分布式文件系统）来存放所有非结构化数据，甚至包括半结构化数据。然而，非结构化数据的快速增长对这种模式提出了挑战。随着开发人员快速学习，POSIX 变得过于冗长，开销过大，无法让应用程序以大规模运行，而且它局限于数据中心，因为它从未打算提供跨区域和跨大陆的访问。

这促使他们转向对象存储，对象存储是为 RESTful API 而设计的（由 AWS S3 开创）。现在应用程序摆脱了处理本地存储的负担，使其实际上变为无状态（因为状态与远程存储系统一起）。

现代应用程序从一开始就是基于这种期望构建的。精心设计的现代应用程序处理各种类型的数据（日志、元数据、Blob 等），通过将状态保存到相关的存储系统，遵循云原生（RESTful API）设计原则。

快速说明一下，RESTful API 仅解决应用程序与存储通信方面的挑战，例如 PUT 和 GET 或 READ/WRITE 数据，以及跟踪元数据和版本数据，但不包括容器编排和自动化。这需要 Kubernetes。

SAN 和 NAS 也可以使应用程序容器无状态，但基于 POSIX 的文件和块在容器化环境中难以灵活地使用 - 例如，无法根据传入负载扩展和缩减应用程序工作进程，无法在当前节点出现故障时立即迁移到新节点等等。这就是为什么对象存储取代它们成为主要存储类别的原因 - 公有云对对象存储的依赖（以及块和文件的定价）就是明证。

这并不是说存储应用程序，例如数据库、对象存储、键值存储，必须是无状态的。相反，它们需要是有状态的，只是它们不应该在过程中使应用程序变为有状态。

为什么选择 MinIO

Kubernetes 原生的存储应用程序（如 MinIO）旨在利用容器带来的灵活性。敏捷和 DevOps 最佳实践要求应用程序和 CI/CD 流程简单直接，独立于底层基础设施，并且在访问底层基础设施的方式上保持一致。简而言之，容器需要在所有地方以相同的方式运行，以便在开发、测试和生产环境之间可移植。结合可变硬件基础设施，Kubernetes 成为所有分散的基础设施、应用程序和数据存储之间的联系点就变得合乎情理。

因此，存储应用程序不能对部署环境做出假设。例如，MinIO 使用内部擦除编码机制来确保系统中具有足够的冗余，跨不同的硬件和云基础设施，允许最多一半的驱动器出现故障。MinIO 还使用其自己的哈希和服务器端加密来管理数据完整性和安全性。

不再需要任何应用程序自行执行这些操作。

在Kubernetes 世界中，功能得到简化和抽象：应用程序执行应用程序相关操作，而存储执行存储相关操作。应用程序无需考虑这些操作，它们会自动完成，所有操作都在可以扩展、迁移或清除的容器内部进行。

这就是云原生方式。

当然，也存在非云原生方式。例如，您可以使用容器存储接口 (CSI) 来解决此问题，但经验丰富的架构师和开发人员不会这样做，因为 CSI 会增加不必要的复杂性和可扩展性挑战。这是因为基于 CSI 的 PV 会带来它们自己的管理和冗余层，通常会与有状态应用程序的设计相冲突。

以下是如何在云原生平台上使用存储和状态的示例。在云原生世界中，Apache Spark 以无状态的方式在 Kubernetes 上运行，并将状态发送到其他系统，而 Spark 容器本身完全是无状态的。大数据分析领域的其他主要企业参与者，例如 Vertica、Teradata、Greenplum，也正在转向计算和存储分离的模式。

同样，从 Presto、Tensorflow 到 R、Jupyter 笔记本的所有其他主要分析平台都遵循这种模式。将状态卸载到远程云存储系统可以使您的应用程序更易于扩展和管理。此外，它有助于保持应用程序的可移植性，使其能够适应不同的环境。

MinIO 一直以来都是从这种角度考虑存储的。我们大多数工作负载（截至今天早上的 5.23 亿次 Docker 拉取）都在容器中运行（64%），几乎一半由 Kubernetes 管理（42%）。这就是 VMware 选择我们作为其 Data Persistence 平台 (DPp) 推出的设计合作伙伴的原因。我们是这种部署方式的标准。

我们一直在改进我们的方法。例如，我们广泛采用的 Helm 图表方法不足以跨越从 DevOps 受众到主流 IT 管理员受众的鸿沟。我们之前的实现有效地处理了单个租户。对于多租户和其他 DevOps 任务，例如配置、扩展、升级/更新、监控和加密服务，这需要客户代码。

我们新的Kubernetes 运算符帮助我们的客户跨越鸿沟。在 MinIO 之上构建一个多租户、自助式对象存储基础设施需要大量的技能和自定义代码开发。

随着运算符的引入，这些任务现在是自动化的，并且由 API/Web 驱动。现在，MinIO 是一个完整的基于 Kubernetes 的多租户、自助式云存储。运算符和控制台将 Kubernetes 原生的、对象存储即服务的强大功能赋予了 IT 人员，无需 CLI 或脚本编写技能。

MinIO 无处不在

当我们开始谈论 #minioeverywhere 的概念时，我们是想说明我们与云原生精英的 集成。然而现在，#minioeverywhere 代表了 MinIO 与 Kubernetes 相结合，可以在任何地方运行的事实。

对于某些人来说，这可能有点难以理解。由于公共云提供商之间存在关键的经济和技术障碍，在所有基础设施上使用 MinIO/Kubernetes 越来越具有吸引力。

例如，公共云并非完全可互换。AWS S3 不等于 Blob（Azure），当然也不等于 GCP（部分兼容 S3）。此外，在公共云中，带宽比存储更昂贵，延迟也更高。消除这些差异是一个非常昂贵的提议。

企业正在将 MinIO 作为其软件堆栈（应用程序和存储）的核心部分，因为他们可以在任何地方部署它。AWS、GCP、Azure、Tanzu、Openshift——名单还在不断增加。由于 MinIO 是 Kubernetes 原生的，并且在容器中运行——MinIO 可以开箱即用地运行在任何 Kubernetes 环境中——从汽车或 5G POP 到公共云。这就是为什么您可以在 AWS、GCP 和 Azure 中找到 770 万个运行 MinIO 的 IP 地址。

让我们一起行动

这里有很多信息，让我们快速总结一下。Kubernetes 的价值在于它能够将基础设施视为代码，为软件堆栈的有状态和无状态组件提供全面的自动化。

只有在您能够将尽可能多的组件放入容器中时，Kubernetes 的价值才能实现。这包括存储/持久性数据。

MinIO 是为此而生的——它很容易放入容器中（约 45 MB），它专为 RESTful API 而设计，并且不断发展其方法（参见 MinIO 运算符），以提供最原生的 Kubernetes 存储体验。

当您是 Kubernetes 原生的时，您可以在它运行的任何地方运行——而今天，这就是您希望运行的任何地方——公共云、私有云、Kubernetes 发行版和边缘。

不要听我们说，自己看看。您可以从 Github 上获取 Kubernetes 的 MinIO 运算符代码。有问题？加入我们 Slack 频道 的讨论，或点击“咨询专家”按钮，立即开始。