SELIGA #10 - Pay less, pay only for what you use, and optimize!

In cloud or on-premise environments, you can reduce your Kubernetes cost in a smart way. Apply the guidelines I explain below, save money, and then order a delivery pastel as a reward!

Here are two very important tips that can greatly reduce your infrastructure costs: 

Adjust the fixed size of your cluster and make good use of your Cloud's elasticity.
Ok, but how do you arrive at the correct sizing for your workload? 

• Install a monitoring stack, track startup and usage over a period of time. This will give you some room to maneuver, so adjust these limits whenever possible. The use of NodePools can be a great ally to segregate workloads.

  
  

• Create guaranteed pods. This type of pod is the cheapest for reasons such as availability, pre-analysis of resource usage and, as its name suggests, is guaranteed and unlikely to be removed in favor of another application.

  
  

Bonus tip:

Try to create the images as small as possible. "FROM scratch" or at least from an "Alpine" are already great steps, because it reduces the size of the images, avoids wasting time on downloads, and the risk of full disks on the nodes. Check out this more complete post on the subject.

Conclusion

Remember: the cost reduction routine is continuous. Every day it is necessary to check infrastructure usage, adjust resources, be aligned with the business team so campaigns are successfully met without downtime, validate the scalability of your environment, and track the cloud expense report.

Sometimes, learning how a monitoring stack works - like Prometheus, Alertmanager, Grafana and family (tempo, loki, etc.) - can save you a lot of money, besides giving you the pleasure of teaching your colleagues how to use top-of-the-market tools admired by everyone!

If you are feeling brave, run a chaos routine: turn off nodes and decrease replicas. Force a situation to analyze recovery time and how much it will cost you. 

Important: the cost of cloud or Kubernetes is not only due to resource usage, but also due to its unavailability in a disaster scenario.