What is a Kubernetes Ingress?

Overview

An Ingress is a Kubernetes object that manages external access to Services inside the cluster, typically HTTP and HTTPS traffic. It acts as a reverse proxy and load balancer, routing incoming requests to the right service based on rules we define (hostnames, URL paths, and so on).

Think of an Ingress as the front door of our cluster: it sits at the edge and decides which internal service should handle each incoming request.

Ingress resource vs Ingress controller

There are two separate concepts here:

• Ingress resource: the Kubernetes object (kind: Ingress) that defines our routing rules (which host maps to which service);
• Ingress controller: the software (e.g. NGINX, Traefik, HAProxy) that actually watches for Ingress resources and configures itself to route traffic accordingly.

An Ingress resource is just configuration. Nothing happens if we don’t have an Ingress controller running in the cluster. Most managed Kubernetes platforms (GKE, EKS, AKS) come with a default Ingress controller pre-installed, but for self-hosted clusters we need to install one ourselves.

Example: Ingress manifest

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /users
            pathType: Prefix
            backend:
              service:
                name: user-service
                port:
                  number: 80
          - path: /orders
            pathType: Prefix
            backend:
              service:
                name: order-service
                port:
                  number: 80

Let’s see what those mean:

• rules defines the routing rules. Here, traffic to api.example.com/users goes to the user-service, and api.example.com/orders goes to order-service;
• pathType: Prefix means the path matches any request that starts with the given prefix (e.g. /users also matches /users/123);
• backend.service points to the target Service and port;
• annotations provide controller-specific configuration (the nginx.ingress.kubernetes.io prefix is specific to the NGINX Ingress controller).

TLS/HTTPS

An Ingress controller can handle TLS termination on our behalf. This means the controller receives encrypted HTTPS traffic from clients, decrypts it using the certificate and private key we provide, and then forwards plain HTTP to our services internally.

The real advantage here is that our services never need to deal with encryption or certificates.

To enable TLS, we store our certificate and private key in a Secret and reference it in the Ingress manifest:

spec:
  tls:
    - hosts:
        - api.example.com
      secretName: api-tls-secret
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-service
                port:
                  number: 80

The secretName must point to a secret of type kubernetes.io/tls containing two keys: tls.crt (the certificate) and tls.key (the private key). The Ingress controller picks these up automatically and begins terminating TLS for that host.

Common Ingress controllers