Sign in to my dashboard Create an account
Menu

Easily manage Kubernetes clusters with a Cloud Volumes ONTAP storage back end in Astra Control Service

Table of Contents

Share this page

Patric Uebele

Now it’s easier than ever to manage Kubernetes (K8s) clusters on Microsoft Azure and Google Cloud. With its latest January update, NetApp® Astra Control Service also supports NetApp Cloud Volumes ONTAP® software as a storage back end for your protected K8s clusters on Azure and Google Cloud platforms.

Cloud Volumes ONTAP is a software-only storage appliance that runs NetApp ONTAP data management software in the cloud. You get enterprise-grade storage features and extended support in Astra Control Service to:

In this blog post, I show you how to configure Cloud Volumes ONTAP as a storage back end for an example AKS cluster (pu-aks-cvo-01). I also show you how to manage and to protect the AKS cluster with Astra Control Service.

Steps to configure Cloud Volumes ONTAP as a back end

To make it easy to manage Cloud Volumes ONTAP and configure it as a storage back end for the AKS cluster, we use the NetApp BlueXP unified control plane in this setup. With BlueXP, you can manage all your storage and data assets from a single intuitive web-based interface.

Keep in mind that although this walk-through uses Cloud Volumes ONTAP for Azure and AKS clusters, you use a similar process for setting up Cloud Volumes ONTAP for Google Cloud and GKE clusters.

First, log in to the BlueXP management console (see how to set up BlueXP ), then select the correct account, workspace, and connector to your Azure environment. Now you can manage an already existing Cloud Volumes ONTAP instance, which is acsakscvobackend in this example, in Storage -> Canvas -> My Working Environments:

CVO AKS ACS 01 CVO AKS ACS 02

CVO AKS ACS 03Search for the test cluster pu-aks-cvo-01 in the list of discovered clusters, and click Next to add it to BlueXP:

CVO AKS ACS 04

CVO AKS ACS 05After you enter the working environment, click Install Trident to let BlueXP configure NetApp Astra Trident, a storage provisioner and orchestrator for the entire NetApp storage portfolio, on the AKS cluster:

CVO AKS ACS 06 07 CVO AKS ACS 06 07

Provide a storage class name and the configuration details for the storage class. Select No in Set as Default Storage Class, because Astra Control Service does that step later. Click Next:

CVO AKS ACS 08

BlueXP searches for available Cloud Volumes ONTAP instances to be configured as a K8s persistent storage back end. In this example, you select the Cloud Volumes ONTAP system acsakscvobackend and click Add to create the storage class and to configure Cloud Volumes ONTAP as its storage back end:

CVO AKS ACS 09

CVO AKS ACS 10Back in the BlueXP storage Canvas, you now see that the AKS cluster pu-aks-cvo-01 is connected to the Cloud Volumes ONTAP instance acsakscvobackend:

CVO AKS ACS 11

Steps to set up management and protection in Astra Control Service

Now you’re all set to manage and to protect your AKS cluster with Astra Control Service. You can also deploy applications with persistent volumes that are backed by Cloud Volumes ONTAP on the cluster.

Switch to the Astra Control Service console, and add the AKS cluster pu-aks-cvo-01 to Astra Control Service:

CVO AKS ACS 12The already configured Service Principal allows Astra Control Service to discover the available clusters in the Azure subscription, and you can filter for the pu-aks-cvo-01 cluster name. After you select the cluster, click Next:

CVO AKS ACS 13

During the process of adding the cluster to Astra Control Service, you’re asked whether you want to assign a new default storage class. Select as the new default storage class the Cloud Volumes ONTAP backed acsakscvobackend-cm storage class that was configured by BlueXP in the previous steps. When you have finished, click Add:

CVO AKS ACS 14

Astra Control Service detects that Astra Trident is already installed and configured on the AKS cluster and changes the default storage class to acsakscvobackend-cm:

CVO AKS ACS 15Now you’re ready to protect persistent applications on the AKS cluster with NetApp Snapshot copies and backups from Astra Control Service. As a demonstration application, here a WordPress instance is quickly deployed through its Bitnami Helm chart in the namespace wordpress:

~# helm install wordpress bitnami/wordpress --namespace wordpress --set wordpressUsername=astra,wordpressPassword= X --create-namespaceNAME: wordpressLAST DEPLOYED: Tue Jan 24 19:00:53 2023NAMESPACE: wordpressSTATUS: deployedREVISION: 1TEST SUITE: NoneNOTES:CHART NAME: wordpressCHART VERSION: 15.2.19APP VERSION: 6.1.1** Please be patient while the chart is being deployed **Your WordPress site can be accessed through the following DNS name from within your cluster:    wordpress.wordpress.svc.cluster.local (port 80)To access your WordPress site from outside the cluster follow the steps below:1. Get the WordPress URL by running these commands:  NOTE: It may take a few minutes for the LoadBalancer IP to be available.        Watch the status with: 'kubectl get svc --namespace wordpress -w wordpress'   export SERVICE_IP=$(kubectl get svc --namespace wordpress wordpress --include "")   echo "WordPress URL: http://$SERVICE_IP/"   echo "WordPress Admin URL: http://$SERVICE_IP/admin"2. Open a browser and access WordPress using the obtained URL.3. Login with the following credentials below to see your blog:  echo Username: astra  echo Password: $(kubectl get secret --namespace wordpress wordpress -o jsonpath="{.data.wordpress-password}" \| base64 -d)
Because acsakscvobackend-cm is set as the default storage class, the two persistent volumes for WordPress are backed by the Cloud Volumes ONTAP instance:
~# kubectl get all,pvc -n wordpressNAME                            READY   STATUS    RESTARTS        AGEpod/wordpress-57bd45f7b-8zbr2   1/1     Running   1 (3m25s ago)   4m56spod/wordpress-mariadb-0         1/1     Running   0               4m56sNAME                        TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)                      AGEservice/wordpress           LoadBalancer   10.4.62.227    20.75.179.28   80:32481/TCP,443:31567/TCP   4m57sservice/wordpress-mariadb   ClusterIP      10.4.126.147            3306/TCP                     4m57sNAME                        READY   UP-TO-DATE   AVAILABLE   AGEdeployment.apps/wordpress   1/1     1            1           4m57sNAME                                  DESIRED   CURRENT   READY   AGEreplicaset.apps/wordpress-57bd45f7b   1         1         1       4m57sNAME                                 READY   AGEstatefulset.apps/wordpress-mariadb   1/1     4m57sNAME                                             STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS          AGEpersistentvolumeclaim/data-wordpress-mariadb-0   Bound    pvc-2936728e-1f87-4b7f-9490-2ba1b5009690   8Gi        RWO            acsakscvobackend-cm   4m58spersistentvolumeclaim/wordpress                  Bound    pvc-96ad0163-ec69-4cb1-9ec6-eeea2f2a7c56   10Gi       RWO            acsakscvobackend-cm   4m58s  

Astra Control Service automatically detects the newly created namespace for WordPress on cluster pu-aks-cvo-01, and you can easily define the whole wordpress namespace as an application in Astra Control Service. When you have finished, click View in Applications:

CVO AKS ACS 16 CVO AKS ACS 17 CVO AKS ACS 18 CVO AKS ACS 19

The Snapshot copies take only a few seconds to be created, because they’re created by using the fast and efficient ONTAP Snapshot mechanisms:

~# kubectl get pvc,volumesnapshots -n wordpressNAME                                             STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS          AGEpersistentvolumeclaim/data-wordpress-mariadb-0   Bound    pvc-2936728e-1f87-4b7f-9490-2ba1b5009690   8Gi        RWO            acsakscvobackend-cm   7mpersistentvolumeclaim/wordpress                  Bound    pvc-96ad0163-ec69-4cb1-9ec6-eeea2f2a7c56   10Gi       RWO            acsakscvobackend-cm   7mNAME                                                                                                                        READYTOUSE   SOURCEPVC                  SOURCESNAPSHOTCONTENT   RESTORESIZE   SNAPSHOTCLASS                            SNAPSHOTCONTENT                                    CREATIONTIME   AGEvolumesnapshot.snapshot.storage.k8s.io/pvc-2936728e-1f87-4b7f-9490-2ba1b5009690-snap-c83ed35b-15d2-4a56-8637-dc20f59f7c53   true         data-wordpress-mariadb-0                           33676Ki       astra-netapp-csi-trident-netapp-io-vsc   snapcontent-6fcb2070-5c1d-4a23-80e1-321dd46c2e3d   36s            37svolumesnapshot.snapshot.storage.k8s.io/pvc-96ad0163-ec69-4cb1-9ec6-eeea2f2a7c56-snap-c83ed35b-15d2-4a56-8637-dc20f59f7c53   true         wordpress                                          250100Ki      astra-netapp-csi-trident-netapp-io-vsc   snapcontent-7b2a73da-f151-44b9-96c3-cd47f030e18d   36s            36s

Finally, with the application Snapshot copy in place, you can test a restore of the application to a new namespace on the same cluster. From the Actions menu of the Snapshot copy in Astra Control Service, you can directly start a restore by clicking Restore Application:

CVO AKS ACS 20Select wordpress-clone as the destination namespace and click Next:

CVO AKS ACS 21

Then start the restore after you check the restore information:

CVO AKS ACS 22

After a short while, the restored WordPress application in the new namespace comes up. Then you can confirm that its two persistent volumes also exist in the acsakscvobackend-cm storage class and are backed by Cloud Volumes ONTAP:

~# kubectl get all,pvc -n wordpress-cloneNAME                             READY   STATUS    RESTARTS   AGEpod/wordpress-65bccc5b66-d9jrz   1/1     Running   0          2m22spod/wordpress-mariadb-0          1/1     Running   0          2m22sNAME                        TYPE           CLUSTER-IP    EXTERNAL-IP    PORT(S)                      AGEservice/wordpress           LoadBalancer   10.4.8.187    20.62.183.37   80:30065/TCP,443:31078/TCP   2m22sservice/wordpress-mariadb   ClusterIP      10.4.154.28            3306/TCP                     2m22sNAME                        READY   UP-TO-DATE   AVAILABLE   AGEdeployment.apps/wordpress   1/1     1            1           2m23sNAME                                   DESIRED   CURRENT   READY   AGEreplicaset.apps/wordpress-65bccc5b66   1         1         1       2m23sNAME                                 READY   AGEstatefulset.apps/wordpress-mariadb   1/1     2m23sNAME                                             STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS          AGEpersistentvolumeclaim/data-wordpress-mariadb-0   Bound    pvc-39d96f88-a1b1-4054-a716-f2dba111e996   8Gi        RWO            acsakscvobackend-cm   2m25spersistentvolumeclaim/wordpress                  Bound    pvc-39b4c713-ecb9-4cf7-88b2-78c05a279c5f   10Gi       RWO            acsakscvobackend-cm   2m25s

Checking back in the BlueXP storage Canvas, you see that BlueXP detected the four created persistent volumes on the AKS cluster:

CVO AKS ACS 23

You can also find more details about the persistent volumes by drilling down into the pu-aks-cvo-01 AKS cluster:

CVO AKS ACS 24

Take advantage of NetApp’s continued innovation

With expanded Cloud Volumes ONTAP support for NetApp Kubernetes users, now you have yet another choice to store your persistent application data in GKE and AKS clusters.

Because NetApp continually innovates and enhances its product capabilities, now Astra Control Service can seamlessly manage and protect Cloud Volumes ONTAP backed persistent applications. In this blog post, I showed how easy it is to deploy Cloud Volumes ONTAP as a storage back end in Astra Control Service, so why wait? Get started today

Drift chat loading