免责声明：这个问题非常具体地涉及所使用的平台和我们试图用它解决的用例。它还比较了我们目前至少在开发阶段使用的两种方法，并试图进行比较，但可能还没有完全理解。我正在就这个非常具体的话题寻求指导。。。
A)我们在DC/OS上运行一个Kafka集群作为Kafka任务，其中数据的持久性通过本地磁盘存储来维护，该磁盘存储与相应的Kafka代理实例在同一主机上提供。
B)我们正试图在Kubernetes上运行Kafka(通过Strimzi Operator)，特别是Azure Kubernete服务(AKS)，并且正在努力使用AKS中的StorageClasses获得可靠的数据持久性。我们尝试了三种可能性：
- (默认)Azure磁盘
- Azure文件
- emptyDir
我看到Azure磁盘的两个主要问题，因为我们能够设置Kafka Pod Affinity，使它们不会出现在同一维护区域/主机上，所以我们没有工具可以在Pod附近的任何地方绑定相应的PersistentVolume。没有什么能比得上NodeAffinity for AzureDisks。此外，Azure磁盘最终出现在与其对应的pod不同的另一台主机上也是很常见的，这可能会受到网络带宽的限制？
有了Azure File，我们不会因为维护区域暂时关闭而出现问题，但作为一种高延迟存储选项，它似乎不太适合，而且Kafka在保留时很难删除/更新文件。
因此，我最终使用了一个短暂的存储集群，这通常是不推荐的，但不会出现上述问题。The Volume"；生命；在pod附近，只要pod本身在任何节点上运行，它就可以使用。在维护案例中，pod和volume一起死亡。只要我能保持法定人数，我看不出这会在哪里引起问题。
- 在Azure磁盘按定义绑定节点时，是否存在类似podAfinity的PersistentVolumes
- 在Kubernetes上的Kafka集群中使用emptyDir进行持久化的主要缺点是什么
是否有类似podAfinity的持久卷作为Azure磁盘是否按定义绑定节点？
正如我所知，没有什么能比得上作为Azure磁盘的PersistentVolumes的podafinity。azure磁盘应该连接到节点，因此如果pod更改主机节点，则pod不能使用该磁盘上的卷。只有Azure文件共享是podAfinity。
在Kubernetes上的Kafka集群？
您可以查看emptyDir:
暂存空间，例如用于基于磁盘的合并排序
这是您使用AKS时最需要注意的事项。你需要计算磁盘空间，也许你需要将多个Azure磁盘连接到节点。
开始-我不确定你说的Azure磁盘最终在分配pod的节点之外的节点上是什么意思-根据我的理解，这应该是不可能的(为了完整性，你可以在具有AKS之外共享磁盘功能的VM上这样做，但据我所知，在撰写本文时，动态磁盘在AKS中不支持这一点)。如果您正在查看PVC上的volume.kubernetes.io/selected-node注释，我认为它不会在初始创建后更新。
您可以通过使用具有反关联性的statefulset来达到您想要的配置。考虑这个状态集。它创建了三个pod，它们必须位于不同的可用性区域。我将其部署到一个具有节点池(nodepool2)的AKS集群，每个AZ:有两个节点
❯ 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>
每个吊舱都根据模板创建了一个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
如您所见，对于值为westus2-3的failure-domain.beta.kubernetes.io/zone中的节点，该PV具有必需的nodeAffinity。这确保了拥有该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门户看到，支持pvpvc-bf6104e0-c05e-43d4-9ec5-fae425998f9d和PVCzonetest/demo-echo-0的托管磁盘kubernetes-dynamic-pvc-bf6104e0-c05e-43d4-9ec5-fae425998f9d被列为Managed by: aks-nodepool2-25997496-vmss_4，因此它已被删除并分配给pod运行的节点。
显示连接到节点4 的磁盘的门户屏幕截图
如果我删除节点，使我在AZ3中没有节点，我将无法启动podecho-1，因为它绑定到AZ3中的磁盘，无法连接到不在AZ 3中的节点。