When Kubernetes autoscaling is worth designing before you need it
If your platform team runs self-managed clusters and faces uneven load, cost pressure or sudden event spikes, autoscaling is a design task you should start before the next incident forces it. Kubernetes autoscaling covers four separate mechanisms: pod-level scaling with the HorizontalPodAutoscaler, resource-level scaling with the Vertical Pod Autoscaler add-on or in-place pod resizing, event-driven scaling with tools such as KEDA, and node-level scaling that adds or removes worker capacity. Each one needs configuration and ownership decisions inside your cluster, and none of them works well by default.
The Kubernetes documentation describes these as distinct mechanisms that interact with each other. A horizontal scaler changes replica counts, a vertical scaler changes resource requests on pods, an event-driven scaler reacts to queues, streams or external signals, and a node autoscaler changes how many machines exist to run pods. When these overlap, they can fight: a vertical change restarts pods that a horizontal policy is also trying to size, or a node autoscaler waits for capacity that a pod scaler has already claimed. Plan the interactions on paper before you enable any of them.
Three questions usually decide the design. The first is workload type: stateless web services, batch jobs, queue consumers and stateful databases each tolerate restarts and changes in replica count differently. The second is metric source: CPU and memory from the metrics pipeline are simple to start with, but request latency, queue depth or custom business signals require a metrics adapter or an event source, and each adds a component your team must run and monitor. The third is who owns node capacity. If a platform team manages node pools and an application team manages workloads, scaling thresholds, instance types and budget limits must be agreed between them, or pods will stay pending or costs will drift.
Designing this early pays off because changing the approach later means touching live workloads. Ask your team to inventory the workloads that vary in load, record which metrics reflect their demand, and name the owner of each node pool. Confirm with your Kubernetes distribution vendor and your cloud or data center team which node autoscaling integrations they support, and which versions of the autoscaler components are compatible with your cluster version. Those answers determine whether autoscaling is a small configuration task or a project with its own test plan.
Which Kubernetes autoscaling mechanism fits each workload
This table compares five Kubernetes autoscaling mechanisms by what each one scales, the signals it reads, when it fits and what to confirm before adopting it. Read each row against your workload type and the components installed in your cluster. The main takeaway is that pod-level mechanisms and node autoscaling solve different capacity problems, so most platforms combine more than one.
| Mechanism | What it scales and typical signals | When it fits | Trade-offs and what to confirm |
|---|---|---|---|
| HorizontalPodAutoscaler (built in) | Replica count of a workload, driven by resource metrics such as CPU or memory utilization, or by custom metrics | Stateless services where adding pods increases throughput and the application tolerates more replicas | Utilization is calculated from pod resource requests, so requests must be set. Confirm the metrics pipeline and custom metrics adapter for your Kubernetes version. |
| Vertical Pod Autoscaler (add-on, separate install) | CPU and memory requests of pods, based on observed usage history | Workloads that do not scale out easily, or right-sizing requests before you set HPA targets | Applying recommendations may restart pods, depending on the update mode. Confirm install method, supported Kubernetes versions and update modes in the project documentation. |
| In-place pod resizing (Kubernetes feature) | CPU and memory of a running pod, changed without recreating the pod, where the feature is enabled | Latency-sensitive pods that need capacity changes without a restart, once support is confirmed | Feature status, supported resources and runtime support depend on the Kubernetes version. Confirm feature gate status and container runtime support for your cluster. |
| KEDA (event-driven autoscaling, separate install) | Replica count driven by external event sources through scalers, including scaling to zero | Queue consumers and event-driven workers whose load comes from a broker or other external system | Adds a component and scaler credentials to operate. Confirm that the scalers you need exist, their versions and how they authenticate to your systems. |
| Node autoscaling (cluster autoscaler or equivalent) | Number of worker nodes, increased when pods cannot be scheduled for lack of capacity | Clusters that can provision and remove machines through an API in infrastructure you control | Self-managed clusters need an integration with your virtualization or cloud platform to add and remove machines. Confirm the provider integration and version compatibility. |
How the autoscalers divide scaling work in a cluster
Scaling in a self-managed cluster happens at four layers, and each layer has its own controller and its own owner. Pod replica counts are set by the HorizontalPodAutoscaler, which changes how many copies of a workload run. Pod resource requests and limits determine how much CPU and memory each copy is allocated. The Vertical Pod Autoscaler can recommend or apply new values, and in-place pod resizing can change them on running pods where your Kubernetes version supports it. Event-driven replica counts come from external sources such as queues or streams, typically through KEDA, which feeds those signals into the replica decision. Node pool capacity sits underneath all of them, and a node autoscaler adds or removes machines. Before you enable any of these, decide which team owns each layer and which signal drives it.
The pod-level scalers and the node scaler work as a chain. When the HorizontalPodAutoscaler raises a replica count, the scheduler tries to place the new pods on existing nodes. If no node has enough free capacity for their requests, those pods stay in the Pending state. The node autoscaler watches for Pending pods it cannot place and requests new nodes from a node pool whose labels, zones, architecture and taints match those pods. In the other direction, when nodes stay underused and their pods can move elsewhere without violating PodDisruptionBudgets, the node autoscaler drains and removes them. The delay at each step depends on how long your platform takes to provision and join a node, so confirm that timing in your environment with a load test before you set expectations for application teams.
Every decision in this chain depends on resource requests being set accurately. The HorizontalPodAutoscaler's CPU and memory utilization targets are calculated as a percentage of requests. A request set too high makes a workload look idle and delays scale-out, while a request set too low makes it look overloaded and can push replicas past what the nodes can hold. The scheduler and the node autoscaler also reason from the requests recorded in each pod spec and do not wait for live usage data. Audit requests for your highest-traffic workloads before you turn on automation. Also avoid running the Vertical Pod Autoscaler in automatic mode against the same CPU or memory signal that drives a HorizontalPodAutoscaler on that workload, because the two controllers can work against each other.
Metrics come from a metrics pipeline that your team must install and monitor. Resource metrics for the HorizontalPodAutoscaler and the Vertical Pod Autoscaler depend on a metrics API provider, commonly metrics-server. Custom and external metrics need an adapter or the KEDA operator with its scalers. Each of these is an in-cluster dependency with its own version, certificates and failure modes. If the metrics API stops answering, autoscalers generally stop acting on fresh data, which can leave a workload at its last replica count during a traffic spike. Confirm in the documentation for your Kubernetes version how each autoscaler behaves when metrics are missing, add alerts for metrics API availability and for scaling events, and test that failure path during the same load test you use for node provisioning.
How to set up Kubernetes autoscaling in stages
This sequence takes a self-managed cluster from a metrics check to verified scale-out and scale-in behavior for both workloads and nodes. Each stage depends on the one before it, so skipping a check usually shows up later as scaling that never fires or fires in the wrong direction.
Confirm cluster version and metrics pipeline
Start by confirming the cluster's Kubernetes minor version and checking which autoscaling APIs and metrics sources it exposes. Your platform engineers should confirm the version against the Kubernetes releases page, since support windows determine which upgrade you need to plan. Then verify that the resource metrics API returns CPU and memory for nodes and pods, for example by running kubectl top nodes and kubectl top pods in a non-production namespace. If custom or external metrics drive scaling, confirm the adapter that serves them is installed and reporting. This step is done when metrics return values for the pods you plan to scale.
Set resource requests on workloads
Every workload that a HorizontalPodAutoscaler will scale on CPU or memory needs CPU and memory requests in its pod spec, because utilization is calculated as a share of the request. Application owners should set requests from measured usage in a test environment rather than from guesses, and document the reasoning. Limits need a deliberate decision as well, since a memory limit set too low can cause repeated restarts under load. Check the result by describing the deployment and confirming that every container reports requests for the resources the scaler will use. This step is done when no targeted container is missing its requests.
Pick scalers per workload class
Group workloads by how they should scale, then assign a mechanism to each group. Stateless web services usually fit the HorizontalPodAutoscaler on CPU, memory or custom metrics. Workloads with uneven or unpredictable sizing may need the Vertical Pod Autoscaler in recommendation mode first, and an add-on must be installed for it. Event-driven workloads such as queue consumers may fit KEDA, which scales on external signals. Stateful workloads often need a different approach entirely. Record the decision for each class with its owner, because a HorizontalPodAutoscaler and a VPA acting on the same CPU signal can fight each other. This step is done when every workload in scope has one named scaling mechanism.
Configure minimum and maximum bounds
Set the minimum and maximum replica counts on each autoscaler, and check that the maximum fits within what the cluster can schedule. The minimum should cover baseline availability and any disruption budget the service requires, and the maximum should be bounded by quotas, node capacity and downstream limits such as database connections. Also review the scale-up and scale-down behavior settings so that scale-in does not remove capacity faster than traffic falls. Confirm the bounds by running kubectl get hpa and checking that the minimum and maximum columns match the agreed values. This step is done when each autoscaler has documented bounds that the owning team has approved.
Configure node autoscaling against capacity planning
Node autoscaling adds and removes machines when pods cannot be scheduled or nodes sit underused. The node group sizes, instance types and labels should come from a capacity plan that covers peak pod counts, daemonset overhead and headroom for failover. Your team should confirm which node autoscaler the distribution supports, and what the cloud or data center provider API needs to let it add and remove machines. Test a pending pod on a deliberately full node pool and confirm that a new node joins and becomes Ready. This step is done when a scale-up caused by unschedulable pods completes and the new node runs the pending workload.
Load test the autoscaling path
Run a controlled load test against a copy of the workload in a test namespace, with the same requests, bounds and node pool settings as production. Increase traffic in steps and record when the autoscaler reacts, how many replicas it adds, and how long new pods take to pass readiness. Then reduce load and watch scale-in, looking for flapping or premature removal of capacity. Keep the test scope and traffic profile agreed in writing with the team that owns the service. The test is done when the load profile is recorded alongside the observed scale-out and scale-in timings.
Verify scaling events and alerts
Confirm the autoscaler's decisions are visible and that someone is alerted when scaling fails. Run kubectl describe hpa during the load test and check the events for successful rescale messages and any failed metric reads. Confirm that alerts exist for autoscalers stuck at maximum replicas, for pods left pending, and for missing metrics, and that each alert routes to an owner. Finally, repeat one scale-out and scale-in cycle after the configuration is locked to confirm the behavior has not drifted. This step is done when a scale-out and scale-in cycle is observed in events, and each failure condition triggers an alert that reaches a named team.
Security and operations risks in Kubernetes autoscaling
Autoscalers change replica counts, resource requests and node pools without a person in the loop, so their permissions, bounds and history matter as much as their settings. The cards below cover the access, cost and evidence controls a self-managed cluster needs before autoscaling is trusted with production capacity.
RBAC for scalers and service accounts
Each autoscaler runs under a service account, and that account can often patch Deployments, StatefulSets or node-group objects. Grant only the verbs and resources each scaler needs, bind them to a single namespace where possible, and review which humans and pipelines can impersonate those accounts. Check that no shared default service account gained scaling rights through a broad role binding.
Who may change min and max bounds
Minimum and maximum replica counts, and node pool limits, define both the availability floor and the cost ceiling. Decide which roles may edit these bounds, usually the platform team, and restrict write access to the HorizontalPodAutoscaler, ScaledObject or node pool resources that hold them. Treat a bound change like a configuration change that needs a reviewer.
Runaway scaling and cost exposure
A misconfigured metric, a flapping signal or a retry storm can drive replicas and nodes to the maximum for hours. Set upper bounds that reflect your budget and quota, cap node pool size at the cloud or hypervisor layer, and alert on sustained scaling at the ceiling. Ask the cloud account owner who receives billing alerts for the cluster.
External event source credentials
Event-driven scalers such as KEDA read queue depths, topic lags or cloud metrics using credentials. Kubernetes stores Secrets unencrypted in etcd by default, so configure encryption at rest, restrict list and watch access, or pull credentials from an external store through the Secrets Store CSI Driver. Confirm that scaler credentials are scoped to read-only metric access.
Audit logs for scaling changes
Every change to replica counts, bounds and scaler definitions should appear in the Kubernetes API audit log with the actor, the object and the time. Confirm that your audit policy records patch and update requests on scaling resources at a level that shows the request body, and that the logs ship to storage outside the cluster. Without this record, a sudden capacity change cannot be traced to a person or pipeline.
Observability for scaling decisions
Operators need to see which metric triggered a scale event, what the current and desired replica counts were, and why a node was added or removed. Export autoscaler status, scaler metrics and node provisioning events to your monitoring stack, and build dashboards that show scaling against pending pods and resource pressure. Check that alerts fire when scaling is blocked by quota or unavailable capacity.
Change control and incident runbooks
Autoscaling settings change how the platform behaves under load, so changes to bounds, metrics and scaler versions belong in the same change control process as other production changes. Incident runbooks should state how to pin replicas, disable a scaler safely and raise limits during an incident, and who approves each step. Rehearse these steps before an outage forces the decision.
Keeping Kubernetes autoscaling working through cluster upgrades
Autoscaling is one of the first things to fail during a cluster upgrade because its decisions depend on components that are versioned separately from the control plane. Each upgrade step needs the whole scaling stack tested against the target minor version, not checked once at the end. That stack includes the HorizontalPodAutoscaler controller inside kube-controller-manager, the metrics pipeline that feeds it, the Vertical Pod Autoscaler add-on if you run it, KEDA for event-driven scaling if you run it, and the node autoscaler acting on each node pool.
The version skew policy sets the order. kube-apiserver must be upgraded one minor version at a time and before kube-controller-manager, kube-scheduler and the kubelets. Kubelets may run up to three minor versions behind kube-apiserver. A node pool that lags is valid under the policy, but the add-ons you run may not support that combination. During an upgrade, expect mixed versions across the control plane and nodes, and confirm that each add-on supports every version present at that moment, not only the final target.
The Kubernetes project maintains the three most recent minor releases. As of September 2026, these were 1.37 (end of life October 28, 2027), 1.36 (June 28, 2027) and 1.35 (February 28, 2027), according to the Kubernetes releases page. Kubernetes ships approximately three minor releases per year on a cycle of about 14 weeks, so upgrade windows arrive often. Before each upgrade step, confirm the compatibility statement and supported Kubernetes versions for the VPA release, the KEDA release, the node autoscaler and the metrics pipeline. These lists change as new minors ship, so check them on the day you plan the step.
Test each step in a non-production cluster that follows the same minor version sequence. Verify that HorizontalPodAutoscalers still read the metrics they used before, that VPA recommendations apply after pod restarts, and that in-place pod resizing behaves as expected on the target version. Confirm that a node pool scales up and down after its kubelets change version. Keep the previous add-on versions available so you can roll back a single component without rolling back the cluster. The main risk is silent failure: an add-on that does not support the new minor can stop scaling without raising an obvious error, so set alerts on scaling activity and on the add-on health signals before you start.
Limits to confirm in your environment before scaling
Autoscaling depends on several components that differ by cluster version, cloud or data center, and event source. The cards below list the items to verify against current project documentation and your own load testing before you set scaling targets for production workloads.
Metrics sources your cluster provides
HorizontalPodAutoscaler scales on resource metrics, custom metrics and external metrics, and each category depends on a separate metrics pipeline. Confirm that a resource metrics API is installed and returning CPU and memory values for your pods, and check whether any custom or external metrics adapter you plan to use is maintained for your Kubernetes version. Test that the metric values match what your monitoring stack shows before you rely on them.
In-place pod resizing availability
In-place pod resizing changes CPU and memory on running pods without a restart, but it is a feature whose availability and maturity depend on your Kubernetes minor version and its feature gate state. Check the current Kubernetes documentation for the version you run, confirm whether the feature is enabled by default in your distribution, and check how your container runtime handles resize requests. Test the behavior with your own workloads before planning around it.
KEDA scaler support for event sources
KEDA scales workloads on external event sources through scalers, and each scaler has its own required fields, authentication model and supported versions. Confirm that a scaler exists for each queue, stream, database or metrics backend you intend to use, and that it works with the KEDA release you plan to deploy. Also confirm how your event source authenticates, since credentials for scalers need to be stored and rotated like any other secret.
Node provisioning options
Node autoscaling depends on what your infrastructure can create on demand. In a public cloud, confirm which node group or instance template integration your autoscaler supports and which instance types and zones are available to your account. On premises or in a private data center, node autoscaling needs an integration with your virtualization or bare metal provisioning layer, and that integration may not exist out of the box. Document the provisioning time you observe in testing.
Quota and capacity limits
Scaling fails quietly when the infrastructure underneath it refuses new capacity. Check cloud service quotas for instances, vCPUs, load balancers, public addresses and storage volumes, and confirm the headroom your account or project has in each zone. On private infrastructure, check hypervisor resource pools, storage capacity, IP address ranges and physical rack power. Ask your provider or internal platform team for the current limits in writing and retest them after any capacity change.
Version and project documentation alignment
Autoscaling components such as the Vertical Pod Autoscaler add-on, KEDA and cluster autoscalers are released on their own schedules and can require specific Kubernetes versions. Record the exact versions you plan to deploy and check each project's compatibility matrix and release notes against your cluster version. Plan an upgrade test for each Kubernetes minor release, since the Kubernetes release cycle is roughly three releases per year.
What drives the cost and effort of Kubernetes autoscaling
The effort in a Kubernetes autoscaling engagement comes mostly from design and tuning work, not from installing controllers. A partner's fixed-scope proposal will separate the one-time build from the recurring work, and you should ask for that split explicitly. The one-time portion covers analysis of how each workload behaves under load, tuning of CPU and memory requests and limits, setup of the metrics and event sources that drive scaling, design of node pools that the cluster autoscaler or another node provisioner can grow and shrink, and load testing that proves the combination behaves as intended. Ask each bidder to list these items separately with the people responsible for each.
Workload analysis and resource request tuning usually take the most judgment. HorizontalPodAutoscaler decisions depend on requests, because utilization is calculated against them, so a request that is set too high or left unset can make scaling appear to work while it does not. Vertical Pod Autoscaler recommendations need a review loop with the application owners, and in-place pod resizing has its own support and behavior limits that your platform version and workload type will determine. Confirm the exact versions and feature states in your target cluster before the proposal is accepted, since these details change with each Kubernetes minor release.
Several factors raise effort materially. The number of workload classes matters most: a cluster with three stateless web tiers, a batch queue and a stateful service needs three different scaling policies, disruption settings and test plans. Each event source adds an integration and an access path, for example a message queue or a database metric that KEDA must authenticate against. Multi-cluster operation multiplies the design and test work, and air-gapped networks add work to mirror controller images, Helm charts and metrics pipelines into a private registry before anything can be installed. Existing observability lowers effort where Prometheus metrics, dashboards and alert routing already exist, and raises it where they do not.
Recurring costs continue after go-live. Controllers such as the Vertical Pod Autoscaler, KEDA and the node autoscaler are add-ons that need version upkeep, and each Kubernetes minor upgrade requires retesting scaling behavior because API changes and default settings can shift. Tuning is also ongoing: traffic patterns change, new services arrive and scaling thresholds drift. Ask whether a proposal includes a retained tuning schedule, who holds the on-call response for scaling incidents, and how upgrade testing is repeated for each new minor release you plan to run.
No price is quoted in this section, and DeployOpen does not publish a price list. To compare proposals, ask each provider to state its assumptions about workload classes, event sources, cluster count, connectivity and existing observability, then check that the fixed scope lists deliverables, test evidence, handover and what happens to recurring upkeep. A written proposal follows the agreed scope, so the scope conversation should happen first.
Questions teams ask before hiring help with Kubernetes autoscaling
What drives the cost of a Kubernetes autoscaling engagement?
Scope drives cost more than anything else: how many workloads need scaling, how many clusters are involved and how many scaling signals each workload uses. The main cost components are:
- Discovery of current resource requests, limits and traffic patterns
- Design of HorizontalPodAutoscaler, Vertical Pod Autoscaler, KEDA or node autoscaling settings per workload
- Load testing and validation in a test environment
- Documentation and handover to your operators
Some work is one-time (the initial design and build), while tuning after production traffic is observed is often recurring. Ask for a written proposal that lists workloads, clusters, test windows and the deliverables for each, so you can compare options on the same basis. DeployOpen does not publish a price list; a quote follows from the agreed scope.
How long does a scoped autoscaling build take?
Duration depends on scope, and DeployOpen does not publish fixed timelines, so the timeline should come from the written scope. The factors that extend it are the number of workloads, whether node autoscaling is included, whether event-driven scaling with KEDA is needed, how many environments must be validated and how long your load test windows are. Ask the proposal to show:
- The number of workloads and clusters in scope
- Which autoscaling mechanisms are covered
- Dependencies on your change windows and approvals
- The verification steps and the point at which production changes are made
A narrower scope, such as one cluster with HorizontalPodAutoscaler on a few services, will be shorter than a multi-cluster programme with node autoscaling and custom metrics. Compare timelines only when the scopes match.
What does our team need to provide during an autoscaling engagement?
Your team provides access and context, because autoscaling behavior depends on your real workloads. Expect to supply:
- Cluster access with the permissions needed to read and change workload and autoscaling resources in agreed namespaces
- Named owners for each workload who can confirm expected traffic, startup behavior and acceptable latency
- Load test windows in non-production environments, and production windows if validation requires them
- Read access to your metrics stack, such as the Prometheus data used for scaling signals or dashboards
- Access to the event sources used by KEDA, where applicable
Confirm access paths, approval routes and who signs off on changes before the build starts. These items are usually the longest lead time, so list them in the proposal.
Can our internal platform team build Kubernetes autoscaling without outside help?
Yes, many platform teams build autoscaling in-house, and the skills involved are standard Kubernetes operations: resource requests and limits, HorizontalPodAutoscaler behavior, metrics pipelines and node group configuration. The difficult parts are usually the time needed for load testing, the coordination with workload owners and the discipline of tuning from observed data rather than guesses. Questions to decide internally:
- Does the team have capacity to run load tests and interpret results?
- Is there someone who understands the metrics pipeline that feeds the scaling decisions?
- Who owns the scaling settings after handover?
If those answers are yes, an internal build with a documented runbook may be the right choice. An outside partner can help when capacity or experience is short, and the written scope should state what is delivered and handed over.
When does a retainer for autoscaling tuning make sense?
A retainer makes sense when scaling settings need ongoing adjustment after the initial build, for example when traffic patterns change, new workloads are added, Kubernetes versions move forward or node pools are reconfigured. Autoscaling is not a one-time setting, because the right values depend on demand that changes over time. A retainer is worth discussing when:
- You expect regular changes to workloads or traffic
- Your team lacks time to review scaling events and adjust thresholds
- Upgrades on your release schedule will touch autoscaling components
Retainers cover agreed ongoing work and are separate from the fixed-scope build. Ask for the scope of the retainer, how requests are prioritized and how changes are tested before they reach production.
Which autoscaling mechanisms are usually in scope, and how do they differ?
The scope usually covers HorizontalPodAutoscaler for changing replica counts, the Vertical Pod Autoscaler add-on for recommending or setting resource requests, in-place pod resizing where your cluster version supports it, KEDA for event-driven scaling and node autoscaling for adding or removing capacity. Each mechanism answers a different question. Confirm these points before you commit:
- Which mechanisms your current cluster version and distribution support
- Whether the Vertical Pod Autoscaler and HorizontalPodAutoscaler will act on the same workload, which needs careful design
- Which metrics are available from your monitoring stack
The Kubernetes version and your distribution determine feature availability, so check them against the official documentation for your release before the scope is fixed.
What should a written proposal for autoscaling include?
A useful proposal makes the scope and responsibilities explicit so you can compare offers. Ask that it includes:
- The clusters, namespaces and workloads in scope
- The autoscaling mechanisms to be designed and configured
- The test environments, load test approach and the production change plan
- Client dependencies, such as access, workload owners and test windows
- The deliverables: configuration, runbooks, dashboards and handover sessions
- Assumptions about existing monitoring, metrics and Kubernetes version
- Exclusions, such as application code changes or capacity purchases
- The fee structure, timeline and how changes to scope are handled
DeployOpen agrees most engagements as fixed scope in writing before work starts, so you can review these items against your own environment.
How DeployOpen scopes and delivers Kubernetes autoscaling
DeployOpen plans Kubernetes autoscaling as part of the cluster it runs in your infrastructure, starting from the workloads, metrics and node pools you already operate. Engagements are fixed-scope, so the autoscaling mechanisms, their configuration and the handover material are agreed in writing before the build begins.
How we scope
- Inventory which workloads need horizontal, vertical or event-driven scaling, and which need in-place pod resizing
- Confirm the metrics sources, custom metrics and event sources that autoscalers will read in your cluster
- Agree in writing which node autoscaling approach and node pools are in scope, and what the scope excludes
How we build
- Configure HorizontalPodAutoscaler and any KEDA ScaledObjects with resource requests and scaling bounds set per workload
- Install and configure the Vertical Pod Autoscaler add-on in recommendation mode before enabling automatic updates
- Test scale-up and scale-down behavior under load in a non-production cluster before promoting changes to production
How we hand over
- Document each autoscaler's targets, bounds, metrics dependencies and the ownership of every setting
- Provide runbooks for diagnosing stalled scaling, pending pods and node provisioning failures
- Walk your platform and application teams through the configuration and the decisions recorded during the build
How we support
- Review autoscaler behavior after Kubernetes minor version upgrades, since the supported APIs and defaults may change
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Confirm the support terms, response expectations and any SLAs with us in writing before the engagement starts
