Same here. I do devops for 10 years (used to be called systems engineering) and have implemented containers once and Kubernetes zero times. I successfully made companies avoid Kubernetes several times. Most of the time tool focused people think that the next thing is a miracle that makes every problem go away, which is certainly not true. If you define the problems first and try to find solutions than you get much better results. Choosing a tool and try to find problems it solves is idiotic. Just like using Kubernetes instead of something much simpler.
You are implying that we need container migration. I give you one example of how you do not need that. Let's set up an autoscaling group with node count = 10. On node error you terminate the node in trouble. Autoscaling detects that you have less capacity than required. Creates a new instance. You are good. This is a much simpler solution to the problem than trying to think where you container fits, avoiding cascading problems and trying to track the state of your cluster.
And to be clear, "container migration" is nothing more advanced than this "take the failed system out of service and spawn it somewhere else" routine that we've been doing since time immemorial.
Things like VMware's vMotion or KVM's live migration can detect trouble and transparently move the running VM -- network connections, memory state, and all -- onto a different underlying host, leaving end users none the wiser.
That's the kind of thing noobs throw out the window when they come in fired up about how k8s have health checks, because they've never heard of health checks before.
People are trying to recreate container-level mobility with things like CRI-U, which is very cool, very cutting edge stuff, but right now it's so unpredictable even the k8s crowd is afraid to touch it. ;)
Once these things eventually pan out and the functionality gets tangled up into some contrived k8s-ified YAML abomination (aka "blessed by the Great Googly Appendage"), when the k8s fanboys start hailing it as the savior of all computerdom, I'm sure I'll be making posts like "Uh, hi, this is awesome tech, but live migration anyone? We've had this for a long time..."
CRI-U has the potential to open many doors, and while true live container migration may be one of them, it's not really the exciting one, primarily because we've already had fatter-but-functionally-similar support for server workloads through VM migration/snapshots. CRI-U's promise is in all the things we can do with process-level "save states" that aren't just "moving 300MB of RAM at a time instead of 8G".
