You make an excellent point, and it emphasizes the need to distinguish between a typical Kubernetes setup (containers, pod/service mesh, and so on), and what Ku

You make an excellent point, and it emphasizes the need to distinguish between a typical Kubernetes setup (containers, pod/service mesh, and so on), and what Kubernetes can do in the abstract. In the extreme, the API server is just an HTTP interface for a KV store with a bit of RBAC and validation-mutation extensions. What Neon is doing is quite a feat: Live migration (of a VM) while preserving TCP connections. It also took a lot of customization to achieve that. But I agree that Kubernetes can indeed be used this way. If anything, it further cements my original point about the Gitpod leadership. The problem was never Kubernetes, but the dimwitted notion of using containers. And then blaming Kubernetes for it: We're leaving you.