3 ms·

That might work in some scenarios. If you're a "newer" company where each application is deployed onto individual nodes, you can do this. But consider that the

That might work in some scenarios. If you're a "newer" company where each application is deployed onto individual nodes, you can do this. But consider that the case for older companies, where it was more common to deploy several systems, often complex ones, onto the same node. You will also cause outages to system x, y and z too. Maybe some of them are inter-dependent? You have to outwhey the consequences and risks carefully in any situation before rebooting.

bschne 3y ago
> Cloud definitely has downsides, and isn’t a fit for all scenarios but in my experience it’s great for situations like this. At least as I read it, this contains the assumption that that‘s not how you deploy your applications
FridgeSeal 3y ago
> it was more common to deploy several systems, often complex ones, onto the same node. Yeah we do this? It doesn’t pose an issue though. Cordon the node (stop any new deployment going on), drain it to remove all current workloads (these either have replicas, or can be moved to another node, if we don’t have a suitable node, K8s spins up one automatically) and then remove the node. Most workloads either have replicas spare, or in the case of “singleton” workloads, have configs ensuring the cluster must always have 1 replica available, so it’s waits for the new one to come up before killing the old. Most machines deploy and join the cluster in a couple of minutes, and most of our containers take only like, 1 or 2 seconds to deploy and start serving on a machine, so rolling a node is a really low impact process.