AKS 持久卷关联？

如何解决AKS 持久卷关联？

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

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

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

（默认）Azure 磁盘
Azure 文件
emptyDir

我看到 Azure Disk 有两个主要问题，因为我们能够以一种方式设置 Kafka Pod Affinity，它们最终不会出现在同一个维护区域/主机上，我们没有工具可以将相应的 PersistentVolume 绑定到附近的任何地方豆荚。 AzureDisks 没有像 NodeAffinity 这样的东西。此外，Azure 磁盘最终位于与其对应的 pod 不同的另一台主机上也很常见，这可能会受到网络带宽的限制？

使用 Azure File 我们没有问题，因为维护区暂时关闭，但作为高延迟存储选项，它似乎不太合适，而且 Kafka 也难以删除/更新文件保留。

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

有没有像 PersistentVolumes 的 podAffinity 之类的东西，因为 Azure 磁盘是每个定义节点绑定的？
在 Kubernetes 上的 Kafka 集群中使用 emptyDir 进行持久化的主要缺点是什么？

解决方法

是否有类似 podAffinity for PersistentVolumes as Azure-Disk 是否根据定义节点绑定？

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

使用emptyDir 持久化的主要缺点是什么？ Kubernetes 上的 Kafka 集群？

你可以看看emptyDir：

临时空间，例如用于基于磁盘的归并排序

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

开始 - 我不确定你的意思是说 Azure 磁盘最终出现在分配 pod 的节点之外的节点上 - 根据我的理解，这应该是不可能的（为了完整性，你可以在在 AKS 之外具有 shared disks 功能的 VM，但据我所知，在撰写本文时，AKS 不支持动态磁盘）。如果您正在查看 PVC 上的 volume.kubernetes.io/selected-node 注释，我认为它不会在初始创建后更新。

您可以通过使用具有反关联性的 statefulset 来获得您正在寻找的配置。考虑this statefulset。它创建了三个 Pod，它们必须位于不同的可用区中。我正在将它部署到一个带有节点池 (nodepool2) 的 AKS 集群，每个可用区有两个节点：

❯ kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{","}{.metadata.labels.topology\.kubernetes\.io\/zone}{"\n"}{end}'
aks-nodepool1-25997496-vmss000000,0
aks-nodepool2-25997496-vmss000000,westus2-1
aks-nodepool2-25997496-vmss000001,westus2-2
aks-nodepool2-25997496-vmss000002,westus2-3
aks-nodepool2-25997496-vmss000003,westus2-1
aks-nodepool2-25997496-vmss000004,westus2-2
aks-nodepool2-25997496-vmss000005,westus2-3

一旦 statefulset 被部署并启动，你可以看到每个 pod 都被分配到 nodepool2 节点之一：

❯ kubectl get pods -o wide
NAME     READY   STATUS    RESTARTS   AGE     IP             NODE                                NOMINATED NODE   READINESS GATES
echo-0   1/1     Running   0          3m42s   10.48.36.102   aks-nodepool2-25997496-vmss000001   <none>           <none>
echo-1   1/1     Running   0          3m19s   10.48.36.135   aks-nodepool2-25997496-vmss000002   <none>           <none>
echo-2   1/1     Running   0          2m55s   10.48.36.72    aks-nodepool2-25997496-vmss000000   <none>           <none>

每个 pod 根据模板创建一个 PVC：

❯ kubectl get pvc
NAME          STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      AGE
demo-echo-0   Bound    pvc-bf6104e0-c05e-43d4-9ec5-fae425998f9d   1Gi        RWO            managed-premium   25m
demo-echo-1   Bound    pvc-9d9fbd5f-617a-4582-abc3-ca34b1b178e4   1Gi        RWO            managed-premium   25m
demo-echo-2   Bound    pvc-d914a745-688f-493b-9b82-21598d4335ca   1Gi        RWO            managed-premium   24m

让我们看看其中一个创建的 PV：

apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    pv.kubernetes.io/bound-by-controller: "yes"
    pv.kubernetes.io/provisioned-by: kubernetes.io/azure-disk
    volumehelper.VolumeDynamicallyCreatedByKey: azure-disk-dynamic-provisioner
  creationTimestamp: "2021-04-05T14:08:12Z"
  finalizers:
  - kubernetes.io/pv-protection
  labels:
    failure-domain.beta.kubernetes.io/region: westus2
    failure-domain.beta.kubernetes.io/zone: westus2-3
  name: pvc-9d9fbd5f-617a-4582-abc3-ca34b1b178e4
  resourceVersion: "19275047"
  uid: 945ad69a-92cc-4d8d-96f4-bdf0b80f9965
spec:
  accessModes:
  - ReadWriteOnce
  azureDisk:
    cachingMode: ReadOnly
    diskName: kubernetes-dynamic-pvc-9d9fbd5f-617a-4582-abc3-ca34b1b178e4
    diskURI: /subscriptions/02a062c5-366a-4984-9788-d9241055dda2/resourceGroups/rg-sandbox-aks-mc-sandbox0-westus2/providers/Microsoft.Compute/disks/kubernetes-dynamic-pvc-9d9fbd5f-617a-4582-abc3-ca34b1b178e4
    fsType: ""
    kind: Managed
    readOnly: false
  capacity:
    storage: 1Gi
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: demo-echo-1
    namespace: zonetest
    resourceVersion: "19275017"
    uid: 9d9fbd5f-617a-4582-abc3-ca34b1b178e4
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: failure-domain.beta.kubernetes.io/region
          operator: In
          values:
          - westus2
        - key: failure-domain.beta.kubernetes.io/zone
          operator: In
          values:
          - westus2-3
  persistentVolumeReclaimPolicy: Delete
  storageClassName: managed-premium
  volumeMode: Filesystem
status:
  phase: Bound

如您所见，对于 nodeAffinity 中的节点，该 PV 具有必需的 failure-domain.beta.kubernetes.io/zone，值为 westus2-3。这确保拥有该 PV 的 pod 只会被放置在 westus2-3 中的节点上，并且该 PV 将在 pod 启动时绑定到运行磁盘的节点。

此时，我删除了所有 Pod 以将它们放在其他节点上：

❯ kubectl get pods -o wide
NAME     READY   STATUS    RESTARTS   AGE     IP             NODE                                NOMINATED NODE   READINESS GATES
echo-0   1/1     Running   0          4m4s    10.48.36.168   aks-nodepool2-25997496-vmss000004   <none>           <none>
echo-1   1/1     Running   0          3m30s   10.48.36.202   aks-nodepool2-25997496-vmss000005   <none>           <none>
echo-2   1/1     Running   0          2m56s   10.48.36.42    aks-nodepool2-25997496-vmss000003   <none>           <none>

无法通过 Kubernetes 看到它，但您可以通过 Azure 门户看到托管磁盘 kubernetes-dynamic-pvc-bf6104e0-c05e-43d4-9ec5-fae425998f9d，它支持 pv pvc-bf6104e0-c05e-43d4-9ec5-fae425998f9d，支持 PVC zonetest/demo-echo-0，被列为Managed by: aks-nodepool2-25997496-vmss_4，因此它已被删除并分配给运行 pod 的节点。

Portal screenshot showing disk attached to node 4

如果我要删除节点，使我在 AZ 3 中没有节点，我将无法启动 pod echo-1，因为它绑定到 AZ 3 中的磁盘，不能附加到不在 AZ 3 中的节点。

如何解决AKS 持久卷关联？

解决方法

相关推荐