Crafting the appropriate number of replicas in Kubernetes and OpenShift to manage fluctuating workloads, with variable incoming requests or tasks, can be a challenging task.
This blog will guide you on utilizing Kubernetes Event-driven Autoscaling (KEDA) with IBM Cloud Monitoring in order to define your application's maximum and minimum replica counts based on metrics.
What is KEDA?
KEDA is a lightweight component that works with native Kubernetes Horizontal Pod Autoscaler extending its functionality and performing its operations with four main components:
The KEDA operator interacts with specific CRDs (triggerauthentications and/or clustertriggerauthentication, scaledobjects and scaledjobs).
The diagram below shows how KEDA interacts with external sources to trigger the HPA to scale up and down your application.
Deploying KEDA with Helm
You can deploy KEDA in Kubernetes and OpenShift with 3 simple steps:
-
Add Helm repository
|
helm repo add kedacore https://kedacore.github.io/charts
|
-
Update Helm repositories
-
Install keda Helm chart
|
helm install keda kedacore/keda --namespace keda --create-namespace
|
Scaling a web application connecting KEDA to IBM Cloud Monitoring
First, let’s deploy an example application based on Nginx with 2 replicas:
kubectl apply -f webapp.yaml -n webapp
|
apiVersion: apps/v1
kind: Deployment
metadata:
name: webapp
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:alpine-slim
ports:
- containerPort: 80
name: web
resources:
requests:
cpu: 100m
memory: 100Mi
limits:
cpu: 100m
memory: 100Mi
|
KEDA requires managing the authentication via TriggerAuthentication or ClusterTriggerAuthentication that references the IBM Cloud Monitoring API Token. See how to get the IBM Cloud Monitoring API Token in this document.
You just need to create a secret with your IBM Cloud Monitoring API Token.
kubectl create secret generic keda-prom-secret --from-literal=bearerToken=<API_KEY> -n webapp
Reference this secret in a new TriggerAuthentication object you can create in the application namespace:
kubectl apply -f triggerauthentication.yaml -n webapp
|
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
name: keda-prom-creds
spec:
secretTargetRef:
- parameter: bearerToken
name: keda-prom-secret
key: bearerToken
|
Finally, define how you want to manage the automatic scale of your webapp creating the ScaledObject. In this case, we’ll be scaling our application when CPU usage of all replicas is in average above 80%:
Note: the serverAddress parameter would depend on the IBM Cloud Monitoring instance region.
kubectl apply -f scaledobject.yaml -n webapp
|
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: nginx-scale
spec:
scaleTargetRef:
kind: Deployment
name: webapp
minReplicaCount: 2
maxReplicaCount: 5
cooldownPeriod: 30
pollingInterval: 30
triggers:
- type: prometheus
metadata:
serverAddress: https://<region>.monitoring.cloud.ibm.com/prometheus
metricName: sysdig_container_cpu_cores_used_percent
query: |
avg(sysdig_container_cpu_cores_used_percent{kube_namespace_name="webapp", kube_workload_name="webapp"})
threshold: "80"
authModes: "bearer"
authenticationRef:
name: keda-prom-creds
|
Notice the metricName parameter. This is a custom name you set for receiving the value from the query. Keda gets the result of the query and creates the sysdig_container_cpu_cores_used_percent metric with it. Then, it uses this metric to trigger the escalation.
You can use any available metric when using KEDA and IBM Cloud Monitoring, system metrics for resource utilization (CPU or memory) but also custom metrics coming from your application (pending requests, latency, etc).
Learn more about IBM Cloud Monitoring
In this article, you learned how easy it is to deploy an Horizontal Pod Autoscaler with Keda that is triggered by metrics from IBM Cloud Monitoring. Click this link to start using IBM Cloud Monitoring today!