Run Kubernetes on a Mac with Kube Solo | Hacker News Reader

Run Kubernetes on a Mac with Kube Solo

deis.com

119 pointstdurden16 comments

A few questions to Kubernetes people:

We are currently using Docker images locally and compose them together with docker-compose. Compose is using a custom devDockerfile identical to the normal Dockerfile, plus a self-reloading / self-compiling webserver.

For deployment we are using AWS EB and push the same Dockerfile (minus the self-reloading webserver). For heavy load applications, we use autoscaling behind a AWS loadbalancer.

Is Kubernetes giving us something over our current Docker setup? Can it improve on our workflow?

Is the time investment for learning this worth it for private projects vs plain Docker that can get pushed to Heroku / Google / AWS?

I have Kubernetes on my list of things I want to check out but every time I go into the getting started guides for local environments, it seems like a lot of work for just setting the environment up. One of the things I love Docker is that I can write the Dockerfile and everyone from our team can very easily use it and immediately has the app running. No Docker? Just install Docker and compose through brew or download it from the website. That's it.

I think it won't give you much in Dev but can give your more in production. We have the following work flow

1. Use Docker images for our applications where we can run them locally by mounting in a config file pointing to local db or dev cluster db etc

2. We then use CI to build new docker images and push them to our registry

3. Using Kubernetes deployment yaml files we then deploy the new versions to the cluster with rolling upgrades. This can be combined with auto scaling For config we have a Kubernetes ConfigMap in the cluster which then gets mounted into the docker containers when they start.

My suggestions would be for you to check out Googles Hosted Kubernetes which removes a lot of the headache of getting up and running. https://cloud.google.com/container-engine/

I still use docker-compose in development even with k8s in production. I recommend you checkout kdm (recently released in k8s 1.4) which will help you setup a cluster on a single node in less than 5 minutes.

As for time investment, k8s is kind of an all-in-one solution. It will take care of rolling updates, container restarts, monitoring so you won't have to roll your own solution. It will definitely improve your workflow. Kubernetes also takes advantage of declarative configuration files so it's super easy to bring up a new cluster somewhere else by just applying your config files again.

Also, Kubernetes is a good investment because it's not tied completely to Docker. Whatever container technology reigns supreme in the future should work with k8s no matter what.

Just curious - how does this compare to just running minikube?

From a casual read - 1) has a status bar icon for easier control, just like Docker for Mac. 2) Uses CoreOS as the base OS in xhyve

What is going on in that second para:

> Fortunately, now that Docker for Mac is generally available, you can easily run both Docker and Kubernetes on OS X

and then

> But what if you want to get up and running with Kubernetes on OS X?

Would love not to have to maintain separate docker-compose config files for development and Kubernetes/Marathon/whatever for staging/production.

Kompose [1] might be the answer for you.

[1] https://github.com/kubernetes-incubator/kompose

We use Minikube during development and have dropped compose files entirely :)

How come? What do you use to declare your dev environment?

Have you run into any issues where the minikube env is sufficiently different from production that you it requires some tweaks/hacks?

Also curious if you run multiple services in local minikube for integration testing?

Curious: Does the usage of CoreOS replace Docker OSX's virtualbox linux VM it uses? And if not, is there any reason why KubeSolo couldn't be designed to run on that VM, just to save resources?

Docker for Mac ditches VirtualBox and uses a more native xhyve. Also, I believe, Alpine Linux is used as the OS for the xhyve VM.

This uses the same Xhyve driver with CoreOS as base OS.

Yes, but why does this depend on Docker for OS X if it's not reusing Docker's Alpine VM?

Docker's new Alpine VM isn't really designed to be reused. AFAICT the interfaces are private and undocumented.

Reusing xhyve/hyperkit seems more stable, given that they're designed to be embedded.

No, this does not depend on Docker for OS X. They both use the underlying driver.

Reply on news.ycombinator.com