Kubernetes Ingress Builder

A Kubernetes Ingress is an API object that manages external HTTP and HTTPS access to services inside a cluster. It acts as a reverse proxy — routing traffic based on hostnames and URL paths to the appropriate backend Services. Ingress consolidates routing rules in one place instead of exposing each Service with a LoadBalancer or NodePort. An Ingress Controller (like NGINX, Traefik, or Istio) must be running in the cluster for Ingress resources to take effect.

Prefix matches any URL path that begins with the specified string (e.g., /api matches /api, /api/users, /api/v2). Exact only matches the path exactly as written (e.g., /api only matches /api, not /api/users). ImplementationSpecific leaves the matching behavior up to the Ingress controller — useful for controllers with custom regex support. Use Prefix for routing to microservices and Exact for specific endpoints.

Create a Kubernetes Secret of type kubernetes.io/tls containing your certificate and private key: kubectl create secret tls my-tls --cert=cert.pem --key=key.pem. Then reference the secret name in the Ingress spec.tls block alongside the hostnames it covers. The Ingress controller handles TLS termination — the backend services receive plain HTTP traffic. Use cert-manager to automate certificate provisioning from Let's Encrypt.

NGINX Ingress is the most widely used, battle-tested, and has extensive annotation support for rate limiting, rewrites, auth, and more. Traefik is cloud-native, auto-discovers routes via annotations and CRDs, and has a built-in dashboard — great for dynamic environments. Istio Ingress provides basic Ingress support but its real power is in Gateway + VirtualService CRDs for advanced traffic management, canary deployments, mutual TLS, and observability. For most use cases, start with NGINX.

ingressClassName replaces the deprecated kubernetes.io/ingress.class annotation in Kubernetes 1.18+. It specifies which Ingress controller should handle the Ingress resource — important when multiple controllers are running in the same cluster. Create an IngressClass resource first (or check what classes exist with kubectl get ingressclass), then set spec.ingressClassName to match. Both annotation and ingressClassName work in most controllers today, but ingressClassName is the modern approach.

Define multiple path rules under the same host, or multiple host rules in one Ingress spec. For example, /api can route to api-service:8080 and /web to frontend-service:3000. Each path entry targets a different backend Service. You can also define separate host blocks in the same Ingress — example.com routes to one service while api.example.com routes to another. All services must be in the same namespace as the Ingress.