4 ms·
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 tha
by 013a 9y ago
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.
- cube2222 9y agoWell, just give em a personal namespace with 4-8000millicpu
- 013a 9y agoYeah 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.