时间戳

首页 > 解决方案 > AKS 持久卷关联性？

azure - AKS 持久卷关联性？

问题描述

免责声明：这个问题是关于使用的平台和我们试图用它解决的用例的非常具体的问题。它还比较了我们目前至少在开发阶段使用并尝试比较的两种方法，但可能还没有完全理解。我正在就这个非常具体的主题寻求指导......

A)我们在 DC/OS 上将 Kafka 集群作为 Kafka 任务运行，其中数据的持久性通过本地磁盘存储来维护，该磁盘存储在与相应的 kafka 代理实例相同的主机上提供。

B)我们正在尝试在 Kubernetes 上运行 Kafka（通过 Strimzi Operator），特别是 Azure Kubernetes Service (AKS)，并且正在努力使用您在 AKS 中获得的 StorageClasses 获得可靠的数据持久性。我们尝试了三种可能性：

  1. （默认）Azure 磁盘
  2. 天蓝色文件
  3. 空目录

我发现 Azure Disk 存在两个主要问题，因为我们能够设置 Kafka Pod 关联性，使其最终不会位于同一维护区域/主机上，因此我们无法在 Pod 附近的任何地方绑定相应的 PersistentVolume。AzureDisks 没有像 NodeAffinity 这样的东西。此外，Azure 磁盘最终位于与其相应 pod 不同的另一台主机上的情况也很常见，那么这可能会受到网络带宽的限制？

使用 Azure 文件，我们不会因为维护区域暂时关闭而出现问题，但作为一种高延迟存储选项，它似乎不太合适，而且 Kafka 在保留时删除/更新文件也有麻烦。

所以我最终使用了一个通常不推荐但不会出现上述问题的临时存储集群。卷“存在”在 pod 附近，只要 pod 本身在任何节点上运行，它就可以使用它。在维护案例中，pod 和 volume 一起死掉。只要我能够维持法定人数，我看不出这可能会导致问题。

标签： azureapache-kafkaazure-akskubernetes-podpersistent-volumes

解决方案

由于 Azure-Disk 是每个定义节点绑定的，因此 PersistentVolumes 是否有类似 podAffinity 的东西？

据我所知，PersistentVolumes 没有像 Azure-Disk 这样的 podaffinity。azure 磁盘应附加到节点，因此如果 pod 更改主机节点，则 pod 无法使用该磁盘上的卷。只有 Azure 文件共享是 podAffinity。

在 Kubernetes 上的 Kafka 集群中使用 emptyDir 进行持久性的主要缺点是什么？

你可以看看emptyDir：

暂存空间，例如用于基于磁盘的合并排序

这是您在使用 AKS 时最需要注意的事情。您需要计算磁盘空间，也许您需要将多个 Azure 磁盘附加到节点。

推荐阅读