Deploy Blazemeter private location engine to your Kubernetes cluster using HELM chart. Plus the chart allows to make advanced configurations if required.
- A BlazeMeter account
- A Kubernetes cluster
- Latest Helm installed
- The kubernetes cluster needs to fulfill Blazemeter Private location requirements
To start with, Blazemeter user will need Harbour_ID, Ship_ID & Auth_token from Blazemeter.
-
Get the Harbour_ID, Ship_ID and Auth_token through BlazeMeter GUI
- Login to Blazemeter & create a Private Location
- Copy the Harbour_ID once the private location has been created in BlazeMeter.
- Create an Agent
- Copy the Ship_ID & Auth_token, you can copy Harbour_ID if you missed it earlier.
-
Get the Harbour_ID, Ship_ID and Auth_token through BlazeMeter API
-
Pull/Download the chart - tar file from the github repository
-
Untar the chart
tar -xvf blazemeter-crane-(version).tgz
- Open
values
file to make ammendments as per requirements
vi values.yaml
- Add the Harbour_ID, Ship_ID and Auth_token in the
values.yaml
file.Harbour_ID
,Ship_ID
andauthtoken
is the one we aquired before see[2.1].
env:
authtoken: "[auth-token]"
harbour_id: "[harbour-id]"
ship_id: "[ship-id]"
- If the proxy needs to be configured, change the value for
enable
toyes
. Now, add the configuration forhttp_proxy
or/andhttps_proxy
. Make sure the values are set toyes
before adding the proxypath
, as shown below:
proxy:
enable: yes
http_proxy: yes
http_path: "http://server:port"
https_proxy: yes
no_proxy: "kubernetes.default,127.0.0.1,localhost,myHostname.com"
- Now, if you want to configure your Kubernetes installation to use CA certificates, make changes to this section of the values.yaml file:
- Change the
enable
toyes
- Provide the path to certificate file respectively for both (ca_subpath & aws_subpath). The best thing is to just copy/move these cert files in the same directory as this chart and just provide the name of the certs instead of complete path.
- Change the
ca_bundle:
enable: no
ca_subpath: "certificate.crt"
aws_subpath: "certificate.crt"
volume:
volume_name: "volume-cm"
mount_path: "/var/cm"
-
Please avoid switching the
serviceAccount.create
toyes
, as serviceAccount other thandefault
will cause issues with Blazemeter crane deployments. Though I have setup code which will successfully create a new serviceAccount and assign it to all resources in this Helm chart, this is something we need to avoid for now. -
Change
auto_update: false
if you do not want the cluster to be auto-updated (Not recommended though).
auto_update: "'true'"
- Lastly, you can name the namespace for this deployment, just add the name in
namespace
, and this helm chart will be installed under that namespace.
deployment:
name: crane
namespace: "bm"
- If you plan to deploy the Blazemeter crane as a non_Priviledged installation, make changes to this part of the
values
file.
non_privilege_container:
enable: no
runAsGroup: 1337
runAsUser: 1337
Change the enable
to yes
and this will automatically run the deployment and consecutive pods as Non_root/Non_priviledge.
- If this OPL/Private location is going to run mock services using istio-ingress, make changes to this part of the
values
file.
istio_ingress:
enable: no
credentialName: "wildcard-credential"
web_expose_subdomain: "mydomain.local"
pre_pulling: "true"
istio_gateway_name: "bzm-gateway"
Change the enable
to yes
and this will automatically setup istio-ingress for this installation. Which will allow outside traffic to access the mock-service pod. However, make sure istio is already installed and configured as per the Blazemeter guide
- If this OPL/Private location is going to run mock services using nginx-ingress, make changes to this part of the
values
file.
nginx_ingress:
enable: yes
credentialName: "wildcard-credential"
web_expose_subdomain: "mydomain.local"
Change the enable
to yes
and this will automatically setup nginx-ingress for this installation. Which will allow outside traffic to access the mock-service pod. However, make sure nginx is already installed and configured. Blazemeter guide
- If user/admins require the AUTH_TOKEN for any crane installation to be secret/secure, the ENV values for AUTH_TOKEN can be inherited from the k8s secret. User needs to make changes to this part of the
values
file.
env:
authToken:
# if you want to pass the AUTH_TOKEN through secret in the crane ENV variables set secret to yes and add secret name and key
secret:
enable: yes
secretName: "your-secretName"
secretKey: "auth-token"
# if secret is not enabled, please enter the AUTH_TOKEN below directly.
token: "MY_SAMPLE_TOKEN-shfowh243owijoidh243o2nosIOIJONo2414"
Change the enable
to yes
and this will automatically inherit the AUTH_TOKEN values from the secret user provide in the following values. Make sure the cluster/namespace has the secret applied in the following format:
apiVersion: v1
kind: Secret
metadata:
name: your-secretName
namespace: blazemeter
type: Opaque
data:
auth-token: ZjIzZjU0ZTIwODk5ZWYwYzgzYmJkMzZmYzU3ODlhNzc3ODJjYTY1YjJjODIzZTMyMjY3NDcxM2QzZTc3Mzg2Yw==
- If user/admins require certain set of labels as part of the deployment of a cluster resource, we can use this
labels
values. These labels will be Inherited from the crane when the child pods are deployed. Because, note that labels added to crane deployment will not be automatically inherited by the child pods. Switch theenable
toyes
and add labels in a Json format as per the example:
labels:
enable: yes
labelsJson: {"label_1": "label_1_value", "label_2": "label2value"}
- If user/admins require a CPU, MEM limit to be applied to all cluster resources, we can use this
resourceLimit
values. These resource limits will be Inherited from the crane ENV when the child pods are deployed. Because, note that resource limit added to crane deployment will not be automatically inherited by the child pods. Switch theenable
toyes
and add resource limits in a string format as per the example:
resourceLimit:
enable: yes
CPU: "800m"
MEM: "4Gi"
- Once the values are updated, please verify if the values are correctly used in the helm chart:
helm template .
This will print the template helm will use to install this chart. Check the values and if something is missing, please make ammends.
- Install the helm chart
helm install crane blazemeter-crane --create-namespace --namespace=bm
Here, crane is the name we are setting for the chart on our system and blazemeter-crane is the actual name of the chart. Make sure the namespace declared here is the same as the one we declared in the values file (see 2.3.2.6 section).
- To varify the installation of our Helm chart run:
helm list -A
It is recommended to install this Helm chart onto the auto-scalable cluster for example - EKS, GKE or AKS.
However, make sure you are scalling the nodes, as it is not recommended to go with EKS Fargate or GKE Autopilot, those types of autoscalling is not supported for Blazemeter crane deployments.
Therefore, always go with Node autoscalling
- 1.2.0 - Chart now supports service virtualisation deployment using nginx-ingress [4.7]
- 1.1.0 - Chart now supports inheriting labels and resourcelimits to child pods from crane environment [4.9] [4.10]
- 1.0.1 - The AUTH_TOKEN can now be inherited from a secret [4.8]
- 1.0.0 - Now supports service virtualisation deployment using istio-ingress [4.6]
- 0.1.3 - Supports configuration for non_proviledge container deployment, also added a license [4.5]
- 0.1.2 - Supports Proxy, CA_certs as an additional configuration of Blazemeter crane deployment [4.3]
- 0.1.1 - Support proxy as an additional configurable aspect of Blazemeter crane deployment [4.2]
- 0.1.0 - Supports standard - vanila Blazemeter crane deployment (no proxy or CA_Bundle configurable)