Модуль sds-local-volume: FAQ

Когда следует использовать LVM, а когда LVMThin?

• LVM проще и обладает высокой производительностью, сравнимой с производительностью накопителя;
• LVMThin позволяет использовать overprovisioning, но производительность ниже, чем у LVM.

Как назначить StorageClass по умолчанию?

Добавьте аннотацию storageclass.kubernetes.io/is-default-class: "true" в соответствующий ресурс StorageClass:

1kubectl annotate storageclasses.storage.k8s.io <storageClassName> storageclass.kubernetes.io/is-default-class=true

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

Узлы, которые будут задействованы модулем, определяются специальными метками, указанными в поле nodeSelector в настройках модуля.

Для отображения и редактирования настроек модуля, можно выполнить команду:

1kubectl edit mc sds-local-volume

Примерный вывод команды:

1apiVersion: deckhouse.io/v1alpha1
2kind: ModuleConfig
3metadata:
4  name: sds-local-volume
5spec:
6  enabled: true
7  settings:
8    dataNodes:
9      nodeSelector:
10        my-custom-label-key: my-custom-label-value
11status:
12  message: ""
13  version: "1"

Для отображения существующих меток, указанных в поле nodeSelector, можно выполнить команду:

1kubectl get mc sds-local-volume -o=jsonpath={.spec.settings.dataNodes.nodeSelector}

Примерный вывод команды:

1nodeSelector:
2  my-custom-label-key: my-custom-label-value

Узлы, метки которых включают в себя набор, указанный в настройках, выбираются модулем как целевые для использования. Соответственно, изменяя поле nodeSelector Вы можете влиять на список узлов, которые будут использованы модулем.

После добавление меток на узлах должны быть запущены pod-ы sds-local-volume-csi-node. Проверить их наличие можно командой:

1 kubectl -n d8-sds-local-volume get pod -owide

Почему не удается создать PVC на выбранном узле с помощью модуля?

Пожалуйста, проверьте, что на выбранном узле работает pod sds-local-volume-csi-node.

1kubectl -n d8-sds-local-volume get po -owide

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

Я хочу вывести узел из-под управления модуля, что делать?

Для вывода узла из-под управления модуля необходимо убрать метки, указанные в поле nodeSelector в настройках модуля sds-local-volume.

Проверить наличие существующих меток в nodeSelector можно командой:

1kubectl get mc sds-local-volume -o=jsonpath={.spec.settings.dataNodes.nodeSelector}

Примерный вывод команды:

1nodeSelector:
2  my-custom-label-key: my-custom-label-value

Снимите указанные в nodeSelector метки с желаемых узлов.

1kubectl label node %node-name% %label-from-selector%-

В результате pod sds-local-volume-csi-node должен быть удален с желаемого узла. Для проверки состояния можно выполнить команду:

1kubectl -n d8-sds-local-volume get po -owide

Если pod sds-local-volume-csi-node после удаления метки nodeSelector все же остался на узле, пожалуйста, убедитесь, что указанные в конфиге d8-sds-local-volume-controller-config в nodeSelector метки действительно успешно снялись с выбранного узла. Проверить это можно командой:

1kubectl get node %node-name% --show-labels

Если метки из nodeSelector не присутствуют на узле, то убедитесь, что данному узлу не принадлежат LVMVolumeGroup ресурсы, использующиеся LocalStorageClass ресурсами. Подробнее об этой проверке можно прочитать здесь.

Как проверить, имеются ли зависимые ресурсы LVMVolumeGroup на узле?

Для проверки таковых ресурсов необходимо выполнить следующие шаги:

1. Отобразить имеющиеся LocalStorageClass ресурсы

   1kubectl get lsc
   

2. Проверить у каждого из них список используемых LVMVolumeGroup ресурсов

   Вы можете сразу отобразить содержимое всех LocalStorageClass ресурсов, выполнив команду:

   1kubectl get lsc -oyaml
   

   1kubectl get lsc %lsc-name% -oyaml
   

   Примерный вид LocalStorageClass

   1apiVersion: v1
   2items:
   3- apiVersion: storage.deckhouse.io/v1alpha1
   4  kind: LocalStorageClass
   5  metadata:
   6    finalizers:
   7    - localstorageclass.storage.deckhouse.io
   8    name: test-sc
   9  spec:
   10    lvm:
   11      lvmVolumeGroups:
   12      - name: test-vg
   13      type: Thick
   14    reclaimPolicy: Delete
   15    volumeBindingMode: WaitForFirstConsumer
   16  status:
   17    phase: Created
   18kind: List
   

   Обратите внимание на поле spec.lvm.lvmVolumeGroups - именно в нем указаны используемые LVMVolumeGroup ресурсы.

3. Отобразите список существующих LVMVolumeGroup ресурсов

   1kubectl get lvg
   

   Примерный вывод LVMVolumeGroup ресурсов:

   1NAME              HEALTH        NODE                         SIZE       ALLOCATED SIZE   VG        AGE
   2lvg-on-worker-0   Operational   node-worker-0   40956Mi    0                test-vg   15d
   3lvg-on-worker-1   Operational   node-worker-1   61436Mi    0                test-vg   15d
   4lvg-on-worker-2   Operational   node-worker-2   122876Mi   0                test-vg   15d
   5lvg-on-worker-3   Operational   node-worker-3   307196Mi   0                test-vg   15d
   6lvg-on-worker-4   Operational   node-worker-4   307196Mi   0                test-vg   15d
   7lvg-on-worker-5   Operational   node-worker-5   204796Mi   0                test-vg   15d
   

4. Проверьте, что на узле, который вы собираетесь вывести из-под управления модуля, не присутствует какой-либо LVMVolumeGroup ресурс, используемый в LocalStorageClass ресурсах.

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

Я убрал метки с узла, но pod sds-local-volume-csi-node остался. Почему так произошло?

Вероятнее всего, на узле присутствуют LVMVolumeGroup ресурсы, которые используются в одном из LocalStorageClass ресурсов.

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

Процесс проверки на наличие вышеуказанных ресурсов описан здесь.

Служебные pod-ы компонентов sds-local-volume не создаются на нужном мне узле. Почему?

С высокой вероятностью проблемы связаны с метками на узле.

Узлы, которые будут задействованы модулем, определяются специальными метками, указанными в поле nodeSelector в настройках модуля.

Для отображения существующих меток, указанных в поле nodeSelector, можно выполнить команду:

1kubectl get mc sds-local-volume -o=jsonpath={.spec.settings.dataNodes.nodeSelector}

Примерный вывод команды:

1nodeSelector:
2  my-custom-label-key: my-custom-label-value

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

Также Вы можете дополнительно проверить селекторы, которые используются модулем в конфиге секрета d8-sds-local-volume-controller-config в пространстве имен d8-sds-local-volume.

1kubectl -n d8-sds-local-volume get secret d8-sds-local-volume-controller-config  -o jsonpath='{.data.config}' | base64 --decode

Примерный вывод команды:

1nodeSelector:
2  kubernetes.io/os: linux
3  my-custom-label-key: my-custom-label-value

В выводе данной команды должны быть указаны все метки из настроек модуля data.nodeSelector, а также kubernetes.io/os: linux.

Проверьте метки на нужном вам узле:

1kubectl get node %node-name% --show-labels

При необходимости добавьте недостающие метки на желаемый узел:

1kubectl label node %node-name% my-custom-label-key=my-custom-label-value

Если метки присутствуют, необходимо проверить наличие метки storage.deckhouse.io/sds-local-volume-node= на узле. Если метка отсутствует, следует проверить работает ли sds-local-volume-controller, и в случае его работоспособности, проверить логи:

1kubectl -n d8-sds-local-volume get po -l app=sds-local-volume-controller
2kubectl -n d8-sds-local-volume logs -l app=sds-local-volume-controller

Как переместить данные между PVC?

Скопируйте следующий скрипт в файл migrate.sh на любом master узле. Использование: migrate.sh NAMESPACE SOURCE_PVC_NAME DESTINATION_PVC_NAME

1#!/bin/bash
2
3ns=$1
4src=$2
5dst=$3
6
7if [[ -z $3 ]]; then
8  echo "You must give as args: namespace source_pvc_name destination_pvc_name"
9  exit 1
10fi
11
12echo "Creating job yaml"
13cat > migrate-job.yaml << EOF
14apiVersion: batch/v1
15kind: Job
16metadata:
17  name: migrate-pv-$src
18  namespace: $ns
19spec:
20  template:
21    spec:
22      containers:
23      - name: migrate
24        image: debian
25        command: [ "/bin/bash", "-c" ]
26        args:
27          -
28            apt-get update && apt-get install -y rsync &&
29            ls -lah /src_vol /dst_vol &&
30            df -h &&
31            rsync -avPS --delete /src_vol/ /dst_vol/ &&
32            ls -lah /dst_vol/ &&
33            du -shxc /src_vol/ /dst_vol/
34        volumeMounts:
35        - mountPath: /src_vol
36          name: src
37          readOnly: true
38        - mountPath: /dst_vol
39          name: dst
40      restartPolicy: Never
41      volumes:
42      - name: src
43        persistentVolumeClaim:
44          claimName: $src
45      - name: dst
46        persistentVolumeClaim:
47          claimName: $dst
48  backoffLimit: 1
49EOF
50
51kubectl create -f migrate-job.yaml
52kubectl -n $ns get jobs -o wide
53kubectl_completed_check=0
54
55echo "Waiting for data migration to be completed"
56while [[ $kubectl_completed_check -eq 0 ]]; do
57   kubectl -n $ns get pods | grep migrate-pv-$src
58   sleep 5
59   kubectl_completed_check=`kubectl -n $ns get pods | grep migrate-pv-$src | grep "Completed" | wc -l`
60done
61echo "Data migration completed"