Блог

В настоящее время я настраиваю кластер Kubernetes, но я заметил, что классы хранения по умолчанию не определены.

 u@n:~$ kubectl get sc                                                                         
No resources found in default namespace.
 

При чтении документов существует множество примеров классов хранения, используемых при развертывании кластера на облачных провайдерах, но не на собственном хостинге. Какой класс хранения мне нужно использовать в моем случае?

Если при самостоятельном размещении вы также имеете в виду, что используете кластер Kubernetes из чистого металла (он же, вы установили Kubernetes на некоторых машинах), то вам, вероятно, потребуется предоставить собственное решение для хранения (например, вам нужно было предоставить сетевой плагин и контроллер входа).

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

Для некоторых приложений (таких как Kafka, ElasticSearch, базы данных с несколькими основными базами данных, такие как galera и т. Д.) Может быть нормально использовать локальное хранилище, Что означает, что данные доступны непосредственно по пути, проложенному от узла.. и только на этом конкретном узле.

Наличие данных только на определенном узле означает, что модуль, которому нужны эти данные (он же, для которого требуется ПВХ, ограниченный этим путем с помощью PV), должен работать на этом единственном узле и не может работать ни на каком другом.. это означает, что он вообще не устойчив к сбоям.

Но, как я уже сказал, это может быть нормально, если приложение состоит из более чем одного модуля и может выжить, если большинство модулей все еще запущено и запущено.

https://kubernetes.io/blog/2019/04/04/kubernetes-1.14-local-persistent-volumes-ga/

Другой вариант-пойти с Ладьей (который является оператором хранилища) и с помощью Ceph вы могли бы обеспечить свою собственную инфраструктуру хранения HA поверх кластера Kubernetes.

В основном вам нужно предоставить пустые диски и ресурсы для запуска инфраструктуры Ceph поверх вашего кластера, и у вас будет доступный класс хранения блоков Ceph (и многое другое), что означает, что тома устойчивы к сбоям узлов (в зависимости от того, сколько узлов и дисков доступно для Ceph, конечно), и это может быть запрошено с любого узла.

Это сложная инфраструктура для размещения в кластере, но она действительно стабильна и может быть приемлемым вариантом для нетестовых кластеров.

https://rook.io/

Существует множество других опций и продуктов, хороший список в документации, который может помочь вам решить, что вы хотите использовать, исходя из ваших потребностей: https://kubernetes.io/docs/concepts/storage/storage-classes/

Вам нужно создать объект StorageClass —

 apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
reclaimPolicy: Retain
allowVolumeExpansion: true
mountOptions:
  - debug
volumeBindingMode: WaitForFirstConsumer
 

Значение поставщика определит, какой плагин тома используется для предоставления постоянных томов. В данном случае это AWS EBS. Вот список поставщиков.

Значение параметра—>тип определяет используемый тип тома. В случае типов томов AWS EBS тип тома по умолчанию-gp2.

Вы можете получить более подробную информацию о классах хранения в документе Kubernetes.

В общем, вы можете начать с документации Kubernetes. Здесь вы можете найти концепцию классов хранения. У каждого класса хранилища есть поставщик, который определяет, какой плагин тома используется для подготовки PVS. Это поле должно быть указано. локальные тома могут вам помочь. Посмотрите на пример:

 apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer
 

Локальные тома в настоящее время не поддерживают динамическую подготовку, однако класс хранилища все равно следует создать, чтобы отложить привязку тома до планирования Pod. Это задается WaitForFirstConsumer режимом привязки тома.

Задержка привязки тома позволяет планировщику учитывать все ограничения по расписанию модуля при выборе подходящего персистентного тома для требования персистентного тома.

Если вы ищете полное руководство по настройке хранилища для кластера из чистого металла, вы можете найти его здесь. Как я уже упоминал ранее, локальные тома в настоящее время не поддерживают динамическую подготовку. Однако это может быть обходным решением, если вы используете сервер NFS. Посмотрите на это руководство.