IsValid accepted a deployment as long as its status reported an
available replica. When the idle reaper scales the deployment to zero,
Spec.Replicas drops right away but the status can still count the pod
that is shutting down, so a cache hit kept routing requests to it.
Export the availability check from executor/util, make it look at the
spec as well, and use it in the container and newdeploy IsValid paths.
createOrGetDeployment decided whether to wait for readiness from the
Status.AvailableReplicas of the copy it read before ScaleDeployment, the same
pattern the container manager had. On the scale-from-zero path that copy can
still count the pod the idle reaper is tearing down, so WaitForDeployment, and
with it the ObservedGeneration gate, was skipped entirely.
Track whether we issued the scale-up and always wait in that case. The test
covers both the pre-scale read and a status the controller has not caught up
with yet.
WaitForDeployment returned as soon as AvailableReplicas was high enough, without checking that the status belonged to the current spec. UpdateScale only writes the spec, so a Get issued right after it can still carry the previous generation's status, counting the pod that is being torn down.
Gate AvailableReplicas behind ObservedGeneration, the same condition WaitForDeploymentRollout already uses in the integration framework.
Turn the scale-from-zero regression into a table so it covers both the pre-scale read and a status the controller has not written yet, and give the type assertion in the reactor the SAFETY comment the lint gate wants.
createOrGetDeployment read the Deployment once and then reused that copy's
Status.AvailableReplicas to decide whether to wait for readiness. On the
scale-from-zero path the read happens while the idle reaper's pod is still
terminating, so the pre-scale status can still report an available replica and
the readiness wait is skipped. The executor then returns a Service whose
endpoints are empty and the router's forward fails with a 500.
Track whether we issued the scale-up and always wait for the deployment in
that case; WaitForDeployment re-reads from the API server, so an already
available deployment still returns on its first poll.
dualfroz
upstream