I’m not quite sure to understand the documentation about maxSurge, because as far as I understand, as we have maxSurge at 25%, Kubernetes can create up to 25% of the desired replica count as additional pods. as we have a replica count of 1, how can it launch even a single replica without directly killing the other one?
okay, so 25% but at least one which make sense
so it means that in my case the 2 replicas will be running together during a short period of time I guess, as far as I don’t explicitly set maxUnavailable to 1 and maxSurge to 0 right?
Yeah since maxunavailable rounds down
OK got it, thanks a lot for your help!
have you looked at vertical pod auto scaling which would increase the CPU/mem resources to your pod if it’s available in the node. It could do that without a restart if you can run the alpha version of vpa
No I didn’t. I’m not sure it would help in this specific case, as our leak is very aggressive so it would mean that it would very quickly use a huge amount of memory. The solution is clearly to fix this leak but I was just wondering how we could “smoothly” restart the pod without any downtime.
My other idea was maybe to have another pod constantly checking the memory usage (e.g. using prometheus metrics) and do a kubectl rollout restart when the amount of memory is too high
