所有帖子

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

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

前几天,我们与一位受人尊敬的行业分析师进行了交谈,他向我们提出挑战,以发现Kubernetes对对象存储如此重要的原因。它使我们认为这是一个值得我们和您共同度过的话题。


从最基本的角度来看,Kubernetes的价值在于将基础架构视为代码的能力,可以为软件本身的有状态和无状态组件提供全面的自动化。


要获得最大的价值,需要将最大数量的组件视为代码并进行编排。这意味着您将一切都放入了容器中,包括应用程序,基础架构和数据。


在现代世界中,应用程序是无状态的和容器化的。但是,该状态必须保留在某个地方。那是对象存储(不是旧版块和文件),并且该对象存储需要在容器中运行。通过这种方式,Kubernetes可以管理基础架构的自动化-有状态和无状态。


如果将对象存储留给裸机或公共云存储服务,则基于Kubernetes的架构流程的好处将大大减少。


考虑它的另一种方法是通过VMware类比。VMware创建了软件定义的数据中心的概念。这是Kubernetes的前身(这就是为什么他们认为它是与生俱来的权利)。为了获得SDDC的真实价值,,您必须虚拟化整个数据中心。如果将某些应用程序留在裸机上运行,则丢失了SDDC的优势。


如果仅对应用程序使用Kubernetes,则只需轻按该值的一小部分即可。让我们更深入地探讨这一点。


首先,在现代模型中,CPU,网络和存储是Kubernetes要抽象的物理层。必须将它们抽象化,制动应用程序和数据存储可以在任何地方作为容器运行。特别是,数据存储包括所有持久性服务(数据库,消息物理,对象存储..)。


从Kubernetes的角度来看,对象存储与任何其他键值存储或数据库没有区别。存储层减少到其下一个物理或虚拟驱动器。 。将必要的服务留给外部物理设备或公共云会剥夺Kubernetes自动化的好处。


VMware在最初职位中宣布了他们建立了Data Persistence平台的原因,这是一个很好的资源。DPp是以下问题的答案:“我们如何允许现代应用程序执行其最擅长的工作,但仍为管理员和开发人员提供VMware平台的易用性和透明操作?”


MinIO,Kubernetes和VMware数据保护平台(DPp)


现代应用程序,尤其是那些在Kubernetes上运行的应用程序,其设计有助于自身内部的可用性,复制,扩展和加密,以完全独立于基础架构。反过来存储需要运行IN,以提供观测,数据放置,维护操作和故障处理的容器。


并非总是如此。传统上,应用程序嵌入数据库来存储和使用结构化数据,并放置到本地驱动器或分布式文件系统之类的存储来容纳其所有非结构化甚至半结构化数据。但是,非结构化数据的迅速增长对这一模型提出了挑战。都不能提供跨区域和大洲的访问。


这导致他们进行对象存储,该对象存储是针对RESTful API设计的(由AWS S3率先推出)。现在,应用程序没有任何负担来处理本地存储,从而使它们有效地成为无状态的(因为远程存储系统处于状态)。


经过精心设计的现代应用程序可以处理某种数据(日志,元数据,blob等),通过将状态保存到相关的存储系统中,从而符合云原生(RESTful API)设计原则。


简要说明一下,REST API仅解决应用程序-存储通信难题,例如PUT和GET或READ / WRITE数据,并跟踪元数据和版本数据,但不解决容器编排和自动化问题。这需要Kubernetes。


SAN和NAS也可以使应用程序容器变为无状态-但基于POSIX的文件和块在容器化环境中没有弹性,即具有使应用程序工作人员根据入站负载增长和收缩的能力,并在当前这就是为什么对象存储已将其替换为主要存储类的原因-公共云对对象存储的依赖(以及块和文件的定价)证明了这一点。


这并不是说存储应用程序(例如数据库,对象存储库,键值存储库)必须是无状态的。相反,它们需要是有状态的-只是不应该具有在流程中使应用程序变成有状态的效果。


为什么选择MinIO

快速和DevOps最佳实践要求应用程序和CI / CD流程简单明了,独立于基础架构,并在访问基础架构的方式上保持一致。简而言之,容器需要在所有地方以相同的方式运行,刹车在开发,测试和生产过程中可植入。将其与可变的硬件基础架构相结合,使Kubernetes成为所有分散的基础架构,应用程序和数据存储之间的联系点是很有价值的。


例如,MinIO使用内部串行编码机制来确保系统在各种硬件和云基础架构之间具有足够的冗余,以允许多个一半的MinIO仍在使用其自己的哈希和服务器端加密来管理数据初始化和安全性。


不再需要任何应用程序自己做任何事情。


在Kubernetes的世界中,功能得到了简化和抽象:应用程序执行应用程序操作,而存储执行存储操作。


这是原生云方式。


当然,还有非云原生方式。例如,您可以使用容器存储接口(CSI)解决此问题,但是高级架构师和开发人员则不能,因为它们增加了带来的复杂性和可伸缩性挑战。这是因为基于CSI的PV带来了它们自己的管理和冗余层,这些层通常与有状态应用程序的设计竞争。


在云原生世界中,Apache Spark在Kubernetes上以无状态方式运行,切换状态传送到其他系统,而Spark容器本身在完全无状态的情况下运行。大数据分析领域中的其他主要企业参与者(例如Vertica,Teradata,Greenplum)也正在转向计算和存储的分解模型。


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


MinIO Console和MinIO Operator,用于管理Kubernetes上的对象存储

MinIO一直在这种情况下考虑存储。我们的大部分工作负载(到今天早上为止,有5.23亿Docker拉动了Docker)在容器中运行(占64%),近一半由Kubernetes管理(占42%) 。这就是为什么VMware选择我们作为其数据持久性平台(DPp)推出的设计合作伙伴的原因。我们是此类部署的标准。


我们将继续完善我们的方法。例如,我们被广泛采用的Helm图表方法不足以跨越DevOps受众到主流IT管理员受众的鸿沟。我们之前的实现有效地处理了一个租户。关于多租户和其他DevOps任务,如预配,扩展,升级/更新,监视和加密服务-这是必需的客户代码。


在MinIO之上建立多租户,自助对象存储基础架构需要大量技能和自定义代码开发。


现在,MinIO是放在Kubernetes之上的功能完备的多租户自助服务云存储。操作员和控制台将Kubernetes原生,对象存储即服务的功能交付给IT部门-无需CLI或脚本编写技能。


MinIO无处不在

但是,现在,现在,#minioeverywhere可以说明一个事实,即MinIO与Kubernetes一起在任何地方运行。


考虑到它的细微差异,这可能会丢失。由于公共云提供商之间存在主要的经济和技术障碍,因此在所有基础架构中使用MinIO / Kubernetes越来越多。


AWS S3不等于Blob(Azure),当然也不等于GCP(与S3兼容)。在公共云中,间距比存储更昂贵,并且使用寿命长。消除这些差异是一个非常昂贵的主张。


企业将MinIO利用其软件模型(应用程序和存储)的核心部分,因为它们可以将其滚动到任何地方。AWS,GCP,Azure,Tanzu,Openshift-清单不胜枚举。在那个容器中运行-MinIO在任何Kubernetes环境中都是开箱即用的-从汽车或5G POP到公共云。这就是为什么您在AWS中,GCP和Azure中找到运行MinIO的770万个IP的原因。


现在都在一起了

这里有很多东西,所以让我们快速总结一下。Kubernetes的价值在于将基础架构视为代码的能力,可以为软件级别的有状态和无状态组件提供全面的自动化。


仅当您可以在容器中获得最大数量的组件时,才能实现Kubernetes的价值。这包括存储/持久数据。


MinIO就是预定而重建的-它很容易装入容器(〜45MB),它是针对RESTful API设计的,并且继续发展其方法(请参见MinIO Operator),以在存储方面提供最原生的Kubernetes体验。


当您原生于Kubernetes时,您可以在它运作的任何事情上运行-如今,您关心的是运行的任何地方-公共云,私有云,Kubernetes分布和边缘。


不要相信我们。你自己看。您可以从Github中提取MinIO Kubernetes代码的运营商。问题?加入我们的Slack频道上的对话,或单击“询问专家”按钮,立即开始。


上一篇