Kubernetes持久化存储是个难题，解决方案有哪些？

虽然 Kubernetes 在许多方面非常有用，例如可伸缩性、可移植性和管理能力，但它不支持存储状态。几乎所有的生产应用程序都是有状态的，即需要某种外部存储。

像 Kubernetes 这样的容器编排 工具 正在彻底改变应用程序的开发和部署方式。随着微服务架构的兴起，以及基础架构与应用程序逻辑从开发人员的角度解耦，开发人员越来越关注构建软件和交付价值。

Kubernetes 对管理的物理机器进行抽象。使用 Kubernetes，你可以通过描述获取所需的内存总量和计算能力，而无需担心底层基础架构。

在管理 Docker 镜像时，Kubernetes 还让应用程序变得可移植。一旦使用 Kubernetes 开发容器化架构，它们就可以部署在任何地方 - 公有云、混合云、本地 - 无需对底层代码进行任何更改。

虽然 Kubernetes 在许多方面非常有用，例如可伸缩性、可移植性和管理能力，但它不支持存储状态。几乎所有的生产应用程序都是有状态的，即需要某种外部存储。

Kubernetes 的架构是不断变化的。容器的创建和销毁，取决于负载和开发人员的规范。容器组和容器可以自我修复和复制。从本质上讲，它们的生命周期是短暂的。

但是，持久化存储解决方案无法承受这种动态行为。持久化存储不能绑定到动态创建和销毁的规则上。

当有状态应用需要部署在另一个基础架构，可能是另一个云提供商、本地或混合模型上时，它们在可移植性方面面临挑战。持久化存储解决方案会绑定到特定的云提供商。

此外，云原生应用程序的存储版图不容易理解。Kubernetes 存储术语可能会造成混淆，因为许多术语都有复杂的含义和微妙的变化。此外，在做出决策之前，开发人员必须考虑许多选项，包括原生 Kubernetes、开源框架、托管或付费服务。

在下面的 CNCF 版图中可以看到列出的云原生存储解决方案：

首先想到的可能就是在 Kubernetes 中部署数据库：选择适合你需求的数据库解决方案，将其容器化并在本地磁盘上运行，然后将其作为另一个工作负载部署在集群中。但是，由于数据库的固有属性，这种方法不是特别好。

容器是基于无状态原则构建的。这使得容器很容易进行伸缩。由于不需要保存和迁移数据，通常来说，集群不需要处理很密集的磁盘读写操作。

使用数据库，需要保存状态。如果数据库以容器方式部署在集群上，不进行迁移或者频繁伸缩，那么实际的数据存储将起作用。理想情况下，将使用数据的容器与数据库位于同一个容器中。

这并不是说在容器中部署数据库是一个坏主意 - 在某些用例中，这种方法可能就足够了。在测试环境中，或者对于不需要生产级数据量的任务，由于所保存的数据规模较小，因此集群中的数据库可能是有意义的。

在生产中，开发人员通常依赖外部存储。

Kubernetes 如何与存储通信?它使用控制平面接口。这些接口将 Kubernetes 与外部存储相关联。这些与 Kubernetes 连接的外部存储解决方案称为卷插件。卷插件可以抽象存储并赋予存储可移植性。

以前，卷插件使用 Kubernetes 核心代码库构建、链接、编译和发布。这极大地限制了开发人员的灵活性，并带来了额外的维护成本。添加新的存储选项需要更改 Kubernetes 代码库。

通过引入 CSI 和 Flexvolume，可以在集群上部署卷插件，而无需更改代码库。

Kubernetes 原生和存储

Kubernetes 原生如何处理存储?Kubernetes 自身提供了一些管理存储的解决方案：临时选项、持久化存储卷、持久化存储卷声明、存储类和有状态副本集。这可能很混乱。

持久化存储卷(PV)是由管理员配置的存储单元。它们独立于任何一个容器组，使它们摆脱容器组的短暂生命周期。

另一方面，持久化存储卷声明(PVC)是对存储的请求，即 PVs。使用 PVC，可以将存储绑定到特定节点，使其可供该节点使用。

有两种处理存储的方法：静态和动态。

采用静态配置，管理员在实际请求之前，为他们认为可能需要的容器组提供 PVs，并且通过明确指定的 PVCs，将这些 PV 手动绑定到指定的容器组。

实际上，静态定义的 PV 与 Kubernetes 的可移植结构不兼容，因为正在使用的存储可能依赖于环境，例如 AWS EBS 或 GCE Persistent Disk。手动绑定需要更改 YAML 文件以指向特定供应商的存储解决方案。

在开发人员如何考虑资源方面，静态配置也违背了 Kubernetes 的思维方式：CPU 和内存未事先分配并绑定到容器组或容器。它们是动态授予的。

动态配置使用存储类完成。集群管理员无需事先手动创建 PV。他们改为创建多个存储配置文件，就像模板一样。当开发人员创建 PVC 时，根据请求的要求，在请求时创建其中一个模板，并将其附加到容器组。

这是对外部存储通常如何使用原生 Kubernetes 进行处理的一个宽泛的概述。但是，还有许多其他选择需要考虑。

CSI - 容器存储接口

在继续之前，我想介绍容器存储接口(CSI)。CSI 是由 CNCF 存储工作组创建的统一工作，旨在定义标准容器存储接口，使存储驱动程序能够在任何容器编排器上工作。

CSI 规范已经适用于 Kubernetes，并且在 Kubernetes 集群上有大量驱动程序插件可供部署。开发人员可以 Kubernetes 上使用 CSI 卷类型访问 CSI 兼容卷驱动程序公开的存储。

随着 CSI 的引入，存储可以被视为另一个工作负载容器化，并在 Kubernetes 集群上部署。

开源项目

围绕云原生技术的工具和项目大幅增加。作为生产环境中最突出的问题之一，有相当多的开源项目致力于解决云原生架构上的存储问题。

关于存储的最受欢迎的项目是 Ceph 和 Rook。

Ceph 是一个动态管理，可水平扩展的分布式存储集群。Ceph 提供了对存储资源的逻辑抽象。它被设计为没有单点故障，可自我管理并基于软件。Ceph 为同一存储集群同时提供块、对象和文件系统接口。

Ceph 的架构很复杂，有许多底层技术，如 RADOS、librados、RADOSGW、RDB、CRUSH 算法，以及监视器、OSD 和 MDS 等组件。Ceph 是一个分布式存储集群，不需要深入研究其体架构，关键在于，它是一个分布式存储集群，可以更轻松地实现可扩展性，在不牺牲性能的情况下消除单点故障，并提供了对对象、块和文件的访问的统一存储。

当然，Ceph 已经适应了云原生环境。可以通过多种方式部署 Ceph 集群，例如使用 Ansible。可以从 Kubernetes 集群中使用 CSI 和 PVC 接口访问部署的 Ceph 集群。

Ceph 架构

另一个有趣且颇受欢迎的项目是 Rook，一个旨在融合 Kubernetes 和 Ceph 的工具 - 将计算和存储集中在一个集群中。

Rook 是一个云原生存储编排器。它扩展了 Kubernetes。Rook 本质上允许将 Ceph 放入容器中，并提供集群管理逻辑，以便在 Kubernetes 上可靠地运行 Ceph。Rook 自动化部署、引导、配置、扩展、负载均衡，即集群管理员需要做的工作。

Rook 允许通过 yaml 文件部署 Ceph 集群，就像 Kubernetes 一样。此文件用作集群管理员在集群中所需内容的高级声明。Rook 整合集群，并开始积极监控。Rook 充当运维人员或控制器，确保 yaml 文件中声明的期望状态得到保证。Rook 在一个协调循环中运行，观察状态并根据检测到的差异采取行动。

Rook 没有自己的持久化状态，也不需要管理。它的确是根据 Kubernetes 的原则构建的。

Rook 架构

Rook 将 Ceph 和 Kubernetes 结合在一起，是最受欢迎的云原生存储解决方案之一，在 Github 上拥有近 4000 颗星，1630 万 下载量和 100 多名贡献者。

作为被 CNCF 接受的首个存储项目，Rook 近期已进入孵化阶段。

对于应用程序中的任何问题，确定需求，设计系统和选择相应工具非常重要。云原生环境中的存储也不例外。虽然问题非常复杂，但仍有许多工具和方法。随着云原生世界的发展，无疑也会出现新的解决方案。

查看英文原文：https://softwareengineeringdaily.com/2019/01/11/why-is-storage-on-kubernetes-is-so-hard/