<p>i am confused about <strong>Nginx Ingress</strong> vs <strong>Nginx deployment</strong>(container) in kubernetes
since both are controlling incomming requests to the cluster
let say i am deploying a web app container and nginx container in one pod and all works perfectly if i deploy an other application and use Nginx Ingress to  route incomming requests
Then <strong>who will controll incomming requests</strong> Nginx Ingress or that nginx container ?
<strong>THANKS</strong></p>

<p>Let's abstract ourselves from nginx. We should distinguish the webserver running alongside an application, from the reverse proxy routing client requests to that application.</p>
<p>In Kubernetes, you may deploy applications based on some Nginx, lighttpd, Apache, ... webserver. Sometimes complex configurations routing clients to different bits composing your application (eg: nodejs backend for an API, static assets, php/smarty frontend ...).</p>
<p>While most Kubernetes clusters would come with an &quot;Ingress Controller&quot;. A Controller in Kubernetes refers to some software integrating with your cluster API. An Ingress Controller watches for &quot;Ingress&quot; objects, and configures itself proxying client requests to &quot;Services&quot; within your cluster.</p>
<p>Answering &quot;who controls incoming requests&quot;, then: a little bit of both. Your Ingress Controller is the proxy exposed to clients connecting to an application in your cluster. The webserver running in your application deployment serves requests proxied by your ingress controller.</p>
<p>And why would we do this: consider Kubernetes comes with an SDN. Services and Pods in your cluster are usually not reachable from clients that would not be part of your cluster network. Ingress controllers is a convenient way to allow end-users of a cluster to expose their own applications, in a somewhat-generic way, managing their own Ingresses. While cluster administrators would make sure traffic can reach your application, setting up the actual Ingress Controller.</p>
