Not the author of this post, but a maintainer of minikube. Glad to answer any questions.

I started playing with kubernetes today and used minikube! Thanks for building it!

Can you outline the differences between minikube and kube-solo?

Is there anything planned to support multiple nodes. So that one can test outage scenarios, load balancing across nodes, etc?

If not what other local deployment method do you suggest that works good? (All other methods seem to be deprecated)

We aren't planning to support multiple nodes anytime soon. The resource overhead would probably be too much for most users just looking to try out kubernetes.

You can take a look at the k8s docs about running locally. There's a script that brings up a cluster with a configurable amount of nodes on linux.

[0] https://github.com/kubernetes/kubernetes/blob/v1.5.0/docs/de...

[1] https://github.com/kubernetes/kubernetes/blob/v1.5.0/hack/lo...

Is there any plan to support MiniKube with LXD as VM driver (not container engine)?

Not really. We run in a buildroot [0] based VM on your laptop so that we can run k8s components and a docker daemon cross platform (windows, osx, linux). On linux, it might be an interesting idea, but it looks like theres still an upstream issue on kubernetes to support lxc/lxd [1].

Right now, minikube supports rkt and docker. And the systemd integration of rkt is pretty nifty.

[0] https://buildroot.org/

[1] https://github.com/kubernetes/kubernetes/issues/6862

[2] https://github.com/kubernetes/minikube

Django doesn't really seem like a framework that is suited to cluster computing, its almost always backed by a relational database and usually IO to the DB is the bottleneck, assuming you now how to use it. Can someone explain the advantages of running it like this to me?

As the other poster said, you run Django on Kubernetes for the same reason you run anything on it:

* Containers are an easy way to package an application so that it's easy to run anywhere, even if it has weird dependencies

* Eventually, you'll want to run containers on more than one machine for performance/reliablity

* Kubernetes makes it easy to schedule containers on a lot of machines, have them talk to each other over a virtual network easily, and provides a toolkit to solve a bunch of other random things you'll probably want (image updates, secret management, namespaces, authentication, jobs, etc)

So the biggest reason to run Django on Kubernetes is you're running other stuff on it, or just because it's one of the many ways to run a containerized app. Sure, you could write a Compose file and just run Docker on a single VM, but you're probably going to quickly want to add other apps or run on more than one machine, at which point you are likely going to look at Kubernetes, Swarm, maybe Mesos/Marathon, or roll-your-own container orchestrator.

Running Django on Kubernetes makes a lot of sense. Running something like Postgres on Kubernetes is the part that is admittedly more questionable. It's mostly just done for fun/as an exercise. Long term, databases will probably run in containers since everything else is. Short-term, for a serious project, I would probably just use a managed database service.

Ok so its more about containerization than running multiple instances of the Django application.

Er, the same as the advantages of running any web application on k8s. Django web applications themselves are well suited for stateless hosts. You don't need any persistence where the Django app runs, you push your DB persistence off to another host (or container backed by a persistent volume).

I was under the impression that the advantages were being able to spin up multiple instances quickly, whereas I usually see Django running on a single server.

What are the other advantages of running on k8?

- Scalability. Even if it is true the db layer will probably be the bottleneck in your typical django app, it is nice to have a scaling strategy at every layer.

- Redundancy. Platforms like k8s and other PaaS can distribute instances of the same apps to multiple hosts / availability zones.

- Zero downtime deployment. Spin up the new version in a container, have both previous and new version running concurrently, then start routing traffic to the new app.

- Standardization. Settling on a container type to run all your apps makes for great dev and ops relationships.

- Immutable code. Know exactly which version is running in production and be confident it can't be changed manually.

Getting development as close to production as possible means you discover problems sooner. I've been trying to get kube-solo up running our entire infrastructure (mongo, postgres, elastic, two python 3.5 apps, one python 2.7 app) for a few days. I think, after this post, I'm going to switch over to minikube now that I know it's officially part of the kubernetes project.