Eric Dapp is an Adoption Engineer at BlazeMeter and an instructor at the BlazeMeter University. He's got over 3 years experience in performance testing, helping teams realize their performance and automated testing goals.

Become a JMeter and Continuous Testing Pro

Start Learning

Test Your Website Performance NOW! |

arrowPlease enter a URL with http(s)

Deploying BlazeMeter Private Locations on Azure Kubernetes Service

This post is a guide to deploying BlazeMeter Private Locations on Azure Kubernetes Service (AKS). AKS will be a means to our deployment but the general procedure, outside of creating the cluster and AKS specific steps, is relevant for any Kubernetes Platform that you may be using. Note that in order to be able to follow along with this tutorial, there are four things you will need: (1) a Microsoft Azure Account with the ability to deploy Kubernetes Clusters and have the ability to set any roles and cluster roles in that environment, (2) Azure CLI (az) installed locally, (3) Kubernetes Command-line tool (kubectl) installed locally, and (4) a BlazeMeter account with the ability to create and edit Private Locations.


Deploying an Appropriate Cluster


While logged in to Azure's Portal, go to Kubernetes Service and create a new cluster. This cluster will have to use a resource group with nodes large enough for the pods that are going to run our performance tests. We recommend nodes with at least 2 CPU and 8GB RAM. But note that these recommendations are dependent on the type of tests that are going to be run, and what you expect will be the load that a single pod will produce.


Deploying BlazeMeter Private Locations on Azure Kubernetes Service


Note also that the pods that you use to run your tests will not have the entire machine's resources available to it, as there is some overhead in running the other containers that facilitate Kubernetes management and any monitoring that may be going on.


This means that you should not expect a node with 2 CPU and 8GB RAM to be able to support pods that request 2 CPU and 8GB RAM. Keep this in mind when setting up your cluster and when setting up the CPU and Memory Overrides in BlazeMeter, we'll touch on this part in a bit.



Logging into Azure CLI



Once the cluster is started on AKS, it's time to access that cluster. With Kubectl and Azure CLI installed on your machine, you can log into your Azure account by running the following command in your terminal.


`az login`



This will open a browser window and let you login as you would normally with the Azure Web Portal. Go back to your terminal, and you should see something like the following


    You have logged in. Now let us find all the subscriptions to which you have access...


        "cloudName": "AzureCloud",
        "homeTenantId": "<Home Tenant ID>",
        "id": "<id>",
        "isDefault": true,
        "managedByTenants": [],
        "name": "<Subscription Name>",
        "state": "Enabled",
       "tenantId": "<Tenant ID>",
       "user": {
          "name": "<username>",
          "type": "user"


Change your Kubectl context with the following command:

 `az aks get-credentials --resource-group <your resource group> --name <your cluster>`



You can check that this was successful by getting Kube's current context:


`kubectl config current-context`


which should print the name of your Azure cluster. If you don't see your Azure cluster's name here, go back to the Azure CLI Login and make sure that you are able to log into your account, also verify that your cluster has properly provisioned before moving forward.




The kubernetes deployment that we are going to perform will rely on the abilities of the service account that will be actually performing the actions, I'll be using the default service account in my "blazemeter" namespace.


 kind: Role
      name: role-crane
    - apiGroups: [""]
      resources: ["pods/exec"]
      verbs: ["create"]
    - apiGroups: [""]
      resources: ["pods", "pods/log"]
      verbs: ["get", "list"]
    - apiGroups: ["extensions", "apps", ""] # leave empty string for core
      resources: ["pods", "services", "endpoints", "daemonsets", "pods/*", "pods/exec", "deployments", "replicasets", "ingresses", "deployments/scale"]
      verbs: ["get", "list", "watch", "create", "update", "patch", "delete", "deletecollection", "createcollection"]


The YAML here details the namespace-level roles that we'll need to bind to our service account. To make use of this, you'll first need to apply these roles, save the YAML as "role.yaml" and use kubectl with the "-f" option to apply from file:


`kubectl apply -f role.yaml`



Note that I'm going to bind this role to a service account in the namespace `blazemeter`. So let's create the `blazemeter` namespace and change our kubectl context to it by running:


    kubectl create namespace blazemeter

    kubectl config set-context --current --namespace=blazemeter



To bind the role to the default service account in the `blazemeter` namespace run this command:


`kubectl create rolebinding <name of rolebinding> --role=<name of role> --serviceaccount=blazemeter:default -n blazemeter`



Similarly, you'll need to follow the same procedure for the cluster roles needed.


 kind: ClusterRole
      name: clusterrole-crane
    - apiGroups: [""] # "" indicated core API Group
      resources: ["nodes"]
      verbs: ["get", "list", "watch", "update", "patch"]


With this YAML saved as clusterrole.yaml, apply them with the following:


`kubectl apply -f clusterrole.yaml`


and bind the cluster role to the service account:


`kubectl create clusterrolebinding <name of clusterrolebinding> --clusterrole=<name of clusterrole> --serviceaccount=blazemeter:default`





Now that we've got our cluster created and configured, we need to add a Private Location in BlazeMeter, you can do this by going to You BlazeMeter settings, then under Workspace > Private Locations, click the big "+" button.


Deploying BlazeMeter Private Locations on Azure Kubernetes Service


When setting up the Private Location, it's important in this context to select "Shared" engine type, this will allow all the Private Location's engines to be controlled from a single deployment. Here, the “Parallel Engine Runs” setting will determine how many engine pods our private location will be able to start. We should change the “Engine’s hardware consumption” settings if we want to set a CPU and Memory override, which will determine the size of the pods that are used in our testing, taking into account the size of the nodes in your resource pool in AKS. If there are no nodes with enough resources to support the pods you want to create, your tests will not start as Kubernetes waits for a node with enough resources.


Next, choose the functionality that you want to have in this Private Location.


Deploying BlazeMeter Private Locations on Azure Kubernetes Service


Once the private location is set up, add an engine to that Private Location, this will produce a `docker run` command with environment variables we'll need for our deployment, so let’s take a look at the deployment YAML for Crane.


apiVersion: extensions/v1beta1
    kind: Deployment
        role: crane
      name: crane
      namespace: blazemeter
      replicas: 1
          role: crane
            role: crane
          - env:
            # - name: A_ENVIRONMENT       # Only Applicable for BlazeMeter Private Cloud
            #   value: <internal URL>
            - name: AUTH_TOKEN
              value: <AUTH_TOKEN>
            - name: HARBOR_ID
              value: <HARBOR_ID>
            - name: SHIP_ID
              value: <SHIP_ID>
            - name: CONTAINER_MANAGER_TYPE
              value: KUBERNETES
            - name: IMAGE_OVERRIDES
              value: '{}'
            - name: AUTO_KUBERNETES_UPDATE
              value: 'true'
            - name: DOCKER_REGISTRY
              value: '<your registry>'
            image: "<your registry>/blazemeter/crane:<crane version>"
            imagePullPolicy: Always
            name: bzm-crane
          restartPolicy: Always 



Crane is the main component of BlazeMeter Private Locations and orchestrates all the other components. You'll need to fill in the appropriate values for the A_ENVIRONMENT (if applicable), AUTH_TOKEN, HARBOR_ID, SHIP_ID.  If you're using an internal image repository, you'll want to point your deployment there in the DOCKER_REGISTRY and IMAGE_OVERRIDES environment variables, the latter of which will have a structure like this:


  {"taurus-cloud:latest": "<your registry>/blazemeter/v4:<version>", "torero:latest": "<your registry>/blazemeter/torero:<version>"}


The above image override configurations are what you will need for a Private Location deployment for Performance Testing.


You will also need to set the "image" field to the crane image in your private registry. If you're not using a private registry, the crane image can be set to<crane version>, to use the newest released version set the version to "latest-master".


If you would rather use a numbered version of the images, you can check the latest versions of BlazeMeter Images by logging into your BlazeMeter account in a browser, then in a new tab, go to this URL:{account_id}/private-locations/versions, making sure to fill in your BlazeMeter account number. This will redirect you to an authenticated RSS feed URL. Copy this URL for use with your RSS feed reader of choice.


When the deployment yaml has been configured, you can apply the deployment like this:


`kubectl apply -f deployment.yaml`



Here are some useful ways to interact with your deployment: Get a list of the pods currently running with


`kubectl get pods`



See logs of a pod with:


`kubectl logs <pod name>`



and to delete the Crane deployment use:


`kubectl delete deployment crane`



When you “get” pods through kubectl, you'll see only the crane pod is running, as crane will manage the starting of any pods you will use for your testing.


Now let’s get testing!


On any BlazeMeter Performance test configuration page, select your new Private Location under "Load Distribution", and configure your test to run the way you want it to.


Deploying BlazeMeter Private Locations on Azure Kubernetes Service


Make sure that your test configuration fits within the resources you have set up in this Private Location. After everything is set up, click the “Run Test” button. If we go back to our terminal and run `kubectl get pods` we will see a new pod (or pods) starting up, which is where our performance test will run. And there we have it, we’re running our performance test, scaling the load engines via Kubernetes using AKS.


Ready to get started? Sign in to your BlazeMeter account or put your URL in the box below.

arrowPlease enter a URL with http(s)

Interested in writing for our Blog?Send us a pitch!