When manageJob() needs to create replacement pods but defers creation
because a pod-failure backoff is still active, it returned a hardcoded
active=0 to the caller. Because no pods were actually created or deleted,
this left Status.Active=0 while Status.Ready still reflected the running
pods. The apiserver correctly rejects such updates ("cannot set more
ready pods than active") with a 422, which blocks flushing uncounted
terminated pods, removing finalizers, and updating job status, leaving
pods stuck Terminating with stale status.
Return the real active count from both backoff early-returns instead,
since the deferral does not change the number of active pods.
Issue: https://github.com/kubernetes/kubernetes/issues/139428
TestStatefulSetScaleDownRespectsMinReadySeconds and
TestStatefulSetOnDeleteStrategyIgnoresMinReadySeconds are testing
.spec.minReadySeconds. This resulted in tests spinning sufficiently long
to reach the desired value. In both cases it was set to 30s.
This change modifies scaleUpStatefulSetControl allowing to inject
fakeClock which allows faster time changes, thus speeding the tests.
Signed-off-by: Maciej Szulik <soltysh@gmail.com>
* Fix format-string argument order in object metric error messages
The error format strings in GetObjectMetricReplicas and
GetObjectPerPodMetricReplicas had the arguments in the wrong order,
causing objectRef.Kind to be printed where the error should appear
and vice versa.
Signed-off-by: Mikhail Fedosin <mfedosin@redhat.com>
* Use %w for error wrapping in fmt.Errorf calls in podautoscaler
Replace %v with %w for error arguments in fmt.Errorf throughout the
HPA controller, replica calculator, and metrics client. This enables
proper error wrapping so that callers can use errors.Is and errors.As
to inspect underlying errors.
Signed-off-by: Mikhail Fedosin <mfedosin@redhat.com>
---------
Signed-off-by: Mikhail Fedosin <mfedosin@redhat.com>
The endpoint-mappings.yaml file specifies which components use which
metrics. The case some, but not all core components (kube-controller-manager
and kube-scheduler in this case) sharing the same metrics was not
supported. This gets fixed by not returning early once the first file path
matches.
Not all metrics in pkg/controller/resourceclaim/metrics are shared. To make the
sharing clearer and fit into the file-path based component support in
endpoint-mappings.yaml, the shared metric gets moved to a new
pkg/resourceclaim/metrics package.
Both kube-controller-manager and kube-scheduler create ResourceClaims. Using
the same metric (sub-system: "dynamic_resource_allocation", name:
"resourceclaim_creates_total") in both components simplifies aggregation across
the entire cluster.
In our defaulting code we ensure that PodReplacementPolicy is set, its
value will depend on PodFailurePolicy being set or not, but we can
safely assume it's set. Thus the method onlyReplaceFailedPods is
sufficient to only verify PodReplacementPolicy and its value.
Signed-off-by: Maciej Szulik <soltysh@gmail.com>
