0

我正在 Kubernetes 之上构建一个平台，除其他要求外，它应该：

  • 与操作系统无关。任何具有健全内核和 cgroup 挂载的 Linux。
  • 通过利用集群节点磁盘提供持久存储。
  • 提供 ReadWriteMany 卷或实现共享存储的方法。
  • POD 不应绑定到特定节点（如本地持久卷）
  • 迁移 POD 时会自动重新附加卷（例如，由于节点耗尽或节点丢失情况）
  • 在存储级别提供数据复制
  • 不假设每个节点都有专用的原始块设备。

我通过对 k8s 组件和容器引擎使用静态二进制文件来解决第一点。再加上最小的主机工具，也是静态二进制文件。

我仍在寻找持久存储的解决方案。

到目前为止我评估/使用的内容：

所以问题是在使用集群节点磁盘时，对于 Kubernetes 持久存储，我还有什么其他选择。

4

3 回答 3

2

可以考虑以下选项

  1. wards 上的 kubernetes 版本 1.14.0 支持本地持久卷。您可以使用节点标签来使用本地 pv。您可能必须在 HA（主从）模式下运行有状态的工作负载，以便在节点故障时数据可用

  2. 您可以在其中一个集群节点上安装 nfs 服务器，并将其用作工作负载的存储。nfs 存储支持 ReadWriteMany。如果您在裸机上设置集群，这可能会很好

  3. Rook 也是您已经尝试过的好选择之一，但它还没有准备好生产。

在这三个中，第一个选项适合您的要求。想听听社区的任何其他选择。

于 2019-11-29T12:13:54.060 回答
0

根据截至目前（v1.16）的官方文档，K8S 在几种不同类型的卷上支持 WriteMany。

即这些是：cephfs，glusterfs和nfs

通常，所有这些都保留了卷的内容，并且仅在删除 Pod 时卸载卷。这意味着卷可以预先填充数据，并且可以在 Pod 之间“传递”数据。这些 FS 可以同时被多个 writer 挂载。

在这些 FS 中，glusterfs可以部署在每个 kubernetes 集群节点上（至少需要 3 个）。可以通过不同方式访问数据，其中一种是 NFS。

卷persistentVolumeClaim用于将PersistentVolume挂载到 Pod 中。PersistentVolumes 是用户在不知道特定云环境详细信息的情况下“声明”持久存储（例如 GCE PersistentDisk 或 iSCSI 卷）的一种方式 ReadWriteMany 支持以下类型的卷： - AzureFile - CephFS - Glusterfs - Quobyte - NFS - PortworxVolume

但这不是无法控制底层基础架构的选项。

卷 选项表示已安装的本地存储设备，例如磁盘、分区或目录local。本地卷只能用作静态创建的 PersistentVolume。缺点是如果一个节点变得不健康，那么本地卷也将变得不可访问，并且使用它的 Pod 将无法运行。

因此，目前没有适合所有开箱即用要求的解决方案。

于 2019-11-29T16:35:30.863 回答
0

您可以使用 OpenEBS Local PV，它可以为使用默认存储类的应用程序消耗整个磁盘openebs-device，您可以使用已安装的磁盘使用默认存储类共享多个应用程序openebs-hostpath。更多信息在 OpenEBS 文档User Guide部分中提供。这不需要 open-iscsi。如果您使用的是直接设备，那么使用 OpenEBS 节点磁盘管理器，将自动检测和消耗磁盘。为了满足 RWM 用例，您可以使用本地 PV 将此预置卷用作使用 NFS 预配器的多个应用程序的底层卷。在 OpenEBS 文档Stateful Application下一节中提到了相同的实现。

于 2019-12-05T17:20:06.337 回答