Могу ли я связать развертывание K8s с PVC по метке или селектору вместо имени?

У меня развёртывание в Kubernetes. В этом развертывании я могу указать утверждение постоянного тома следующим образом:

  volumes:
  - name: my-volume
    persistentVolumeClaim:
      claimName: my-claim

У меня есть диск (точнее, диск Azure) с большим количеством предварительно обработанных данных, которые я могу выставить в Kubernetes как PVC с именем my-claim. На следующем этапе я связываю его с развертыванием, как показано выше. Проблема с этим подходом в том, что я не могу масштабировать развертывание более чем на один модуль.

Как я могу масштабировать эту установку? Я попытался продублировать диск и создать его как второй PVC с другим именем. Это сработало, но теперь я не вижу способа сообщить развертыванию Kubernetes, что каждый модуль должен монтировать один из этих двух PVC.

Я надеюсь, что есть возможность пометить оба PVC общей меткой, а затем связать мое развертывание с этой меткой вместо имени PVC. Есть ли что-то подобное или мой подход совершенно неверен?

Спасибо!


azure kubernetes persistent-volumes kubernetes-pvc
person Stephan    schedule 20.11.2020    source источник
comment
Я обновил свой ответ решением, использующим две реплики StatefulSet - это должно сработать для вас.   -  person Jonas    schedule 21.11.2020
comment
Большое спасибо за развернутый ответ. Он дал много понимания основных концепций. Причина использования дисков Azure - это высокие требования к производительности, которым не могут соответствовать файлы Azure.   -  person Stephan    schedule 23.11.2020
comment
Добро пожаловать. Да, я согласен, Azure Disks - лучший вариант - более облачный. Также диск Utlra кажется наиболее производительным: docs.microsoft. ru / en-us / azure / aks / use-ultra-disks   -  person Jonas    schedule 23.11.2020

Ответы (1)


arrow_upward
2
arrow_downward

У меня есть диск (точнее, диск Azure) с большим количеством предварительно обработанных данных, которые я могу выставить в Kubernetes как PVC с именем my-Claim. На следующем этапе я связываю его с развертыванием, как показано выше. Проблема с этим подходом в том, что я не могу масштабировать развертывание более чем на один модуль.

Здесь вы используете PersistentVolumeClaim с режимом доступа ReadWriteOnce ( это единственный вариант для дисков Azure, см. ссылку на режим доступа)

Как я могу масштабировать эту установку? Я попытался продублировать диск и создать его как второй PVC с другим именем. Это сработало, но теперь я не вижу способа сообщить развертыванию Kubernetes, что каждый модуль должен монтировать один из этих двух PVC.

Здесь похоже, что вам нужен том с режимом доступа ReadOnlyMany - поэтому вам нужно подумать о системе хранения, поддерживающей этот режим доступа.

Я попытался продублировать диск и создать его как второй PVC с другим именем. Это сработало, но теперь я не вижу способа сообщить развертыванию Kubernetes, что каждый модуль должен монтировать один из этих двух PVC.

Это не работает для развертывания, поскольку template для каждого модуля идентичен . Но вы можете сделать это с помощью StatefulSet, объявив свой PVC с помощью volumeClaimTemplates - затем PVC для каждого модуля имеет уникальную, хорошо известную идентичность.

Пример части StatefulSet:

  volumeClaimTemplates:
  - metadata:
      name: my-pvc
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "my-storage-class"
      resources:
        requests:
          storage: 1Gi

Затем, если у вас есть две копии вашего StatefulSet, они предоставят вам PVC с именами my-pvc-0 и my-pvc-1, где номер называется порядковым. volumeClaimTemplate создает новый PVC, только если он не существует, поэтому, если вы создали PVC с правильными именами, будут использоваться существующие.

Альтернативные решения для хранения

Альтернативным хранилищем Azure Disk является Azure Files. Файлы Azure поддерживают режим доступа ReadWriteOnce, ReadOnlyMany и ReadWriteMany. См. Динамическое создание и использование постоянного тома с файлами Azure в Служба Azure Kubernetes (AKS).

Также могут быть другие альтернативы хранения, которые лучше подходят для вашего приложения.

person Jonas    schedule 20.11.2020