5 ms·

I also had a look at Docker for Mac. It's now my default k8s dev environment, I must admit that even if their high CPU usage issue it's still a lot more CPU fri

I also had a look at Docker for Mac. It's now my default k8s dev environment, I must admit that even if their high CPU usage issue it's still a lot more CPU friendly than minikube. What's great for development is that you can also build images on Mac and run them inside k8s environment, no need to change daemons. Which was sometimes a bit annoying with Minikube and I usually found myself just pushing them to the dockerhub and then pulling to minikube :) However, not sure why the dashboard is not enabled by default, it's quite handy. If you are interested in ingress controllers and demoing your apps directly from your mac, have a look at my recent blog post: https://webhookrelay.com/blog/2018/01/08/ingress-with-docker-for-mac/ https://webhookrelay.com/blog/2018/01/08/ingress-with-docker...

bogomipz 9y ago
>"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.
hinkley 9y ago
At this point minikube is so far behind on docker versions that the docker documentation is a source of frustration. I’m working on dockerizing a largish node project and so I have to keep clearing out old containers to make space, and the cleanup commands aren’t there. Also about once a week I’ll build and tag a docker image successfully and it’s just gone. Docker images doesn’t show it and you can’t run it. Restart minikube and run a ten minute build again. Super. I’m supposed to be documenting this stuff for people who don’t use docker. Right. Off to upgrade docker for Mac instead.

bogomipz 9y ago

>"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.

hinkley 9y ago

At this point minikube is so far behind on docker versions that the docker documentation is a source of frustration. I’m working on dockerizing a largish node project and so I have to keep clearing out old containers to make space, and the cleanup commands aren’t there. Also about once a week I’ll build and tag a docker image successfully and it’s just gone. Docker images doesn’t show it and you can’t run it. Restart minikube and run a ten minute build again. Super. I’m supposed to be documenting this stuff for people who don’t use docker. Right. Off to upgrade docker for Mac instead.