If you're developing a service architecture that runs in kube on production, you want to emulate that as close as possible locally.

I'm more of the opinion that devs should just have access to a kube "cluster" (maybe just one machine) in the cloud, possibly one per dev. Make a change to the service, build it, and deploy it. Give easy tools to re-image your cluster whenever you want. Primarily because you want your "local" environment to match production as closely as possible.

Well, just give em a personal namespace with 4-8000millicpu

Yeah that can work as well. In general, though, I prefer absolutely strict isolation between environments. In our deployments, this goes all the way to having separate GCP Projects for each environment. This has as much to do with kubernetes as it does with all the other cloud resources in each environment that we don't want commingling inside the same GCP project.

Kube also still has some oddities when working with namespaces, especially when using third party tools.

I have two projects that talk directly with k8s, it's keel (CI tool for kube) https://github.com/keel-hq/keel and ingress controller for webhookrelay.com so I need a working cluster locally. However, other services are also tested on local minikube as it's easier to make sure they are interacting as intended when running in K8s :)

Thanks, that makes perfect sense. I guess that's what I expected but wanted to see if there was another use case. Keel looking interesting. I will take a look. Thanks.