Trident: CSINode не содержит драйвер csi.trident.netapp.io

Созданный на 21 окт. 2020  ·  6Комментарии  ·  Источник: NetApp/trident

Описание
Используя оператор трезубца и kubernetes 1.17.6, я могу создавать постоянные тома, но не могу монтировать их в модули.

При получении описания модуля возвращается следующая ошибка:
CSINode does not contain driver csi.trident.netapp.io

Окружающая обстановка

  • Версия трезубца: [20.07.1]
  • Используемые флаги установки Trident: [без пользовательских флагов, так как мы используем расположение по умолчанию /var/lib/kubelet]
  • Среда выполнения контейнера: [Docker 19.3.12]
  • Версия Kubernetes: [1.17.6]
  • Оркестратор Kubernetes: [нет]
  • Шлюзы функций с поддержкой Kubernetes: [нет необходимости]
  • ОС: [Centos 7 - 3.10.0-1062.12.1.el7.x86_64]
  • Типы бэкенда NetApp: [ OnTap 9.7 ]
  • Другой:

Воспроизвести
Установите оператора, как указано здесь: https://netapp-trident.readthedocs.io/en/stable-v20.07/kubernetes/deploying/operator-deploy.html .

После создания класса хранения и потребителя pv привязывается, но модуль не может локально подключить том к рабочему

Ожидаемое поведение
Ожидалось, что Pod смонтирует том и запустится. вместо этого он просто остается в состоянии "ожидание"
Дополнительный контекст
Описание пода:
```kubectl -n test описывает po web-0
Предупреждение FailedScheduling 11s (x2 over 12s) ошибка планировщика по умолчанию при запуске подключаемого модуля фильтра VolumeBinding для модуля web-0: модуль имеет несвязанные немедленные PersistentVolumeClaims
Обычный Запланировано 9s Планировщик по умолчанию Успешно назначен test/web-0 для hh1kbw02x
Предупреждение о сбое аттачволуме(x6 больше) attachdetach-controller AttachVolume.Attach не удалось выполнить для тома "pvc-934230b9-900c-4539-bb0c-8feff6e18628": CSINode hh1kbw02x не содержит драйвер csi.trident.netapp.io
Предупреждение о сбое аттачволуме(x6 больше) attachdetach-controller AttachVolume.Attach не удалось выполнить для тома "pvc-f4c2b654-ff73-4dd5-84ef-a31491b83f26": CSINode hh1kbw02x не содержит драйвер csi.trident.netapp.io



Logs from trident on this worker:

kubectl -n логи трезубца trident-csi-9sgrt -c trident-main -f
time="2020-10-21T17:15:31Z" level=debug msg="n>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> nPUT https://10.111.4.90:34571/trident/v1/node/hh1kbw02xnHeaders : map[Content-Type:[application/json]]nBody: {n "name": "hh1kbw02x",n "ips": [n "10.49.12.102",n "172.17.0.1"n ]n}n------------------------------------------------ ----------------------------------------------------------------------------"
time="2020-10-21T17:15:32Z" level=debug msg="n<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


Logs from registrar sidecar on this worker:

kubectl -n журналы trident trident-csi-9sgrt -c драйвер-регистратор
I1021 17:14:18.636803 6672 main.go:110] Версия: v1.3.0-0-g6e9fff3e
I1021 17:14:18.636888 6672 main.go:120] Попытка открыть соединение gRPC с помощью: «/plugin/csi.sock»
I1021 17:14:18.636908 6672 connection.go:151] Подключение к unix:///plugin/csi.sock
I1021 17:14:18.637420 6672 main.go:127] Вызов драйвера CSI для обнаружения имени драйвера
I1021 17:14:18.637435 6672 connection.go:180] Вызов GRPC: /csi.v1.Identity/GetPluginInfo
I1021 17:14:18.637442 6672 connection.go:181] Запрос GRPC: {}
I1021 17:14:18.639851 6672 connection.go:183] Ответ GRPC: {"name":"csi.trident.netapp.io","vendor_version":"20.07.1"}
I1021 17:14:18.640235 6672 connection.go:184] Ошибка GRPC:
I1021 17:14:18.640242 6672 main.go:137] Имя драйвера CSI: «csi.trident.netapp.io»
I1021 17:14:18.648537 6672 node_register.go:51] Запуск сервера регистрации по адресу: /registration/csi.trident.netapp.io-reg.sock
I1021 17:14:18.648666 6672 node_register.go:60] Сервер регистрации запущен по адресу: /registration/csi.trident.netapp.io-reg.sock


Description of csi node

kubectl получить csinode hh1kbw02x -n трезубец -o yaml
Версия API: storage.k8s.io/v1
вид: CSINode
метаданные:
СозданиеTimestamp: 2020-09-10T07:58:40Z
имя: hh1kbw02x
владелецСсылки:

  • апиВерсия: v1
    вид: узел
    имя: hh1kbw02x
    UID: d3db28d6-e2be-4ad4-8534-c853b2e025b5
    ResourceVersion: "30914526"
    самоссылка: /apis/storage.k8s.io/v1/csinodes/hh1kbw02x
    UID: a764977a-be67-4ee9-8b7e-9aac304e0890
    спецификация:
    драйверы: ноль

Логи Кубелета:
6 ноября 10:14:18 hh1kbw01x kubelet: I1106 10:14:18.883059 2393 reconciler.go:209] OperationExecutor.VerifyControllerAttachedVolume запущен для тома "pvc-3bcc4e38-2e69-4541-9910-711d2c086671" (UniqueesName.io) csi/csi.trident.netapp.io^pvc-3bcc4e38-2e69-4541-9910-711d2c086671") под "web-0" (UID: "a235d5f9-05bf-4c77-8a84-e48f2f657d98")
6 ноября 10:14:18 hh1kbw01x kubelet: E1106 10:14:18.883223 2393 nestedpendingoperations.go:301] Операция для "{ volumeName:kubernetes.io/csi/csi.trident.netapp.io ^pvc-3bcc4e38-2e69- 4541-9910-711d2c086671 имя_пода: имя_узла:}" не удалось. Повторные попытки не разрешены до 06.11.2020 10:14:19,383183856 +0100 CET m=+1353591,737508759 (durationBeforeRetry 500 мс). Ошибка: «Том не был добавлен в список VolumesInUse в статусе тома узла для тома «pvc-3bcc4e38-2e69-4541-9910-711d2c086671» (UniqueName: «kubernetes.io/csi/csi.trident.netapp.io ^pvc-3bcc4e38-2e69-4541-9910-711d2c086671") pod "web-0" (UID: "a235d5f9-05bf-4c77-8a84-e48f2f657d98") "
6 ноября 10:14:18 hh1kbw01x kubelet: I1106 10:14:18.983580 2393 reconciler.go:209] OperationExecutor.VerifyControllerAttachedVolume запущен для тома "pvc-f138b6cc-988b-455c-bb2e-fce022755634" (UniquesName: "ku/netiqueName:" csi/csi.trident.netapp.io^pvc-f138b6cc-988b-455c-bb2e-fce022755634") под "web-0" (UID: "a235d5f9-05bf-4c77-8a84-e48f2f657d98")
6 ноября 10:14:18 hh1kbw01x kubelet: E1106 10:14:18.983662 2393 nestedpendingoperations.go:301] Операция для "{ volumeName:kubernetes.io/csi/csi.trident.netapp.io ^pvc-f138b6cc-988b- 455c-bb2e-fce022755634 podName: nodeName:}" не удалось. Повторные попытки не разрешены до 06.11.2020 10:14:19,483629729 +0100 CET m=+1353591,837954619 (durationBeforeRetry 500 мс). Ошибка: «Том не был добавлен в список VolumesInUse в статусе тома узла для тома «pvc-f138b6cc-988b-455c-bb2e-fce022755634» (UniqueName: «kubernetes.io/csi/csi.trident.netapp.io ^pvc-f138b6cc-988b-455c-bb2e-fce022755634") pod "web-0" (UID: "a235d5f9-05bf-4c77-8a84-e48f2f657d98") "
6 ноября 10:14:19 hh1kbw01x kubelet: I1106 10:14:19.385072 2393 reconciler.go:209] OperationExecutor.VerifyControllerAttachedVolume запущен для тома "pvc-3bcc4e38-2e69-4541-9910-711d2c086671" (UniqueesName.io) csi/csi.trident.netapp.io^pvc-3bcc4e38-2e69-4541-9910-711d2c086671") под "web-0" (UID: "a235d5f9-05bf-4c77-8a84-e48f2f657d98")
```

Самый полезный комментарий

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

Это вводило в заблуждение, так как мы настраиваем наши kubelet так, чтобы файлы конфигурации находились в каталоге /var/lib/kubelet, который является корневым каталогом по умолчанию.

Пару месяцев назад мы решили разделить мозг и переместить модули и контейнеры в отдельное хранилище, поэтому мы отделили управление от эксплуатации.

Поэтому мы изменили корневой каталог в файле конфигурации, чтобы он указывал на /containers вместо /var/lib/kubelet.

Средство обеспечения Trident по умолчанию будет искать в местоположении по умолчанию и, так сказать, «вставлять» плагины.

Итак, вам нужно проверить две вещи:

  1. ps aux | grep kubelet | grep -e 'root-dir -> взять настроенную папку (в моем случае это была /container)
  2. измените файл trident_provisioner_cr.yaml и настройте его, добавив параметр " kubeletDir "
    apiVersion: trident.netapp.io/v1 kind: TridentProvisioner metadata: name: trident namespace: trident spec: debug: true kubeletDir: /container

Удачи. Я закрываю это.

Все 6 Комментарий

Идентичная проблема здесь с Rancher RKE и K8S (v1.18.10) и узлами под управлением Ubuntu 18.04.4 LTS с Docker 19.3.13, остальные соответствуют указанной выше среде...

то же самое здесь с восходящим потоком k8s на Ubuntu 18.04

Я смог «решить» это, повторно развернув набор демонов trident-csi и развертывание, а затем перезапустив kubelet.

Ага. я использовал tridentctl вместо оператора.

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

Это вводило в заблуждение, так как мы настраиваем наши kubelet так, чтобы файлы конфигурации находились в каталоге /var/lib/kubelet, который является корневым каталогом по умолчанию.

Пару месяцев назад мы решили разделить мозг и переместить модули и контейнеры в отдельное хранилище, поэтому мы отделили управление от эксплуатации.

Поэтому мы изменили корневой каталог в файле конфигурации, чтобы он указывал на /containers вместо /var/lib/kubelet.

Средство обеспечения Trident по умолчанию будет искать в местоположении по умолчанию и, так сказать, «вставлять» плагины.

Итак, вам нужно проверить две вещи:

  1. ps aux | grep kubelet | grep -e 'root-dir -> взять настроенную папку (в моем случае это была /container)
  2. измените файл trident_provisioner_cr.yaml и настройте его, добавив параметр " kubeletDir "
    apiVersion: trident.netapp.io/v1 kind: TridentProvisioner metadata: name: trident namespace: trident spec: debug: true kubeletDir: /container

Удачи. Я закрываю это.

Наблюдал нечто подобное, когда модули набора демонов trident-csi не могли взаимодействовать с trident-controller . В данном случае это произошло из-за сетевой политики, которая предотвратила это.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги