Trident: CSINode no contiene el controlador csi.trident.netapp.io
Descripción
Con el operador trident y kubernetes 1.17.6, puedo crear volúmenes persistentes, pero no puedo montarlos en los pods.
Al obtener la descripción del pod, se devuelve el siguiente error:
CSINode does not contain driver csi.trident.netapp.io
Ambiente
- Versión Tridente: [20.07.1]
- Banderas de instalación de Trident utilizadas: [no hay banderas personalizadas, ya que usamos la ubicación predeterminada /var/lib/kubelet]
- Tiempo de ejecución del contenedor: [Docker 19.3.12]
- Versión de Kubernetes: [1.17.6]
- Orquestador de Kubernetes: [ninguno]
- Puertas de características habilitadas para Kubernetes: [no se necesita]
- SO: [Centos 7 - 3.10.0-1062.12.1.el7.x86_64]
- Tipos de back-end de NetApp: [ OnTap 9.7 ]
- Otro:
Reproducir
Instale el operador como se indica aquí: https://netapp-trident.readthedocs.io/en/stable-v20.07/kubernetes/deploying/operator-deploy.html
Después de crear la clase de almacenamiento y el consumidor, el pv se vincula, pero el pod no puede adjuntar el volumen localmente al trabajador
Comportamiento esperado
Se esperaba que Pod montara el volumen y se ejecutara. en cambio, solo permanece en "pendiente"
Contexto adicional
Descripción de la vaina:
```kubectl -n test describe po web-0
Advertencia FailedScheduling 11s (x2 over 12s) error del programador predeterminado al ejecutar el complemento de filtro "VolumeBinding" para el pod "web-0": el pod tiene PersistentVolumeClaims inmediatos sin vincular
Normal Scheduled 9s default-scheduler Prueba/web-0 asignada con éxito a hh1kbw02x
Error de advertenciaAttachVolume
Error de advertenciaAttachVolume
Logs from trident on this worker:
kubectl -n trident registros trident-csi-9sgrt -c trident-main -f kubectl -n trident logs trident-csi-9sgrt -c controlador-registrar kubectl obtener csinode hh1kbw02x -n trident -o yaml Registros de Kubelet:
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] Versión: v1.3.0-0-g6e9fff3e
I1021 17:14:18.636888 6672 main.go:120] Intentando abrir una conexión gRPC con: "/plugin/csi.sock"
I1021 17:14:18.636908 6672 connection.go:151] Conexión a unix:///plugin/csi.sock
I1021 17:14:18.637420 6672 main.go:127] Llamar al controlador CSI para descubrir el nombre del controlador
I1021 17:14:18.637435 6672 conexión.go:180] Llamada GRPC: /csi.v1.Identity/GetPluginInfo
I1021 17:14:18.637442 6672 conexión.go:181] Solicitud GRPC: {}
I1021 17:14:18.639851 6672 conexión.go:183] Respuesta de GRPC: {"nombre":"csi.trident.netapp.io","vendor_version":"20.07.1"}
I1021 17:14:18.640235 6672 conexión.go:184] Error de GRPC:
I1021 17:14:18.640242 6672 main.go:137] Nombre del controlador CSI: "csi.trident.netapp.io"
I1021 17:14:18.648537 6672 node_register.go:51] Inicio del servidor de registro en: /registration/csi.trident.netapp.io-reg.sock
I1021 17:14:18.648666 6672 node_register.go:60] Servidor de registro iniciado en: /registration/csi.trident.netapp.io-reg.sock
Description of csi node
apiVersión: storage.k8s.io/v1
tipo: CSINode
metadatos:
creaciónMarca de tiempo: 2020-09-10T07:58:40Z
nombre: hh1kbw02x
propietarioReferencias:
tipo: nodo
nombre: hh1kbw02x
uid: d3db28d6-e2be-4ad4-8534-c853b2e025b5
versión del recurso: "30914526"
autoenlace: /apis/storage.k8s.io/v1/csinodes/hh1kbw02x
uid: a764977a-be67-4ee9-8b7e-9aac304e0890
Especificaciones:
controladores: nulo
6 de noviembre 10:14:18 hh1kbw01x kubelet: I1106 10:14:18.883059 2393 reconciler.go:209] operationExecutor.VerifyControllerAttachedVolume iniciado para el volumen "pvc-3bcc4e38-2e69-4541-9910-711d2c086671" (UniquenetesName: "/kubernetesName: " csi/csi.trident.netapp.io^pvc-3bcc4e38-2e69-4541-9910-711d2c086671") módulo "web-0" (UID: "a235d5f9-05bf-4c77-8a84-e48f2f657d98")
6 de noviembre 10:14:18 hh1kbw01x kubelet: E1106 10:14:18.883223 2393 nestedpendingoperations.go:301] Operación para "{v olumeName:kubernetes.io/csi/csi.trident.netapp.io ^pvc-3bcc4e38-2e69- 4541-9910-711d2c086671 podName: nodeName:}" falló. No se permiten reintentos hasta el 2020-11-06 10:14:19.383183856 +0100 CET m=+1353591.737508759 (durationBeforeRetry 500ms). Error: "El volumen no se agregó a la lista de VolumesInUse en el estado del volumen del nodo para el volumen "pvc-3bcc4e38-2e69-4541-9910-711d2c086671" (UniqueName: "kubernetes.io/csi/csi.trident.netapp.io ^pvc-3bcc4e38-2e69-4541-9910-711d2c086671") módulo "web-0" (UID: "a235d5f9-05bf-4c77-8a84-e48f2f657d98") "
6 de noviembre 10:14:18 hh1kbw01x kubelet: I1106 10:14:18.983580 2393 reconciler.go:209] operationExecutor.VerifyControllerAttachedVolume iniciado para el volumen "pvc-f138b6cc-988b-455c-bb2e-fce022755634" (UniqueName.io/kubernetesName: " csi/csi.trident.netapp.io^pvc-f138b6cc-988b-455c-bb2e-fce022755634") módulo "web-0" (UID: "a235d5f9-05bf-4c77-8a84-e48f2f657d98")
6 de noviembre 10:14:18 hh1kbw01x kubelet: E1106 10:14:18.983662 2393 nestedpendingoperations.go:301] Operación para "{v olumeName:kubernetes.io/csi/csi.trident.netapp.io ^pvc-f138b6cc-988b- 455c-bb2e-fce022755634 podName: nodeName:}" falló. No se permiten reintentos hasta el 2020-11-06 10:14:19.483629729 +0100 CET m=+1353591.837954619 (durationBeforeRetry 500ms). Error: "El volumen no se agregó a la lista de VolumesInUse en el estado del volumen del nodo para el volumen "pvc-f138b6cc-988b-455c-bb2e-fce022755634" (UniqueName: "kubernetes.io/csi/csi.trident.netapp.io ^pvc-f138b6cc-988b-455c-bb2e-fce022755634") módulo "web-0" (UID: "a235d5f9-05bf-4c77-8a84-e48f2f657d98") "
6 de noviembre 10:14:19 hh1kbw01x kubelet: I1106 10:14:19.385072 2393 reconciler.go:209] operationExecutor.VerifyControllerAttachedVolume iniciado para el volumen "pvc-3bcc4e38-2e69-4541-9910-711d2c086671" (UniquenetesName: "/kubernetesName: " csi/csi.trident.netapp.io^pvc-3bcc4e38-2e69-4541-9910-711d2c086671") pod "web-0" (UID: "a235d5f9-05bf-4c77-8a84-e48f2f657d98")
```
alexandru-ersenie
Todos 6 comentarios
Problema idéntico aquí con Rancher RKE y K8S (v1.18.10) y nodos que ejecutan Ubuntu 18.04.4 LTS con Docker 19.3.13 el resto coincide con el entorno indicado anteriormente...
smangelkramer
en 30 oct. 2020
lo mismo aquí con upstream k8s en ubuntu 18.04
AndreasDeCrinis
en 13 nov. 2020
Pude "resolverlo" volviendo a implementar tanto el demonio trident-csi como el despliegue y luego reinicié kubelet
AndreasDeCrinis
en 13 nov. 2020
sí. Usé tridentctl en lugar de operador.
smangelkramer
en 13 nov. 2020
Así que lo arreglé, si se me permite decirlo. Después de leer cómo funciona el aprovisionador de almacenamiento externo y comprender el concepto de registro de controladores mediante el contenedor sidecar, revisé nuestra configuración.
Fue muy engañoso, ya que configuramos nuestros kubelets para comenzar con los archivos de configuración que residen en /var/lib/kubelet, que es el directorio raíz predeterminado.
Hace un par de meses, decidimos dividir el cerebro y mover las cápsulas y los contenedores a una ubicación de almacenamiento separada, por lo que separamos la administración de la operación.
Por lo tanto, cambiamos el directorio raíz en el archivo de configuración para que apunte a /containers en lugar de /var/lib/kubelet
El aprovisionador tridente predeterminado buscará en la ubicación predeterminada e "incrustará" los complementos, por así decirlo.
Por lo tanto, debe verificar dos cosas:
ps aux | grep kubelet | grep -e 'root-dir-> tomar la carpeta configurada (en mi caso fue /container)- cambie trident_provisioner_cr.yaml y personalícelo agregando el parámetro " kubeletDir "
apiVersion: trident.netapp.io/v1 kind: TridentProvisioner metadata: name: trident namespace: trident spec: debug: true kubeletDir: /container
Buena suerte. Estoy cerrando esto.
alexandru-ersenie
en 19 nov. 2020
Se observó algo similar cuando los trident-csi daemonset pods no pueden comunicarse con el trident-controller . En este caso se debió a una política de red que lo impedía.
balaramesh
en 7 dic. 2021
Temas relacionados
leemmcc
·
4Comentarios
r0ss3
·
6Comentarios
uberspot
·
3Comentarios
uberspot
·
5Comentarios
tksm
·
4Comentarios
Comentario más útil
Así que lo arreglé, si se me permite decirlo. Después de leer cómo funciona el aprovisionador de almacenamiento externo y comprender el concepto de registro de controladores mediante el contenedor sidecar, revisé nuestra configuración.
Fue muy engañoso, ya que configuramos nuestros kubelets para comenzar con los archivos de configuración que residen en /var/lib/kubelet, que es el directorio raíz predeterminado.
Hace un par de meses, decidimos dividir el cerebro y mover las cápsulas y los contenedores a una ubicación de almacenamiento separada, por lo que separamos la administración de la operación.
Por lo tanto, cambiamos el directorio raíz en el archivo de configuración para que apunte a /containers en lugar de /var/lib/kubelet
El aprovisionador tridente predeterminado buscará en la ubicación predeterminada e "incrustará" los complementos, por así decirlo.
Por lo tanto, debe verificar dos cosas:
ps aux | grep kubelet | grep -e 'root-dir-> tomar la carpeta configurada (en mi caso fue /container)apiVersion: trident.netapp.io/v1 kind: TridentProvisioner metadata: name: trident namespace: trident spec: debug: true kubeletDir: /containerBuena suerte. Estoy cerrando esto.