>> Hello and welcome. In this video,
we'll be going over KEDA. Let's get started.
KEDA is an Event Driven
Autoscaler for Kubernetes that allows you to
scale your workload when running
Kubernetes based on external events,
which could be Cloud events
like Azure Blob storage events, Azure Event Hubs,
Log Analytics or Service Bus or queues,
as well as many other
open-source event sources like MongoDB,
Prometheus, RabbitMQ or Redis, and many more.
To get started with KEDA on AKS,
I have an AKS cluster here that I just created.
Then I just need to deploy KEDA to it.
To do that, I need to add the KEDA Helm chart repo
and then just create the namespace and deploy KEDA.
Since I already have the Helm chart edit,
I'm just going to create the namespace,
then install KEDA in that namespace.
This should take a couple seconds.
Now I can check the pods in that namespace.
These are the KEDA pods, and once they are running,
I can start deploying applications
that will scale based on the event.
What I have here is
an Azure queue that's empty right now.
I want my application to only run pods if they were
actually messages in the queue
for the application to consume.
If I look at my application here,
I have a deployment that
starts with the replica zero because that's what I want.
I don't want it running if there is nothing in the queue.
It uses this secret to connect the app to Azure queues.
Then I deploy this also scaled object.
Let's get to work with that deployment.
The scaled object, as you can see here,
refers to deployment by name.
This scaled object is for the deployment.
It also specifies the min and max replica count
that I want this deployment to be running at.
If there are no messages,
I want it to be at zero.
If there are a lot of messages,
I want the maximum to be running is 10.
The triggers that activates
that deployment are defined here.
In this case, it's only Azure Queues.
I want the ideal queue length per pod to be five.
This is my queue name and
then we have to get the secret file.
If I go and deploy this deployment,
now I have to create it here.
If I come here and I do keep scale deployments,
I can see that my deployment is not
running because I don't have anything in the queue.
Let's go put a message there on the queue.
I'm going to add a little "Word" message.
When I add it here, I should see
this deployment start running
at one to consume that message.
Once that message is consumed,
the deployment should scale back to
zero after the cool-down period
that we have defined there.
This is the activation and deactivation of deployment.
To scale beyond one,
I need to add a lot of messages on that queue.
Here scaled back to zero because now
it's done processing all the messages.
I have another producer
here that will put a few thousand messages in the queue.
If I come here and refresh this,
I should see those messages starting to come in here.
Then this deployment is going to start
scaling between the min and max that I have set for it.
We should see it scale yet now striking out four and it's
going to keep scaling up
to match that queue length that was specified there.
As you can see, messages are actually being consumed
from the queue now by these four deployments.
Once they all catch up and drain that queue completely,
my deployment will scale back to zero.
Now it's running at eight instances.
I still have messages in the queue
that are being consumed. Now the queue is empty.
Now we should see it begin to scale down back
to zero since older messages
that we have put in the queue have been consumed.
This same behavior works for
all the other scalars that KEDA has.
KEDA has a lot of different scalars that worked with
all different Cloud event sources as well
as Kubernetes events as well as
other open source components that will work through this.
If you'd like to read more about KEDA,
checkout documentation in the KEDA website.
Thank you for watching this demo.