[question] Migration requirements and limitations

[d-uzlov]

I found this project while searching for options for pod live migration. I don't think I need to scale to zero.
I'm trying to understand if this project will be useful in my case.

I read the readme, and I have a few things I don't understand about current state of the migration feature and the future possibilities.
Please, don't read it as a list of feature requests, even though bottom of the list contains "possible to implement" type questions. This is really just a list of questions, I want to understand the limitations of the technology.

1. Is it possible to use migration without scaling down pods?

What will happen if a pod is deleted while it is active?

Readme mentions that it's possible to disable scaledown by setting zeropod.ctrox.dev/scaledown-duration=0.
Will the migration feature work at all in this case?

2. How does zeropod decide that it needs to migrate pod?

Readme says that when migration is enabled, new pod will fetch checkpoint from the old pod.
Reddit post mentions that zeropod uses pod-template-hash to check if migration is possible (should this be added to readme here?).
But how does zeropod know that migration is required for a certain new pod?

For example:

2.1. Deployment has 2 pods on node N1. Node is being drained, and these pods are deleted. Will they both migrate?
2.2. One pod is deleted and 2 new ones are created. All 3 have the same revision hash. Which one will be migrated and which one will be created from scratch?
2.3. I want to forcefully recreate a pod. I delete it, and deployment creates a new pod. Will it get a migration? If yes, then how do I prevent it?

3. Could it be possible to force migration?

Let's say pod X is running on node N1. I want to migrate it to node N2.
My understanding is that currently there is no configuration for this. But could this be possible at all with current design?
It seems like relying to pod-template-hash prevents this. So, migration could be used only to rescue pods from a certain drained node?

4. Which parts of the pod are and aren't migrated?

Here is my current understanding.

Migrated (for all containers included in zeropod.ctrox.dev/migrate):

• Root filesystem state
• Memory state

Recreated:

• Root filesystem state (for containers not in zeropod.ctrox.dev/migrate)
• Memory state (for containers not in zeropod.ctrox.dev/migrate)
• Pod IP
• Pod name
• Pod UID
• Environment variables (downward API, values from configmaps)
• Container metrics
• Logs
• EmptyDir volumes
• • It was mentioned in reddit discussion 2 months ago. Is this still the case?
• All volumes are reattached
• All devices are reattached (and who knows if application will successfully reconnect)

Obviously, any hostPath volumes will break, and should not be used.

Am I correct here? Am I missing some important state in the lists?

5. Could it be possible to use migration for something other than deployments?

In readme I see that currently migration is only for deployments.
But it would be nice to migrate pods of StatefulSet applications. Will it work? Is it possible to implement?

There are also custom pod controllers that could benefit from migration. For example, Postgres Cluster from CNPG, or CloneSet (=deployment with custom fields) from OpenKruise.
Could migration work with custom controllers?