In my previous post, we discussed how to take advantage of VPA to implement automatic vertical scaling for our Konnect Data Planes. In this post, we'll focus on HPA for horizontal Kubernetes Pods autoscaling.
VPA docs recommend not using VPA along with HPA on CPU or memory metrics at this moment. HPA should be configured with custom and external metrics instead.
Since we'll be running fundamental HPA use cases, let's delete the VPA policy with:
Horizontal Pod Autoscaler (HPA) is a standard API resource in Kubernetes that automatically updates a workload resource, for example a Deployment, to match a throughput demand.
The following diagram was taken from the official Kubernetes HPA documentation. Please check it out to learn more.
HPA requires metrics provided by the Kubernetes Metrics Server, we have already installed. The Metrics Server collects resource metrics from the kubelets in your cluster, and exposes those metrics through the Kubernetes API.
To have better control of the HPA environment, let's set our Konnect Data Plane deployment requesting more CPU and memory resources:
Also, to see HPA in action, we are going to replace the existing NodeGroup with a smaller one, this time based on the t3.large Instance Type with 2 vCPUs and 8GiB of memory:
The Kubernetes Autoscale command tells HPA how to proceed to instantiate new Pod replicas. The command tells that HPA should create new replicas of the Data Plane when the CPU usage reaches the 75% threshold. HPA should create up to 10 replicas of the Data Plane.
You can use the HorizontalPodAutoscaler CRD instead. Bear in mind this is a basic use case, there are many other scenarios addressed by HPA. Please, check the HPA documentation to learn more about it.
Check the HPA with. Since we haven't consumed the Data Plane yet, the HPA current usage is unknown.
Now, you are going to submit the Data Plane to a higher throughput in order to see HPA in action, spinning up new replicas of the Pod. Additionally, this is a long 20-minute run, so we should see how HPA performs in a scenario like this. First of all, make sure you delete any Fortio Pods you might have running.
After some minutes, you should see a new status:
If you check the running Pods you should see new replicas were started. However, there are two of them in the Pending status.
Let's check one of them a bit closer. The condition message says there are no more CPUs available to be allocated, hence the Pod has not been scheduled.
For more evidence, you can check the Nodes consumption themselves and see it has run out of resources:
The straightforward solution would be to create new Nodes for the Cluster. That's the main reason why we should use a cluster autoscaler mechanism alongside HPA.
Amazon EKS supports two autoscaling products:
Check out the third part of this series to see Kubernetes Cluster Autoscaler in action.
Zero to Hero on Amazon EKS with Konnect’s Mesh Manager We’re excited to announce a new addition to our Kong Konnect EKS Blueprint Family: the Kong Konnect Mesh EKS Blueprint Add-on to deploy your Mesh Zones. Deploy your zones securely on AWS with
"To prioritize the safety and security of the ecosystem, Kubernetes SIG Network and the Security Response Committee are announcing the upcoming retirement of Ingress NGINX . Best-effort maintenance will continue until March 2026. Afterward, there w
We’re at it again, bringing more incremental improvements to Kong Mesh! Built on top of Kuma, Kong Mesh brings much-needed simplicity and production-grade tooling. Kong Mesh is built for smooth operations with platform teams in mind, providing secu
We are happy to announce the latest release for both Kong Mesh and Kuma, which is packed with features and improvements. Kong Mesh 1.7 is focused on security and stability, as it allows to better integrate with AWS thanks to a native AWS ACM integra
A quick refresher: Kong Cloud Gateways Kong Cloud Gateways are fully managed, high-performance data planes running on customer-dedicated infrastructure, orchestrated and operated by Kong through Kong Konnect . Customers can choose between: Serverle
Using Konnect Advanced Analytics for a faster real-time measurement of what your users are experiencing Earlier this year the Kong Konnect Analytics team was looking to leverage the stability and flexibility of our own Kong Gateway to handle the e
This blog addresses the common challenges organizations face with fragmented API management in Kubernetes environments and presents Kong Konnect combined with the Kong Ingress Controller (KIC) as a comprehensive solution. We'll highlight the issues