[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Rolling pod evacuation



Thanks for the clarification. 

On Sun, 23 Apr 2017 at 23:30 Marko Lukša <marko luksa gmail com> wrote:
No, they are different. With a Deployment, maxUnavailable=0 will just make the controller create a new pod before it deletes the old one. With a PDB, if its minAvailable is equal to the desired number of replicas, the PDB won't allow the pod to be deleted, and the drain operation also won't create a replacement pod before it tries to delete the pod. (a drain operation never creates pods, it just deletes them).

As Michail said, pdb.minAvailable==deploy.replicas causes the drain to be blocked. So, PDB.minAvailable needs to be less than or equal to deploy.replicas-1. In that case, the drain operation will delete a pod and then wait for the deployment/replicaset controller to run a replacement pod. When that pod is available, the drain will continue. 

On Sun, Apr 23, 2017 at 2:14 PM, Andrew Lau <andrew andrewklau com> wrote:
Do PDB work like the earlier mentioned maxUnavailable=0 or do they simply prevent a pod from being evicted if a node is being drained?

On Fri, 21 Apr 2017 at 17:37 Michail Kargakis <mkargaki redhat com> wrote:
Sorry, just reread the thread. In that case you would use a PDB but normal users cannot use them in 3.5 and 3.6 yet... But even PDB can't help you today if you run a single pod. I think those deployments will block evacuation and that may be a reason why we didn't enable them for users initially.

On Fri, Apr 21, 2017 at 9:27 AM, Marko Lukša <marko luksa gmail com> wrote:

He isn't performing a rolling upgrade; he just wants to drain a node one pod at a time.


On 21. 04. 2017 09:18, Michail Kargakis wrote:
If you used those settings and it wasn't honoured then it's a bug.

On Fri, Apr 21, 2017 at 1:38 AM, Andrew Lau <andrew andrewklau com> wrote:
I didn't think this was honoured as it just deletes the pods?

On Thu, 20 Apr 2017 at 18:43 Michail Kargakis <mkargaki redhat com> wrote:
If you want to scale up first and wait for the new pod to come up before deleting the old use maxSurge=1, maxUnavailable=0

On Thu, Apr 20, 2017 at 10:11 AM, Andrew Lau <andrew andrewklau com> wrote:
Is there any way to evacuate a node using the rolling deployment process where a the new pod can start up first before being deleted from the current node?

Drain seems to only delete the pod straight away. If there is a grace period set, it would be nice if the new pod could atleast have its image pulled into a new node first before being deleted from the drained more.

_______________________________________________
users mailing list
users lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users





_______________________________________________
users mailing list
users lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


_______________________________________________
users mailing list
users lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


_______________________________________________
users mailing list
users lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]