Saving money with Fargate
By Diego Sgro, Cloud Engineer at EDRANS.
Intro
Using AWS EKS with Fargate we can run pods without configuring any server, and we can also configure scaling options based on the traffic (using for example CPU/Memory metrics with HPA).
So, by using this scaling technique, we can scale up in working hours and reduce our deployments to run with at least 1 pod in non-working hours to save money; this article shows you how.
But, those pods have a cost associated and in some environments -like DEV, TEST, UAT- this means wasted money when nobody is using it.
What do we do then?
To fix it, we are going to create two Kubernetes CronJobs, one to stop all the pods in non-working hours, and another one to start them before the development team starts to work.
In this case in the working hours, we are going to have the scaled numbers of pods managed by the deployment/HPA, but in the rest of the time, we will reduce the number of pods to zero.
Resources
Let’s go through the implementation, using RBAC, Kubernetes CronJob, and kubectl scale.
First of all, we have to create two cron jobs: each CronJob passed the kubectl scale command for their respective deployments to set replica count to 0 (if we want to stop all pods) or 1 if we need to start our deployment.
Then we need a Role to grant access to modify deployments resources, and finally, a BindingRole to make a relationship between the Role and the ServiceAccount where the resources live.
In summary, we just need to create:
- Two Kubernetes CronJobs (Scale-Up/Scale-Down Jobs)
- A Role
- A RoleBinding
Scale-Up Job:
Scale-Down Job:
All CronJob schedule: times are based on the timezone of the kube-controller-manager so take care when you are setting this.
We also avoided starting during the weekend by specifying 1–5 for weekdays in our crontab expression.
Role:
RoleBinding:
Deployment
You can edit a file like scheduler.yaml, paste all of the block code, and apply it:
Now you can see that 4 resources have been created (2 cronjobs, 1 role, and 1 rolebinding):
Let’s list the CronJobs:
Here you can get information about:
- Name of the task
- Scheduled frequency to run
- Active (when the job is running it change to 1 and then back to 0 again)
- Last Scheduler execution
Testing
When the stop task runs, a new pod is created and modifies the deployment scale to 0, so the other pods will be killed.
If you try to get the pods again, you can see that all the pods were terminated and it only remains a Scheduler pod with “Completed” status:
Same way, when the time matches with the Schedule starter task, it runs, modifies the scale deployment to “1”, and the pods will be created again.
Also, you can see the logs and check what happened:
Or, by doing:
Configure
If you need to change the crontab expression, you can just edit the cron job object:
And change the “schedule” line:
Savings
Using the Fargate Pricing Calculator we can quickly estimate the costs (and savings) by using this solution.
Running 24/7:
Scheduled 10 hs x day (Mon-Fri):
Conclusion
The Cloud provides us the possibility to “pay as you go & pay per use”. But if you don´t remember to stop your unused services, you will pay for it! This is how you can save money using EKS Fargate in non-working hours, in non-prod environments.
Interested in Kubernetes, EKS & AWS? Join us @ Edrans!