Skip to content

Ingress

Ingress is an API for HTTP and HTTPS routing into cluster services.

Important distinction:

  • Ingress resource: your routing rules
  • Ingress controller: implementation that enforces those rules

Without a controller, Ingress objects do nothing.

Typical traffic path

graph LR
  A[Client] --> B[External Load Balancer]
  B --> C[Ingress Controller]
  C --> D[Service]
  D --> E[Pods]

How an Ingress controller actually works

There is no magic in the data path -- an Ingress controller is just a reverse proxy (NGINX, Envoy, HAProxy) running as pods in your cluster, plus a control loop:

  1. The controller watches Ingress objects, Services, EndpointSlices, and TLS Secrets via the API server.
  2. On every relevant change it renders proxy configuration mapping hosts and paths to backends.
  3. The proxy receives traffic through a Service of type LoadBalancer (cloud) or NodePort/hostNetwork (on-prem) and forwards it to pods.

Two practical consequences:

  • Most controllers route to pod IPs directly (read from EndpointSlices), not through the Service ClusterIP -- the proxy, not kube-proxy, does the balancing, which is how sticky sessions and least-connections work at this layer.
  • The controller is a workload like any other: it needs replicas, resources, a PodDisruptionBudget, and monitoring. "Ingress is down" usually means "the controller deployment is unhealthy," diagnosed exactly like any other broken deployment.

IngressClass and controller ownership

Set ingressClassName so the intended controller handles your object.

Common patterns:

  • one class for internet-facing traffic
  • one class for internal traffic

Ingress example

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - app.example.com
      secretName: app-example-tls
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 8080
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-service
                port:
                  number: 80

Path matching notes

  • Prefix: matches on /-separated path segments (/api matches /api and /api/users, not /apiv2)
  • Exact: strict path match
  • ImplementationSpecific: controller-defined behavior, use carefully

When multiple paths match a request, the most specific wins: exact matches beat prefix matches, and longer prefixes beat shorter ones. That ordering is why the /api and / rules in the example above can coexist safely.

Certification notes

  • The CKA includes Ingress (and now Gateway API) tasks. Practice the imperative scaffold: kubectl create ingress app --rule="app.example.com/api*=api-service:8080" --class=nginx --dry-run=client -o yaml.
  • Verify with kubectl describe ingress -- the Backends column shows whether the service resolved to endpoints; <none> or an error there answers most "why isn't my Ingress working" scenarios.

TLS operations

Ingress commonly terminates TLS at the controller. Certificates are referenced from Kubernetes secrets.

For managed cert lifecycle, use cert-manager or your platform-native certificate workflow.

Common issues

  • wrong ingressClassName
  • backend service name or port mismatch
  • no healthy endpoints behind the backend service
  • DNS not pointing to controller entrypoint

Quick debug checklist

kubectl get ingress -A
kubectl describe ingress app-ingress
kubectl get svc -A
kubectl get endpointslices -A
kubectl logs -n ingress-nginx deploy/ingress-nginx-controller

Ingress vs Gateway API

Ingress remains widely used and practical for straightforward HTTP routing.

Gateway API is better when you need:

  • clearer platform and app ownership boundaries
  • richer policy and traffic controls
  • multi-team self-service at scale

Summary

Ingress is the standard entry point for HTTP and HTTPS in many Kubernetes platforms. Keep configuration explicit, validate controller ownership, and monitor route behavior as part of day-2 operations.