KEP-6003: Add KEP for configurable HPA sync period#6004
KEP-6003: Add KEP for configurable HPA sync period#6004Fedosin wants to merge 1 commit intokubernetes:masterfrom
Conversation
Fedosin
commented
Apr 8, 2026
Fedosin
commented
- One-line PR description: Introduce KEP proposing an optional syncPeriodSeconds field on HorizontalPodAutoscalerBehavior to allow per-HPA override of the global --horizontal-pod-autoscaler-sync-period.
- Issue link: Configurable sync period for HPA #6003
- Other comments: [WIP] Add per-HPA configurable sync period via syncPeriodSeconds field kubernetes#138222
Introduce KEP proposing an optional syncPeriodSeconds field on HorizontalPodAutoscalerBehavior to allow per-HPA override of the global --horizontal-pod-autoscaler-sync-period.
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: Fedosin The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
k8s-ci-robot
added
kind/kep
| per-item interval during reconciliation and cleans it up on HPA deletion. | ||
|
|
||
| The informer event handlers are updated so that: | ||
| - Newly created HPAs and spec changes (detected via `Generation` comparison) |
There was a problem hiding this comment.
HPA's generation fields are currently not set.
I have kubernetes/kubernetes#138228 to get this fixed
| We propose to add a new field to the existing [`HorizontalPodAutoscalerBehavior`][] object: | ||
|
|
||
| - `syncPeriodSeconds`: *(int32)* the period in seconds between each | ||
| reconciliation of this HPA. Must be greater than 0 and less than or equal |
There was a problem hiding this comment.
This will allow this HPA to query more frequently the metric source, which is usually metrics-server, which caches its metrics. The end result is that in most situations reducing this sync period won't have much impact. Conceivably you could add a field that only targets custom/external metrics, although my suspicion is that will result in a non-intuitive API.
| periods (e.g. 1s) for many HPAs, increasing the rate of metrics queries | ||
| and scale sub-resource calls. This is mitigated by: | ||
| - Validation bounds: `syncPeriodSeconds` must be >= 1 and <= 3600. | ||
| - Cluster administrators can use admission webhooks or policies to enforce |
There was a problem hiding this comment.
Wouldn't a meaningful webhook require to calculate the aggregate sync frequency across all HPAs in the cluster? For users, this looks difficult to reason about.
Do you see another way such a webhook could implemented? Perhaps it could be part of this KEP to ensure this feature is safe by default?
| ``` | ||
|
|
||
| The per-HPA sync frequency is implemented via a new `PerItemIntervalRateLimiter` | ||
| in the HPA controller's workqueue. This rate limiter supports per-key interval |
There was a problem hiding this comment.
Wouldn't metrics-server and custom/external metrics API need to respond in less than 1s to ensure the workqueue doesn't saturate? This looks like a very short timeout. Do you see how to prevent the workqueue from blocking? Perhaps this new field should only be a hint (i.e. a best-effort goal)?
4 participants
