Change Kubernetes requests and limits without putting applications at risk

Prometheus and Grafana show where requests and usage diverge. They cannot tell you whether an application can safely run with less.

The Technical Guide to Kubernetes Rightsizing with supporting resource review materials

Download The Technical Guide to Kubernetes Rightsizing to understand how Kubernetes scheduling, Linux cgroups, container metrics, and application runtimes interact before you change production resources.

By downloading, your email will be shared with CloudBolt, who may contact you about their products and services. You can unsubscribe from their communications at any time. See CloudBolt's privacy policy.

Grafana shows the gap but cannot explain it.

Metrics reveal how a container is being used, but they do not show what the application actually needs.For example, a flat memory graph does not tell you if the application still requires that memory, if the runtime is holding onto it for later, or if lowering it will lead to more garbage collection and higher CPU usage.

A low average CPU does not mean that setting a CPU limit is safe. Since quotas are enforced in short bursts, your application might still get throttled even if the dashboard shows unused CPU.

Prometheus and Grafana give you important data. Before you change production resources, make sure you know what Kubernetes and Linux are enforcing and how your application will react.

Understand the change before you make it

There is no single percentile, buffer, or tool that can turn container usage into safe requests and limits for every app.Build a technical model to interpret the data, involve the right people, and check the impact before changing production workloads.

By downloading, your email will be shared with CloudBolt, who may contact you about their products and services. You can unsubscribe from their communications at any time. See CloudBolt's privacy policy.

This series is made possible by

Diamond