3 ms·

>"It's now my default k8s dev environment, ..." Could I ask you what are you developing that you need a whole local K8 dev environment? What I mean is as oppo

>"It's now my default k8s dev environment, ..." Could I ask you what are you developing that you need a whole local K8 dev environment? What I mean is as opposed to just using docker compose or docker container themselves. Are you specifically developing K8 features? Thanks.

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 ago
  Well, just give em a personal namespace with 4-8000millicpu
  - 013a 9y ago
    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.
deforciant 9y ago
I have two projects that talk directly with k8s, it's keel (CI tool for kube) https://github.com/keel-hq/keel 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 :)
- bogomipz 9y ago
  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.

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 ago
Well, just give em a personal namespace with 4-8000millicpu
- 013a 9y ago
  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.

deforciant 9y ago

I have two projects that talk directly with k8s, it's keel (CI tool for kube) https://github.com/keel-hq/keel 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 :)

bogomipz 9y ago
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.