Installing a BlazeMeter Agent for Kubernetes

The following article explains how to install a BlazeMeter on-premise agent for Kubernetes on your server/instance behind your firewall.

When adding an on-premise agent for a Private Location, you will come across commands for Docker and Kubernetes installations, which can be copied and run on your machine to install the agent.

Ensure that you update all environment variables according to your Kubernetes instance.

BlazeMeter supports the following Ingress controllers for Kubernetes:

• Contour
• Istio

Mock Services use Istio and Contour to help route Ingress traffic into the desired pod in containers and the cluster. We support Contour as well as Istio for defining Ingress traffic.

Contour Configuration

• Install Kubernetes Agent
• Using the Kubernetes Auto-Generated Command

Install Kubernetes Agent

BlazeMeter provides two methods for installing a Kubernetes agent:

• Automatic: Involves copying a BlazeMeter auto-generated command, then replacing and/or adding the environment variables with your own. This is a straightforward method recommended for most use cases.
• Manual: Involves creating separate YAML files, filling them with your environment variables, and executing them individually. This method is recommended for special use cases; i.e., if you need to use CA certificates with your agent.

The following steps walk you through the automatic method. For the manual method, see this article.

Prerequisites: Before proceeding with installation, make sure your server/instance meets the minimum requirements.

1. Log into your BlazeMeter account and click Settings in the top right corner.
   
2. Navigate to the Private Location where you want to create the Agent. Go to Workspaces, Private Locations and choose the Private Location.
   

   Tip: A reminder that for our Kubernetes implementation, your Private Location needs to support a Shared Run Type instead of Dedicated. See Creating a Private Location for details.

3. Click Add agent.

   

4. Enter the agent name.
5. (Optional) Enter the IP address of the machine.
6. Click Create Agent.
   
7. A Kubernetes installation command and configuration is generated on the Kubernetes Configuration tab.
   
8. Copy the command, then update and/or add to the environment variables as per details of your Kubernetes instance. For details, see the following Using the Kubernetes Auto-Generated Command section and also BlazeMeter Agent Environment Variables.
   

   Note:

   • When installing an agent behind a corporate proxy, follow these additional steps.
   • When installing an agent on a host with multiple network interfaces, follow these additional steps.
   • If your application requires a custom certificate to be able to communicate over HTTPS, see Optional Installation Step: Bring Your Own Certificate – Mock Services.

   Important: If you are installing an agent that uses a CA certificate, we recommend using the manual install method instead.

9. Run the updated command on your private engine.
10. Use the following command to check on the status of the pod launch for the crane deployment:
    

    kubectl get pods

11. Once the Kubernetes pod shows as 'Running', the agent will show to be in an 'Idle' status and will be available for use. Visit this article to learn how to use your new private location!

    

Using the Kubernetes Auto-Generated Command

When adding an on-premise agent for a Private Location, you will come across commands for Docker and Kubernetes installations, which can be copied and run on your machine to install the agent.

The Kubernetes auto-generated command allows you to consolidate all configuration and deployment variables for a simpler execution.

Prerequisites for using the auto-generated command

• You must have a cluster admin access to execute the command.
• You must replace all instances of namespace with your assigned namespace. See the Kubernetes documentation for best practices for a namespace.
  • Use the following yaml to create a namespace if required:

    apiVersion: v1
    kind: Namespace
    metadata:
    name: BLAZEMETER

• If using Contour as Ingress controller, do not forget to comment out the Contour stanza (the last part of the auto-generated command).
• You can also add and/or replace other environment variables as per your instance. See the complete list of BlazeMeter Agent Environment Variables for details.

Example auto-generated command

cat <<'_FILE_1234567890_END_' | kubectl apply -f -  # guide: https://guide.blazemeter.com/hc/en-us/articles/360015269617
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata: { namespace: BLAZEMETER, name: role-crane }
rules: [{ apiGroups: [''], resources: [pods/exec], verbs: [create] }, { apiGroups: [''], resources: [pods, pods/log], verbs: [get, list] }, { apiGroups: [extensions, apps, ''], resources: [pods, services, endpoints, daemonsets, 'pods/*', pods/exec, deployments, replicasets, ingresses, deployments/scale], verbs: [get, list, watch, create, update, patch, delete, deletecollection, createcollection] }]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata: { name: role-binding-crane }
subjects: [{ kind: ServiceAccount, name: default, namespace: BLAZEMETER }]
roleRef: { kind: Role, name: role-crane, apiGroup: rbac.authorization.k8s.io }
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata: { name: cluster-role-crane }
rules: [{ apiGroups: [''], resources: [nodes], verbs: [get, list, watch, create, update, patch] }]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata: { name: cluster-role-binding-crane }
roleRef: { apiGroup: rbac.authorization.k8s.io, kind: ClusterRole, name: cluster-role-crane }
subjects: [{ kind: ServiceAccount, name: default, namespace: BLAZEMETER }]
---
apiVersion: apps/v1
kind: Deployment
metadata: { name: crane, labels: { role: role-crane, harbor_id: 5fab0840a7cf6b5c2a3aa414, ship_id: 5fb2f5a65c99071c0f79bfd6 } }
spec: { selector: { matchLabels: { role: role-crane, harbor_id: 5fab0840a7cf6b5c2a3aa414, ship_id: 5fb2f5a65c99071c0f79bfd6 } }, replicas: 1, strategy: { type: Recreate }, template: { metadata: { labels: { role: role-crane, harbor_id: 5fab0840a7cf6b5c2a3aa414, ship_id: 5fb2f5a65c99071c0f79bfd6 } }, spec: { restartPolicy: Always, terminationGracePeriodSeconds: 30, containers: [{ name: bzm-crane-5fb2f5a65c99071c0f79bfd6, image: 'blazemeter/crane:latest', imagePullPolicy: Always, env: [{ name: HARBOR_ID, value: 5fab0840a7cf6b5c2a3aa414 }, { name: SHIP_ID, value: 5fb2f5a65c99071c0f79bfd6 }, { name: AUTH_TOKEN, value: c2d9fccc40a1391c4a3ff1000039feba6ed4908d73f2abce4ca6a67434a211ee }, { name: CONTAINER_MANAGER_TYPE, value: KUBERNETES }, { name: IMAGE_OVERRIDES, value: '{}' }, { name: DOCKER_REGISTRY, value: gcr.io/verdant-bulwark-278 }, { name: AUTO_KUBERNETES_UPDATE, value: 'true' }] }] } } }
## Uncomment following YAML to grant read/write access to HttpProxy in Contour
# ---
# apiVersion: rbac.authorization.k8s.io/v1
# kind: ClusterRole
# metadata: { name: contour-access-cluster-role }
# rules: [{ apiGroups: [''], resources: [nodes], verbs: [get, list, watch, create, update, patch] }]
# ---
# apiVersion: rbac.authorization.k8s.io/v1
# kind: ClusterRoleBinding
# metadata: { name: contour-access-for-default-sa }
# roleRef: { apiGroup: rbac.authorization.k8s.io, kind: ClusterRole, name: contour-access-cluster-role }
# subjects: [{ kind: ServiceAccount, name: default, namespace: BLAZEMETER }]
_FILE_1234567890_END_

Istio Configuration

Mock Services use Istio to help route Ingress traffic into the desired pod in containers and the cluster.

Gateway

Gateway serves as a load balancer configuration and as an entry point into your cluster. In gateway, you can define ports that you want to expose and you can list different hosts (domain names) that each of the ports should handle.

Virtual Services

Istio handles traffic through the gateway. You can create resources called virtual services that serve as a bridge between the gateway and the actual services that are running on your Kubernetes cluster.

For incoming traffic that is targeting a given host name (example: blazevse1-9090-default.mocks.yoursite.com), a virtual service forwards traffic to a specific service which then forwards it to the pod and the containers within your cluster.

Sidecar Injection

Additionally, for any pod that you create in your cluster, Istio will inject a container that helps inforce mutual TLS traffic for anything that is going in and out of your pods.

The following procedures show how to set up and validate BlazeVSE on a cluster with Istio setup.

Istio Configuration steps:

• Set Up Istio
• Create a Secret
• Deploy Gateway
• Deploy an Agent

Set Up Istio

Follow these steps:

1. Download the binary using the document ‘curl -L https://istio.io/downloadIstio | sh -‘.
2. Ensure that the cluster is clean. Run the command ‘kubectl get all’.
3. Delete the projectcontour namespace if it is present. Run the command `kubectl delete ns projectcontour`.

4. Install and set a profile. Run the command `./istioctl install --set profile=demo -y`.

   

5. Enable the istio-injection. Run the command `kubectl label namespace default istio-injection=enabled`.

   

Create a Secret

Follow these steps:

1. Create a secret by running the arguments below.
2. Generate a wildcard cert using openssl.

   Note: Ensure that the common name is set properly in csr. The common name will be your subdomain.
   Example: *.blazevse.local and the load balancer should have a wild card cert.)

3. Run openssl genrsa -out blazevse.local.key 2048

   

4. Run openssl req -new -key blazevse.local.key -out blazevse.local.csr

   

5. Run openssl x509 -req -days 3650 -in blazevse.local.csr -signkey blazevse.local.key -out blazevse.local.crt

6. Run rm blazevse.local.csr

   

7. Create a secret in istio-system name using the wildcard certs.

   

You created a secret.

Deploy Gateway

Follow these steps:

1. Here is a sample of the gateway file contents:
   

   apiVersion: networking.istio.io/v1alpha3
   kind: Gateway 
   metadata: 
   name: bzm-gateway 
   spec: 
   selector: 
   istio: ingressgateway 
   servers: 
   - hosts: 
   - "*" 
   port: 
   name: http-80 
   number: 80 
   protocol: http 
   - hosts: 
   - "*" 
   port: 
   name: https-443 
   number: 443 
   protocol: https 
   tls: 
   mode: PASSTHROUGH 
   - hosts: 
   - "*" 
   port: 
   name: https-15443 
   number: 15443 
   protocol: https 
   tls: 
   mode: SIMPLE 
   credentialName: wildcard-credential

2. Deploy the gateway.
   

   `kubectl apply -f <path to yaml>/bzm_gateway.yaml`

You deployed a gateway.

Deploy an Agent

Follow these steps:

1. Create an agent in BlazeMeter private location section and copy the Kubernetes configuration.

   Note: See Example Kubernetes Command.

   

2. Copy the Kubernetes Configuration agent creation command and update / add the following:
   
   
   • Update the namespace ‘BLAZEMETER’ with the namespace where you want to deploy crane, in this example, replace with ‘default’.
   • Update imagePullPolicy value:
     imagePullPolicy: Always
     
     Add the below properties under spec of kind Deployment:
     
   • name: KUBERNETES_WEB_EXPOSE_TYPE
     value: ISTIO
   • name: KUBERNETES_WEB_EXPOSE_SUB_DOMAIN
     value: blazevse.local
   • name: KUBERNETES_WEB_EXPOSE_TLS_SECRET_NAME
     value: wildcard-credential
   • name: KUBERNETES_SERVICE_USE_TYPE
     value: CLUSTERIP
   • name: KUBERNETES_USE_PRE_PULLING
     value: "true"
   • name: KUBERNETES_ISTIO_GATEWAY_NAME
     value: bzm-gateway

     Note: The environment variable KUBERNETES_ISTIO_GATEWAY_NAME is optional. If it is not set, the crane agent creates a gateway resource for every mock deployment.

   • name: KUBERNETES_SERVICES_BLOCKING_GET
     value: "true"
     

3. Apply the changes to deploy the agent.

   

4. Verify the pods to ensure that the agent is running.

   

5. Once the agent is deployed, it will show up under the private location as shown below:

   

6. Deploying a BlazeVSE virtual service or HTTP txn mock creates an Istio virtual service.

   

7. The endpoint should be visible in the UI with the FQDN ending the subdomain. In this example, it is "blazevse.local".

   

8. Stopping or deleting service deletes the Istio virtual service.

9. To verify Istio deployments, run the following commands:
   kubectl get gw
   kubectl get vs

   

You deployed an agent.

Now that you have an Agent installed, let's review how you can use your new Private Location.