Is it necessary to run Django behind a reverse proxy when deployed on Kubernetes

Question

Historically, it's always been good practice to launch any wsgi app behind a reverse proxy. So, it felt natural to me, when launching on Kubernetes, to throw up a 2 container pod, one running an nginx reverse proxy, the other running the Django application. Is this just wasted resources when providing ingress via an nginx ingress controller? Is there any benefit at all to running an additional reverse proxy in this scenario?

Answer 1

There is no need for launching additional reverse proxy container within the pod. Ingress is specially designed for fast setup. The only thing you should do is to describe your configuration using yaml, which is easier and faster than third-party solutions. Managing load balancing and reverse proxying external from K8s management could be very tough to manage. I encourage to read an interesting article about it.

Answer 2

Depends on your needs of control over the traffic and also if you have already an nginx pod configured that you are using on that architecture could be easy for you to put in front of your Django app.

I can recommend that if your idea is to have a good reverse proxy with more options control to use an ingress-controller different than the default that uses kube-poxy. A good ones are:

• nginx ingress controller
• HAProxy ingress controller

But you also have the option to use a service mesh, for example, Istio where the controller injects an envoy proxy container on each pod that controls the ingress traffic but also the egress traffic of the pod to also control how and where can connect from inside also from outside the pod.

In terms of performance, all solutions are optimized for high volumes of traffic and you have the advantage of allowing to scale horizontally your app with automatic load balancing if you set the correct livenessProbe and readynessProbe on the deployment definition.