vertical-pod-autoscaler/enhancements/8026-per-vpa-component-configuration/README.md
Currently, VPA components (recommender, updater, admission controller) are configured through global flags. This makes it challenging to support different workloads with varying resource optimization needs within the same cluster. This proposal introduces the ability to specify configuration parameters at the individual VPA object level, allowing for workload-specific optimization strategies. The goal is not to introduce new configuration options but rather to make existing internal configurations accessible and customizable per VPA object.
Different types of workloads in a Kubernetes cluster often have different resource optimization requirements. For example:
Currently, supporting these different needs requires running multiple VPA component instances with different configurations, which increases operational complexity and resource usage.
The configuration will be split into two sections: container-specific recommendations under containerPolicies and updater configuration under updatePolicy. This structure is designed to be extensible, allowing for additional parameters to be added in future iterations of this enhancement.
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
name: simple-vpa
spec:
targetRef:
apiVersion: apps/v1
kind: Deployment
name: my-app
updatePolicy:
updateMode: Auto
evictAfterOOMSeconds: 300
resourcePolicy:
containerPolicies:
- containerName: "*"
oomBumpUpRatio: "1.5"
oomMinBumpUp: 104857600
memoryAggregationInterval: "12h"
memoryAggregationIntervalCount: 5
oomBumpUpRatio and oomMinBumpUp:
These parameters work together to determine memory increases after OOM events.
The VPA selects the larger of:
oomMinBumpUpoomBumpUpRatiooomBumpUpRatio = 1, oomMinBumpUp = 0), OOM-based increases are disabled.This ensures:
oomMinBumpUp, e.g., +100MB).oomBumpUpRatio, e.g., ×1.5).Implementation logic:
memoryNeeded := ResourceAmountMax(
memoryUsed + MemoryAmountFromBytes(GetAggregationsConfig().OOMMinBumpUp),
ScaleResource(memoryUsed, GetAggregationsConfig().OOMBumpUpRatio)
)
Example: with oomBumpUpRatio: "1.5" and oomMinBumpUp: 104857600 (100MB):
Note: Using a single field approach (e.g., a unified oomBumpUp field) would not provide sufficient flexibility for users who need both a minimum absolute increase and a proportional ratio.
For example, if a user wants to ensure a minimum increase of 100MB while also applying a 1.5x ratio for larger containers, a single field cannot express this combined behavior. The current dual-field design allows users to specify both constraints independently, ensuring small containers get a guaranteed minimum bump while larger containers receive appropriate proportional scaling. This approach provides more precise control over memory recommendation adjustments after OOM events than a simplified single-field model could offer.
oomBumpUpRatio (Quantity):
oomMinBumpUp (bytes):
memoryAggregationInterval (duration):
memoryAggregationIntervalCount (integer):
evictAfterOOMSeconds (int32):
Each parameter can be configured independently, falling back to global defaults if not specified. Values should be chosen based on workload characteristics and stability requirements.
When designing the configuration parameters, we analyzed each parameter to determine the most appropriate configuration level:
oomBumpUpRatio, oomMinBumpUp)memoryAggregationInterval, memoryAggregationIntervalCount)memoryAggregationInterval and memoryAggregationIntervalCount are container-level, VPA-wide configuration can still be achieved using the wildcard container name "*"evictAfterOOMSeconds)The per-VPA configuration parameters introduced in this proposal are designed to override the corresponding global flags when specified in a VPA object. If a parameter is not defined at the VPA level, the VPA components will fall back to using the value set via global flags.
This approach ensures backward compatibility and allows users to adopt per-VPA configuration incrementally, without requiring changes to existing setups. Users can continue relying on global defaults while gradually introducing workload-specific tuning where needed.
For example:
oomBumpUpRatio is set in a VPA's containerPolicy, that value will be used for recommendations for that container.This override behavior applies to all parameters introduced in this AEP:
oomBumpUpRatiooomMinBumpUpmemoryAggregationIntervalmemoryAggregationIntervalCountevictAfterOOMSecondsValidation and error handling will ensure that invalid or conflicting values are caught early, either through CEL rules or admission controller logic.
Extend ContainerResourcePolicy with:
oomBumpUpRatiooomMinBumpUpmemoryAggregationIntervalmemoryAggregationIntervalCountExtend PodUpdatePolicy with:
evictAfterOOMSecondsThis AEP will be updated as additional parameters are identified for per-object configuration. Potential candidates include:
confidenceIntervalCPUconfidenceIntervalMemoryrecommendationMarginFractionPerVPAConfigThe feature gate will remain in alpha (default off) until:
Disabling of feature gate PerVPAConfig will cause the following to happen:
Enabling of feature gate PerVPAConfig will cause the following to happen:
The PerVPAConfig feature requires VPA version 1.5.0 or higher. The feature is being introduced as alpha and will follow the standard Kubernetes feature gate graduation process:
Initial validation rules (CEL):
oomMinBumpUp >= 0memoryAggregationInterval > 0memoryAggregationIntervalCount > 0evictAfterOOMSeconds > 0Validation via Admission Controller: Some components cann't be validated using Common Expression Language (CEL). This validation is performed within the admission controller.
oomBumpUpRatio – Using Kubernetes Quantity type for validation. The value must be greater than or equal to 1.Additional validation rules will be added as new parameters are introduced. E2E tests will be included to verify:
oomBumpUpRatio and oomMinBumpUp as container-level parametersThis enhancement is designed to be extensible. As the VPA evolves and users provide feedback, additional parameters may be added to the per-object configuration. Each new parameter will:
The decision to add new parameters will be based on:
Continue with current approach of running multiple VPA deployments with different configurations:
Use different VPA deployments per environment (dev/staging/prod):