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:
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
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.
- Log into your BlazeMeter account and click Settings in the top right corner.
- 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.
Click Add agent.
- Enter the agent name.
- (Optional) Enter the IP address of the machine.
- Click Create Agent.
- A Kubernetes installation command and configuration is generated on the Kubernetes Configuration tab.
- 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.
- Run the updated command on your private engine.
- Use the following command to check on the status of the pod launch for the crane deployment:
kubectl get pods
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
- Use the following yaml to create a namespace if required:
- 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 -
---
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: mydomain1-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 environments on a cluster with Istio setup.
Istio Configuration steps:
Set Up Istio
Follow these steps:
- Download the binary using the document
curl -L https://istio.io/downloadIstio | sh -
- Ensure that the cluster is clean. Run the command
kubectl get all
- Delete the projectcontour namespace if it is present. Run the command
kubectl delete ns projectcontour
Install and set a profile. Run the command
./istioctl install --set profile=demo -y
Enable the istio-injection. Run the command
kubectl label namespace default istio-injection=enabled
Create a Secret
Follow these steps:
- Create a secret by running the arguments below.
- 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: *.mydomain.local and the load balancer should have a wild card cert.) Run the command
openssl genrsa -out mydomain.local.key 2048
Run the command
openssl req -new -key mydomain.local.key -out mydomain.local.csr
- Run the command
openssl x509 -req -days 3650 -in mydomain.local.csr -signkey mydomain.local.key -out mydomain.local.crt
Run the command
rm mydomain.local.csr
Create a secret in istio-system name using the wildcard certs.
You have created a secret.
Deploy Gateway
Follow these steps:
- 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 - Deploy the gateway.
kubectl apply -f <path to yaml>/bzm_gateway.yaml
You have deployed a gateway.
Deploy an Agent
Follow these steps:
Create an agent in BlazeMeter private location section and copy the Kubernetes configuration.
Note: See Example Kubernetes Command.
- 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: mydomain.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-gatewayNote: 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"
Apply the changes to deploy the agent.
Verify the pods to ensure that the agent is running.
Once the agent is deployed, it will show up under the private location as shown below:
Deploying a HTTP txn mock creates an Istio virtual service.
The endpoint should be visible in the UI with the FQDN ending the subdomain. In this example, it is
"Mydomain.local"
- Stopping or deleting service deletes the Istio virtual service.
To verify Istio deployments, run the following commands:
kubectl get gw
kubectl get vs
You have deployed the agent.
Now that you have an Agent installed, let's review how you can use your new Private Location.
0 Comments