The rise of Kubernetes has resulted in an dramatic growth of new applications. Development projects no longer require funding for physical hardware or dedicated operating system instances. Containers eliminate production application library dependency issues since they inherently bundle in all the required libraries. Developers, operating under very rapid product release lifecycles, can very quickly roll out new application releases to shared production infrastructure. As a result, many business teams that previously would not consider creating applications have now started creating them.
However, as happens with the rise of any new technology, Kubernetes also creates new business challenges. For example, how do you quickly detect new enterprise application deployments on your various on-premises Kubernetes clusters? How do you protect the business-critical data that they are using? How do you capture application configuration changes? And when necessary, how do you safely migrate those application deployments to a different Kubernetes cluster ? NetApp Astra Control enables you to easily address and solve these challenges.
In this post we will cover how Astra Control Service (ACS): A NetApp-managed service that provides application-aware data management of Kubernetes clusters in AKS, can help you resolve these challenges. In combination, we will be using Azure Netapp Files as persistent volume storage backend.
Let’s take a look into Astra control plane:
First of all, we should discover our AKS cluster from Astra. If you don’t have an AKS cluster already deployed and connected to ANF, you can refer to the following anfcommunity’s article: https://anfcommunity.com/2021/02/16/azure-netapp-files-trident-dynamic-and-persistent-storage-for-kubernetes/
Important: You don’t need to install Trident in AKS, since once the cluster is discovered with Astra, Trident will be automatically installed!
If we don’t have it already, we would need to create a Service Principal account for Astra to be able to discover our AKS cluster. Astra Control requires an Azure Service Principal account with Contributor role access to the subscription hosting your Kubernetes clusters.
Store the resulting output as a file that you will provide to Astra Control to manage your Kubernetes data management operations. You would need the Subscription ID and the mentioned Service Principal to discover your cluster:
Once entered, you should be able to see the eligible AKS clusters. Make sure you have an eligible cluster to be discovered by Astra.
Next step would be the storage configuration. The wizard would display the available service level in ANF, and we should select the one that would be considered as the default storage class in AKS:
Review the configuration and click “Add cluster”:
After the cluster addition, we should be able to see the AKS cluster in the clusters tab:
Including the configured storage classes:
Let’s take a look into our AKS cluster to see what is been installed from the CSI side. Trident is installed within the trident namespace by default. Using tridentctl command we may see the configured backends. On the AKS side, we can check the storage classes that would be linked to the trident backned for ANF. In this case, the default one is ANF standard:
Now that we can see trident installed and the ANF backend configured, let’s deploy an application in our AKS cluster. I will use a mysql deployment with a persistent volume running in ANF (you can find it here: https://github.com/josem-gomez/Trident_ANF/blob/main/mysql-deployment-pvc_anf_standard-2.yaml)
Let’s check what it’s just been created in AKS. If everything was successful, we should see a deployment, replicaset, pod and the correspondent persistent volume claim (this one running automatically in ANF thanks to Trident):
Let’s get back to Astra and check the apps tab:
We should see an unprotected application in the list. So, let’s manage it!
Next step would be to configure a protection policy for the app:
We will stablish one daily snapshot and 4 hourly snapshots. Important! These are ANF (Netapp) snapshots that will be automated via Astra. If you need to know more about ANF snapshots, take a look into this link: https://docs.microsoft.com/en-us/azure/azure-netapp-files/snapshots-introduction
As you can see in the screenshot above, you can also decide to keep the snapshot as a backup and it will be moved to object storage (blob). That not only means that you can define a longer retention period at a lower cost but also that, since it resides outside the cluster, will also be available in case AKS is deleted accidentally or even if the AKS region fails.
Review the protection policy configuration:
After some time and depending on our protection policy schedule, we should start seeing the correspondent snapshots and backups in Astra:
Having stateful Kubernetes workloads using a rich set of storage and application-aware data management services powered by NetApp is never been easier!
If you want to know more about ANF and Astra, take a look into the following links: