As a part of the web ecosystem, our main concern is how to create an application that handles more, many more requests and how to keep it afloat. Am I wrong?

Whatever you have, such as monolith, microservices, or functions you need to create ways to deal with the concern. You can add a new machine into your infrastructure (please don’t say, “ok boomer”, I’m not!) or watch the actions from your monitoring systems and click the red button: auto-deploy the new instance and split the traffic! Or, you can create your rules before the chaos, automate your scaling, lay back, and enjoy it!

What about Kubernetes universe?

If you live in Kubernetes, it gives a hand for the deals with **HorizontalPodAutoscaler **API — a.k.a. _HPA — . _You can easily say _“hey! If the memory/CPU consumption of my application is more than X, please add a new Pod!” _If you use **metric-server **cluster add-on, you could get these values with metrics.k8s.io API.

What if my needs are different than CPU or memory consumption?

For instance, I want to scale my application according to incoming requests per minute. It’s the most natural wish for the web, isn’t it? Or, it’s the main goal of the story, I would like to scale my function by the total call count.

Let’s say hello to custom metric. You can create your own custom adapters to collect your own metrics or you could use known solutions. At the end of the road, you reach the values with custom.metrics.k8s.io API.

Throughout the story, we’ll use Prometheus Adapter as a known solution to collect the Kubeless function metrics and auto-scale the functions.

Let’s do it!

Before the roll up our sleeves, I need to list the environment:

Kubernetes version is 1.16.13

Prometheus version is 2.20.1

Kubeless version is 1.0.7

Helm version is 2.16.1

Prometheus adapter version is 0.7.0

I assume that you have a ready-in-use Kubernetes cluster and Prometheus server. If don’t, there are a lot of useful articles on the web about to setup them.

#helm #kubernetes #prometheus #autoscaling #kubeless