Thanks for the clarification. On Sun, 23 Apr 2017 at 23:30 Marko Lukša <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> >>>> wrote: >>>> >>>>> I didn't think this was honoured as it just deletes the pods? >>>>> >>>>> On Thu, 20 Apr 2017 at 18:43 Michail Kargakis <[email protected]> >>>>> 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 <[email protected]> >>>>>> 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 >>>>>>> [email protected] >>>>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users >>>>>>> >>>>>>> >>>>>> >>>> >>>> >>>> _______________________________________________ >>>> users mailing >>>> [email protected]http://lists.openshift.redhat.com/openshiftmm/listinfo/users >>>> >>>> >>>> >>>> _______________________________________________ >>>> users mailing list >>>> [email protected] >>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users >>>> >>>> >>> _______________________________________________ >>> users mailing list >>> [email protected] >>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users >>> >> >
_______________________________________________ users mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/users
