在 Kubernetes 上运行存储服务

随着 容器 的出现，现在是重新思考存储的绝佳时机。由于应用程序现在由不稳定的、松散耦合的 微服务 集合组成，这些微服务在容器中运行，规模不断变化，持续更新和重新部署，并且始终在发展，因此服务存储和数据服务的传统思维方式必须改变。

Kubernetes 为实现这些类型的应用程序铺平了道路，它使得运行构成应用程序的数百个容器实例变得经济高效且易于管理。同样，软件定义存储 (SDS) 使得运行构成高度弹性存储系统的数十个系统，为许多客户端提供数百个卷/LUN 成为可行且可管理的。现在是将这两个系统结合起来的绝佳时机。

背景

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

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

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

Kubernetes 与传统存储

Kubernetes 支持使用现有的传统纵向扩展存储系统，例如 SAN 阵列。采用这种方式可能会导致一些挑战：

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

   在缺乏自动化的情况下，管理员必须预先猜测每个卷的存储需求，手动配置并将其暴露给 Kubernetes，然后不断监控实际需求与供应估计的匹配程度。这将无法扩展，并且几乎肯定会保证开发人员和运维人员的不满。

2. 另一种情况是，现有存储以某种方式与 Kubernetes 自动化配置相关联，但它并非旨在扩展到通常在 Kubernetes 上运行的存储消费者的数量。存储系统可能已针对涉及 hypervisor 的用例进行了优化，在 hypervisor 中，通常最终会提供数十个（在极少数情况下为数百个）可预测大小的卷作为数据存储。对于 Kubernetes，这可以并且很容易达到数百到数千个卷，因为它们通常在每个容器的基础上被消耗。大多数存储系统可能将卷的数量限制在一个级别，这不适合 Kubernetes 预期的并行性和消耗。

Kubernetes 与软件定义存储

将传统存储与 Kubernetes 一起使用充其量只是一个短期选择，用于桥接到下一个采购周期的时间。在这个阶段，您将进入充满希望的软件定义存储领域，该领域的系统在构建时就考虑到了规模和自动化。在这里，您会发现许多解决方案都带有“为容器做好准备”的标签。然而，许多解决方案并不适合容器，因为它们在底层有一个针对虚拟机而不是容器的遗留实现。

在开源领域，GlusterFS 是一个众所周知的项目，它在构建时就考虑到了规模，并且已经在世界各地的生产系统中运行多年。

Kubernetes 上的 GlusterFS

GlusterFS 不仅为 Kubernetes 上的工作负载提供存储，具有适当的动态配置，而且还与其他工作负载一起在 Kubernetes 之上运行。这就是 gluster-kubernetes 的意义所在——它将 GlusterFS 软件二进制文件放入容器中，并将它们作为 Kubernetes pod（容器的 Kubernetes 抽象）运行，这些 pod 可以访问集群节点全部或子集上的主机网络和存储，以提供文件、块甚至对象存储。这完全由 Kubernetes 控制平面控制。

以这种方式将 GlusterFS 与 Kubernetes 一起使用具有几个明显的优势。首先，存储——无论是否是软件定义的——当在 Kubernetes 之外运行时，始终是您必须随平台一起拖累的东西。存储是一个带有自己管理系统的系统，必须在部署 Kubernetes 的环境中得到支持，必须安装在其他系统上，并且有自己的安装程序、打包、可用性管理等等。

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

通过 Kubernetes 上的 GlusterFS，后者将接管在容器中调度您的 SDS 软件进程，并确保始终有足够的实例在运行，同时还为它们提供足够的网络、CPU 和磁盘资源。为此，GlusterFS 镜像已被制作出来，可以在 OCI 兼容的容器运行时中运行。

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

GlusterFS 可以在所有这三种类型以及所有公有云提供商上运行，并且在足够高的层（Linux 操作系统、TCP/IP 堆栈、LVM2、块设备）上进行了抽象，因此它几乎不关心表面之下实际是什么。

将 GlusterFS 放在 Kubernetes 之上使得事情变得更加容易：安装和配置过程 完全相同，无论您在哪里部署，因为它完全由 Kubernetes 抽象化。当这仅仅是启动新版本的容器镜像，以滚动方式更新现有集群的问题时，更新就变得轻而易举。

第三，尤其是在云提供商上，通过 Kubernetes 之上的 GlusterFS，无论底层平台看起来如何，您都可以依赖于通用的功能集。在云中，计算网络和存储资源实际上位于多个可用区中。这对于应用程序开发人员来说并不总是显而易见的。云存储，尤其是当它基于块设备时，通常不会跨这些可用区复制。

通过依赖于此，虽然 Kubernetes 灵活的调度会在可用区完全丢失的情况下在另一个区域中重新启动您的 pod，但您的云提供商存储不会随之移动，因此您的应用程序将毫无价值。

GlusterFS 集成的复制在可用区之间运行良好（支持高达 5 毫秒的往返时间，请注意，流行的云提供商可用区之间的平均延迟要低得多）。您可以指示 Kubernetes 上的 GlusterFS 在每个区域中至少运行一个 GlusterFS 容器实例，从而在每次写入操作时将数据的冗余副本分布在整个区域中。在这里，一个站点/区域的故障对于存储消费者是透明的，并且一旦恢复（再次，在 Kubernetes 调度的帮助下），自动自愈就会在后台开始。

最后，如前所述，您很可能尝试利用本地 SAN 存储供 Kubernetes 上的工作负载使用。GlusterFS 可以帮助您使它们为容器做好准备。GlusterFS 处理 Linux 主机上本地可用的存储，这些存储可以来自本地 SATA/SAS 接口以及光纤通道 LUN。当您将后者呈现给您的 Kubernetes 节点时，您就拥有了 Kubernetes 上 GlusterFS 所需的一切。

通过这种方式，GlusterFS 可以弥合这些存储系统与容器有效使用之间的差距。当然，最终使用本地存储时，可以实现理想的成本占用空间。

影响和注意事项

当然，这种方法不仅有优点，也有一些挑战。其中一些挑战将随着时间的推移而克服。

目前，Kubernetes 上 GlusterFS 的实现由 pod 组成，这些 pod 运行 glusterd 软件守护程序，该守护程序通过众所周知的网络端口提供其存储服务。这些端口既不能由安装程序配置，也不能由客户端配置，因此，在一个主机上运行的 pod 将独占这些端口——实际上使得在该系统上运行另一个 GlusterFS pod 成为不可能。

此外，到目前为止，Kubernetes 尚不具备 将块存储直接呈现给容器 的能力。然而，GlusterFS 需要直接访问块存储，即使在容器中运行时也是如此。因此，GlusterFS pod 目前需要作为具有提升权限的超级特权容器运行，以直接访问块设备。

此外，生产集群的最小节点数量为三个。可以有更多节点，但少于三个节点会将您的数据置于风险之中：如果您的数据只有一个副本，由单个节点上的单个 GlusterFS pod 持有，则会给您带来单点故障。两个节点上两个 pod 中的两个副本容易出现脑裂情况，因为 GlusterFS 需要（并将强制执行）仲裁以确保数据一致性。当您丢失两个 pod 中的一个时，您的数据将完好无损，但只读。——只有三个或更多 pod，您的数据才会复制三次，使其免受因中断而造成的丢失或不一致。因此，您至少需要三个 Kubernetes 节点才能开始。

除了纯粹的技术方面之外，当涉及到操作这样的平台时，这也将为运维带来新的视角：存储团队，或者一般的运维团队，不仅需要熟悉如何部署和运行 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 和红帽的 OpenShift 容器平台完美集成，无论 Kubernetes 在何处以及如何部署，都提供一致的功能集存储服务。它可以将您与不同环境中的所有不同实现和限制隔离开来，同时它自然地补充了 Kubernetes 已经提供的现有计算和网络服务。同时，它遵循 Kubernetes 鼓励的相同设计原则：基于分布在商品系统集群中的容器中的服务的软件定义横向扩展。

要了解更多信息，请参加在德克萨斯州奥斯汀举行的 12 月 6 日至 8 日举行的 KubeCon + CloudNativeCon 上的演讲 您有状态应用程序 - 如果 Kubernetes 也运行您的存储会怎样？。