How Nginx and Nginx‑Ingress Work Together to Proxy Services in Kubernetes

Host Nginx

Typical Nginx reverse‑proxy (gateway) configuration on a host looks like the following:

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

The nginx‑ingress controller runs as a pod and acts as a unified entry point for external traffic, forwarding requests to the appropriate service endpoints based on Ingress resources. It is one of many Ingress controller plugins such as istio‑ingressgateway.

1. Pod

The nginx‑ingress pod has two main components:

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

Unlike a host‑based Nginx, the pod’s Nginx runs inside the container. To expose it externally, a Service with a NodePort (or other type) is required.

The official deployment manifest can be found at:

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

Relevant excerpt from the manifest:

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

This configuration exposes both port 80 and port 443, allowing HTTP and HTTPS traffic to reach the services.

2. Ingress Resource

An Ingress resource is defined in YAML to route traffic to a specific service:

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

The nginx‑ingress controller watches this resource and generates the corresponding Nginx configuration inside the pod:

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 Ingress name: order
    }
}

If the Ingress includes HTTPS, the controller also generates the appropriate 443 listener and certificate configuration (not shown here).

3. Exposing nginx‑ingress

Typically a Service of type NodePort is created for the nginx‑ingress pod so that external traffic can reach it. This Service definition is omitted for brevity.

4. nginx‑ingress Workflow

Because the nginx‑ingress pod proxies all services, it can become a bottleneck under high concurrency; scaling out by adding more pod replicas is a common solution.