In this video, you'll see how you can use Kubernetes-based Event Driven Autoscaler (KEDA)
to proactively scale your Kubernetes workloads.
With this solution, you can define the events that drive the autoscaling response and employ
horizontal pod autoscaling to deploy Amazon Elastic Kubernetes Service (Amazon EKS) clusters
efficiently and cost effectively.
To get started, let’s create an Amazon EKS cluster.
We’ll work in the AWS Cloud9 integrated development environment.
Let's access the configuration file we'll use.
The file creates a cluster and a service account with query access to Amazon Managed Service for Prometheus.
This is the service account the KEDA operator will use.
It also creates an AWS Fargate profile with four namespaces.
Let's configure the cluster.
It will take a few minutes for the cluster to come online.
Let's go to the Amazon EKS console to check the cluster’s progress.
The cluster now has a Fargate profile provisioned with namespaces.
Let's return to the Cloud9 terminal.
The cluster has been created.
Again, this is the configuration file we used.
Let’s confirm that the pods are running in the Fargate infrastructure.
We can see that the pods have Fargate IPs.
Next, we’ll need to deploy the KETA operator.
First, let's check whether the KEDA Helm chart is part of the cluster's repositories.
It is, so let's access the configuration file for the KEDA operator.
The file sets the security context.
Let's deploy the KEDA operator to the KEDA namespace.
We'll confirm by calling for the pods.
The status for the new containers is "pending."
Let's continue checking until they achieve a "running" status.
Next, we'll provision a workspace in Amazon Managed Service for Prometheus.
Now let's visit Amazon Managed Service for Prometheus console to view the workspace.
The workspace is active.
Let's return to the Cloud9 terminal.
Next, we'll deploy a sample application called “ho11y” that we can use to scrape metrics into the workspace.
To install the application, we’ll clone a repository from GitHub.
Let's enter the ho11y directory.
Before we can build the image, we'll establish the AWS environment for the application.
Let's go to a new terminal to find the AWS Account ID.
Let's copy the ID and return to the main terminal.
We'll also define the AWS Region, using the location of our EKS cluster.
Let's run the command to build a Docker image of the application.
Now we'll upload the image to the Amazon Elastic Container Registry (Amazon ECR).
Let's log in.
We'll create a repository for the sample application.
In this case, the repository already exists.
Let’s proceed.
Let’s go to the Amazon ECR repository to confirm that the Docker image was pushed.
Here's the repository.
Here’s the Docker image.
Now we can deploy the sample application.
Let's return to the Cloud9 terminal.
We'll build a "ho11y" namespace first, which is where the application will be deployed.
Let's access the configuration file.
The sample application deploys a frontend and two backends to the ho11y namespace.
Let’s deploy it.
Now let's check the pods to monitor the deployment.
Once all three pods are in a "running" status, we can proceed.
Next, we'll deploy the AWS Distro for OpenTelemetry (ADOT)
to scrape the metrics and send them to the Amazon Managed Service for Prometheus workspace.
We'll set up some environment variables first.
Let's export the EKS cluster.
We'll also deploy an AWS Identity and Access Management service account
with remote-write access to Amazon Managed Service for Prometheus.
The service account has been successfully created.
Now let’s set up some more environment variables.
Let's capture the workspace URL.
Let's go to the Amazon Managed Service for Prometheus console to verify it's correct.
On the workspace page, we can verify that the Endpoint remote-write URL matches the one we used.
Let's go back to the terminal.
Let's access the configuration file for deploying the AWS Distro for OpenTelemetry.
The file contains parameters for scraping the ho11y sample application.
Let's copy the file onto the kubectl CLI to put it into effect.
Let's review the file once more and confirm the remote-write endpoint.
The endpoint was correctly placed.
Now, let's go back and apply the file in the ho11y namespace.
Let's check on the pods to confirm they've been provisioned and are all running.
Next, we'll configure AWS Signature Version 4 (sigv4) authentication for querying the workspace.
Since KEDA doesn’t support sigv4, we'll deploy a proxy.
Let's access and then apply the sigv4 proxy configuration file.
We'll check the pods to monitor the deployment.
The configuration was successful.
Now we'll apply a ScaledObject specification to define how KEDA should scale the querying application.
It builds a ScaledObject and creates a Horizontal Pod Autoscaler (HPA) object.
Before we move on, let's check our pods.
We want to configure one of the backend pods, "downstream zero," as our target for ADOT
when scraping the metrics.
Let's recall the workspace and copy the server address.
We'll view the YAML file again.
Let's edit the server address we just copied so they match.
We're ready to apply the ScaledObject.
Let's call for the ho11y namespace on the HPA.
We'll also call the ScaledObject.
We can see its target, configured minimum and maximum values, and that our Prometheus workspace is the trigger.
Let's also view the HPA.
Here we see the name of the target metric, the replica counts, and its average value.
We're ready to apply some load to the ho11y application.
Before we run the command, let's go to Amazon Managed Grafana.
We'll connect a Grafana dashboard with Amazon Managed Service for Prometheus to visualize the metrics we're loading.
Let's view our workspaces.
We'll use an existing workspace.
Let's log in.
We'll view our AWS Data Sources.
We'll add an Amazon Managed Service for Prometheus data source.
Let's supply the Region where we've provisioned our resources.
Now we can see the workspace we built earlier.
Let's add the data source.
Now we'll go to the Explore page.
We’ll select the data source we just added.
On the left side of the panel, we can review the observable metrics.
Let's return to the Cloud9 terminal and put some load on the application.
We can see some trace IDs generating.
In the second terminal, let's monitor the ho11y namespace.
The target average value count, which had been zero, is now very high, indicating the application is accepting load.
Let’s go back to the Grafana console.
We'll select a metric.
Let's revise the query to give the sum of the rate for a one-minute period, which was provided in the ScaledObject configuration file.
The graph shows that the value is within the desired range.
Let's return to the terminal and apply more load until the value exceeds 20,000.
We'll call for the HPA.
The value is 19,000, which is also in the desired range.
We'll keep applying load.
In a new tab, let's monitor the count.
Now the value has exceeded the range.
This initiated a successful re-scale event, as shown by the HPA size increasing from one to two.
Let's also view the pods.
There are now two "downstream zero" pods in "running" status,
confirming that KEDA could successfully scale the application using the metrics ingested into Amazon Managed Service for Prometheus.
We can also confirm this by going to the Amazon Managed Grafana console.
The graph shows that the 20,000-value threshold has been exceeded.
You've just seen how you can use KEDA to proactively scale your Kubernetes workloads.
You can learn more about this topic in the description and links for this video.
Thanks for watching.
Now it's your turn to try.