在AKS上部署Weaviate时出现的问题(Azure Kubernetes服务)

Question

我正在尝试在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类。相反，我使用了默认的kubernetes类，它利用了Azure管理的磁盘。

有没有人有办法解决这个问题？谢谢!

Answer 1

我们已经更新了我们的文档，因为它们围绕etcd disaster recovery in the helm chart的主题并不完整。考虑到更新的文档，让我试着解释一下这里发生了什么：

默认情况下不需要nfs卷

默认情况下，Weaviate对其备份数据库使用持久卷。这些文件的存储类使用默认值，即不使用nfs。因此，当使用默认的values.yaml nfs 时，群集上不需要支持。

etcd容灾

在撰写本文时，Weaviate的存储后端之一是etcd。我们使用在Weaviate Chart as a subchart中引用的bitnami etcd chart。Etcd不能在节点定额(Source)故障中幸存下来。特别是在小型部署中(例如，3个或更少的etcd pod)，定期的Kubernetes维护很容易导致灾难性的etcd故障。为了解决这个问题，上面提到的来自Bitnami的图表包含了一个灾难恢复模式。

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

如果需要etcd灾难恢复，请部署nfs provisioner。

etcd灾难恢复功能which is part of the bitnami etcd helm chart需要快照卷的ReadWriteMany访问权限。建议使用Weaviate Helm Docs中概述的nfs provisioner。

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

灾难恢复是稳定生产设置的关键部分，这似乎有悖于直觉，但置备程序并未作为子图表包含在weaviate图表中。这有多个原因：

Weaviate mix of concerns：Weaviate图表安装Weaviate的目的是将所有影响隔离到单个名称空间。Kubernetes会在集群范围内进行可能不完全是obvious

• Multi-tenancy：的更改。我们不能假设您的nfs-provisioner集群只运行一个Weaviate实例，甚至只运行Weaviate实例。它可能是一个有多个租户的大型共享集群。在这种情况下，捆绑置备程序将导致安装多个置备程序，而群集可以且应该只有一个one

• Different生命周期导致循环依赖关系：如果置备程序与Weaviate捆绑在一起，则不可能删除Weaviate图表。这是因为删除Weaviate图表也会删除etcd子图表。后者删除用于快照的nfs卷。但是，如果捆绑程序是图表的一部分，则它可能已经在删除，从而导致群集无法删除nfs卷。

tl;dr:在不同的名称空间中部署provisioner一次，在不同的名称空间中部署任意数量的Weaviate实例。这避免了生命周期差异、多租户和循环依赖问题。