Clarify use cases

[the-gigi]

The use cases say

Only time will tell how useful zeropod actually is. Some made up use-cases that could work are:

Low traffic sites
Dev/Staging environments
"Mostly static" sites that still need some server component
Hopefully more to be found

Can you clarify it some more? As far as Kubernetes is concerned the pod is still there, so all its requested resources are unavailable to other workloads on the same node.

If a regular pod does nothing when no traffic is coming then it's actual CPU usage will be zero anyway, so checkpointing it will not contribute much.

The only benefit I can see is for containers that keep a large in-memory cache, which is wasted if the container is inactive for long periods of time. Other workloads on the same node can use this memory when the container is checkpointed and their mem limit > mem requests (memory overbooking), which can cause OOM kill when the container needs to be brought back.

Is that a correct analysis or am I missing something obvious?

[ctrox]

If in-place resource scaling is enabled, the cpu and memory requests will both be adjusted on scale-down so the freed up resources should be available to other workloads on the same node. So this makes it very simple to overbook a node. But you are right, there are going to be problems if a node is already low on resources and zeropod tries to restore a container on that same node.

I already mentioned this in #38, I'm currently working on a migration feature that makes it possible to essentially move scaled-down pods to another node. This will make it possible to rebalance things in the cluster so for example if we have node1 with 95% of memory requested but also a few scaled down zeropods, we could decide to move a few of these away to another node that has more free capacity. This will of course need some parameters depending on how often zeropods are being restored or something similar that VPA does where we look back at the history and tries to approximate the usage.