4

如何将 100GB 持久卷磁盘附加到 AKS Kubernetes 群集中的每个节点？

我们使用 AKS 在 Azure 上使用 Kubernetes。

我们有一个场景，我们需要将持久卷附加到 AKS 群集中的每个节点。我们在集群中的每个节点上运行 1 个 Docker 容器。

动态附加卷的原因是增加每个 Docker 容器完成其工作所需的可用 IOPS 和可用存储量。

在每个 Docker 容器内运行的程序处理非常大的输入数据文件 (10GB) 并写出更大的输出文件 (50GB)。

我们可以挂载 Azure 文件共享，但 Azure 文件共享被限制为 60MB/ps，这对我们来说太慢了，无法处理这么多原始数据。在 Docker 映像中运行的程序完成后，会将输出文件 (50GB) 移动到 Blob 存储。所有容器的所有输出文件的总和可能超过 1TB。

我在想，如果我们可以将持久卷附加到每个节点，我们就可以增加可用磁盘空间以及 IOPS，而无需使用高 vCPU/RAM 虚拟机配置（即 DS14_v2）。我们的程序比 CPU 更密集 I/O。

Pod 中运行的所有 Docker 镜像都完全相同，它们从队列中读取消息，告诉它要处理的特定输入文件。

我按照文档创建了一个 StorageClass、Persistent Volume Claims 和 Persistent Volume，并针对 1 个 POD 运行它。https://docs.microsoft.com/en-us/azure/aks/azure-disks-dynamic-pv

但是，当我创建部署并将 Pod 数量从 1 扩展到 2 时，我收到错误消息（在生产中，我们会根据需要扩展到尽可能多的节点 ~100）

卷“pvc-784496e4-869d-11e8-8984-0a58ac1f1e06”的多附加错误卷已被 Pod 使用 pv-deployment-67fd8b7b95-fjn2n

我意识到 Azure 磁盘只能附加到 SingleNode (ReadWriteOnce) 但是我不确定在加载 Kubernetes 集群并开始工作时如何创建多个磁盘并将它们附加到每个节点。

持久卷声明： 

apiVersion: v1
kind: PersistentVolumeClaim
    metadata:
    name: azure-managed-disk
spec:
    accessModes:
    - ReadWriteOnce
    storageClassName: managed-premium
    resources:
    requests:
    storage: 100Gi

这是我的部署：

apiVersion: apps/v1
kind: Deployment
    metadata:
    name: pv-deployment
    labels:
    app: nginx
    spec:
    replicas: 1
    selector:
    matchLabels:
    app: nginx
    template:
    metadata:
    labels:
        app: nginx
    spec:
      containers:
        - name: myfrontend
        image: nginx
        volumeMounts:
        - name: volume
        mountPath: /mnt/azure
        resources: 
          limits:
            cpu: ".7"
            memory: "2.5G"
          requests:
            cpu: ".7"
            memory: "2.5G"      
         volumes:
         - name: volume
         persistentVolumeClaim:
          claimName: azure-managed-disk

如果我知道我要扩展到 100 个节点，我是否必须创建一个包含 100 个部署的 .yaml 文件并明确让每个部署使用特定的卷声明？

例如，在我的卷声明中，我将拥有 azure-claim-01、azure-claim-02 等，并且在每个部署中，我必须对每个命名的卷声明进行声明

volumes:
    - name: volume
      persistentVolumeClaim:
        claimName: azure-claim-01

我无法完全理解如何动态地完成所有这些工作？

你能推荐一个更好的方法来达到预期的结果吗？

4

2 回答 2

3

您应该使用StatefulSet和volumeClaimTemplates配置，如下所示：

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 4
  updateStrategy:
    type: RollingUpdate
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: k8s.gcr.io/nginx-slim:0.8
          ports:
           - containerPort: 80
          volumeMounts:
            - name: persistent-storage
              mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: persistent-storage
      annotations:
        volume.beta.kubernetes.io/storage-class: hdd
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 2Gi
---
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: hdd
provisioner: kubernetes.io/azure-disk
parameters:
  skuname: Standard_LRS
  kind: managed
  cachingMode: ReadOnly

您将获得每个节点的持久卷：

kubectl get pv

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS    CLAIM                              STORAGECLASS   REASON
  AGE
pvc-0e651011-7647-11e9-bbf5-c6ab19063099   2Gi        RWO            Delete           Bound     default/persistent-storage-web-0   hdd
  51m
pvc-17181607-7648-11e9-bbf5-c6ab19063099   2Gi        RWO            Delete           Bound     default/persistent-storage-web-1   hdd
  49m
pvc-4d488893-7648-11e9-bbf5-c6ab19063099   2Gi        RWO            Delete           Bound     default/persistent-storage-web-2   hdd
  48m
pvc-6aff2a4d-7648-11e9-bbf5-c6ab19063099   2Gi        RWO            Delete           Bound     default/persistent-storage-web-3   hdd
  47m

每个节点都会创建专用的持久卷声明：

kubectl get pvc

NAME                       STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistent-storage-web-0   Bound     pvc-0e651011-7647-11e9-bbf5-c6ab19063099   2Gi        RWO            hdd            55m
persistent-storage-web-1   Bound     pvc-17181607-7648-11e9-bbf5-c6ab19063099   2Gi        RWO            hdd            48m
persistent-storage-web-2   Bound     pvc-4d488893-7648-11e9-bbf5-c6ab19063099   2Gi        RWO            hdd            46m
persistent-storage-web-3   Bound     pvc-6aff2a4d-7648-11e9-bbf5-c6ab19063099   2Gi        RWO            hdd            45m
于 2019-05-14T13:53:50.160 回答
1

我会考虑使用 DaemonSet。这将允许您的 pod 仅在每个节点上运行，因此 ReadWriteOnce 将生效。限制是，您不能将应用程序扩展超过您拥有的节点数。

于 2018-07-14T01:48:06.663 回答