在AKS上部署Weaviate时出现的问题(Azure Kubernetes服务) [英] Issues while deploying Weaviate on AKS (Azure Kubernetes Service)

问题描述

我正在尝试在Azure Kubernetes服务上部署Weaviate.在掌舵部署过程中遇到问题，我收到以下错误消息:

I am trying to deploy Weaviate on Azure Kubernetes Service. During the helm deployment run into a problem where I get the following error message:

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中唯一更改的是存储类名称:

The only thing I changed in values.yaml is the Storage Class Name:

pvc:
  size: 2Gi
  storageClassName: default

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

I made this change as Azure does not have an NFS class installed. Instead I used the default kubernetes class which is levering Azure Managed disks.

有人对如何解决此问题有想法吗?谢谢！

Does anyone have an idea on how to solve this issue? Thanks!

推荐答案

我们已经更新了文档，因为围绕

We've updated our docs as they weren't complete around the topic of etcd disaster recovery in the helm chart. With the updated docs in mind, let me try to explain what's going on here:

默认情况下，Weaviate将持久卷用于其后备数据库.这些存储类别使用默认值，即不是nfs.因此，使用默认的values.yaml时，群集上不需要nfs支持.

By default Weaviate uses Persistent Volumes for its backing databases. The storage classes for those use the defaults, i.e. not nfs. Therefore when using the default values.yaml no nfs support is required on the cluster.

在编写此答案时，Weaviate的存储后端之一是etcd.我们使用在Weaviate图表中引用的 bitnami etcd图表 a href ="https://github.com/semi-technologies/weaviate-helm/blob/2ec040c3a84cc8aee392412dec28c1e88e2938a3/weaviate/requirements.yaml#L7-L11" rel ="nofollow noreferrer">作为子图表. Etcd无法承受一定数量的节点故障(源).特别是在小型部署(例如3个或更少的etcd容器)中，常规的Kubernetes维护很容易导致灾难性的etcd故障.为了解决这个问题，上面提到的Bitnami图表包含一个灾难恢复模式.

At the time of writing this answer, one of the storage backends for Weaviate is etcd. We use the bitnami etcd chart which is referenced in the Weaviate Chart as a subchart. Etcd does not survive a failure of a quorum of nodes (Source). Especially in a small deployment (e.g. 3 or fewer etcd pods), regular Kubernetes maintenance can easily lead to a disastrous etcd failure. To combat this, the above mentioned chart from Bitnami contains a disaster recovery mode.

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

etcd灾难恢复功能这是bitnami的一部分etcd helm chart 需要快照卷的ReadWriteMany访问权限.建议使用

The etcd disaster recovery feature which is part of the bitnami etcd helm chart requires ReadWriteMany access for the snapshot volumes. The recommendation is to use an nfs provisioner as outlined in the Weaviate Helm Docs.

灾难恢复是稳定生产设置的关键部分，这似乎是违反直觉的，但预配置程序未作为子图表包含在weaviate图表中.这有多种原因:

It might seem counter-intuitive that the disaster recovery is a crucial part for a stable production setup, yet the provisioner is not included in the weaviate chart as a sub-chart. This has multiple reasons:

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

• A mix of concerns: The Weaviate chart installs Weaviate with the goal to isolate all effects to a single namespace. The nfs-provisioner makes cluster wide-changes that might not be entirely obvious
• Multi-tenancy: We can make no assumption that your Kubernetes cluster runs only a single Weaviate instance or even only Weaviate instances. It might be a big shared cluster with multiple tenants. In this case bundling the provisioner would lead to the installation of multiple provisioners, when the cluster can and should have only a single one
• Different Lifecycles lead to circular dependencies: If the provisioner were bundled up with Weaviate it would become impossible to delete the Weaviate chart. This is because deleting the Weaviate chart, also deletes the etcd subchart. The latter removes the nfs volumes used for snapshotting. However, if the bundler was part of the chart it would already have been deleting, rendering the cluster unable to delete nfs volumes.

tl; dr:在不同的名称空间中部署一次配置程序，并在单独的名称空间中部署任意数量的Weaviate实例.这样可以避免生命周期差异，多租户问题和循环依赖问题.

tl;dr: Deploy the provisioner once in a different namespace, deploy as many Weaviate instances as you like in separate namespaces. This avoids lifecycle differences, issues with multi-tenancy and circular dependencies.

这篇关于在AKS上部署Weaviate时出现的问题(Azure Kubernetes服务)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！