Блог

Я пытаюсь использовать динамический поставщик локальных томов для k8s, принадлежащий Rancher, С несколькими экземплярами, каждый со своим собственным классом хранения, чтобы я мог предоставлять несколько типов локальных томов в зависимости от их производительности (например, ssd, hdd и т. Д.).

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

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

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

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

При использовании Pod локальных постоянных томов нет необходимости определять правила привязки узлов на уровне. Сходство с узлом может быть указано в PersistentVolume определении.

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

Нет, его нельзя указать на StorageClass уровне. Вы также не можете сделать a StorageClass доступным только для подмножества узлов.

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

Динамическая подготовка томов позволяет создавать тома хранилища по требованию. Без динамической подготовки администраторам кластера приходится вручную обращаться к своему поставщику облака или хранилища для создания новых томов хранилища, а затем создавать объекты PersistentVolume для их представления в Kubernetes. Функция динамической подготовки устраняет необходимость в предварительной подготовке хранилища администраторами кластера. Вместо этого он автоматически резервирует хранилище, когда его запрашивают пользователи.

Итак, рассматривая весь процесс предоставления тома с самого начала, он выглядит следующим образом:

Пользователь создает только PersistenVolumeClaim объект, в котором он указывает StorageClass :

 apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 10Gi
  storageClassName: local-storage ### 👈
  

и его можно использовать в Pod определении:

 apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim ### 👈
  

Таким образом, на практике в Pod определении вам нужно только указать правильный PVC . Здесь нет необходимости определять какие-либо правила привязки к узлу.

A Pod ссылается на a PVC , PVC затем ссылается на a StorageClass , StorageClass ссылается на provisioner то, что должно использоваться:

 apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: local-storage
provisioner: kubernetes.io/my-fancy-provisioner ### 👈
volumeBindingMode: WaitForFirstConsumer
  

Итак, в конце концов, задача a provisioner заключается в создании соответствующего PersistentVolume объекта. Это может выглядеть следующим образом:

 apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-pv
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete
  storageClassName: local-storage
  local:
    path: /var/tmp/test
  nodeAffinity: ### 👈
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - ssd-node ### 👈
  

Таким образом, a Pod , который использует myclaim PVC -> который ссылается на local-storage StorageClass -> который выбирает правильное хранилище provisioner , будет автоматически запланирован на узле, выбранном в PV определении, созданном этим поставщиком.