I was wondering what termination strategy is employed by Replication Controller during scale-in requests.
For Example:
Initial replicas = 2
2 Pods are created { Pod-1, Pod-2 }
Scale out to 5
3 more Pods will be created { Pod-1, Pod-2, Pod-3, Pod-4, Pod-5 }
Scale down to 2 again
3 Pods will be deleted, and we are left with only 2 Pods { Pod-x, Pod-y }
Now, will Replication controller terminate and delete the pods as per their age? or it depends if container inside the Pod is busy? or is it a random order?
I tested this scenario a couple of times and found that the Pods are terminated at random. Can anyone please confirm the same? And is there a way to control the termination sequence?
Thanks in advance.
A Kubernetes replication controller ensures that a specified number of pod "replicas" is running at any given time. If there are too many, it will kill some. If there are too few, it will start more. Unlike in the case where user directly created pods those maintained by the ReplicationController are automatically replaced if they fail, are deleted or are terminated
There is a logic in the selection of pods to be killed under the downscaling process.
Wages used to select pod to be killed are described by developers:
// 1. Unassigned < assigned
// If only one of the pods is unassigned, the unassigned one is smaller
// 2. PodPending < PodUnknown < PodRunning
// 3. Not ready < ready
// 4. Been ready for empty time < less time < more time
// If both pods are ready, the latest ready one is smaller
// 5. Pods with containers with higher restart counts < lower restart counts
// 6. Empty creation time pods < newer pods < older podsThere is no config option you can set to avoid particular pods to be killed. If you want to understand in detail how it is working - please look at the source code, have a nice lecture.