The Hidden Cost of Fixing Your Kubernetes Clusters
While the adoption of Kubernetes to speed software development has become a recipe for success in the containerized world, many organizations working to streamline and optimize their processes are encountering a major issue—namely, a heavy cost for repairs. When defects and other code issues occur without a cost-awareness and savings plan in place, the price of Kubernetes ownership can go through the roof. The good news is, cost optimization in Kubernetes boils down to two key words—proper configuration.
Along with security, compliance, reliability and scalability, cost optimization is now considered to be one of the five key enablers of business success and a major player in a Kubernetes service ownership model. While the issue of proper configuration touches each of these areas in different ways, the direct impact misconfiguration can have on the cost of Kubernetes ownership is a critical one to understand. Simply put, proper configuration of Kubernetes is what dictates how much organizations spend (or overspend, as the case may be) on their containerized workloads.
Misconfigurations Matter
Overall cost management of Kubernetes is inextricably linked to correct configuration in a few different ways. The Kubernetes platform is known for its ability to automatically scale resources up or down to meet certain demands. When owners run their containerized workloads without a clear sense of how much CPU or memory a specific application is expected to use, Kubernetes is forced to make a random guess about how best to scale.
Of course, setting proper requests and limits for compute resources is considered a best practice, but it’s far from mandatory. In fact, Kubernetes will happily accept workloads with zero optimization settings and send you the bill later. But practitioners paying attention to the overall cost of their Kubernetes clusters will soon see that ignoring these settings and leaving them up to the platform only leads to significant overspending. To make matters worse, misconfigurations in Kubernetes tend to grow increasingly hard over time, eating up time and creating security risks.
Kubernetes Nodes
Understanding what a Kubernetes workload really costs can be challenging in more ways than one. Aside from recognizing how misconfigurations impact spending, it’s also important to understand how Kubernetes nodes can affect cost. When Kubernetes runs your containerized workloads by putting them into pods, they are run on nodes. This Kubernetes node can be either a virtual or physical machine, depending on the cluster in question.
Kubernetes nodes are dynamic, which means they can be created and destroyed as the cluster scales—or replaced entirely in the event of a failure or upgrade. Kubernetes technology puts workloads into these nodes based on what it understands to be the most efficient use of resources—it’s called bin packing—much like a game of Tetris. When the pieces fit nicely together, space and cost can both be optimized. But when the resources on a node are shared across multiple applications and users do not have a clear sense of how the bin packing process works, space within the container is underutilized and often wasted—just like the money needed to pay for it.
Rightsizing Works
Teams working in Kubernetes can address these inefficiencies through a process known as rightsizing resources. In reality, these teams are responsible for setting and allocating the exact amount of memory and CPU needed for an application. When teams fail to clearly specify these settings or set them too high, costly mistakes are made.
When thinking about rightsizing workloads, it’s important to remember that a developer’s job is to build and ship software at the speed of business. When faced with an optional issue of configuration, such as memory requests and limits, they may not recognize the significance. Conversely, DevOps teams who attempt to set the proper amount of memory and CPU often overallocate resources out of concern that there may not be enough. From a developer’s point of view, more compute is a good thing and they are not always thinking about how this attitude affects overall cost optimization.
When Kubernetes is run without cost controls or a strong feedback loop for developers in place, cloud compute bills go up and up and up. Without the proper information, Kubernetes will continue to honor the CPU and memory settings it has been told to create. The containerized workloads will do their best to fit all the pieces together efficiently (and win the game of Tetris), but it can only do so much alone.