Loading...

XML

Word

Printable

Details

Type: Story
Resolution: Unresolved
Priority: Normal
Fix Version/s: None
Affects Version/s: openshift-4.13
Labels:
- controller
- upstream

Story Points:
13
Blocked:
False
Blocked Reason:
None
Ready:
False
Epic Link:
Upstream SIG-Apps 4.16
Feature Link:
OCPSTRAT-46 - Strategic Upstream Work - OCP Control Plane and Node Lifecycle Group

Sprint:
Workloads Sprint 234, Workloads Sprint 235, Workloads Sprint 236, Workloads Sprint 237, Workloads Sprint 238, Workloads Sprint 239, Workloads Sprint 240, Workloads Sprint 241, Workloads Sprint 248, Workloads Sprint 249, Workloads Sprint 250, Workloads Sprint 251, Workloads Sprint 252

Target Version:

openshift-4.16

SFDC Cases Links:
SFDC Cases Counter:

Description

In some cases people are surprised that their deployment can momentarily have more pods during a rollout than described ( replicas - maxUnavailable < availableReplicas < replicas + maxSurge). The culprit are Terminating pods that can run in addition to the Running + Starting pods.
Even though Terminating pods are not considered part of a deployment this can cause problems with resource usage and scheduling as described in https://github.com/kubernetes/kubernetes/issues/107920

There is a KEP that tries to solve this issue for Deployments/ReplicaSets and also for a similar use case in Jobs: https://github.com/kubernetes/enhancements/pull/3940 . Also similar feature gap is in daemonsets. We should help out with pushing this feature forward.

This has a customer impact and we are tracking this as an RFE https://issues.redhat.com/browse/RFE-2328