Kubernetes
Intermediate 14 min read Kubernetes

Ingress & Ingress Controllers

The L7 front door on Kubernetes

Ingress is a Layer-7 API: hostname + path → backend Service, plus TLS and rewrites — enforced by an ingress controller (nginx, ingress-nginx, AWS LB, GKE Ingress) that installs the actual router.

IngressIngressClassingress-nginxTLSpathhostcanary
Prerequisites: Services & Service Networking
Before we start

What you will learn

  • Design Ingress resources: host/path routing to Services
  • Terminate TLS and configure default backends
  • Compare ingress controllers and pick one per environment
In 60 seconds

Ingress resource = declarative routing table. controller watches these objects and programs a router (nginx/traefik/cloud LB). Traffic: LB → controller → Service endpoints. TLS via secret per host/path.

Introduction

What is this?

Ingress resource: rules (host, http.paths[].path(pathType Exact/Prefix/ImplementationSpecific), backend service/port), tls block (secretName, hosts), defaultBackend. IngressClass: controller name + parameters → which controller owns which objects. Controllers: ingress-nginx (CNCF, mature), Traefik, HAProxy; cloud-native: AWS Load Balancer Controller, GKE Ingress (GLB), Azure Application Gateway ingress, NGINX on alb in EKS. Advanced: annotations vs spec changes (rewrite, client-body-size, canary via ingress-canary), websockets, gRPC, SSO external auth, rate limits. Ingress → Service → endpoints: the rotation you saw earlier.

Motivation

Why do you need it?

  • Metrics, auth, TLS, and path routing on one control point rather than per-service.
  • Declarative: 'mypath goes to my service' is a config file, not LB surgery.
  • Cost: a single shared ingress controller routes N services (one LB bill).
  • Canary weight via canary-annotation lets you shift real traffic gradually.
Think about it

Mental model

Imagine

An airport's arrivals board coding which gate connects your flight

Think of

Ingress routing

Boarding gate (service port), gate assignment (path+host rule), checkpoints and customs (TLS/auth) all happen at one counter before your plane (the pod).

Mechanics

How it works

  • Create a Service (ClusterIP) and an Ingress referencing it.
  • Controller watches namepace → reads rules → updates its router config + reloads.
  • Provider installs an LB/NodePort so external requests reach the controller's HTTPS listener.
  • TLS secret loaded; handshake picks cert by SNI host.
  • Request matches first rule (host then path) → forwarded to backend service port.

External → ingress → service.

Client
Ingress controller
Service api-o
Endpoints
Hands-on

Examples

Two hosts, one controller

Two hosts, one controller
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  ingressClassName: nginx
  tls:
    - hosts: [api.example.com]
      secretName: api-tls
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /orders(/|$)(.*)
            pathType: ImplementationSpecific
            backend: { service: { name: orders-svc, port: { number: 8080 } } }

Declared routing: TLS for the host, a rewrite keeping the suffix, backend lookup by Service — no LB API calls.

Real world

In production

  • Single ingress-nginx shared across the prod namespace with per-path services.
  • GKE: two IngressClasses (GLB for north-south, nginx for internal).
  • Canary recipe: canary ingress with svc v2 at 5% weight, promote when metrics look right.
Guidelines

Best practices

  • Name services/ports deliberately; ingresses break when they drift.
  • Route TLS by SNI per-host with wildcard certs where domains are stable.
  • Put a default backend in; 404s should be yours, not the router's.
  • Use IngressClass routing to separate internal vs external exposure.
  • Reserve annotations for controller-specific knobs; translate to spec where possible.
Watch out

Common mistakes

  • An Ingress with no controller installed → silently no routing (resource Accepted but empty).
  • PathType Exact vs the full-path trailing slash brittleness.
  • TLS secret missing/missing hosts on SNI → browser errors and scramble.
  • Canary weight on an ingress class that ignores canary → full blast-risk deploy.
When things break

Debugging tips

  • kubectl get ingress <name> shows ADDRESS; empty → controller not ready or class mismatch.
  • curl -H 'Host: api.example.com' http://<lb-ip>/ — reproduce locally without DNS.
  • Examine controller logs for IngressClass/admission rejections.
  • Canary not taking weight → controller version + annotation support check.
Interviews

Interview checkpoint

Practice

Hands-on lab

Route Hosts Through an Ingress Controller
40 min · intermediate
In progress
Objectives
  • Install ingress-nginx (or use a platform IngressClass)
  • Create two backends + one Ingress with host/path rules
  • Verify path routing and TLS via secret

Route Hosts Through an Ingress Controller

40 min · intermediate

0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

Which decides host/path matching for a rule?

2

TLS termination happens at the:

Go deeper

Official documentation

Kubernetes Ingress
docs
Ingress controllers
docs
ingress-nginx
docs