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 th

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.