Understanding Kubernetes Ingress: Principles, Configuration, and Practical Examples

Kubernetes Ingress is a standard resource object that requires an Ingress controller (e.g., ingress‑nginx) to interpret its routing rules and expose internal services to the outside world, typically via a LoadBalancer service.

Before Ingress, a simple Nginx HTTP server could serve static files or act as a proxy using configurations like:

location /folder {
    root /var/www/;
    index index.html;
}

or proxy requests to another server:

location /folder {
    proxy_pass http://second-nginx-server:8000;
}

In Kubernetes, services are usually exposed as ClusterIP objects. To make them reachable from outside, they can be converted to LoadBalancer services, but each LoadBalancer consumes a scarce IP address and incurs cost.

A manual solution is to create a single Nginx proxy service (e.g., service-nginx-proxy ) that routes requests based on URL paths to different internal services:

location /folder {
    proxy_pass http://service-nginx:3001;
}
location /other {
    proxy_pass http://service-python:3002;
}

While functional, this approach requires manual updates whenever routing rules change. Kubernetes Ingress automates this by letting the Ingress controller generate the necessary Nginx configuration from a declarative YAML.

To install the ingress‑nginx controller:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.24.1/deploy/mandatory.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.24.1/deploy/provider/cloud-generic.yaml

After installation, a typical Ingress manifest looks like:

# just example, not tested
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
  namespace: default
  name: test-ingress
spec:
  rules:
  - http:
      paths:
      - path: /folder
        backend:
          serviceName: service-nginx
          servicePort: 3001
  - http:
      paths:
      - path: /other
        backend:
          serviceName: service-python
          servicePort: 3002

Ingress resources can be enriched with annotations to fine‑tune Nginx settings, such as timeouts, CORS, or custom snippets:

kind: Ingress
metadata:
  name: ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/proxy-connect-timeout: '30'
    nginx.ingress.kubernetes.io/enable-cors: "true"
    nginx.ingress.kubernetes.io/cors-allow-origin: "*"
    nginx.ingress.kubernetes.io/configuration-snippet: |
      if ($host = 'www.example.com') {
        rewrite ^ https://example.com$request_uri permanent;
      }

For TLS termination, Ingress can reference a Kubernetes Secret containing the certificate, allowing multiple services to share the same HTTPS configuration:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: tls-example-ingress
spec:
  tls:
  - hosts:
    - sslexample.foo.com
    secretName: testsecret-tls
  rules:
  - host: sslexample.foo.com
    http:
      paths:
      - path: /
        backend:
          serviceName: service1
          servicePort: 80

Testing can be performed with curl -v to verify routing, and logs from the ingress‑nginx pod help troubleshoot issues.

In summary, Kubernetes Ingress provides a declarative, scalable way to expose services, reduce the need for multiple LoadBalancers, and centralize routing, TLS, and advanced Nginx configurations within a cloud‑native environment.