Kubernetes Config Connector: Provision GCP Infrastructure Using Kubernetes
github.com
github.com
It is too bad because declarative specifications and control loops to have state converge to what it should be is a nice pattern.
Keeping up with all of AWS’s surface area though is hard if their heart isn’t in it.
You end up in this weird place where your compute nodes can, at any time, assume super powerful roles that can change nacls, security groups, completely destroy database clusters or what have you.
It feels like running your app as root and database admin, but more. I guess if you completely trust your kube control plane?
Like everything I'm sure it has a use somewhere.
In AWS you end up with a manually built/managed root cluster and if you've automated deploying / upgrading (which you probably should) that then you might as well just use those pipelines and code for all your other clusters too instead of having 1 special thing.
If the infrastructure gets complex there will start to be dependencies between stuff, there is definitely a tipping point where you need a real iac pipeline (tf/cf) instead in any case.
I think captn3mo proposed one of the more reasonable use cases which is provisioning stuff like queues and dbs for test envs or ci, we ended up stubbing out aws for ci and using the same pipeline code we use to deploy to prod instead for "full fat" testing but I can see where it might make sense to use kube manifests. Probably some creative uses for "deployment per customer" SaaSs too.
So much better to get an immediate feel for a service.
So why not cloud resources too?
Having to run a cluster to do so doesn't feel quite right, however. But then if you're using Terraform - which is the most popular "cloud convergence engine" - you've probably provisioned compute resources with which to run Terraform. So not that strange.
Even better, this model uses the RBAC, namespaces, quotas and tools that developers are already using.
It's very difficult to delete infra in AWS without a resource graph once you have enough things that refer to each other.
You can only get so far with a bunch of isolated yaml manifests for single resources.
So the MVP of anything that can solve the general case basically ends up doing the exact same things as terraform... and might as well actually be terraform.