KEDA

PRESENTATION
BY –
VIKAS UPADHYAY
KEDA
(Kubernetes Event-driven Autoscaling)
 KEDA (Kubernetes Event-driven Autoscaling) is an open-source framework designed to enable
efficient autoscaling of Kubernetes workloads based on events.
 It allows us to dynamically scale your containerized applications running on Kubernetes based on
various external events, such as message queues, streaming platforms, or custom metrics.
 Use Cases of KEDA
 Scaling Event-Driven Workloads: KEDA automatically scales
Kubernetes workloads based on incoming events, ensuring optimal
resource allocation.
 Efficient Resource Utilization: KEDA dynamically adjusts resource
allocation, avoiding overprovisioning and optimizing resource usage
in Kubernetes.
 High Performance: KEDA enables quick and efficient handling of
workload spikes, ensuring high performance and responsiveness
during peak event traffic.
 Seamless Event Integration: KEDA integrates smoothly with event
sources (e.g., Kafka, RabbitMQ) in Kubernetes, allowing
autoscaling based on event volume or defined metrics.
 Microservices Scaling: KEDA scales individual microservice
instances based on workload, optimizing resource utilization and
performance in Kubernetes microservices architectures.
 Simplified Management: KEDA simplifies workload management
by automating scaling based on events, reducing manual
intervention and streamlining operations in Kubernetes.
 Use KEDA when
 You have event-driven workloads in Kubernetes
that require automatic scaling based on incoming
events.
 You want to optimize resource utilization by
dynamically adjusting resources to match
workload demands.
 You need to handle workload spikes and maintain
high performance during peak event traffic.
 You want seamless integration with event sources
like Kafka, RabbitMQ, or Azure Event Hubs.
 You have microservices architectures and want to
scale individual instances based on workload.
Avoid KEDA when:
 You have workloads that are not event-
driven and don't require autoscaling
based on events.
 Your workloads have predictable and
consistent resource demands, and manual
scaling is sufficient.
 You don't have event sources or event-
driven requirements in your Kubernetes
environment.
 You are already using alternative
autoscaling solutions that meet your
specific needs.
 Pros of KEDA
 Automatic scaling: KEDA enables automatic
scaling of container workloads based on events,
ensuring your application can handle varying
workloads efficiently.
 Resource optimization: KEDA allows fine-
grained control over scaling behavior, optimizing
resource utilization and cost efficiency.
 Wide event source support: KEDA supports
various event sources, making it easy to integrate
with different event-driven architectures.
 Seamless Kubernetes integration: KEDA
integrates smoothly with Kubernetes, leveraging
its management capabilities for containerized
workloads.
Cons of KEDA
 Learning curve: As with any new
technology, there may be a learning curve
involved in understanding and effectively
using KEDA.
 Complexity for simple use cases: If your
application has a simple and predictable
workload without much need for event-
driven scaling, implementing KEDA
might introduce unnecessary complexity.
 Dependency on Kubernetes: Since KEDA
relies on Kubernetes, you need to have a
Kubernetes cluster set up and operational
to use KEDA effectively.
There is an example of a test queue with a CLI and also we can do it from
the AWS console by using the IAM service

cat > sqs.json <<EOF

{
"Version": "2012-10-17",
"Statement": [
{ With this, you will have a sqs.json
"Effect": "Allow", file that will give permission to do
a GetQueueAttributes on that
"Action": "sqs:GetQueueAttributes",
specific SQS queue.
"Resource": ”<ARN of queue>"
}
]
}
EOF
Now We have to create a policy regarding this role

 There is an example with the CLI and we can do it from the AWS console also by
using the IAM service

aws iam create-policy --policy-name keda-sqs

--policy-document file://sqs.json
 Now We have Policy so now comes EKS part

let's use EKSCTL to create the IAM role

Let's create the namespace. and Service Account with CLI
 Command –  Command –

Kubectl create ns keda eksctl create iamserviceaccount --name keda-

operator
--namespace keda
--cluster <Cluster-name>
--attach-policy-arn <Policy ARN>
--region <Region>
--approve
Just copy the policy ARN and paste it here.
Now we have a Service Account named Keda-Operator in the Keda namespace that has permission to
read the SQS queue. This means that we just need to deploy KEDA and tell it to use this Service
Account.

 We use helm for deploying KEDA

 Add the repo of KEDA by the helm

helm repo add kedacore https://kedacore.github.io/charts

 The secret is not to let Helm create the Service Account but to reuse the one we created.

helm install keda kedacore/keda --namespace keda

--set serviceAccount.create=false
--set serviceAccount.name=keda-operator

 Soon we will see two pods in the keda namespace. As soon as both are in Running.
 apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: aws-sqs-queue-scaledobject
namespace: default

We have to create the scaled object rules spec:

against the service deployment whatever we scaleTargetRef:

name: <your-service-deployment>
want to scale. To make the rule we need to
minReplicaCount: 0
create a YAML file.
maxReplicaCount: 5
pollingInterval: 5
Then apply the deployment file with - cooldownPeriod: 25
triggers:
kubectl apply –f <scaled-object>.yaml - type: aws-sqs-queue
metadata:
queueURL: <URL of a queue>
queueLength: "10"
awsRegion: "<Region>"
identityOwner: operator
The ScaledObject is the specific configuration of the integration between KEDA
and the product that will provide the data to scale. In this case, it is AWS SQS
 Let's take a look at the spec parameters

 minReplicaCount - If there is nothing in SQS, keep 0 replicas.

 maxReplicaCount - Can scale up to a maximum of 5 replicas.
 pollingInterval - Retrieve information from the queue every 5 seconds.
 cooldown period - Wait 25 seconds to scale in (remove replicas).
 Subsequently, in metadata, is where the magic happens.

 queue length - How many messages can each pod process? For example, if each pod can process 10
messages, set the value to 10. If you have 30 messages in the queue, there will be 3 pods processing
the requests.
 identityOwner - How will authentication and authorization be done? In this case, we are telling it to
reuse the IAM role of the pod operator.
If want to learn more about KEDA these are the GITHUB page and
documentation of KEDA

GITHUB:-HTTPS://GITHUB.COM/KEDACORE/KEDA

SAMPLES:-

HTTPS://GITHUB.COM/KEDACORE/SAMPLES

DOCUMENTATION

HTTPS://KEDA.SH/DOCS/

Thank You