Autoscaling DigitalOcean Managed Kubernetes Clusters with the Cluster Autoscaler

Problem: Sudden traffic spikes leave pods pending

When a workload experiences a burst of requests, Kubernetes may schedule more pods than the existing nodes can accommodate. Without automatic node provisioning, those pods stay in a Pending state, increasing latency and potentially causing timeouts for users. Manually adding nodes is slow and error‑prone, especially for teams that operate multiple environments.

Thesis: Enable the Cluster Autoscaler on DOKS to match node count to pod demand

DigitalOcean Kubernetes Service (DOKS) integrates the upstream Cluster Autoscaler. By defining a minimum and maximum node count per node pool, the autoscaler watches for unschedulable pods and adds or removes nodes automatically, keeping the cluster right‑sized for cost and performance.

How the autoscaler works on DOKS

The autoscaler runs as a deployment in the kube-system namespace. It evaluates two conditions:

1. Scale‑up trigger: When a pod cannot be scheduled because of insufficient CPU, memory, or other resources in the existing node pool.
2. Scale‑down trigger: When a node has been underutilized for a configurable stabilization period (default 10 minutes) and its pods can be moved elsewhere.

Autoscaling decisions are based solely on pod requests (not limits). If a pod lacks resource requests, the autoscaler cannot determine whether it would fit, so it ignores that pod for scaling decisions.

Enabling autoscaling via the console or doctl

You can configure autoscaling when creating a node pool or edit an existing pool.

• Console: Navigate to Kubernetes → your cluster → Node Pools → select pool → Settings → Autoscaling. Toggle Enable autoscaling, set Minimum nodes and Maximum nodes, and optionally choose a scaling profile (balanced or optimize-utilization).
• CLI: Use doctl to create or update a node pool. Example:

# Create a new node pool with autoscaling (min=1, max=5)
doctl kubernetes node-pool create \
  --cluster-name my-doks-cluster \
  --name worker-pool \
  --size s-2vcpu-4gb \
  --node-count 1 \
  --min-count 1 \
  --max-count 5 \
  --auto-scale true

# Update an existing pool to enable autoscaling
doctl kubernetes node-pool update \
  --cluster-name my-doks-cluster \
  --worker-pool \
  --min-count 2 \
  --max-count 8 \
  --auto-scale true

After the command finishes, the control plane installs the autoscaler if it is not already present.

Worked example: Scaling an NGINX workload

This example demonstrates the end‑to‑end flow. Adjust the placeholders (<cluster-name>, <namespace>) to match your environment.

1. Deploy a test application with explicit resource requests.

kubectl apply -f - <

1. Observe pending pods. Immediately after applying, some pods will be Pending because the node pool may start with only the minimum node count.
2. Watch the node count grow. Run:

kubectl get nodes --watch

You should see new nodes appear as the autoscaler adds them to accommodate the unschedulable pods. The autoscaler logs (see next section) will contain lines like:

event=scale-up pod=nginx-autoscale-... reason=Insufficient cpu

1. Scale down by reducing replicas.

kubectl scale deployment/nginx-autoscale --replicas=5

After the stabilization period (default 10 minutes), the autoscaler will drain and remove excess nodes, bringing the total back toward the minimum.

Monitoring and diagnostics

Verify scaling activity with:

• kubectl get nodes – shows current node count and status.
• kubectl top nodes – provides CPU/memory utilization (requires metrics‑server).
• kubectl logs -n kube-system -l app=cluster-autoscaler – streams autoscaler events and errors.

Look for scale-up and scale-down messages. If you see repeated Failed to schedule pod warnings without subsequent scale‑up, check that pods have resource requests and that the node pool’s instance type can satisfy them.

Trade‑offs and limitations

While autoscaling simplifies capacity management, it is not a silver bullet:

• Scale‑up latency: New nodes take time to provision (typically 60‑90 seconds on DOKS). During that window, pods may remain pending, causing brief latency spikes.
• Node‑pool homogeneity: Mixed instance sizes can lead to inefficient packing; the autoscaler may add a large node when a smaller one would suffice, increasing cost. Consider using uniform node sizes or node taints/tolerations for specialized workloads.
• Baseline capacity: Autoscaling does not replace capacity planning for steady‑state traffic. Set the minimum node count high enough to handle your baseline load, otherwise you risk under‑provisioning during low‑traffic periods.
• Resource requests are mandatory: Without requests, the autoscaler cannot assess schedulability, so it will ignore those pods entirely.

Actionable closing

To get the most out of DOKS autoscaling:

1. Define realistic resource requests for all containers in your workloads.
2. Start with a conservative node range (e.g., min=2, max=10) and adjust based on observed utilization metrics.
3. Enable the autoscaler via the console or doctl and verify its operation with a test deployment like the NGINX example above.
4. Monitor autoscaler logs and node counts regularly; tune the scale‑down stabilization period if you notice excessive churn.
5. For heterogeneous workloads, create separate node pools with taints/tolerations or use node affinity to keep the autoscaler’s decisions predictable.

By following these steps, you let the cluster automatically respond to demand while keeping costs under control and maintaining predictable performance for your applications.