Chapter 19: Kubernetes Services, Ingress and Volumes

19.7 Ingress — a hostname, not a free public domain

By Ravindra Bagale · Last updated: 25 October 2026

Why: the problem

A startup runs five apps: the shop, the admin panel, the API, the blog and the image service. If each gets its own LoadBalancer Service, that is five load balancers and five bills, and five places to manage HTTPS certificates. Real teams at companies like Nykaa put one Ingress controller behind one load balancer and write Ingress rules: shop.example.com goes to the shop Service, example.com/api goes to the API Service, and so on. The Ingress controller (ingress-nginx, Traefik, or the AWS ALB controller) reads those rules and routes HTTP traffic. One important truth: an Ingress gives routing by hostname, not a free public domain. You still buy a domain and point its DNS to the load balancer. In this lesson you will install ingress-nginx on kind, route by host and by path, add TLS with a self-made certificate, and see the 404 and 503 errors every beginner hits.

What we will build

You will run two apps, tea and coffee, behind one ingress-nginx on kind. tea.local and coffee.local route by host; cafe.local/tea and cafe.local/coffee route by path. Then you will add HTTPS with a self-signed certificate stored in a TLS Secret.

What: every term in plain English

• Ingress — A Kubernetes object with HTTP routing rules: host and path to Service.
• Ingress controller — The program that reads Ingress objects and does the routing, like ingress-nginx.
• IngressClass — Says which controller should handle an Ingress.
• Host rule — Route by the name in the URL, like tea.local.
• Path rule — Route by the part after the name, like /tea.
• pathType Prefix — Match the path and anything below it.
• TLS Secret — A Secret that holds a certificate and its private key.
• Default backend — Where traffic goes when no rule matches; ingress-nginx returns 404.

How: step by step

1. Create kind with port 80 and 443

   cat kind-ing.yaml && kind create cluster --name lab --config kind-ing.yaml
   

   What it does: The node is labelled ingress-ready and laptop ports 80 and 443 map to it.

   Output

   kind: Cluster
   apiVersion: kind.x-k8s.io/v1alpha4
   nodes:
   - role: control-plane
     kubeadmConfigPatches:
     - |
       kind: InitConfiguration
       nodeRegistration:
         kubeletExtraArgs:
           node-labels: "ingress-ready=true"
     extraPortMappings:
     - containerPort: 80
       hostPort: 80
     - containerPort: 443
       hostPort: 443
   Set kubectl context to "kind-lab"
   

2. Install ingress-nginx for kind

   kubectl apply -f https://kind.sigs.k8s.io/examples/ingress/deploy-ingress-nginx.yaml
   

   What it does: The kind project's ready manifest for ingress-nginx.

   Output

   namespace/ingress-nginx created
   deployment.apps/ingress-nginx-controller created
   ingressclass.networking.k8s.io/nginx created
   

3. Wait for the controller

   kubectl -n ingress-nginx wait --for=condition=ready pod -l app.kubernetes.io/component=controller --timeout=120s
   

   What it does: Waits until it can route traffic.

   Output

   pod/ingress-nginx-controller-6b8f5d8b5c-x2k9p condition met
   

4. Make a practice namespace

   kubectl create namespace practice
   kubectl config set-context --current --namespace=practice
   

   What it does: Keeps all lab objects in one folder that is easy to delete.

   Output

   namespace/practice created
   Context "kind-lab" modified.
   

5. Run tea and coffee

   for a in tea coffee; do kubectl create deploy $a --image=hashicorp/http-echo:1.0 -- /http-echo -text="$a is ready" -listen=:5678; kubectl expose deploy $a --port=80 --target-port=5678; done
   

   What it does: Two tiny apps that print a word, each with a ClusterIP Service.

   Output

   deployment.apps/tea created
   service/tea exposed
   deployment.apps/coffee created
   service/coffee exposed
   

6. Add names to your hosts file

   echo "127.0.0.1 tea.local coffee.local cafe.local" | sudo tee -a /etc/hosts
   

   What it does: Your laptop now sends these names to kind.

   Output

   127.0.0.1 tea.local coffee.local cafe.local
   

Example 1: Route by host name

Stack. ingress-nginx on kind

Goal. Route by host name.

host-ing.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: by-host
spec:
  ingressClassName: nginx
  rules:
  - host: tea.local
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service: {name: tea, port: {number: 80}}
  - host: coffee.local
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service: {name: coffee, port: {number: 80}}

terminal

kubectl apply -f host-ing.yaml
curl -s tea.local
curl -s coffee.local

What each line does

• ingressClassName: nginx — Let ingress-nginx handle this Ingress.
• host: tea.local — Only requests for this name match.
• path: / Prefix — Every path under the host.
• backend service tea port 80 — Send matching traffic to Service tea.

Green output

ingress.networking.k8s.io/by-host created
tea is ready
coffee is ready

Expected result. One entry point, two apps, chosen by the host name in the request.

Example 2: Route by path on one host

Stack. ingress-nginx annotations

Goal. Route by path on one host.

path-ing.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: by-path
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
  - host: cafe.local
    http:
      paths:
      - path: /tea
        pathType: Prefix
        backend:
          service: {name: tea, port: {number: 80}}
      - path: /coffee
        pathType: Prefix
        backend:
          service: {name: coffee, port: {number: 80}}

terminal

kubectl apply -f path-ing.yaml
curl -s cafe.local/tea
curl -s cafe.local/coffee
curl -s -o /dev/null -w "%{http_code}\n" cafe.local/juice

What each line does

• rewrite-target: / — Send / to the app instead of /tea. Many apps only know /.
• path: /tea — cafe.local/tea and below go to tea.
• path: /coffee — cafe.local/coffee goes to coffee.
• /juice — No rule matches, so the default backend answers 404.

Green output

tea is ready
coffee is ready
404

Expected result. Path rules let one domain serve many apps, like example.com/api and example.com/shop.

Example 3: HTTPS with a TLS Secret

Stack. OpenSSL 3, ingress-nginx

Goal. HTTPS with a TLS Secret.

terminal

openssl req -x509 -nodes -days 30 -newkey rsa:2048 \
  -keyout tls.key -out tls.crt -subj "/CN=tea.local" -addext "subjectAltName=DNS:tea.local"
kubectl create secret tls tea-tls --cert=tls.crt --key=tls.key
kubectl patch ingress by-host --type=merge -p '{"spec":{"tls":[{"hosts":["tea.local"],"secretName":"tea-tls"}]}}'
curl -sk https://tea.local
curl -s -o /dev/null -w "%{http_code} -> %{redirect_url}\n" http://tea.local

What each line does

• openssl req -x509 — Makes a self-signed certificate for lab use.
• subjectAltName=DNS:tea.local — Browsers and curl check this name.
• create secret tls — Stores the cert and key as a kubernetes.io/tls Secret.
• spec.tls — Tells the Ingress which hosts use which certificate.
• curl -k — Accept the self-signed cert in the lab. Real sites use Let's Encrypt via cert-manager.
• 308 redirect — ingress-nginx redirects HTTP to HTTPS when TLS is set.

Green output

secret/tea-tls created
ingress.networking.k8s.io/by-host patched
tea is ready
308 -> https://tea.local/

Expected result. HTTPS works and HTTP is redirected. In production, cert-manager gets free certificates from Let's Encrypt automatically.

Verify: did it work?

1. List Ingresses

   kubectl get ingress
   

   What it does: Shows hosts and the address.

   Output

   NAME      CLASS   HOSTS                    ADDRESS     PORTS
   by-host   nginx   tea.local,coffee.local   localhost   80, 443
   by-path   nginx   cafe.local               localhost   80
   

2. Read controller logs

   kubectl -n ingress-nginx logs deploy/ingress-nginx-controller --tail=2
   

   What it does: Each request is logged with host, path and status.

   Output

   172.18.0.1 - - [25/Oct/2026:10:20:01 +0000] "GET / HTTP/1.1" 200 13 "-" "curl/8.5.0" 78 0.002 [practice-tea-80]
   

When it is red 1

404 Not Found (nginx)

Cause. No rule matched the host or path, or ingressClassName is missing.

Fix, step by step

1. Check the host in curl matches the rule exactly.
2. Add ingressClassName: nginx.
3. kubectl describe ingress for warnings.

When it is red 2

503 Service Temporarily Unavailable

Cause. The rule matched, but the Service has no ready endpoints.

Fix, step by step

1. kubectl get endpointslices -l kubernetes.io/service-name=tea.
2. Check Pods are Ready and the Service port is right.

When it is red 3

curl: (6) Could not resolve host: tea.local

Cause. Your laptop does not know the name.

Fix, step by step

1. Add it to /etc/hosts.
2. Or use curl -H "Host: tea.local" localhost.

Cleanup

1. Remove the hosts line

   sudo sed -i "/tea.local coffee.local cafe.local/d" /etc/hosts
   

   What it does: Cleans your hosts file.

   Output

   (no output means it worked)
   

2. Delete the cert files

   rm -f tls.key tls.crt
   

   What it does: Lab keys should not stay on disk.

   Output

   (no output means it worked)
   

3. Delete the practice namespace

   kubectl delete namespace practice
   

   What it does: Deletes every object you made in this lesson in one go.

   Output

   namespace "practice" deleted
   

4. Delete the lab cluster

   kind delete cluster --name lab
   

   What it does: Removes the whole cluster container. On minikube use: minikube delete.

   Output

   Deleting cluster "lab" ...
   Deleted nodes: ["lab-control-plane"]
   

Practice tasks

Homework: try at home

Recap

• An Ingress routes HTTP by host and path to Services.
• An Ingress controller must be installed to make it work.
• One load balancer can serve many apps.
• spec.tls with a TLS Secret adds HTTPS.
• 404 means no rule matched; 503 means no ready endpoints.

FAQ

ingress-nginx or Traefik or ALB?

All work. ALB is common on EKS; ingress-nginx is common everywhere.

Is Gateway API replacing Ingress?

Gateway API is the newer, richer standard. Ingress is still everywhere, so learn both.

How do I get a free certificate?

cert-manager with Let's Encrypt.

Do I need /etc/hosts in production?

No. Real DNS records point to the load balancer.

Can Ingress route TCP like MySQL?

Standard Ingress is HTTP only. Use a LoadBalancer Service or Gateway API for TCP.

Interview questions

1. What is an Ingress?

   An API object that defines HTTP routing rules by host and path to Services, implemented by an Ingress controller.

2. Difference between Ingress and LoadBalancer Service?

   LoadBalancer is L4 per Service; Ingress is L7 routing that can share one load balancer across many Services.

3. How do you enable HTTPS on Ingress?

   Add spec.tls with a TLS Secret, usually created by cert-manager.

4. What does a 503 from ingress-nginx mean?

   The backend Service has no ready endpoints.

5. What is IngressClass?

   It binds an Ingress to a specific controller.

Samajla ka?

Ravi Sir's Cards for this lesson

Revision cardInterview cardComparison card

मराठी cards