Learn how to streamline your workflow by automating nconnect and snapshot offload. Unlock the potential for massively increased efficiency and performance using standard NFSv3 or v4.1 with VAAI and your existing VMware vSphere environment. Guess what, it's free! ... View more

In today's rapidly evolving digital landscape, businesses increasingly leverage cloud technologies to enhance their operations and drive innovation. One such powerful combination is NetApp ® Trident ™ software with Google Cloud NetApp Volumes, mainly when used with the SMB protocol. This integration offers a seamless, efficient, and scalable solution for managing persistent storage in Kubernetes environments.   Overview of Trident and Google Cloud NetApp Volumes NetApp Trident is a dynamic storage orchestrator for Kubernetes, enabling the provisioning, management, and scaling of storage resources. It simplifies storage operations by automating the process of creating and managing volumes, making it an essential tool for modern cloud-native applications. Google Cloud NetApp Volumes, on the other hand, provides a fully managed, high-performance storage solution that integrates smoothly with Google Cloud services. These volumes support various protocols, including NFS and SMB, catering to diverse application needs.   Benefits of using SMB SMB is a network file-sharing protocol that allows applications to read and write to files and request services from server programs in a computer network. Integrating SMB with Trident and Google Cloud NetApp Volumes offers several advantages: Compatibility. SMB is widely supported across operating systems, making it an ideal choice for heterogeneous environments. Performance. SMB provides efficient file-sharing capabilities, ensuring high performance and low latency. Security. SMB includes robust security features, such as encryption and authentication, to protect data in transit and at rest. Scalability. With Google Cloud NetApp Volumes, you can easily scale your storage resources to meet the growing demands of your applications.   Setting up Trident with Google Cloud NetApp Volumes for SMB You can get all of this up and running in just four easy steps: Install Trident using Helm. Create the Trident back end for Google Cloud NetApp Volumes. Create a secret with Active Directory credentials. Create storage classes.   Prerequisites Before installing Trident 25.02 or later versions, read the prerequisites. Be sure that your Kubernetes cluster is in a Virtual Private Cloud (VPC) peered to a Google Cloud NetApp Volumes VPC. Be sure that Helm is installed on your device used to access the Kubernetes cluster. Your kubeconfig needs to be able to access the cluster where you want to install Trident.   Step 1: Install Trident using Helm You can use two methods to install Trident: using an operator or using tridentctl. For the operator method, you can use a Helm chart or install it manually. The tridentctl application can be downloaded, and it operates similarly to kubectl. In this blog, we’ll cover installing with a Helm chart. (For information about the other installation methods, see Manually deploy the Trident operator and Install using tridentctl.)  Add Trident’s Helm repository by using the following command: $ helm repo add NetApp-trident https://netapp.github.io/trident-helm-chart   After the repository is added, use Helm to install Trident on your Kubernetes cluster. The following command creates a Kubernetes namespace called Trident and installs Trident into that namespace.  $ helm install trident netapp-trident/trident-operator --version 100.2502.0 --create-namespace --namespace trident --set windows=true NAME: trident LAST DEPLOYED: Wed Mar 6 14:34:30 2025 NAMESPACE: trident STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: Thank you for installing trident-operator, which will deploy and manage NetApp's Trident CSI storage provisioner for Kubernetes. Your release is named 'trident' and is installed into the 'trident' namespace. Please note that there must be only one instance of Trident (and trident-operator) in a Kubernetes cluster. To configure Trident to manage storage resources, you will need a copy of tridentctl, which is available in pre-packaged Trident releases. You may find all Trident releases and source code. online at https://github.com/NetApp/trident. To learn more about the release, try: $ helm status trident $ helm get all trident   After a few moments, Trident should be installed on your cluster in the Trident namespace. $ kubectl get po -n trident NAME READY STATUS RESTARTS AGE trident-controller-6ddb4b4d6c-xhsv9 6/6 Running 0 2d14h trident-node-linux-6lq8d 2/2 Running 3 (2d14h ago) 2d14h trident-node-windows-crrzv 3/3 Running 0 2d14h trident-operator-76578bb8f6-cj6vh 1/1 Running 0 2d14h Now connect Trident to Google Cloud NetApp Volumes.   Step 2: Create the Trident back end Create secret and back-end YAML files that allow Trident access to Google Cloud NetApp Volumes for persistent storage. There are many ways to provision volumes to meet your applications’ needs, from different service levels to limiting volume size. As an example, let's set up Trident to create volumes for our Kubernetes applications within the Google Cloud NetApp Volumes Standard and Premium storage pools, although Extreme and Flex could be used as well. The pools we’ll use need to be configured in Google Cloud NetApp Volumes before the back end is created, as shown here. (For more information about creating storage pools in Google Cloud NetApp Volumes, see Create a storage pool.) If you’re using Google Kubernetes Engine, you can use either a cloud identity or a secret to access the storage pools. In this blog, we’ll use a secret. We next create a secret to allow Trident access to Google Cloud NetApp Volumes. The secret includes Google credentials to allow Trident to create the volumes. To obtain the information needed for the secret, create a Google Cloud service account with the Google Cloud NetApp Volumes admin role and download a key. A sample secret is shown here: apiVersion: v1 kind: Secret metadata: name: backend-tbc-gcnv-secret namespace: trident type: Opaque stringData: private_key_id: 123456789abcdef123456789abcdef123456789a private_key: | -----BEGIN PRIVATE KEY----- znHczZsrrtHisIsAbOguSaPIKeyAZNchRAGzlzZE4jK3bl/qp8B4Kws8zX5ojY9m znHczZsrrtHisIsAbOguSaPIKeyAZNchRAGzlzZE4jK3bl/qp8B4Kws8zX5ojY9m znHczZsrrtHisIsAbOguSaPIKeyAZNchRAGzlzZE4jK3bl/qp8B4Kws8zX5ojY9m znHczZsrrtHisIsAbOguSaPIKeyAZNchRAGzlzZE4jK3bl/qp8B4Kws8zX5ojY9m -----END PRIVATE KEY----- Next, we create the secret in the Trident namespace (or where Trident is running). $ kubectl apply -f secret.yaml secret/backend-tbc-gcnv-secret created The backend YAML file is used to create the back end. We can use as many service levels as we have storage pools configured in that region. This back-end file will direct Trident to create volumes in the specified storage pool in that service level, but that isn’t necessary. If no storage pool is specified, the volumes will be created in any storage pool with the correct characteristics. A sample back-end file using the Premium service level is shown here, although all four service levels are supported. apiVersion: trident.netapp.io/v1 kind: TridentBackendConfig metadata: name: backend-tbc-gcnv namespace: trident spec: version: 1 storageDriverName: google-cloud-netapp-volumes projectNumber: '123456789' location: us-west2 serviceLevel: premium nasType: smb apiKey: type: service_account project_id: cloud-xxxx-xxx client_email: test-dxx@cloud-xxxx-xxx.iam.gserviceaccount.com client_id: '12345678912313416734' auth_uri: https://accounts.google.com/o/oauth2/auth token_uri: https://oauth2.googleapis.com/token auth_provider_x509_cert_url: https://www.googleapis.com/oauth2/v1/certs client_x509_cert_url: https://www.googleapis.com/robot/v1/metadata/x509/test-dxx%40test-dxx@cloud-xxxx-xxx.iam.gserviceaccount.com credentials: name: backend-tbc-gcnv-secret We’ll use the back-end YAML file to create the back end. $ kubectl apply -f backend.yaml tridentbackendconfig.trident.netapp.io/backend-tbc-gcnv created And let's check to be sure that the back end is bound. $ kubectl get tbc -n trident NAME BACKEND NAME BACKEND UUID PHASE STATUS backend-tbc-gcnv backend-tbc-gcnv 86e67a80-329d-42e2-987f-8158d50cb3b4 Bound Success   The back end binds only if the storage pools in the appropriate service level have already been created.   Step 3: Create a secret with Active Directory credentials Create a secret with Active Directory credentials used to mount the pod to the SMB volume. This secret will be used as an annotation in the storage class. A sample secret file with Active Directory credentials is shown here: apiVersion: v1 stringData: password: 'xxxxxxxxxxxxxxx' username: 'asbnfff\abcdsew' kind: Secret metadata: name: secretsmb namespace: default type: Opaque We’ll use the secret YAML file to create the SMB secret: $ kubectl apply -f secretsmb.yaml secret/secretsmb created   Step 4: Create storage classes Create at least one storage class. In the following sample, we create a storage class that has the SMB secret as the annotation. apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: gcnv-sc-smb provisioner: csi.trident.netapp.io parameters: backendType: "google-cloud-netapp-volumes" trident.netapp.io/nasType: "smb" csi.storage.k8s.io/node-stage-secret-name: "secretsmb" csi.storage.k8s.io/node-stage-secret-namespace: "trident" We create the sample storage class. $ kubectl apply -f storageclass.yaml storageclass.storage.k8s.io/gcnv-sc-smb created Let's check to be sure the storage classes are available. $ kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE gcnv-sc-smb csi.trident.netapp.io Delete Immediate false 6m40s kind: PersistentVolumeClaim apiVersion: v1 metadata: name: gcnv-pvc-identity namespace: default spec: accessModes: - ReadWriteMany resources: requests: storage: 1Gi storageClassName: gcnv-sc-smb $ kubectl apply -f pvc.yaml persistentvolumeclaim/gcnv-pvc-identity created After the PVCs come up, they are bound to persistent volumes created by Trident. $ kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE gcnv-pvc-identity Bound pvc-90543c07-4607-4922-98ee-265349f130b6 100Gi RWX gcnv-sc-smb <unset> 48m   The volumes in Google Cloud NetApp Volumes are shown. Now, all we need to do is attach our application to the PVC, and we’ll have high-performance reliable storage for our stateful Kubernetes applications.   Use cases and applications The integration of Trident with Google Cloud NetApp Volumes for SMB is particularly beneficial for: File-sharing applications. Applications that require strong file-sharing capabilities can greatly benefit from the performance and security features of SMB. Data Analytics. SMB's efficient data access and management capabilities make it an excellent choice for data analytics workloads. Enterprise applications. Many enterprise applications rely on SMB for file access and storage, making this integration ideal for enterprise environments.   Conclusion NetApp Trident with Google Cloud NetApp Volumes for SMB offers a powerful and flexible solution for managing persistent storage in Kubernetes environments. By harnessing the strengths of both technologies, businesses can achieve high performance, scalability, and security for their applications. Whether you're running file-sharing services, data analytics workloads, or enterprise applications, this integration provides the robust storage capabilities needed to succeed in today's cloud-driven world. ... View more

Are you ready to take your storage solutions to the next level? Discover how the latest Trident 25.02 release empowers NetApp ONTAP users to leverage their existing Fiber Channel investments for provisioning persistent storage on OpenShift Container Platform. Whether you're running containers or virtual machines, this game-changing capability ensures high performance and reliability for your critical workloads. Join us as we dive into the details and show you how to seamlessly integrate Fiber Channel protocol into your modernized infrastructure. Don't miss out on this opportunity to enhance your storage capabilities and future-proof your applications! ... View more

By Nikhil Hegde and @Aparna , Software Engineers at NetApp ... View more

When it comes to cybersecurity, ransomware stands out as one of the most dangerous and relentless threats facing organizations today. Autonomous Ransomware Protection (ARP) elevates your defense strategy by providing a cutting-edge built-in capability to detect and mitigate potential attacks with precision. ARP does a solid job right out of the box, but how do you ensure you are using ARP in the most effective way to protect your data from ransomware attacks? ... View more