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.