As I was reading this I thought it was calling for using the K8s API as an abstraction over all types of backend compute vendors. That would actually avoid vendor lock-in. Set up one control plane somewhere and use it to manage your AWS, Azure, GCP, on-prem VMWare etc.

That would mean you need the K8s API for your control plane but not necessarily that you have to run a K8s cluster or clusters as long as the API layer is the same. Maybe the control plane is a managed service too and you just interact with it.

I'm a bit skeptical of these single pane of glass type solutions since the abstractions always end up being somewhat leaky. The abstraction turtle stack is so high at this point you have to know 11 different technologies just to start a process on a Linux box.

But I get the operational appeal of having a central control plane rather than a million control planes all with their own AuthN/AuthZ, logging, custom YAML DSL, APIs, security configurations, integration points etc.

I think that's the actual goal of kcp: https://github.com/kcp-dev/kcp