How Nginx Ingress Transforms Ingress Resources into Nginx Configurations

Host Nginx

Typical Nginx reverse‑proxy configuration on a host uses an upstream block to list service endpoints and a server block to forward requests.

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;
    }
}

The IP:port pairs are called Endpoints , representing concrete services such as the “order” service.

Pod nginx‑ingress

The nginx‑ingress pod acts as a gateway for all external traffic, forwarding it to the appropriate service endpoints. It is an Ingress controller plugin; other examples include istio‑ingressgateway.

1. Pod components

The pod runs two components:

controller: communicates with the Kubernetes API to update Nginx configuration in real time (based on Ingress resources)
nginx: performs the actual reverse‑proxy function

The deployment manifest can be found at https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/mandatory.yaml . A relevant excerpt is:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx
  template:
    metadata:
      labels:
        app.kubernetes.io/name: ingress-nginx
    spec:
      terminationGracePeriodSeconds: 300
      serviceAccountName: nginx-ingress-serviceaccount
      containers:
        - name: nginx-ingress-controller
          image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.26.1
          ports:
            - name: http
              containerPort: 80
            - name: https
              containerPort: 443

By default the pod exposes ports 80 and 443, allowing HTTP and HTTPS traffic.

2. Ingress resource

An Ingress resource is defined in YAML, for example:

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

The controller translates this 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;
    }
}

If HTTPS is specified, additional 443‑port and certificate directives are generated (omitted here).

3. Exposing the nginx‑ingress pod

To make the pod reachable from outside the cluster, a Service of type NodePort is typically created, mapping external ports to the pod’s 80/443 ports.

4. Workflow diagram