Описание
Используя оператор трезубца и kubernetes 1.17.6, я могу создавать постоянные тома, но не могу монтировать их в модули.
При получении описания модуля возвращается следующая ошибка:
CSINode does not contain driver csi.trident.netapp.io
Окружающая обстановка
Воспроизвести
Установите оператора, как указано здесь: 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
Предупреждение о сбое аттачволуме
Предупреждение о сбое аттачволуме
Logs from trident on this worker:
kubectl -n логи трезубца trident-csi-9sgrt -c trident-main -f kubectl -n журналы trident trident-csi-9sgrt -c драйвер-регистратор kubectl получить csinode hh1kbw02x -n трезубец -o yaml Логи Кубелета:
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:
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
Версия API: storage.k8s.io/v1
вид: CSINode
метаданные:
СозданиеTimestamp: 2020-09-10T07:58:40Z
имя: hh1kbw02x
владелецСсылки:
вид: узел
имя: 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")
```
Идентичная проблема здесь с 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 по умолчанию будет искать в местоположении по умолчанию и, так сказать, «вставлять» плагины.
Итак, вам нужно проверить две вещи:
ps aux | grep kubelet | grep -e 'root-dir
-> взять настроенную папку (в моем случае это была /container)apiVersion: trident.netapp.io/v1
kind: TridentProvisioner
metadata:
name: trident
namespace: trident
spec:
debug: true
kubeletDir: /container
Удачи. Я закрываю это.
Наблюдал нечто подобное, когда модули набора демонов trident-csi
не могли взаимодействовать с trident-controller
. В данном случае это произошло из-за сетевой политики, которая предотвратила это.
Самый полезный комментарий
Так что исправил, если можно так сказать. После прочтения о том, как работает внешний поставщик хранилища, и понимания концепции регистрации драйверов с использованием контейнера sidecar, я рассмотрел нашу настройку.
Это вводило в заблуждение, так как мы настраиваем наши kubelet так, чтобы файлы конфигурации находились в каталоге /var/lib/kubelet, который является корневым каталогом по умолчанию.
Пару месяцев назад мы решили разделить мозг и переместить модули и контейнеры в отдельное хранилище, поэтому мы отделили управление от эксплуатации.
Поэтому мы изменили корневой каталог в файле конфигурации, чтобы он указывал на /containers вместо /var/lib/kubelet.
Средство обеспечения Trident по умолчанию будет искать в местоположении по умолчанию и, так сказать, «вставлять» плагины.
Итак, вам нужно проверить две вещи:
ps aux | grep kubelet | grep -e 'root-dir
-> взять настроенную папку (в моем случае это была /container)apiVersion: trident.netapp.io/v1 kind: TridentProvisioner metadata: name: trident namespace: trident spec: debug: true kubeletDir: /container
Удачи. Я закрываю это.