When deploying a new web property to Kubernetes, it’s easy to set the resource limits and requests high. After all, we don’t want our application’s pods evicted incorrectly because we happened to guess too low. So better set the resource limits to near infinite just to get it quickly out the door.
However, with very high CPU and memory reservations, Kubernetes can’t schedule other work on the same node without over-allocating the machine. Worse still, if the application goes awry, we don’t have the built-in benefits of k8s and Shoreline’s continuous monitoring, keeping the fleet healthy.
After the software has been in place for a while, it’s time to level-up our infrastructure, and optimize for durability and cost savings. We need to right-size the resource limits and requests to match how the application actually performs in-place. This will help the product be successful in the long-term.
This Shoreline runbook allows an operator to compare the pod’s resource requests and limits to the container’s current and recent historical usage. If there’s a large discrepancy, the user can use the runbook to pick more appropriate limits, and apply it directly to the deployment, stateful set, or daemon set. Other cells in the runbook facilitate creating a ticket for the development team with the necessary k8s YAML diff to commit back to the GitOps repository, documenting the change, and ensuring it becomes permanent.
