Discussion: Allow per-VPA component configuration parameters

[omerap12]

Background

The VPA components (recommender, updater, admission controller) configuration is controlled through global flags. While this works well for simple deployments, it becomes challenging when different workloads require different configuration strategies.

Consider a Kubernetes cluster running both batch jobs processing large amounts of data and user-facing microservices. Each workload type has different resource optimization needs:

Batch processing may benefit from aggressive OOM handling and frequent adjustments, while web services might need more conservative growth to maintain stability. Currently, this requires running multiple VPA recommender instances:

Batch workload recommender

--oom-bump-up-ratio=1.5
--memory-aggregation-interval=1h
--recommender-name=batch-recommender

Web services recommender

--oom-bump-up-ratio=1.2
--memory-aggregation-interval=3h
--recommender-name=web-recommender

Proposal

Instead of managing multiple instances with different flags, we could allow configuring these parameters in the VPA object itself ( something similar to this or maybe a simpler approach ):

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: batch-processor-vpa
spec:
  recommenderConfig:
    oomBehavior:
      bumpUpRatio: 1.5
    aggregation:
      memoryAggregationInterval: "1h"
---
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: web-service-vpa
spec:
  recommenderConfig:
    oomBehavior:
      bumpUpRatio: 1.2
    aggregation:
      memoryAggregationInterval: "3h"

This approach would allow running a single instance of each VPA component while supporting different configuration needs per workload. The same pattern could potentially extend to updater and admission controller parameters.

Key Questions

1. How should we think about the global vs per-VPA parameter scope? Some parameters might make more sense to remain global.
2. What's the right balance between flexibility and complexity? While we could make every flag configurable per-VPA, should we?

I'll be happy to open a KEP for it if seems valid.
/kind feature

[omerap12]

/area vertical-pod-autoscaler