You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is currently done in the [getReplicaSetFraction](https://github.com/kubernetes/kubernetes/blob/1cfaa95cab0f69ecc62ad9923eec2ba15f01fc2a/pkg/controller/deployment/util/deployment_util.go#L492-L512)
302
-
function. The leftover pods are added to the newest ReplicaSet.
302
+
function. The leftover pods are added to the largest ReplicaSet (or newest if more than one ReplicaSet has the largest number of pods).
303
303
304
304
This results in the following scaling behavior.
305
305
@@ -364,7 +364,7 @@ As we can see, we will get a slightly different result when compared to the firs
364
364
due to the consecutive scales and the fact that the last scale is not yet fully completed.
365
365
366
366
The consecutive partial scaling behavior is a best effort. We still adhere to all deployment
367
-
constraints and have a bias toward scaling the newest ReplicaSet. To implement this properly we
367
+
constraints and have a bias toward scaling the largest ReplicaSet. To implement this properly we
368
368
would have to introduce a full scaling history, which is probably not worth the added complexity.
0 commit comments