Lifecycle
A recommendation is captured as a deterministic revision, validated progressively, and either marked ValidatedWithoutPersistence or held at ValidatedAwaitingPersistence until admission-time injection occurs.
Stable, cumulative pod selection
StableHash sorts eligible pods using the workload UID and pod UID. Each percentage uses a prefix of that stable ordering, making steps cumulative: 10% followed by 25% adds the next 15%, rather than selecting a separate 25%.
Desired counts use ceiling division, so 10% of 11 pods selects 2 pods.
In-place resize semantics
| State | Meaning |
|---|---|
| Pending | No resize has been requested. |
| InProgress | Pod spec has the target but runtime status has not caught up. |
| Deferred | Kubernetes reports a pending, retryable resize. |
| Infeasible | Kubernetes cannot apply the resize; validation fails. |
| Applied | Both pod spec and runtime status reflect the target. |
A successful API patch is not enough. Kapr waits for pod status to report the target resources before counting the pod as applied.
Recommendation revisions and supersession
The revision fingerprints workload identity, container names, requests, and limits. Container order does not affect it.
If a recommendation changes during validation, Kapr supersedes the in-flight revision and begins again. If it changes after validation but before persistence, Kapr clears webhook eligibility and re-baselines from the already-resized live pods.
Deferred persistence
In AdmissionOnNextPodTemplateChange mode, validation does not patch the workload template. The webhook waits for the next update whose pod template is already changing, injects the validated resources, and adds revision annotations. The reconciler observes those annotations and records Persisted.
Post-pause analysis
The optional CPU throttling evaluator queries Prometheus after the readiness check and pause. It supports AnyPod, PercentageOfPods, and Average aggregation. A failure triggers best-effort rollback and places the revision on a sticky deny-list.
The settle gate ensures every canary pod has been at target resources for at least the Prometheus lookback window before evaluation.