Requests set from what the pod used.
Not from what someone guessed at launch.
Datadog Kubernetes Autoscaling turns the container metrics Datadog already collects into rightsizing recommendations, and applies them through a DatadogPodAutoscaler when you let it. We check the prerequisites, pick the workloads, set the bounds, and run it every month so the cluster is sized for the traffic it has now.
Quick facts
Related
- Container Monitoring, the data the recommendations are built from
- Cloud Cost Management, what the recommendation is worth in your bill
- Infrastructure Monitoring, the nodes underneath
The requests in the manifest finally meet the usage on the graph
Every deployment in the cluster requests two cores and four gigabytes, because the first one did and the rest were copied from it. The scheduler believes the requests. The nodes fill up with reservations nobody uses. Kubernetes Autoscaling replaces the copied number with the measured one.
Recommendations from real history. Vertical recommendations are built from the last eight days of container usage that Datadog already holds, weighted towards recent samples, so a workload that changed last week is sized for last week.
One object per workload. A DatadogPodAutoscaler can scale replicas, scale requests, or both, with the Cluster Agent as the controller and bounds you set. The HPA and the VPA it replaces were two objects with two opinions.
Changes applied without the restart, where the cluster allows. On recent Kubernetes versions vertical changes can be applied in place. Elsewhere, the update strategy decides when pods are rolled, which means you decide.
The waste at cluster level, in money. The Cluster Scaling view shows idle CPU, idle memory and the cost of both per cluster, using your bill when Cloud Cost Management is on and default rates when it is not.
Two controllers, a disabled admission controller, and a recommendation taken in the quietest fortnight of the year
How it bills. Kubernetes Autoscaling is billed per autoscaled vCPU per month. The recommendations are computed from the container usage data the Agent already collects. Cloud Cost Management is optional and has its own meter. Datadog publishes the rates. We publish nothing here, because the price is not the problem. The configuration is.
The configuration traps. The product has real prerequisites: a recent Agent and Cluster Agent, Remote Configuration enabled on the organisation and in the cluster, the Admission Controller on, and Kubernetes State Core metrics flowing. When the Admission Controller is off, horizontal scaling works and vertical scaling silently does nothing. A workload with an HPA still attached has two controllers. A recommendation is only as good as the eight days behind it, and the eight days after a launch are not the eight days before one. None of this looks like an error. All of it looks like the product not working.
Field noteThe most common gap we see is the HPA that was never removed. The DatadogPodAutoscaler scales the deployment down, the HPA scales it back up, and the replica graph looks like a heartbeat. The ticket says autoscaling is flapping. Both controllers are doing exactly what they were told.
Field noteThe Admission Controller was disabled in the Helm values during an unrelated incident months earlier. Vertical recommendations are generated, accepted and applied, and the requests in the running pods never change. The conclusion drawn is that rightsizing is cosmetic.
Field noteRecommendations were reviewed and applied in the last week of December. They were right for the last week of December. The pods were evicted on the first busy Monday of January, the new requests were too small, and the rollback took the rest of the morning.
Field noteThe update strategy was left at its default, so the first batch of vertical changes was applied the moment the recommendation landed, which was the middle of the afternoon, and on that cluster applying it meant rolling the pods. Nothing broke. Everyone noticed. The next batch was approved three months later.
Prerequisites first. Stateless workloads second. Production on a window you chose.
We start with a Datadog HealthScan. It is read-only and fully automated, and it reports Agent and Cluster Agent versions, whether Remote Configuration and the Admission Controller are on, and which workloads have enough history to be worth a recommendation. Kubernetes Autoscaling only works on a cluster where Container Monitoring already works, so if that is not the case, we fix that first.
- Confirm the prerequisites, cluster by cluster. Agent and Cluster Agent versions, Remote Configuration, Admission Controller, Kubernetes State Core, and the orchestrator tag cardinality setting. Each one is checked, not assumed.
- Pick the workloads. Stateless deployments with a stable traffic pattern and at least a full cycle of history. Anything with an HPA or a VPA attached is listed, and the removal is agreed before the DatadogPodAutoscaler is created.
- Set bounds and strategy per workload. Minimum and maximum replicas, request floors and ceilings, vertical only where a workload cannot scale out, scale-down disabled where it should never shrink. Written down with the reason.
- Apply in non-production and watch a full cycle. The recommendations go live on a cluster that can afford to be wrong, through one weekly peak, before anything touches production.
- Roll out to production on a window you chose. Update strategies set so that pods are rolled when you expect them to be, one tier of workloads at a time.
- Hand over, in writing. Which workloads are autoscaled, with what bounds, and which were excluded and why. The autoscaled vCPU count and the Cluster Scaling idle figures on the day we finished.
Access is admin on the Datadog organisation with the Autoscaling and Workload Scaling permissions, plus read access to the cluster manifests and the Helm values or Operator configuration. Changes to the manifests go through your pipeline, not ours. We do not need cluster-admin on production, and we do not ask for it.
A recommendation is a snapshot. The traffic is not.
A new workload ships with copied requests. A seasonal peak arrives that the eight-day window has never seen. A team sets a bound during an incident and forgets it. Managed Observability is the monthly service that keeps Kubernetes Autoscaling matching the cluster it scales.
Every month, we review what was applied and what was held. Recommendations accepted, recommendations declined and why, and the autoscaled vCPU count against last month. Anything that moved gets a reason or a fix.
Coverage follows the deployments. A workload that shipped last month with copied requests is brought into scope once it has a full cycle of history, with bounds set the same way as the rest.
Bounds are kept honest. A floor set during an incident, a ceiling that a quiet quarter made irrelevant, a scale-down that was disabled for a migration that finished: each is revisited against what the workload actually did.
The cluster is read with the bill. With Cloud Cost Management in place, the Cluster Scaling view and the invoice are reviewed together, so the idle figure on the dashboard and the number finance sees are the same number.
We operate the stack. You own the product.
An implementation partner creates the autoscalers and hands over. A managed partner is still there when the January peak arrives and the December recommendations are wrong. We are the second kind. The DatadogPodAutoscaler manifests, the bounds and the reasoning stay in your repositories and your Datadog organisation, documented, and you can take them in-house whenever you choose.
Datadog is our proof, not our headline. Datadog certified one managed provider globally. We are it. The Powered by Datadog accreditation means Datadog's own engineers reviewed how we instrument, alert, respond and report. We are also a Datadog Advanced Partner, ISO 27001 certified and Cyber Essentials Plus certified, with offices in Cardiff, London and Dublin.
Datadog Kubernetes Autoscaling, answered plainly
How is Datadog Kubernetes Autoscaling billed?
Datadog bills Kubernetes Autoscaling per autoscaled vCPU per month. The recommendations themselves are computed from the container usage data the Agent already collects. We do not publish prices. The meters are what we tune, and the first decision is which workloads are worth putting under automated scaling at all.
Does Datadog Kubernetes Autoscaling replace the HPA and the VPA?
For the workloads it manages, yes. A DatadogPodAutoscaler can scale a workload horizontally, vertically or both from one object, with the Cluster Agent acting as the controller. Datadog recommends removing any existing HorizontalPodAutoscaler or VerticalPodAutoscaler from a workload before handing it over, because two controllers with different opinions about the right replica count will take turns being right. Workloads you leave alone keep whatever they had.
Can Datadog Kubernetes Autoscaling scale the nodes as well as the pods?
The generally available product scales workloads: replicas and resource requests. The Cluster Scaling view shows idle CPU, idle memory and cost per cluster so the node-level waste is visible. Cluster autoscaling itself is in Preview at the time of writing and needs a recent Agent. We implement workload scaling first, because that is where the requests that drive node count are set.
Do we need Cloud Cost Management to use Kubernetes Autoscaling?
No. Without Cloud Cost Management the savings estimates use fixed default rates. With it, they use your actual cloud bill, which makes the estimate something a finance team will accept. Most customers who adopt one end up adopting the other, because the question that follows a rightsizing recommendation is always what it is worth.
What does Critical Cloud do with Kubernetes Autoscaling every month?
Managed Observability runs it. Every month we review which recommendations were applied and which were held back and why, check the bounds on every DatadogPodAutoscaler against what the workload did, bring newly shipped workloads into scope once they have enough history, confirm the Cluster Agent and Agent versions still meet the prerequisites, and report the autoscaled vCPU count and what changed.
- Datadog products: every product, and how we implement and run each one
- Datadog Container Monitoring: the Agent, Cluster Agent and metrics the recommendations depend on
- Datadog Cloud Cost Management: the bill next to the telemetry that explains it
- Datadog HealthScan: read-only and fully automated, the prerequisite check before any autoscaler is created
Requests that match usage. A cluster sized for now.
Tell us which clusters have only ever grown. We will tell you what Kubernetes Autoscaling would recommend, what has to be true before it can act, and what it takes to get there.