Why would you expect that? Or use it that way? The clouds are IaaS, and Kubernetes is like a virtual human that creates resources using the same APIs you would. It's on K8S to keep track of what it's creating.
Why not use Kubernetes to declaratively define nodes, disks, load balancers, firewall rules, DNS rules...? If you look at Terraform, for example, it's just an "object store" (the state file) that you modify in order to "converge" your infrastructure.
If you're already using Kubernetes via GKE or a similar IaaS, then of course Kubernetes has underlying primitives (GCE disks, GLBCs, etc.) that are exposed. But those primitives are exposed because GKE runs on top of GCP.
What I'm proposing is a "KaaS" where Kubernetes is the control plane, without the baggage of an additional API.
That's because Kubernetes isn't an infrastructure system, it's an application system. More PaaS than IaaS, so you're supposed to define what your app needs and let it do the work.
You don't specify a node but the CPU/RAM your application requires and let K8S scale up the cluster if necessary. Likewise, you specifiy the storage needed instead of managing disks, and set network policies to control load balancing and routing. If you want to live in Kubernetes only today, you can absolutely do that. Launch your cluster once and then use kubectl and yaml for the rest.
Why not use Kubernetes to declaratively define nodes, disks, load balancers, firewall rules, DNS rules...? If you look at Terraform, for example, it's just an "object store" (the state file) that you modify in order to "converge" your infrastructure.
If you're already using Kubernetes via GKE or a similar IaaS, then of course Kubernetes has underlying primitives (GCE disks, GLBCs, etc.) that are exposed. But those primitives are exposed because GKE runs on top of GCP.
What I'm proposing is a "KaaS" where Kubernetes is the control plane, without the baggage of an additional API.