How Nginx Ingress Transforms Ingress Resources into Dynamic Proxy Configurations

Host Nginx

General Nginx reverse‑proxy configuration example:

upstream order{
    server 192.168.1.10:5001;
    server 192.168.1.11:5001;
}
server {
    listen 80;
    server_name order.example.com;
    access_log /var/log/nginx/order.example.com-access.log;
    error_log /var/log/nginx/order.example.com-error.log;
    location / {
        proxy_pass_header Server;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Scheme $scheme;
        proxy_pass http://order;
    }
}

Here 192.168.1.10:5001 and 192.168.1.11:5001 are the service endpoints (e.g., the order service).

Pod nginx‑ingress

nginx‑ingress is a pod that acts as a gateway; external traffic enters this pod and the internal Nginx forwards it to the appropriate service endpoints. It is one of many ingress‑controller plugins such as istio‑ingressgateway.

1. Pod

The nginx‑ingress pod runs two components: a controller that watches the Kubernetes API and updates Nginx configuration, and the Nginx reverse‑proxy itself.

controller: communicates with the Kubernetes API to keep Nginx config in sync (based on Ingress resources); nginx: performs normal reverse‑proxy duties.

Unlike a host‑based Nginx, the pod’s Nginx listens on ports defined in its Deployment.

The official deployment manifest can be found at:

https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/mandatory.yaml

Excerpt of the manifest shows the container ports 80 and 443 are exposed, enabling HTTP and HTTPS services.

- name: http
  containerPort: 80
- name: https
  containerPort: 443

2. Ingress resource

An Ingress object is described in YAML, for example:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: order
spec:
  rules:
  - host: order.example.com
    http:
      paths:
      - /
        backend:
          serviceName: order
          servicePort: 80

This single rule tells the nginx‑ingress pod to forward all requests for order.example.com to the internal order service on port 80.

The controller translates the Ingress into an Nginx configuration similar to:

upstream order{
    server order:80;
}
server {
    listen 80;
    server_name order.example.com;
    ...
    location / {
        proxy_pass_header Server;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Scheme $scheme;
        proxy_pass http://order; # matches the Ingress name
    }
}

If the Ingress includes TLS, the controller also generates the corresponding 443 server block and certificate configuration (not shown).

Multiple services can be exposed by adding more upstream blocks and server sections.

3. Exposing nginx‑ingress

To make the pod reachable from outside the cluster, a Service of type NodePort (or LoadBalancer) is created for the nginx‑ingress pod. This Service forwards external traffic to the pod’s ports 80/443.

4. Workflow diagram

Because the nginx‑ingress pod proxies all services, it can become a bottleneck under high load; scaling the deployment by adding more pod replicas mitigates this pressure.