Kubernetes v1.33 introduces a game-changing enhancement to the Horizontal Pod Autoscaler (HPA): custom tolerance values for each workload. This long-requested feature gives platform engineers granular control over scaling behavior, addressing one of the most significant limitations in Kubernetes autoscaling.

The One-Size-Fits-All Problem with HPA

Kubernetes’ Horizontal Pod Autoscaler has been instrumental in automating workload scaling based on metrics like CPU utilization. However, its effectiveness has been limited by a fixed, cluster-wide tolerance threshold - typically set at 10%.

This single tolerance value has caused numerous headaches for platform teams:

  • For large deployments, even a 10% fluctuation represents a substantial resource gap
  • Critical production services might suffer delayed scale-up during traffic surges
  • Different applications have vastly different scaling requirements based on their initialization time and performance characteristics
  • Development environments often need different scaling behaviors than production

I’ve encountered this limitation repeatedly when managing production Kubernetes clusters, particularly with latency-sensitive microservices where even small delays in scaling can impact user experience.

Configurable Tolerance Arrives in v1.33

With Kubernetes 1.33, we finally have the ability to set custom tolerance values per HPA, with separate controls for scale-up and scale-down operations. This enhancement is implemented as an optional field in the HPA v2 API specification.

Key Improvements:

  1. Per-workload sensitivity: Define exact scaling thresholds for each application
  2. Split tolerances: Use different values for scale-up vs scale-down operations
  3. Backward compatibility: Existing HPAs continue to work with the global default
  4. Gradual adoption: Apply custom tolerances only where needed

The feature doesn’t fundamentally change how HPA works but provides the configuration hooks many of us have been requesting for years.

Real-World Example: Optimizing for Traffic Spikes

Let’s examine a practical scenario where this feature shines. Consider a payment processing API running with 20 replicas and a CPU target of 70%. During flash sales, traffic can spike rapidly.

With the default 10% tolerance, scaling only triggers when utilization exceeds 77% (70% × 1.1). By the time scaling starts, your service might already be experiencing latency issues.

Using the new feature, you can set a more responsive 5% tolerance for scale-up while keeping a conservative 15% tolerance for scale-down:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: payment-api
spec:
  minReplicas: 20
  maxReplicas: 100
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  behavior:
    scaleUp:
      tolerance: 0.05  # More sensitive to load increases
    scaleDown:
      tolerance: 0.15  # Conservative approach to scaling down

With this configuration, scaling begins when utilization exceeds 73.5% (70% × 1.05), giving your system more runway to handle incoming traffic spikes. Meanwhile, the higher scale-down tolerance prevents premature pod termination during temporary traffic dips.

Under the Hood: How It Works

The HPA controller uses a straightforward mechanism to determine when scaling should occur. It calculates the replica count needed based on current utilization versus the target, then applies the tolerance check:

// Pseudo-code showing tolerance logic
if math.Abs(1.0 - currentUtilization/targetUtilization) <= tolerance {
    // Skip scaling - we're within tolerance range
    return currentReplicas
}

When the feature is enabled, the HPA controller simply uses your specified tolerance value instead of the global default. This small change provides significantly more control over scaling behavior.

Enabling Configurable HPA Tolerance

This feature is currently in alpha status in Kubernetes v1.33 and requires explicit enablement. To use it:

  1. Enable the feature gate in kube-apiserver and kube-controller-manager:

    --feature-gates=HPAConfigurableTolerance=true

  2. Update your HPAs to include the tolerance field in the behavior section as shown in the example above

  3. Monitor scaling events to validate the behavior meets your expectations

Remember, this feature only works with the autoscaling/v2 API version, so ensure your HPAs are using this version.

Compatibility and Rollback Safety

One aspect I particularly appreciate about this implementation is its careful consideration of backwards compatibility:

  • If the feature gate is disabled, any tolerance configuration is simply ignored
  • Existing HPAs continue to function using the global default
  • Downgrading to earlier Kubernetes versions is safe—your workloads will revert to default behavior

This design follows the Kubernetes principle of making potentially disruptive features opt-in rather than changing default behaviors.

Real-World Benefits

From my experience managing complex Kubernetes environments, this feature addresses several critical real-world needs:

  1. Workload-specific tuning: Different applications have unique performance characteristics; a database proxy may need different scaling behavior than a static content server

  2. Production vs. non-production environments: You can now implement more aggressive scaling in production while using conservative approaches in development environments

  3. Cost optimization: Fine-tune scaling sensitivity to avoid over-provisioning resources while maintaining performance

  4. Improved user experience: Faster reactions to load increases help maintain consistent application performance during traffic spikes

What’s Next for Kubernetes Autoscaling

While configurable tolerance is a significant improvement, it’s worth mentioning other autoscaling enhancements on the horizon:

  • Improved metric stability algorithms
  • Better integration with VPA (Vertical Pod Autoscaler)
  • Enhanced prediction-based scaling rather than purely reactive approaches

I expect the Kubernetes autoscaling capabilities to continue maturing based on real-world usage patterns and user feedback.

Conclusion

Configurable HPA tolerance in Kubernetes v1.33 represents a small API change with outsized real-world impact. This feature addresses a long-standing limitation in Kubernetes, giving platform engineers like us much-needed control over autoscaling behavior.

If you’re managing production workloads on Kubernetes, I strongly recommend experimenting with this feature, especially for applications with strict latency requirements or unpredictable traffic patterns. The ability to fine-tune scaling sensitivity per workload rather than cluster-wide is a powerful tool for optimizing both performance and resource utilization.

Have you been impacted by HPA’s fixed tolerance limitation? I’d love to hear your experiences in the comments below.