Hi Team, In our Kubernetes (K8s) environment, each application team is assigned their own namespace, and they deploy their own pods within it. While testing the NetApp Trident integration, we observed the following and would appreciate your feedback on how we can address these concerns: Tenant A provisions a PersistentVolumeClaim (PVC) named pvc1. How does the system ensure that Tenant B cannot access pvc1 or its underlying PersistentVolume (PV)? What security mechanisms are in place (e.g., namespace isolation, RBAC, storage-level encryption, etc.) to enforce tenant isolation and prevent unauthorized access? Are there any best practices to enhance security in a multi-tenant Kubernetes environment using NetApp Trident? In our current setup, PVCs are namespace-scoped, and each application team has access only to their respective namespace. Looking forward to your input. Thanks
... View more
VDI and PC Cloud need to be storage on super speed and strong storage system. How we can speed the adoption to use super fast Virtual Machine to deploy a Desktop on premise and Cloud Services.
... View more
Somebody has experience using Trident version 20.10.1 and the K0s Kubernetes runtime (running k8s 1.22.5). I used the operator to install. When verifying the installation, I'm able to create backend and do some persistent storage claim, the volume is correctly created. But when using this inside pod I have issue, when describing the pod I see "CSINode does not contain driver csi.trident.netapp.io." sh-4.2# /usr/local/bin/k0s kubectl get csidriver NAME ATTACHREQUIRED PODINFOONMOUNT STORAGECAPACITY TOKENREQUESTS REQUIRESREPUBLISH MODES AGE csi.trident.netapp.io true false false <unset> false Persistent 42h sh-4.2# /usr/local/bin/k0s kubectl get csinode NAME DRIVERS AGE lxdocapa22 0 89d lxdocapa23 0 15d As you can see, for some reason there is no registration done of the netapp csi on the two nodes. sh-4.2# /usr/local/bin/k0s kubectl -n tme-ns-trident logs -f trident-csi-9v9qc -c driver-registrar I0126 09:00:28.434839 9017 main.go:164] Version: v2.3.0 I0126 09:00:28.434937 9017 main.go:165] Running node-driver-registrar in mode=registration I0126 09:00:28.435884 9017 main.go:189] Attempting to open a gRPC connection with: "/plugin/csi.sock" I0126 09:00:29.437022 9017 main.go:196] Calling CSI driver to discover driver name I0126 09:00:29.440276 9017 main.go:206] CSI driver name: "csi.trident.netapp.io" I0126 09:00:29.440328 9017 node_register.go:52] Starting Registration Server at: /registration/csi.trident.netapp.io-reg.sock I0126 09:00:29.440544 9017 node_register.go:61] Registration Server started at: /registration/csi.trident.netapp.io-reg.sock I0126 09:00:29.440718 9017 node_register.go:91] Skipping healthz server because HTTP endpoint is set to: "" Seems to go wrong inside the registration step? I checked on other distribution (Miratis MKE) and there it is is all fine -sh-4.2$ kubectl -n tme-ns-trident logs -f trident-csi-ntscm -c driver-registrar I0123 10:35:00.363933 2216 main.go:113] Version: v2.1.0 I0123 10:35:00.365110 2216 main.go:137] Attempting to open a gRPC connection with: "/plugin/csi.sock" I0123 10:35:00.365140 2216 connection.go:153] Connecting to unix:///plugin/csi.sock I0123 10:35:00.366670 2216 main.go:144] Calling CSI driver to discover driver name I0123 10:35:00.369727 2216 main.go:154] CSI driver name: "csi.trident.netapp.io" I0123 10:35:00.369784 2216 node_register.go:52] Starting Registration Server at: /registration/csi.trident.netapp.io-reg.sock I0123 10:35:00.370335 2216 node_register.go:61] Registration Server started at: /registration/csi.trident.netapp.io-reg.sock I0123 10:35:00.370409 2216 node_register.go:83] Skipping healthz server because HTTP endpoint is set to: "" I0123 10:35:01.311995 2216 main.go:80] Received GetInfo call: &InfoRequest{} I0123 10:35:01.386294 2216 main.go:90] Received NotifyRegistrationStatus call: &RegistrationStatus{PluginRegistered:true,Error:,} Can somebody advise?
... View more
Hi Team, I have two environment(Prod,DR) and I have deployed app on Prod. I am planning to perform the failover from prod to DR with the help of trident. I have installed and configured the backend on both cluster and followed the below URL in order to implement the DR failover. I have stopped the SVN on prod and try create the backend in DR and discover the volume as per the steps described in below URL but unable to find the disk. Can you please help me to find the right approach in order to do that? https://netapp-trident.readthedocs.io/en/stable-v19.04/dag/kubernetes/backup_disaster_recovery.html Regards, Bala
... View more
