Trident: CSINode enthält keinen Treiber csi.trident.netapp.io

Erstellt am 21. Okt. 2020  ·  6Kommentare  ·  Quelle: NetApp/trident

Beschreibung
Mit dem Trident-Operator und Kubernetes 1.17.6 kann ich persistente Volumes erstellen, sie aber nicht in die Pods einbinden.

Beim Abrufen der Pod-Beschreibung wird folgender Fehler zurückgegeben:
CSINode does not contain driver csi.trident.netapp.io

Umfeld

  • Dreizack-Version: [20.07.1]
  • Verwendete Trident-Installations-Flags: [keine benutzerdefinierten Flags, da wir den Standardspeicherort /var/lib/kubelet verwenden]
  • Containerlaufzeit: [Docker 19.3.12]
  • Kubernetes-Version: [ 1.17.6]
  • Kubernetes-Orchestrator: [keine]
  • Kubernetes-aktivierte Feature-Gates: [keine erforderlich]
  • Betriebssystem: [Centos 7 - 3.10.0-1062.12.1.el7.x86_64]
  • NetApp-Backend-Typen: [ OnTap 9.7 ]
  • Andere:

Reproduzieren
Installieren Sie den Operator wie hier angegeben: https://netapp-trident.readthedocs.io/en/stable-v20.07/kubernetes/deploying/operator-deploy.html

Nach dem Erstellen der Speicherklasse und des Verbrauchers wird das PV gebunden, aber der Pod kann das Volume nicht lokal an den Worker anhängen

Erwartetes Verhalten
Pod sollte das Volume mounten und ausgeführt werden. stattdessen bleibt es einfach in "ausstehend"
Zusätzlicher Kontext
Pod-Beschreibung:
```kubectl -n test beschreibt po web-0
Warnung FailedScheduling 11s (x2 über 12s) Default-Scheduler-Fehler beim Ausführen des „VolumeBinding“-Filter-Plugins für Pod „web-0“: Pod hat ungebundene unmittelbare PersistentVolumeClaims
Normal Scheduled 9s default-scheduler Test/web-0 erfolgreich hh1kbw02x zugewiesen
Warnung FailedAttachVolume(x6 über) AttachDetach-Controller AttachVolume.Attach für Volume "pvc-934230b9-900c-4539-bb0c-8feff6e18628" fehlgeschlagen: CSINode hh1kbw02x enthält keinen Treiber csi.trident.netapp.io
Warnung FailedAttachVolume(x6 über) AttachDetach-Controller AttachVolume.Attach für Volume "pvc-f4c2b654-ff73-4dd5-84ef-a31491b83f26" fehlgeschlagen: CSINode hh1kbw02x enthält keinen Treiber csi.trident.netapp.io



Logs from trident on this worker:

kubectl -n trident logs 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 logs trident-csi-9sgrt -c Treiber-Registrar
I1021 17:14:18.636803 6672 main.go:110] Version: v1.3.0-0-g6e9fff3e
I1021 17:14:18.636888 6672 main.go:120] Versuch, eine gRPC-Verbindung zu öffnen mit: „/plugin/csi.sock“
I1021 17:14:18.636908 6672 connection.go:151] Verbinden mit unix:///plugin/csi.sock
I1021 17:14:18.637420 6672 main.go:127] CSI-Treiber wird aufgerufen, um den Treibernamen zu ermitteln
I1021 17:14:18.637435 6672 connection.go:180] GRPC-Aufruf: /csi.v1.Identity/GetPluginInfo
I1021 17:14:18.637442 6672 connection.go:181] GRPC-Anfrage: {}
I1021 17:14:18.639851 6672 connection.go:183] GRPC-Antwort: {"name":"csi.trident.netapp.io","vendor_version":"20.07.1"}
I1021 17:14:18.640235 6672 connection.go:184] GRPC-Fehler:
I1021 17:14:18.640242 6672 main.go:137] CSI-Treibername: "csi.trident.netapp.io"
I1021 17:14:18.648537 6672 node_register.go:51] Starten des Registrierungsservers unter: /registration/csi.trident.netapp.io-reg.sock
I1021 17:14:18.648666 6672 node_register.go:60] Registrierungsserver gestartet unter: /registration/csi.trident.netapp.io-reg.sock


Description of csi node

kubectl get csinode hh1kbw02x -n trident -o yaml
apiVersion: storage.k8s.io/v1
Art: CSINode
Metadaten:
ErstellungZeitstempel: 2020-09-10T07:58:40Z
Name: hh1kbw02x
BesitzerReferenzen:

  • apiVersion: v1
    Art: Knoten
    Name: hh1kbw02x
    uid: d3db28d6-e2be-4ad4-8534-c853b2e025b5
    resourceVersion: "30914526"
    selfLink: /apis/storage.k8s.io/v1/csinodes/hh1kbw02x
    uid: a764977a-be67-4ee9-8b7e-9aac304e0890
    Spezifikation:
    Treiber: null

Kubelet-Protokolle:
6. November 10:14:18 hh1kbw01x kubelet: I1106 10:14:18.883059 2393 reconciler.go:209] operationExecutor.VerifyControllerAttachedVolume gestartet für 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. November 10:14:18 hh1kbw01x kubelet: E1106 10:14:18.883223 2393 nestedpendingoperations.go:301] Vorgang für "{v olumeName:kubernetes.io/csi/csi.trident.netapp.io ^pvc-3bcc4e38-2e69- 4541-9910-711d2c086671 podName: nodeName:}" fehlgeschlagen. Keine Wiederholungen zulässig bis 2020-11-06 10:14:19.383183856 +0100 CET m=+1353591.737508759 (durationBeforeRetry 500ms). Fehler: „Volume wurde nicht zur Liste von VolumesInUse im Volume-Status des Knotens für Volume „pvc-3bcc4e38-2e69-4541-9910-711d2c086671“ hinzugefügt (UniqueName: „kubernetes.io/csi/csi.trident.netapp.io ^pvc-3bcc4e38-2e69-4541-9910-711d2c086671") Pod "web-0" (UID: "a235d5f9-05bf-4c77-8a84-e48f2f657d98") "
6. November 10:14:18 hh1kbw01x kubelet: I1106 10:14:18.983580 2393 reconciler.go:209] operationExecutor.VerifyControllerAttachedVolume gestartet für Volume „pvc-f138b6cc-988b-455c-bb2e-fce022755634“ (UniqueName: „.io/kubernetes csi/csi.trident.netapp.io^pvc-f138b6cc-988b-455c-bb2e-fce022755634") Pod "web-0" (UID: "a235d5f9-05bf-4c77-8a84-e48f2f657d98")
6. November 10:14:18 hh1kbw01x kubelet: E1106 10:14:18.983662 2393 nestedpendingoperations.go:301] Vorgang für "{v olumeName:kubernetes.io/csi/csi.trident.netapp.io ^pvc-f138b6cc-988b- 455c-bb2e-fce022755634 podName: nodeName:}" fehlgeschlagen. Keine Wiederholungen zulässig bis 2020-11-06 10:14:19.483629729 +0100 MEZ m=+1353591.837954619 (durationBeforeRetry 500ms). Fehler: „Volume wurde nicht zur Liste von VolumesInUse im Volume-Status des Knotens für Volume „pvc-f138b6cc-988b-455c-bb2e-fce022755634“ hinzugefügt (UniqueName: „kubernetes.io/csi/csi.trident.netapp.io ^pvc-f138b6cc-988b-455c-bb2e-fce022755634") Pod "web-0" (UID: "a235d5f9-05bf-4c77-8a84-e48f2f657d98") "
6. November 10:14:19 hh1kbw01x kubelet: I1106 10:14:19.385072 2393 reconciler.go:209] operationExecutor.VerifyControllerAttachedVolume gestartet für 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")
```

bug
Quelle
picture alexandru-ersenie

Hilfreichster Kommentar

Also habe ich es repariert, wenn ich das sagen darf. Nachdem ich gelesen hatte, wie der externe Speicherprovider funktioniert, und das Konzept der Fahrerregistrierung mit dem Sidecar-Container verstanden hatte, überprüfte ich unser Setup.

Das war sehr irreführend, da wir unsere Kubelets so konfigurieren, dass sie mit den Konfigurationsdateien beginnen, die sich unter /var/lib/kubelet befinden, dem Standard-Root-Verzeichnis.

Vor ein paar Monaten haben wir beschlossen, das Gehirn aufzuteilen und die Hülsen und Behälter an einen separaten Lagerort zu bringen, also haben wir das Management vom Betrieb getrennt

Daher haben wir das Root-Verzeichnis in der Konfigurationsdatei so geändert, dass es auf /containers statt auf /var/lib/kubelet zeigt

Der Standard-Trident-Bereitsteller sucht am Standardspeicherort und "bettet" die Plugins sozusagen ein.

Sie müssen also zwei Dinge überprüfen:

  1. ps aux | grep kubelet | grep -e 'root-dir -> den konfigurierten Ordner nehmen (in meinem Fall war es /container)
  2. Ändern Sie die trident_provisioner_cr.yaml und passen Sie sie an, indem Sie den Parameter „ kubeletDir “ hinzufügen.
    apiVersion: trident.netapp.io/v1 kind: TridentProvisioner metadata: name: trident namespace: trident spec: debug: true kubeletDir: /container

Viel Glück. Ich schließe dies.

picture alexandru-ersenie am 19. Nov. 2020
🎉1 👍1

Alle 6 Kommentare

Identisches Problem hier mit Rancher RKE und K8S (v1.18.10) und Knoten, auf denen Ubuntu 18.04.4 LTS mit Docker 19.3.13 ausgeführt wird, stimmt mit der oben angegebenen Umgebung überein ...

smangelkramer picture smangelkramer am 30. Okt. 2020

dasselbe hier mit Upstream-k8s auf Ubuntu 18.04

AndreasDeCrinis picture AndreasDeCrinis am 13. Nov. 2020

Ich konnte es "lösen", indem ich sowohl das Trident-CSI-Daemonset als auch das Deployment erneut bereitstellte und anschließend Kubelet neu startete

AndreasDeCrinis picture AndreasDeCrinis am 13. Nov. 2020

ja. Ich habe tridentctl anstelle des Operators verwendet.

smangelkramer picture smangelkramer am 13. Nov. 2020

Also habe ich es repariert, wenn ich das sagen darf. Nachdem ich gelesen hatte, wie der externe Speicherprovider funktioniert, und das Konzept der Fahrerregistrierung mit dem Sidecar-Container verstanden hatte, überprüfte ich unser Setup.

Das war sehr irreführend, da wir unsere Kubelets so konfigurieren, dass sie mit den Konfigurationsdateien beginnen, die sich unter /var/lib/kubelet befinden, dem Standard-Root-Verzeichnis.

Vor ein paar Monaten haben wir beschlossen, das Gehirn aufzuteilen und die Hülsen und Behälter an einen separaten Lagerort zu bringen, also haben wir das Management vom Betrieb getrennt

Daher haben wir das Root-Verzeichnis in der Konfigurationsdatei so geändert, dass es auf /containers statt auf /var/lib/kubelet zeigt

Der Standard-Trident-Bereitsteller sucht am Standardspeicherort und "bettet" die Plugins sozusagen ein.

Sie müssen also zwei Dinge überprüfen:

  1. ps aux | grep kubelet | grep -e 'root-dir -> den konfigurierten Ordner nehmen (in meinem Fall war es /container)
  2. Ändern Sie die trident_provisioner_cr.yaml und passen Sie sie an, indem Sie den Parameter „ kubeletDir “ hinzufügen.
    apiVersion: trident.netapp.io/v1 kind: TridentProvisioner metadata: name: trident namespace: trident spec: debug: true kubeletDir: /container

Viel Glück. Ich schließe dies.

alexandru-ersenie picture alexandru-ersenie am 19. Nov. 2020
🎉1 👍1

Ähnliches wurde beobachtet, wenn die trident-csi Daemonset-Pods nicht mit trident-controller kommunizieren konnten. In diesem Fall lag es an einer Netzwerkrichtlinie, die dies verhinderte.

balaramesh picture balaramesh am 7. Dez. 2021
War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

acsulli picture acsulli  ·  4Kommentare
tksm picture tksm  ·  4Kommentare
takuhiro picture takuhiro  ·  5Kommentare
gnarl picture gnarl  ·  5Kommentare
timvandevoort picture timvandevoort  ·  5Kommentare