🔳 🧒🏽 🖼️ Kubernetes存储模式 👩🏼‍🤝‍👨🏿 🚈 ✊

哈Ha！

我们提醒您，我们已经发布了另一本关于Kubernetes模式的非常有趣和有用的书。一切始于布伦丹·伯恩斯（Brendan Burns）的“ 模式 ”，顺便说一下，这一部分的工作正在紧锣密鼓地进行。今天，我们邀请您阅读MinIO博客上的一篇文章，其中概述了Kubernetes中数据存储模式的趋势和细节。

Kubernetes从根本上改变了应用程序开发和部署的传统模式。现在，团队可以花几天时间在不同的环境中以及Kubernetes集群中的所有环境中开发，测试和部署应用程序。使用前几代技术进行的这种工作通常要花费数周，甚至数月。

得益于Kubernetes提供的抽象，这样的加速才有可能实现-也就是说，由于Kubernetes本身与物理或虚拟机的低级详细信息进行交互，允许用户在其他参数中声明所需的处理器，所需的内存以及容器实例的数量。由于Kubernetes受到庞大社区的支持，并且Kubernetes的范围不断扩大，因此在所有容器编排平台中都有很大的领先优势。

随着Kubernetes的用途扩展，对其使用的存储模式的困惑也随之增加。

在争夺Kubernetes馅饼（即用于数据存储）方面的普遍竞争中，当谈到数据存储时，信号淹没在嘈杂的噪音中。
Kubernetes体现了用于开发，部署和管理应用程序的现代模型。这种现代模型将数据存储与计算分离。为了在Kubernetes的上下文中完全理解这种分离，您还需要了解什么是有状态和无状态应用程序，以及如何将数据存储与此相结合。与其他解决方案中常见的POSIX / CSI方法相比，S3使用的REST API方法具有明显的优势。

在本文中，我们将讨论Kubernetes中的存储模式，并将分别讨论关于状态安全和无状态应用程序的辩论，以便我们可以清楚地了解它们之间的区别以及它为何重要。在本文的进一步内容中，我们将根据与容器和Kubernetes一起使用的最佳实践来考虑应用程序和其中使用的数据存储模式。

无状态容器

容器本质上是轻便的和短暂的。它们可以轻松地停止，删除或部署在另一个节点上-所有这些仅需几秒钟。在大型容器编排系统中，此类操作始终发生，并且用户甚至没有注意到这种更改。但是，只有在容器不依赖于其所在节点的情况下，才可以移动。据说这些容器在没有状态保存的情况下工作。

有状态的容器

如果容器将数据存储在本地连接的设备（或块设备）上，则必须将其所在的数据仓库连同容器本身一起移至新节点，以防发生故障。这很重要，因为否则容器中运行的应用程序将无法正常运行，因为它需要访问存储在本地媒体上的数据。据说这些容器是有状态的。

从纯粹的技术角度来看，有状态容器也可以移动到其他节点。通常，这是通过使用分布式文件系统或阻止连接到容器在其上运行的所有节点的网络存储来实现的。因此，容器可以访问卷以进行持久数据存储，并且信息存储在整个网络中的磁盘上。我将这种方法称为“ 状态保存容器方法 ”，在本文的其余部分中，为了统一起见，我将其称为“ 状态保存容器方法 ”。

在典型的有状态容器方法中，所有应用程序容器都连接到一个分布式文件系统-获得一种共享存储，在其中获取所有应用程序数据。尽管可能会有一些变化，但这是一种高级方法。

现在让我们看看为什么在基于云的世界中有状态容器方法是反模式的。

基于云的应用程序设计

传统上，应用程序使用数据库来进行信息的结构化存储，并使用本地磁盘或分布式文件系统将所有非结构化甚至半结构化的数据转储到那里。随着非结构化数据量的增长，开发人员意识到POSIX太健谈了，带来了可观的成本，并且最终在大规模迁移时会干扰应用程序。

这主要是为数据存储新标准的出现做出了贡献，即基于云的存储主要基于REST API进行工作，并使应用程序摆脱了本地数据仓库繁重的维护工作。在这种情况下，应用程序实际上会进入操作模式而不保存状态（因为状态在远程存储中）。考虑到这一因素，从头开始构建现代应用程序。通常，任何处理一种或另一种数据（日志，元数据，blob等）的现代应用程序都是在面向云的范式上构建的，状态被转移到专门为其存储分配的软件系统中。

有状态的容器方法使整个范例完全回滚到它开始的地方！

当使用POSIX接口存储数据时，应用程序的工作方式与维护状态相同，因此，它偏离了基于云的设计的最重要假设，即，根据传入的数据来更改应用程序工作流的大小的能力加载，在当前节点出现故障后立即移至新节点，依此类推。

仔细观察这种情况可以发现，在选择数据仓库时，我们一次又一次地面临“ POSIX与REST API”的难题，但由于Kubernetes环境的分布式性质而导致POSIX问题的加剧。特别是，

POSIX : POSIX , . , . API , , S3 API, , , «» . , . .
: , , . , , ( ), , . - POSIX . , S3 API , , , .
: POSIX : . - . , API, , , ..
: , . , , , . , , , .

容器数据存储接口（CSI）在Kubernetes卷级别的分配方面起到了很大作用，部分将其传递给了第三方数据仓库供应商，但也无意中促成了人们坚信有状态容器方法是Kubernetes中推荐的数据存储方法。

CSI被开发为在使用Kubernetes时为旧版应用程序提供任意块和文件存储系统的标准。而且，如本文所示，只有在应用程序本身是无法添加对对象数据存储API的支持的旧有系统时，才是有状态容器方法（以及当前形式的CSI）才是合适的情况。

重要的是要理解，以当前形式使用CSI，即在使用现代应用程序安装卷时，我们将遇到与以POSIX样式组织数据存储的系统中几乎相同的问题。

更好的方法

在这种情况下，重要的是要了解，大多数应用程序固有地不会针对具有状态保留或不具有状态保留的工作而进行特定处理。此行为取决于系统的整体体系结构以及设计期间选择的特定选项。让我们谈谈有状态应用程序。

原则上，所有应用程序数据都可以分为几种类型：

记录数据
时间戳数据
交易数据
元数据
容器图片
Blob数据（斑点）

所有这些数据类型在现代数据存储平台上都得到了很好的支持，并且有几种基于云的平台适合于以每种特定格式交付数据。例如，交易数据和元数据可以驻留在现代的基于云的数据库中，例如CockroachDB，YugaByte等。可以基于MinIO将容器映像或Blob数据存储在Docker注册表中。时间戳数据可以存储在时间序列数据库中，例如InfluxDB等。我们不会详细介绍每种类型的数据和相关应用程序，但总体思路是避免基于本地磁盘安装的持久性数据存储。

此外，提供临时缓存层通常很有效，该层用作应用程序的一种临时文件存储，但是应用程序不应依赖此级别作为事实来源。

有状态的应用程序存储

尽管在大多数情况下使应用程序保持无状态是有用的，但那些旨在存储数据的应用程序（例如数据库，对象存储，键和值存储）应保持状态。让我们看看为什么将这些应用程序部署到Kubernetes。以MinIO为例，但是类似的原理也适用于任何其他大型的基于云的存储系统。

以云为中心的应用程序旨在最大程度地利用容器固有的灵活性。这意味着他们对部署环境不做任何假设。例如，MinIO使用内部擦除编码机制，该机制为系统提供了足够的稳定性，因此即使一半的驱动器发生故障，它也可以正常运行。 MinIO还使用其自己的服务器端哈希和加密来管理数据完整性和安全性。

对于此类基于云的应用程序，本地永久卷（PV）最方便用作备份存储。本地PV提供了存储原始数据的能力，而在这些PV之上运行的应用程序则独立收集信息以扩展数据并管理不断增长的数据需求。

与基于CSI的PV相比，这种方法简单得多，并且可扩展性明显更好，后者为系统带来了自己的数据管理和冗余级别。事实是，这些级别通常与根据状态保存原理设计的应用程序冲突。

从计算中释放数据的信心运动

在本文中，我们讨论了如何在不保存状态的情况下重新定向应用程序以使其工作，换句话说，数据存储在它们上进行了计算限制。总之，我们考虑了这种趋势的一些实际例子。传统上，著名的数据分析平台

Spark已用于状态部署和部署到HDFS文件系统。但是，随着Spark过渡到基于云的世界时，越来越多地使用该平台而不使用`s3a'进行状态保存。 Spark使用s3a将状态传输到其他系统，而Spark容器本身完全在不保存状态的情况下工作。大数据分析领域的其他大型企业参与者，特别是Vertica，Teradata，Greenplum还致力于数据存储和计算的划分。

在其他大型分析平台上也可以看到类似的模式，包括Presto，Tensorflow到R，Jupyter。将状态上传到远程云存储系统可以更轻松地管理和扩展您的应用程序。此外，它有助于将应用程序移植到各种环境。