1

我正在尝试在 Azure Kubernetes 服务上部署 Weaviate。在 helm 部署期间遇到问题，我收到以下错误消息：

Multi-Attach error for volume "pvc-69db6155-4f28-11ea-b829-b2b3d6f12b6f" Volume is already exclusively attached to one node and can't be attached to another
Unable to mount volumes for pod "esvector-master-0_weaviate(20dafc44-4f58-11ea-b829-b2b3d6f12b6f)": timeout expired waiting for volumes to attach or mount for pod "weaviate"/"esvector-master-0". list of unmounted volumes=[esvector-master]. list of unattached volumes=[esvector-master default-token-ckf7v]

我在 values.yaml 中唯一更改的是存储类名称：

pvc:
  size: 2Gi
  storageClassName: default

由于 Azure 没有安装 NFS 类，因此我进行了此更改。相反，我使用了利用 Azure 托管磁盘的默认 kubernetes 类。

有谁知道如何解决这个问题？谢谢！

4

1 回答 1

1

我们更新了我们的文档，因为它们在 helm chart 中围绕 etcd 灾难恢复的主题并不完整。考虑到更新的文档，让我尝试解释这里发生了什么：

nfs默认情况下不需要卷

默认情况下，Weaviate 使用 Persistent Volumes 作为其后备数据库。这些存储类使用默认值，即 not nfs。因此，当使用默认值时，集群values.yaml不需要nfs支持。

etcd 灾难恢复

在撰写此答案时，Weaviate 的存储后端之一是etcd. 我们使用Wea​​viate 图表中引用的 bitnami etcd 图表作为子图表。Etcd 无法在法定数量的节点（源）失败后幸存下来。尤其是在小型部署中（例如 3 个或更少的 etcd pod），定期的 Kubernetes 维护很容易导致灾难性的 etcd 故障。为了解决这个问题，Bitnami 的上述图表包含了灾难恢复模式。

请注意，etcd.disasterRecovery.enabled 默认为false，但我们建议true在生产中将其设置为。

nfs如果需要 etcd 灾难恢复，请部署配置程序。

作为bitnami etcd helm 图表一部分的etcd 灾难恢复功能需要ReadWriteMany访问快照卷。建议使用Wea​​viate Helm Docsnfs中概述的配置器。

为什么nfs-provisioner不是 Weaviate 图表的一部分？

灾难恢复是稳定生产设置的关键部分，这似乎违反直觉，但供应商并未作为子图表包含在 weaviate 图表中。这有多种原因：

  • 综合考虑：Weaviate 图表安装 Weaviate 的目的是将所有效果隔离到单个命名空间。这nfs-provisioner使得集群范围内的变化可能并不完全明显
  • 多租户：我们不能假设您的 Kubernetes 集群只运行一个 Weaviate 实例，甚至只运行 Weaviate 实例。它可能是一个有多个租户的大型共享集群。在这种情况下，捆绑provisioner会导致安装多个provisioner，而集群可以并且应该只有一个provisioner
  • 不同的生命周期导致循环依赖：如果配置器与 Weaviate 捆绑在一起，则无法删除 Weaviate 图表。这是因为删除 Weaviate 图表也会删除etcd子图表。后者删除nfs用于快照的卷。但是，如果捆绑器是图表的一部分，它就会被删除，从而使集群无法删除nfs卷。

tl;dr：在不同的命名空间中部署一次供应商，在不同的命名空间中部署尽可能多的 Weaviate 实例。这避免了生命周期差异、多租户问题和循环依赖。

于 2020-03-03T11:03:04.437 回答