hamburger icon close icon
Azure File Storage

Out-of-This-World Kubernetes Performance on Azure with Azure NetApp Files

October 8, 2019

Topics: Azure NetApp Files 5 minute read

On June 1, 2019, Microsoft announced the GA of their latest shared file service: Azure NetApp Files (ANF), a PaaS shared file service that supports both NFS and SMB protocols. Historically, NetApp technology has been widely used in on-premises deployments with Kubernetes and OpenShift, so many users have some knowledge of the inner-workings of NetApp products. With the official general availability launch of ANF, however, Azure users will be able to take advantage of this ultra-low latency and high-performance platform without needing familiarity with the foundations of NetApp products at all.

That means that users of Azure will be able to easily use ANF without having to know any NetApp at all.

Out-of-This-World Kubernetes Performance on Azure with ANF

Now, with the release of Trident (19.07)—a dynamic storage provisioner for Kubernetes/OpenShift/Docker—Azure users can quickly ensure that their containers and applications are able to easily take advantage of the benefits of ANF, automatically.

Why Use ANF?

A great question with a simple answer: Using ANF as your underlying data platform allows you to take advantage of features like:

  • Consistent sub-millisecond latency: Your apps will be extremely responsive.
  • Scalability: Grow cloud volumes in ANF up to 100TB in seconds.
  • Simplicity: With three performance levels that lay bare performance possibilities, you’ll be able to focus on the important things, as opposed to worrying about your application responsiveness because of the underlying data platform.

How Do I Get Started With ANF?

Getting started is simple.  I’ll run you through a sample end-to-end deployment in this section. But first, let’s take a moment to understand the deployment options for Azure NetApp Files and Kubernetes in Azure.

Supported deployments for Kubernetes in Azure

Azure NetApp Files with AKS

This guide will focus on using AKS-Engine to deploy our Kubernetes clusters because (though it goes without saying, really) you want full control of your management nodes to use advanced features like dynamic provisioning of Azure NetApp Files storage.

Kubernetes Deployment in ANF looks like this:

  1. Deploy Kubernetes cluster in Azure using AKS-Engine.
  2. Install Trident into the master node.
  3. Configure Azure NetApp Files.
  4. Done!

And with that, let’s get started (grab a coffee first!).

Deploy Kubernetes cluster in Azure using AKS-Engine

In order to configure the Kubernetes features for advanced data management offered by Trident you will need to enable the flags described here. aks-engine is the deployment mechanism used by AKS to deploy clusters. Using it directly gives you more control over the management node, while still allowing you to perform easy upgrades, among other things. Detailed deployment instructions can be found here.

  1. Create a resource group
    az group create — name k8s — location <yourLocation>
    For example, I use “westeurope” as my location. You can run an Availability Zone list (account-locations) to view all the location codes. Be sure that you’re deploying your cluster in a location/region offered by Azure NetApp Files!

  1. Find your subscription:
    az account list -o table

    Take note of your subscription ID because you’ll need it later.

  1. Create the service principal for the Kubernetes cluster
    a. We will use a service principal in order to provide security and permissions to Trident for our Azure NetApp Files resources:

    az ad sp create-for-rbac — role=”Contributor” -scopes=”/subscriptions/<yourSubId>/resourceGroups/Kubernetes”

    b. Once you’ve created your service principal, assign it a role by navigating to “Subscriptions” -> select your subscription -> “IAM” -> “Add Role Assignment”

Access control (IAM)

  1. Deploy Kubernetes cluster using aks-engine
    Make a note of the appId and password because you’ll use these in the next command.

    Next, we’ll use aks-engine to deploy our cluster.

An example configuration file called kubernetes.json is available at my GitHub repo.
In this example, I’ll deploy a small cluster using Standard_B2s VM sizes. Be sure to change api-model below to match the correct path of your config file.

aks-engine deploy — subscription-id <yourAzureSubID> \
— dns-prefix <enterAnyName> \
— resource-group <yourResourceGroupName>\
— location <westeurope> \
— api-model examples/kubernetes.json \
— client-id <appId> \
— client-secret <password>\
— set servicePrincipalProfile.clientId=”<appId>” \
— set servicePrincipalProfile.secret=”<password>"

This configuration will deploy your cluster. If you used the example file provided above, you will have deployed the latest version of Kubernetes.

  1. Download and install Trident
    a. Now that your cluster is up and running, log into the management node via SSH and run the following commands:

    wget https://github.com/NetApp/trident/releases/download/v19.07.0/trident-installer-19.07.0.tar.gz
    tar -xf trident-installer-19.07.0.tar.gz
    cd trident-installer

    b. Now install Trident with the following command:

    ./tridentctl install -n trident

    Once finished you can check the status of your installation with the following commands:

    ./tridentctl -n trident version

.tridentctl -n trident version

and

kubectl get pod -n trident

kubectl get pod -n trident

  1. Configure the backend.

    Now that Trident is installed, the next step is configuring the backend. Trident supports a wide variety of backends and, in this instance, I have provided a quick start template here. More advanced configurations can be found here.

  2. Once the backend configuration is created, run:

    ./tridentctl -n trident create backend -f backend-azure-anf-advanced.json

tridentctl -n trident create backend -f backend-azure-anf-advanced

  1. Next, let’s add a storage class, a quickstart template that will create a class called azure-netapp-files is here.

    kubectl create -f storage-class-csi.yaml

    storage class

       
      Check the status of your storage class (above) with:
   
   kubectl get sc azure-netapp-files

  1. Next, create a persistent volume claim (PVC)


    kubectl create -f pvc-basic.yaml

    persistent volume claim

    You can monitor the status of your PVC with the following command. A volume typically takes 1–3 minutes to provision.

PVC Volume

Congratulations! Your Kubernetes Cluster is Now Using Azure NetApp Files!

Optional: You can set Azure NetApp Files to be the default storage class with the following two commands:

  1. Set the storage class called azure-netapp-files (if you used the quickstart — or your storage class name if you specified differently)
    kubectl patch storageclass azure-netapp-files -p ‘{“metadata”: {“annotations”:{“storageclass.kubernetes.io/is-default-class”:”true”}}}’

  1. Remove the old default (Azure Managed Disks)

    kubectl patch storageclass default -p ‘{“metadata”: {“annotations”:{“storageclass.kubernetes.io/is-default-class”:”false”}}}’

That’s it! Your applications are now able to take advantage of the fastest shared file storage in Azure and get out-of-this-world Kubernetes performance!

Become the Cloud Genius at Your Organization.

Read the top three reasons why your cloud first mandate needs Azure or learn more about how you can use Azure NetApp Files without knowing any NetApp at all.

Principal Technologist

-