Knative as a pod time-machine

This morning I came across this awesome article by Joseph Burnett ., he had articulated very well how auto scaling works and how to configure it properly.

As a prequel to Joseph Burnett story I would like to share the developer sentiments around:- How do I configure scale to zero? (save some more money for my boss and bag my extra incentive ;) )

Knative is configured to scale to zero only after some seconds.As a developer I was always curious on how to configure the scaling parameters the controls the scale to zero. In this story am going to share how exactly we can do it.

Where it is configured ?

All the auto scaling related configurations are stored in a Kubernetes ConfigMap called config-autoscaler of the knative-serving namespace. Let us pull it out using the command kubectl -n knative-serving get cm config-autoscaler to find what it contains by default:

apiVersion: v1
kind: ConfigMap
metadata:
name: config-autoscaler
namespace: knative-serving
data:
container-concurrency-target-default: "100"
container-concurrency-target-percentage: "1.0"
enable-scale-to-zero: "true"
enable-vertical-pod-autoscaling: "false"
max-scale-up-rate: "10"
panic-window: 6s
scale-to-zero-grace-period: 30s
stable-window: 60s
tick-interval: 2s

The two attributes scale-to-zero-grace-period and stable-window are very critical to compute when Knative can scale down your service deployment to zero. The termination period is sum of the properties scale-to-zero-grace-period and stable-window, with my elementary mathematics I came with the following formulae:

termination period of the service pod = stable-window + scale-to-zero-grace-period

As a developer, you don’t believe me until you see it happening on your machine right? Thats good, don’t worry I am just going make you feel it as well ;).

To get started let us deploy the following service in your Knative environment:

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
name: greeter
spec:
runLatest:
configuration:
revisionTemplate:
spec:
container:
image: quay.io/rhdevelopers/knative-tutorial-greeter:0.0.1
livenessProbe:
httpGet:
path: /healthz
readinessProbe:
httpGet:
path: /healthz

After successful deployment you will see the service running in your environment. How do I fire request, how do I check if it’s working ? …. Wait wait wait … we don’t need all of those for this exercise, all we need is patience. What patience ? Yes! because you are going to be idle watching your command prompt without playing with the your knative service :).

To watch your service scale up and down you can just use the command watch kubectl get pods.

Use any timer you want (I just used my stopwatch on phone), you will see the pods starting to terminate approximately 1 min and 30 secs since its ready state. Hooray ! that is what we computed earlier right?

The developer in us woke up again, you know they are very impatient because their keyboard is idle for quite sometime ;), so I decided to make them happy now.

My boss felt we can make to run these applications for a bit more longer ( whispering … got some new budget allocation in this new year), so my developer wanted to increase the scale-to-zero-grace-period to 1 minute.

Do I need to edit configmap config-autoscaler ?

Yes you are right! edit the config map config-autoscaler of knative-serving and update the value to be like 1m(1 minute). If your service pod has already been terminated we need to wake that guy up, how do I do that ? fire a http request as shown below:

INGRESSGATEWAY=istio-ingressgateway
IP_ADDRESS="$(minishift ip):$(kubectl get svc $INGRESSGATEWAY --namespace istio-system --output 'jsonpath={.spec.ports[?(@.port==80)].nodePort}')"
curl -H "Host: greeter.example.com" $IP_ADDRESS

You will see your service up and running, back to our stopwatches now, our developer is busy watching the stopwatch … Voila! when it is just over 2 min you will see your service starting to terminate!

One last point before I leave your developer play more, the configmap attribute scale-to-zero-grace-period is a “dynamic parameter” i.e. any updates to this value are reflected immediately to all its consumers; while all other parameters are static parameters i.e. change to it need a restart of the autoscaler deployment of knative-serving namespace.

Our developers are now really happy that they were able to hack something nice on Knative today.

Enjoy your further journey with Knative! See you sometime later with another story.