随着的出现，现在是完全重新考虑存储的好时机。 由于应用程序现在由运行在容器中的松散耦合的的不稳定集合组成，它们的规模不断变化，不断更新和重新部署，并且始终在发展，因此必须改变服务存储和数据服务的传统观念。

通过使其便宜且易于管理来运行构成应用程序的数百个容器实例，从而为启用这些类型的应用程序铺平了道路。 同样，软件定义的存储（SDS）可以运行数十个系统，这些系统构成了高度灵活的存储系统，可为数百个可行/可管理的客户端提供数百个卷/ LUN。 现在是结合这两种系统的绝佳时机。

背景

Kubernetes大规模运行容器，而GlusterFS大规模运行存储。 两者都是完全由软件定义的横向扩展方法，为下一代工作负载提供了理想的基础。 通过在Kubernetes上运行GlusterFS，您将拥有一个通用的基础架构堆栈，可在裸机部署，本地虚拟化环境以及私有云和公共云中使用-基本上可以在任何运行Linux的地方使用。

是软件定义的可横向扩展的POSIX兼容文件存储。 Gluster在行业标准的服务器，VM或容器上运行，并将本地连接的存储虚拟化为单个弹性池，该弹性池通常可通过本机网络协议或SMB3或NFS进行访问。 对于容器工作负载，已添加了iSCSI块存储和S3对象访问协议。

Kubernetes是核心的容器编排平台，具有容器化应用程序的自动部署，扩展和管理功能。 Kubernetes可以将Linux系统集群变成一个灵活的应用程序平台，为容器提供计算，存储，网络，部署例程和可用性管理。 红帽的容器平台基于Kubernetes提供强大的PaaS，可以将开发人员的代码转换为在测试，开发和生产中运行的应用程序。

具有传统存储的Kubernetes

Kubernetes支持使用现有的旧式向上扩展存储系统，例如SAN阵列。 走这条路线可能会带来一些挑战：

1. 现有的存储系统不是由API驱动的，而是完全为人工管理而构建的。 在这种情况下，无法与Kubernetes上的动态存储供应功能正确集成，在这种情况下，需要即时供应应用程序实例（因此需要存储）。 用户（以及代表他们的Kubernetes）无法使用Kubernetes API从后端请求临时存储，因为没有存储配置API，在这些旧式存储系统上进行配置通常是一个静态且漫长的过程。 对于基于NFS，iSCSI或FC的存储，通常是这种情况。

   在没有自动化的情况下，管理员必须预先按卷猜测存储需求，将其手动配置并公开给Kubernetes，然后不断监视实际需求如何与供应估算相匹配。 这将无法扩展，几乎可以肯定地保证了开发人员和操作人员的不满。

2. 另一种情况是，现有存储以某种方式绑定到Kubernetes自动化的配置中，但是其设计目的并不是要扩展到通常在Kubernetes上运行的消费者使用的存储数量。 存储系统可能已针对涉及虚拟机管理程序的用例进行了优化，在这种情况下，通常您最终将数十个（在极少数情况下为数百个）可预测大小的卷用作数据存储。 使用Kubernetes，它可以而且很容易进入数百到数千个卷，因为它们通常是按每个容器消耗的。 大多数存储系统可能会被限制在一个级别的多个卷上，这不适合Kubernetes预期的并行性和消耗。

具有软件定义存储的Kubernetes

在Kubernetes上使用传统存储充其量是短期的选择，可以将时间缩短到下一个采购周期。 在这个阶段，您将进入充满希望的软件定义存储领域，其系统已考虑到规模和自动化。 在这里，您会发现有许多带有“容器准备就绪”标签的解决方案。 但是，许多解决方案都不适合容器，因为它们在幕后针对虚拟机而不是容器具有传统实现。

在开源空间中，GlusterFS是一个着眼于规模构建的著名项目，并且已经在全球的生产系统中运行了多年。

Kubernetes上的GlusterFS

GlusterFS不仅为Kubernetes上的工作负载提供存储，而且还与其他工作负载一起在Kubernetes上运行。 这就是所在-它将GlusterFS软件二进制文件放入容器中，并以Kubernetes Pod（容器的Kubernetes抽象）形式运行它们，可以访问主机网络并在所有或部分集群节点上存储存储以提供文件，块，甚至对象存储。 这完全由Kubernetes控制平面控制。

以这种方式与Kubernetes一起使用GlusterFS具有两个明显的优势。 首先，存储（无论是否由软件定义）在Kubernetes之外运行时，始终是您必须随平台一起使用的东西。 存储是一个具有自身管理功能的系统，必须在部署Kubernetes的环境中提供支持，必须将其安装在其他系统上，并且具有自己的安装过程，打包，可用性管理等。

在这一点上，实际上您正在做的是学习一个额外的管理系统，同时复制许多功能，Kubernetes已经提供了开箱即用的横向扩展应用程序—仅用于运行软件定义的存储，这仅仅是另一个横向扩展应用程序。

借助Kubernetes上的GlusterFS，后者将接管容器中SDS软件进程的调度，并确保始终有足够的实例在运行，同时还为它们提供对足够的网络，CPU和磁盘资源的访问权限。 为此，已使GlusterFS映像可用于在OCI兼容的容器运行时中运行。

其次，大多数SDS技术安装在VM，云实例或裸机服务器中时，需要特殊的设置过程，而这些过程对于所有这些环境都是不同的。 所有这些部署选项甚至都没有支持许多解决方案，这在您要使用多个解决方案（例如混合云，多个公共云等）的情况下，阻碍了您使用Kubernetes。

GlusterFS可以在所有三种版本以及所有公共云提供程序上运行，并且在足够高的层（Linux OS，TCP / IP堆栈，LVM2，块设备）上抽象，因此它几乎不在乎表面的实际内容。

将GlusterFS置于Kubernetes之上使事情变得更加容易：无论在何处部署， 都是完全相同的，因为它是Kubernetes完全抽象的。 只需发布新版本的容器映像即可轻松进行更新，从而以滚动方式更新现有机队。

第三，尤其是在云提供商上，无论Kubernetes的基础平台是什么样，都可以将GlusterFS置于Kubernetes之上。 在云中，计算网络和存储资源实际上位于几个可用区中。 对于应用程序开发人员来说，这并不总是显而易见的。 云存储（尤其是基于块设备的云存储）通常不会在这些可用性区域之间复制。

依靠这一点，虽然Kubernetes灵活的调度只会在可用性区域完全消失的情况下在另一个区域中重新启动Pod，但是您的云提供商存储将不会随之移动，因此您的应用程序将毫无价值。

GlusterFS集成的复制在各个可用区域上都非常有效（往返时间最多支持5毫秒，并注意到流行的云提供商可用区域之间的平均延迟要低得多）。 您可以指示Kubernetes上的GlusterFS在每个区域中至少运行一个GlusterFS容器实例，从而在每次写入操作时在整个区域中分布数据的冗余副本。 在这里，一个站点/区域的故障对存储用户而言是透明的，并且一旦恢复（再次借助Kubernetes调度），就会在后台开始自动自我修复。

最后，如前所述，您很有可能尝试利用内部现有的SAN存储来供Kubernetes上的工作负载使用。 GlusterFS可以帮助您使其成为容器就绪的。 GlusterFS处理Linux主机上本地可用的存储，而存储又可以来自本地SATA / SAS接口以及FibreChannel LUN。 将后者提供给Kubernetes节点时，您将拥有Kubernetes上GlusterFS所需的全部内容。

这样，GlusterFS可以弥合那些存储容器可以有效使用的存储系统的空白。 当然，最终使用本地存储可以实现理想的成本足迹。

含义和警告

当然，这种方法不仅具有优势，而且还存在一些挑战。 随着时间的流逝，其中一些将被克服。

当前，在Kubernetes上实现GlusterFS包括Pod，这些Pod运行glusterd软件守护程序，该守护程序通过著名的网络端口提供其存储服务。 这些端口不能由安装程序配置，也不能与客户端一起配置，因此，主机上运行的一个Pod将专门占用这些端口，从而实际上无法在该系统上运行另一个GlusterFS Pod。

同样，到目前为止，Kubernetes还没有能力将 。 但是，即使在容器中运行GlusterFS，也需要直接访问块存储。 因此，目前，GlusterFS容器需要作为具有特权的超级特权容器运行，以直接访问块设备。

同样，生产集群的最小节点数为三个。 可能会有更多的节点，但要少于这个节点，这将使您的数据面临风险：将数据的一个副本保存在单个节点上的单个GlusterFS Pod上将给您带来单点故障。 由于GlusterFS要求（并将强制执行）仲裁以确保数据一致性，因此在两个节点上的两个Pod中有两个副本很容易出现裂脑情况。 当您从两个Pod中丢失一个时，您的数据将是完整的但是只读的。—只有三个或更多Pod，您的数据才会被复制3次，从而不会因中断而丢失或出现不一致。 因此，您至少需要三个Kubernetes节点。

除了单纯的技术方面，在操作这种平台时，这还将为操作提供新的视角：存储团队或一般运维团队不仅需要熟悉如何部署和运行Kubernetes，还需要熟悉如何在其之上运行基础架构软件。 幸运的是，事实证明，Kubernetes已经处理了许多经典的管理操作。

在Kubernetes的世界中，开发人员可以通过自助服务访问计算资源和网络，在一定程度上可以控制“谁获得多少以及何时获得”。 并以一路按需存储容量。 现在有了动态的供应序列，而无需人工干预（只需几秒钟），而经典的基于票证的批准过程不再需要额外的容量（这可能需要数小时至数天）。

最后，Kubernetes的存储世界还很新，令人兴奋。 Kubernetes的PersistentVolumes（代表用户和容器存储的主要逻辑实体Kubernetes）和PersistentVolumeClaims（一种请求方式）的简单抽象模型尚不具备经典平台希望从存储中获得的许多功能，例如快照，复制或分层。在Kubernetes中存储）。 因此，尽管GlusterFS当然可以提供这些功能（例如快照，地理复制等），但它们尚未通过Kubernetes API提供。 GlusterFS社区与Kubernetes社区中的Storage SIG紧密合作，以稳定地实现这些概念。

您应该感兴趣吗？

如果您希望利用容器的优势，在组织中引入和支持DevOps文化，运行微服务或通常尝试通过缩短上市时间来使公司IT为业务提供更直接的价值，您将至少评估Kubernetes 当您采用它时，很快就会有状态的应用程序进入集群，并且需要强大，持久的存储。 数据库会属于那些应用程序吗？ 很可能。 还是共享大型内容存储库或消耗对象存储的工作负载？ 在这两种情况下，您都绝对应该看看gluster-kubernetes。

因此，如果您只有无状态应用程序，或者所有应用程序都管理存储并且存储本身完全是一致性的，则gluster-kubernetes不会给您带来额外的好处。 但是，您不太可能拥有这样的集群。

判决

Kubernetes上的GlusterFS为现代计算提供了一种瑞士军刀方法，该方法现在比以往任何时候都需要更强大的存储能力，并且需要更大的规模和速度。 它与Kubernetes和Red Hat的OpenShift容器平台完美集成，并且无论Kubernetes的部署位置和方式如何，都提供一致的存储服务功能集。 它使您免受不同环境中所有不同的实现和限制的影响，同时自然地补充了Kubernetes已经提供的现有计算和网络服务。 同时，它遵循Kubernetes鼓励的相同设计原则：基于在整个商品系统集群中的容器中分布的服务的软件定义的横向扩展。

要了解更多信息，请参加“ 将于12月6日至8日在德克萨斯州奥斯汀举行的 。

翻译自: