Skip to main content
Use this reference to interpret pre-checks and filters shown in logs, events, and recommendation payload summaries. Until global configuration is ready, ordinary pod admission skips all automation mutations, including compaction, recommendation inheritance, runtime hooks, and resizing. Pod creation and webhook health probes continue normally.

Quick Links


How To Read Outcomes

  • precheck means execution is gated. A failed pre-check blocks the current resizing attempt.
  • filter means action pruning. A filter removes one or more resize resource actions.
Where you will see the various pre-checks and filters:
  • rightsizing summary contains the summary and logs failedChecks and appliedFilters
  • Warning events with reason PrecheckFailed for failed pre-checks
  • Normal workload events with reason ActionFilteredByAutoscaler when HPA or VPA filters suppress resize actions
  • Recommendation payload summaries in precheckSummary and filterSummary
How to interpret retry in the context of this document:
  • When a resize action will be retried, it means the condition that caused the pre-check failure is expected to resolve itself, for example when a pod becomes Ready.
  • This is independent from GlobalConfiguration.spec.rescanInterval, which controls the regular interval for checking whether pods require resizing.

Pre-Checks

For hook-only ContainerArgsPolicy convergence, when no AutomationStrategy resolves, the controller uses a 30-second fallback for safetyChecks.resizeRetryInterval. A resolved strategy interval remains authoritative.

Filters

Evaluation Order

  1. Build candidate actions from selected recommendations.
  2. Apply automation-strategy-disabled.
  3. Run early pre-checks: pod-terminating, namespace-protected, optional pause-active, optional resource-quota-exceeded.
  4. Apply pod action filters: change-below-threshold, container-skip-active, hpa-resource-managed, vpa-resource-managed, node-capacity-insufficient, pod-limit-range-violated.
  5. Run final non-retryable plan consistency checks: requests-exceed-limits, gpu-plan-consistency, and controller-only common-resize-method.
  6. If any remaining action is outside its scheduling window, retain the filter summary, block the full controller plan, and requeue for the earliest allowed time.
  7. Run final retryable health checks: min-ready-duration-not-met, owner-pods-not-ready, max-unavailable-exceeded.
  8. Execute in-place resize or eviction if actions remain.
Notes:
  • Workload policy recommendation generation also applies limit-range-violated before owner annotations are written.
  • The webhook evaluation path runs namespace-protected, pause-active, and resource-quota-exceeded.
  • pod-terminating, scheduling windows, common-resize-method, and the final retryable health checks are controller-side.
  • Pod-wide safety settings use the strictest value among strategies that supplied selected actions. Boolean checks use logical OR, minimum percentages and readiness durations use the larger value, and losing candidates do not contribute.

Reading failedChecks and appliedFilters

  • failedChecks contains check failures with name, optional message, and optional metadata.
  • appliedFilters contains pruned actions with name, optional filter metadata, and targets with container, usage, and resource.
  • Bounds enforcement also appears in appliedFilters: floor-clamped and ceiling-clamped indicate the controller adjusted the desired value before deciding whether any resize action still remained.
  • pause-active sets failedChecks[].metadata.scope to pod or namespace; namespace pauses also include failedChecks[].metadata.namespace.
  • container-skip-active sets appliedFilters[].metadata.scope=container and appliedFilters[].metadata.container=<name>.
Example interpretation:
  • {"name":"min-ready-duration-not-met","message":"pod not ready"} in failedChecks means execution is blocked for now and retried.
  • {"name":"resource-quota-exceeded","message":"resource quota exceeded (ResourceQuota/team-quota)","metadata":{"name":"team-quota"}} in failedChecks identifies the specific blocking quota.
  • {"name":"container-skip-active","metadata":{"scope":"container","container":"app"},"targets":[{"container":"app","usage":"requests","resource":"cpu"}]} in appliedFilters means only that container action was removed because skip-containers matched that container.
  • {"name":"hpa-resource-managed","targets":[{"container":"app","usage":"requests","resource":"cpu"}]} in appliedFilters means that resize action was removed because HPA controls that resource.
  • {"name":"floor-clamped","metadata":{"value":"200Mi","originalDesired":"128Mi","clampedDesired":"200Mi","rule":"AutomationStrategy/example-rule"},"targets":[{"container":"app","usage":"requests","resource":"memory"}]} in appliedFilters means the recommendation was raised to the strategy floor before execution.