Kubernetes存储模式

是 否 +2 论坛币

k人 参与回答

经管之家送您一份

应届毕业生专属福利!

求职就业群

赵安豆老师微信：zhaoandou666

经管之家联合CDA

送您一个全额奖学金名额~ !

立即领取

感谢您参与论坛问题回答

经管之家送您两个论坛币！

+2 论坛币

Kubernetes存储模式
通过Nitish Tiwari
Kubernetes从根本上改变了传统的应用程序开发和部署模式。应用程序开发团队现在可以在数天之内跨不同的环境在Kubernetes集群中开发，测试和部署其应用程序。前几代技术通常要花费数周甚至数月的时间。
由于Kubernetes带到表的抽象性，所以这种加速是可能的，即它处理物理或虚拟机的基础细节，同时允许用户声明CPU，内存，容器实例数以及其他参数。在庞大，充满爱心的社区的支持下，Kubernetes的采用率不断提高，并且在很大程度上领先于容器编排平台。
随着采用率的增长，对Kubernetes中存储模式的困惑也越来越多。
由于每个人都在争夺Kubernetes的存储市场份额，存储选项周围有很多噪音，淹没了信号。
Kubernetes是用于应用程序开发，部署和管理的现代模型。现代模型分解存储和计算。为了充分了解Kubernetes上下文中的分解，我们还需要了解有状态和无状态应用程序和存储的概念。在这里，S3的RESTful API方法比其他解决方案所提供的POSIX / CSI方法具有明显的优势。
这篇文章讨论了Kubernetes的存储模式，并讨论了无状态与有状态的辩论，目的是确切了解为什么存在差异以及为何如此重要。在文章的后面，我们将根据容器和Kubernetes最佳实践介绍应用程序及其存储模式。
无状态容器
容器本质上是轻量级且短暂的，可以在几秒钟之内轻松停止，删除或部署到另一个节点。在大型的容器编排系统中，这种情况一直发生，而其使用者甚至没有注意到这种变化。但是，只有在容器对基础节点没有任何数据依赖性的情况下，这种移动才是可能的。这样的容器是无状态的。
有状态的容器
如果容器将数据存储在本地安装的驱动器（或块设备）上，则在发生故障的情况下，必须将基础存储与容器本身一起移动到新节点。这很重要，否则容器中运行的应用程序将无法正常运行，因为它需要引用存储在本地挂载中的数据。这样的容器是有状态的。
从技术上讲，有状态容器也可以移动到不同的节点。通常，这是通过分布式文件系统或连接到运行容器的所有节点的网络块存储来实现的。这样，容器就可以访问持久卷安装，并且数据存储到附加的存储中，该存储在整个网络上都可以使用。为了统一起见，我将这种方法称为有状态容器方法。  
在典型的有状态容器方法中，将应用程序容器安装到一个分布式文件系统上，这是所有应用程序数据所驻留的一种共享存储。尽管可能会有一些变化，但这是高级方法。
现在，让我们了解为什么有状态容器方法在云原生世界中是一种反模式。
云原生应用程序设计
传统上，应用程序使用用于结构化数据的数据库以及本地驱动器或分布式文件系统来转储其所有非结构化甚至半结构化数据。随着非结构化数据的增长，开发人员意识到POSIX过于闲谈，需要支付大量的间接费用，最终阻碍了应用程序大规模运行。
这在很大程度上促进了新的存储标准，即由RESTful API驱动的云原生存储，从而减轻了应用程序处理本地存储的负担并使其有效地实现了无状态（就像远程存储系统的状态一样）。考虑到这一点，现代应用程序已经建立起来。通常，处理某种类型的数据（日志，元数据，blob等）的任何现代应用程序都将状态传送到相关的存储系统，从而符合云原生设计。
有状态的容器方法可以将其带回到开始的地方！
使用POSIX接口存储数据，应用程序可以以有状态的方式运行，并且失去了云本机设计的最重要原则，即具有使应用程序工作人员根据入站负载增长和收缩的能力，可以在当前节点后立即移动到新节点下去等等。
随着我们变得更加具体，我们发现我们可以再次使用POSIX vs REST API进行存储，但是由于Kubernetes环境的分布式性质，但是POSIX问题的进一步放大。特别，
POSIX是Chatty：POSIX语义要求每个操作都具有关联的元数据和文件描述符，以维护操作状态。这导致了很多开销，没有增加任何实际价值。诸如S3 API之类的对象存储API摆脱??了这些要求，从而允许应用程序触发并忘记调用。来自存储系统的响应指示该操作是否成功。如果发生故障，应用程序可以重试。
网络限制： 在分布式系统中，暗含的是可能有多个应用程序试图将数据写入单个安装。因此，不仅应用程序争用带宽（将数据发送到安装架），存储系统本身还争夺同一网络上的带宽以将数据发送到实际驱动器。由于POSIX聊天，网络呼叫的数量增加了几倍。另一方面，S3 API允许将客户端和服务器之间以及内部服务器之间的网络调用明确分开。
安全性：POSIX安全性模型是为人类用户构建的，管理员为每个用户或组配置特定的访问级别。这使得很难适应云原生世界。现代应用程序依赖于具有策略定义的访问权限，服务帐户，临时凭据等的基于API的安全模型。
可管理性： 有状态的容器增加了管理开销。同步并行数据访问，确保数据一致性等需要仔细考虑数据访问模式。这意味着要安装，管理和配置更多的软件，当然还要付出更多的开发工作。
集装箱存放接口
尽管CSI在将Kubernetes卷层扩展到第三方存储供应商方面做得很出色，但它也无意间使生态系统相信有状态容器方法是Kubernetes中推荐的存储方法。
CSI被开发为将任意块和文件存储存储系统暴露给Kubernetes上的遗留应用程序的标准。而且，正如我们在这篇文章中所看到的，有状态容器方法（以及当前形式的CSI）才有意义的唯一情况是，应用程序本身是否是旧系统，无法添加对对象存储API的支持。
重要的是要理解，以当前形式使用CSI，即在现代应用程序中进行卷安装，最终会导致类似问题，这在POSIX风格的存储系统中已经看到。
更好的方法
要了解的重要一点是，大多数应用程序本身并不是有状态的或无状态的。它们的行为由整体体系结构和特定的设计选择定义。当然，有些存储应用程序需要是有状态的（例如MinIO）。我们将稍后讨论有状态的应用程序。
通常，应用程序数据可以分为几种类型：
记录数据
时间戳数据
交易数据
元数据
容器图片
斑点数据
所有这些数据类型在现代存储平台中都得到很好的支持，并且有多种云原生平台可满足这些特定数据格式中的每一种。例如，事务数据和元数据可以放在现代的云原生数据库中，例如CockroachDB，YugaByte等。容器映像或Blob数据可以存储在基于MinIO的docker注册表中。时间戳数据可以存储在时间序列数据库（例如InfluxDB等）上。我们将跳过每种数据类型和相关应用程序的详细信息，但是这样做的目的是避免基于本地安装的持久性。
此外，在许多情况下，将临时缓存层用作应用程序的暂存空间是有效的，但是应用程序不应依赖于该层作为真相的来源。
有状态的应用程序存储
通常，最好使应用程序保持无状态，但存储应用程序（例如数据库，对象存储，键值存储）需要保持状态。让我们了解如何在Kubernetes上部署这些应用程序。我将以MinIO为例，但是类似的原理适用于所有主要的云原生存储系统。
云本机存储应用程序旨在利用容器带来的灵活性，这意味着这些应用程序不会对部署它们的环境进行假设。例如，MinIO使用内部擦除编码机制来确保系统中有足够的冗余，以允许多达一半的驱动器发生故障。MinIO还使用自己的哈希和服务器端加密来管理数据完整性和安全性。
对于此类云原生应用程序，本地持久卷（PV）最适合作为后备存储。本地PV提供原始存储容量，而在这些PV之上运行的应用程序则使用其自身的智能来扩展和管理不断增长的数据需求。
与基于CSI的PV相比，它们具有自己的管理和冗余层（通常与有状态应用程序的设计竞争），这是一种更简单且可扩展的方法。
稳步走向分解
在这篇文章中，我们讨论了应用程序变为无状态，或者换句话说，将存储与计算分离。现在，让我们看一下这种趋势的一些现实例子。
传统上，著名的数据分析平台Spark一直以有状态的方式在面向HDFS的部署上运行，但是当它迁移到云原生世界时，Spark越来越多地使用“ s3a”连接器在Kubernetes上以无状态的方式运行。当Spark容器本身完全无状态运行时，Spark使用连接器将状态发送到其他系统。大数据分析领域中的其他主要企业参与者（例如Vertica，Teradata，Greenplum）也正在转向计算和存储的分解模型。   
同样，从Presto，Tensorflow到R，Jupyter笔记本的所有其他主要分析平台都遵循这种模式。将状态卸载到远程云存储系统使您的应用程序更易于扩展和管理。此外，它有助于使应用程序可移植到不同的环境。

关注 CDA人工智能学院 ，回复“录播”获取更多人工智能精选直播视频！

扫码加我 拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

分享0 收藏0 回帖

关键词：Uber Ber NET Teradata 时间序列数据