Re: Rolling pod evacuation

Thanks for the clarification. On Sun, 23 Apr 2017 at 23:30 Marko Lukša 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

Re: Rolling pod evacuation

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

Re: Rolling pod evacuation

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 wrote: > Sorry, just reread the thread. In that case you would use a PDB but normal > users cannot use them in 3.5

Re: Rolling pod evacuation

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.

Re: Rolling pod evacuation

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 > wrote: I

Re: Rolling pod evacuation

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 wrote: > I didn't think this was honoured as it just deletes the pods? > > On Thu, 20 Apr 2017 at 18:43 Michail Kargakis wrote: > >> If you want to scale up first and wait for the new

Re: Rolling pod evacuation

Thanks. I did see PodDisruptionBudget in the docs but it requires that extra step, users are also unable to create their own by default(?) On Thu, 20 Apr 2017 at 19:23 Marko Lukša wrote: > Take a look at PodDisruptionBudget. It allows you to specify the minimum > number of pods that must be kept

Re: Rolling pod evacuation

I didn't think this was honoured as it just deletes the pods? On Thu, 20 Apr 2017 at 18:43 Michail Kargakis 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 > wr

Re: Rolling pod evacuation

Take a look at PodDisruptionBudget. It allows you to specify the minimum number of pods that must be kept running when removing pods voluntarily (draining nodes is an example of this). But this feature may not be in OpenShift yet (IIRC draining nodes in Kubernetes honors the PodDisruptionBudget

Re: Rolling pod evacuation

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 wrote: > Is there any way to evacuate a node using the rolling deployment process > where a the new pod can start up first befor

Rolling pod evacuation

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