Trident: CSINode não contém o driver csi.trident.netapp.io
Descrição
Usando o operador trident e o kubernetes 1.17.6, consigo criar volumes persistentes, mas não consigo montá-los nos pods.
Ao obter a descrição do pod, o seguinte erro é retornado:
CSINode does not contain driver csi.trident.netapp.io
Ambiente
- Versão tridente: [20.07.1]
- Sinalizadores de instalação do Trident usados: [sem sinalizadores personalizados, pois usamos o local padrão /var/lib/kubelet]
- Tempo de execução do contêiner: [Docker 19.3.12]
- Versão do Kubernetes: [ 1.17.6]
- Orquestrador do Kubernetes: [nenhum]
- Gates de recursos habilitados para Kubernetes: [nenhum necessário]
- SO: [Centos 7 - 3.10.0-1062.12.1.el7.x86_64]
- Tipos de back-end da NetApp: [ OnTap 9.7 ]
- De outros:
Reproduzir
Instale o operador conforme fornecido aqui: https://netapp-trident.readthedocs.io/en/stable-v20.07/kubernetes/deploying/operator-deploy.html
Depois de criar a classe de armazenamento e o consumidor, o pv é vinculado, mas o pod não pode anexar o volume localmente ao trabalhador
Comportamento esperado
Esperava-se que o pod montasse o volume e estivesse em execução. em vez disso, ele permanece em "pendente"
Contexto adicional
Descrição do pod:
```kubectl -n test descreve po web-0
Aviso FailedScheduling 11s (x2 sobre 12s) erro de agendador padrão ao executar o plug-in de filtro "VolumeBinding" para o pod "web-0": o pod desvinculou PersistentVolumeClaims imediato
Agendamento padrão de 9s programado normal Test/web-0 atribuído com sucesso a hh1kbw02x
Aviso FailedAttachVolume
Aviso FailedAttachVolume
Logs from trident on this worker:
kubectl -n trident logs trident-csi-9sgrt -c trident-main -f kubectl -n trident logs trident-csi-9sgrt -c driver-registrar kubectl obtém csinode hh1kbw02x -n trident -o yaml Registros do 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] Versão: v1.3.0-0-g6e9fff3e
I1021 17:14:18.636888 6672 main.go:120] Tentando abrir uma conexão gRPC com: "/plugin/csi.sock"
I1021 17:14:18.636908 6672 connection.go:151] Conectando ao unix:///plugin/csi.sock
I1021 17:14:18.637420 6672 main.go:127] Chamando o driver CSI para descobrir o nome do driver
I1021 17:14:18.637435 6672 connection.go:180] Chamada GRPC: /csi.v1.Identity/GetPluginInfo
I1021 17:14:18.637442 6672 connection.go:181] Solicitação GRPC: {}
I1021 17:14:18.639851 6672 connection.go:183] Resposta GRPC: {"name":"csi.trident.netapp.io","vendor_version":"20.07.1"}
I1021 17:14:18.640235 6672 connection.go:184] Erro GRPC:
I1021 17:14:18.640242 6672 main.go:137] Nome do driver CSI: "csi.trident.netapp.io"
I1021 17:14:18.648537 6672 node_register.go:51] Iniciando o servidor de registro em: /registration/csi.trident.netapp.io-reg.sock
I1021 17:14:18.648666 6672 node_register.go:60] Servidor de registro iniciado em: /registration/csi.trident.netapp.io-reg.sock
Description of csi node
apiVersion: storage.k8s.io/v1
tipo: CSINode
metadados:
CreationTimestamp: 2020-09-10T07:58:40Z
nome: hh1kbw02x
proprietárioReferências:
tipo: nó
nome: hh1kbw02x
uid: d3db28d6-e2be-4ad4-8534-c853b2e025b5
resourceVersion: "30914526"
selfLink: /apis/storage.k8s.io/v1/csinodes/hh1kbw02x
uid: a764977a-be67-4ee9-8b7e-9aac304e0890
especificação:
motoristas: null
6 de novembro 10:14:18 hh1kbw01x kubelet: I1106 10:14:18.883059 2393 reconciliar.go:209] operationExecutor.VerifyControllerAttachedVolume iniciado para o volume "pvc-3bcc4e38-2e69-4541-9910-711d2c086671" (UniqueName: "UniqueName: " csi/csi.trident.netapp.io^pvc-3bcc4e38-2e69-4541-9910-711d2c086671") pod "web-0" (UID: "a235d5f9-05bf-4c77-8a84-e48f2f657d98")
6 de novembro 10:14:18 hh1kbw01x kubelet: E1106 10:14:18.883223 2393 nestedpendingoperations.go:301] Operação para "{v olumeName:kubernetes.io/csi/csi.trident.netapp.io ^pvc-3bcc4e38-2e69- 4541-9910-711d2c086671 podName: nodeName:}" falhou. Não são permitidas novas tentativas até 2020-11-06 10:14:19.383183856 +0100 CET m=+1353591.737508759 (durationBeforeRetry 500ms). Erro: "O volume não foi adicionado à lista de VolumesInUse no status do volume do nó para o volume "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 de novembro 10:14:18 hh1kbw01x kubelet: I1106 10:14:18.983580 2393 reconciliar.go:209] operationExecutor.VerifyControllerAttachedVolume iniciado para o volume "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 de novembro 10:14:18 hh1kbw01x kubelet: E1106 10:14:18.983662 2393 nestedpendingoperations.go:301] Operação para "{v olumeName:kubernetes.io/csi/csi.trident.netapp.io ^pvc-f138b6cc-988b- 455c-bb2e-fce022755634 podName: nodeName:}" falhou. Não são permitidas novas tentativas até 2020-11-06 10:14:19.483629729 +0100 CET m=+1353591.837954619 (durationBeforeRetry 500ms). Erro: "O volume não foi adicionado à lista de VolumesInUse no status do volume do nó para o volume "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 de novembro 10:14:19 hh1kbw01x kubelet: I1106 10:14:19.385072 2393 reconciliar.go:209] operationExecutor.VerifyControllerAttachedVolume iniciado para o volume "pvc-3bcc4e38-2e69-4541-9910-711d2c086671" (UniqueName: "UniqueName: " csi/csi.trident.netapp.io^pvc-3bcc4e38-2e69-4541-9910-711d2c086671") pod "web-0" (UID: "a235d5f9-05bf-4c77-8a84-e48f2f657d98")
```
alexandru-ersenie
Todos 6 comentários
Problema idêntico aqui com Rancher RKE e K8S (v1.18.10) e nós executando Ubuntu 18.04.4 LTS com Docker 19.3.13 rest corresponde ao ambiente declarado acima...
smangelkramer
em 30 out. 2020
mesmo aqui com k8s upstream no Ubuntu 18.04
AndreasDeCrinis
em 13 nov. 2020
Consegui "resolver" reimplantando o daemonset trident-csi e a implantação e reiniciei o kubelet depois
AndreasDeCrinis
em 13 nov. 2020
sim. eu usei tridentctl em vez de operador.
smangelkramer
em 13 nov. 2020
Então eu consertei, se assim posso dizer. Depois de ler como o provisionador de armazenamento externo funciona e entender o conceito de registro de driver usando o contêiner sidecar, revisei nossa configuração.
Foi muito enganoso, pois configuramos nossos kubelets para iniciar com os arquivos de configuração que residem em /var/lib/kubelet, que é o diretório raiz padrão.
Alguns meses atrás, decidimos dividir o cérebro e mover os pods e contêineres para um local de armazenamento separado, então dividimos o gerenciamento da operação
Portanto, alteramos o diretório raiz no arquivo de configuração para apontar para /containers em vez de /var/lib/kubelet
O provedor de tridente padrão procurará no local padrão e "incorporar" os plugins, por assim dizer.
Então você precisa verificar duas coisas:
ps aux | grep kubelet | grep -e 'root-dir-> pegue a pasta configurada (no meu caso foi /container)- altere o trident_provisioner_cr.yaml e personalize-o adicionando o parâmetro " kubeletDir "
apiVersion: trident.netapp.io/v1 kind: TridentProvisioner metadata: name: trident namespace: trident spec: debug: true kubeletDir: /container
Boa sorte. Estou fechando isso.
alexandru-ersenie
em 19 nov. 2020
Observado algo semelhante quando os pods do daemonset trident-csi não conseguem se comunicar com o trident-controller . Nesse caso, foi devido a uma política de rede que o impediu.
balaramesh
em 7 dez. 2021
Questões relacionadas
SuperBaobab
·
3Comentários
uberspot
·
5Comentários
khankth
·
4Comentários
arndt-netapp
·
6Comentários
kaparora
·
5Comentários
Comentários muito úteis
Então eu consertei, se assim posso dizer. Depois de ler como o provisionador de armazenamento externo funciona e entender o conceito de registro de driver usando o contêiner sidecar, revisei nossa configuração.
Foi muito enganoso, pois configuramos nossos kubelets para iniciar com os arquivos de configuração que residem em /var/lib/kubelet, que é o diretório raiz padrão.
Alguns meses atrás, decidimos dividir o cérebro e mover os pods e contêineres para um local de armazenamento separado, então dividimos o gerenciamento da operação
Portanto, alteramos o diretório raiz no arquivo de configuração para apontar para /containers em vez de /var/lib/kubelet
O provedor de tridente padrão procurará no local padrão e "incorporar" os plugins, por assim dizer.
Então você precisa verificar duas coisas:
ps aux | grep kubelet | grep -e 'root-dir-> pegue a pasta configurada (no meu caso foi /container)apiVersion: trident.netapp.io/v1 kind: TridentProvisioner metadata: name: trident namespace: trident spec: debug: true kubeletDir: /containerBoa sorte. Estou fechando isso.