How Nginx‑Ingress Transforms Ingress Resources into Nginx 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;
    }
}

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 serves as a gateway, forwarding external traffic to internal services via an embedded Nginx instance.

1. Pod

The pod contains two components: a controller and Nginx.

controller: communicates with the Kubernetes API to update Nginx configuration (based on Ingress resources). nginx: performs the normal reverse‑proxy function.

Unlike a host‑based Nginx, this pod runs inside Kubernetes; its configuration is defined in a Deployment YAML.

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

A snippet of the deployment shows the container ports that are exposed:

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

2. Ingress resource

Ingress resources are managed via 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 rule directs all external requests to the internal order service on port 80.

The controller converts the Ingress into an Nginx upstream and server block:

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; # corresponds to Ingress name: order
    }
}

If HTTPS is used, additional configuration for port 443 and certificates is generated (not shown).

3. Exposing nginx‑ingress

Typically a Service of type NodePort is created to expose the pod externally.

4. Workflow

Because the pod proxies all services, scaling the number of nginx‑ingress pods is required for high‑traffic scenarios.