Kubernetes Ingress

The Kubernetes API object that provides Layer 7 (HTTP/HTTPS) routing into the cluster. Ingress enables a single external IP to serve multiple applications based on hostnames and URL paths — a core topic in the CKA “Services & Networking” domain (~20%). Synthesized from CKA Day 33 — Kubernetes Ingress Tutorial | Ingress Explained by @AbhishekVeeramalla.

The Problem Services Cannot Solve

Kubernetes Services are Layer 4 (TCP/UDP) load balancers. While they provide stable networking for Pods, they are not designed for HTTP-specific routing:

• One Service = one app. If you run 10 web applications, you need 10 Services.
• NodePort consumes high ports. Each Service needs a unique port in the 30,000–32,767 range — users must remember NodeIP:30001 for app A, NodeIP:30002 for app B.
• LoadBalancer is expensive. Every Service of type LoadBalancer provisions a separate cloud load balancer with its own public IP. Ten apps = ten cloud LBs = ten bills.
• No hostname or path routing. Services route by IP and port alone. You cannot say “app1.example.com goes to Service A, /api goes to Service B.”

Ingress solves all of these by introducing a single entry point that understands HTTP semantics.

Ingress Resource vs Ingress Controller

The most important distinction in Kubernetes networking: the Ingress resource is just a rulebook; the Ingress Controller is the traffic cop that reads it.

Component	Type	Role
Ingress Resource	Kubernetes API object (kind: Ingress)	Declares routing rules: which host/path goes to which Service
Ingress Controller	Pod/Deployment (third-party)	Watches Ingress resources and configures a reverse proxy (nginx, Traefik, Envoy)
IngressClass	Kubernetes API object (kind: IngressClass)	Binds an Ingress resource to a specific controller when multiple controllers exist

Critical Trap: Kubernetes clusters ship with no default Ingress Controller. Creating an Ingress resource on a fresh cluster does absolutely nothing until you install a controller (nginx, Traefik, HAProxy, etc.). Source: CKA Day 33

Ingress YAML Anatomy

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

Field Reference

Field	Description	Required
apiVersion	networking.k8s.io/v1 (stable since 1.19; replaces deprecated extensions/v1beta1)	Yes
metadata.name	Unique name in the namespace	Yes
metadata.annotations	Controller-specific hints (not validated by Kubernetes)	No
spec.ingressClassName	References an IngressClass object to select the controller	Recommended
spec.rules[].host	Virtual hostname to match (HTTP Host header)	No (omitting creates a catch-all)
spec.rules[].http.paths[].path	URL path to match	Yes
spec.rules[].http.paths[].pathType	Matching semantics: Exact, Prefix, or ImplementationSpecific	Yes
spec.rules[].http.paths[].backend.service.name	Target Service name	Yes
spec.rules[].http.paths[].backend.service.port.number	Target Service port	Yes
spec.tls[].hosts	Hostnames to secure with TLS	No
spec.tls[].secretName	Name of a kubernetes.io/tls Secret holding the certificate and key	No

Path Types Explained

Type	Behavior	Example
Exact	Case-sensitive, full-path match only	/foo matches /foo; does NOT match /foo/ or /foo/bar
Prefix	Matches beginning of path, split on /	/foo matches /foo, /foo/bar, /foo/bar/baz; does NOT match /foobar
ImplementationSpecific	Controller decides matching rules	nginx may treat it as regex-capable Prefix

CKA Tip: On the exam, use Prefix for most routing and Exact when you need strict single-path matching. Avoid ImplementationSpecific unless the question explicitly references a controller-specific feature.

The Default Backend

Every Ingress Controller maintains a default backend — a fallback Service that receives all requests matching no rules. This is how the controller returns HTTP 404 pages for unknown hosts/paths. You can inspect it with:

kubectl get svc -n ingress-nginx   # The default backend is usually named "ingress-nginx-defaultbackend"

IngressClass: Selecting the Right Controller

When multiple Ingress Controllers run in one cluster (e.g., one for public traffic, one for internal), IngressClass objects disambiguate which controller handles which Ingress:

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: nginx
spec:
  controller: k8s.io/ingress-nginx   # The controller's self-reported identifier

The Ingress resource references it via spec.ingressClassName: nginx. Before Kubernetes 1.18, this was done with the annotation kubernetes.io/ingress.class: nginx — now deprecated in favor of the explicit field.

Annotations: Controller-Specific Power-User Features

Annotations are the escape hatch for features that the Ingress API spec does not cover. They are controller-specific and silently ignored if the controller does not recognize them.

Annotation	Controller	Purpose
nginx.ingress.kubernetes.io/rewrite-target: /	nginx	Removes the matched path prefix before forwarding to the backend
nginx.ingress.kubernetes.io/ssl-redirect: "true"	nginx	Redirects all HTTP requests to HTTPS
nginx.ingress.kubernetes.io/proxy-body-size: "10m"	nginx	Increases maximum allowed upload body size
nginx.ingress.kubernetes.io/rate-limit: "100"	nginx	Enables request-rate limiting

Trap: Typos in annotations are not rejected by kubectl apply. If an annotation does not work, check the controller logs first.

TLS Termination at Ingress

Ingress is the canonical place to terminate TLS for cluster applications. Rather than managing certificates in every Pod, the Ingress Controller holds the certificate and decrypts traffic before forwarding HTTP to backend Services:

# Create a TLS Secret from certificate files
kubectl create secret tls frontend-tls \
  --cert=frontend.crt --key=frontend.key

spec:
  tls:
    - hosts:
        - frontend.example.com
      secretName: frontend-tls
  rules:
    - host: frontend.example.com
      http:
        paths:
          - path: /
            backend:
              service:
                name: frontend-svc
                port:
                  number: 80

Traffic flow with TLS:

Client (HTTPS)
    │
    ▼
Ingress Controller — TLS termination (cert from Secret)
    │
    ▼
Service (HTTP, port 80)
    │
    ▼
Pod (plain HTTP)

Security Note: By default, traffic from the Ingress Controller to the Service is unencrypted. For end-to-end encryption, use a service mesh (Istio, Linkerd) or configure the controller to re-encrypt to the backend. See TLS Fundamentals for certificate mechanics. Source: CKA Day 20

Common Ingress Controllers

Controller	Best For	Notable Features
NGINX Ingress Controller	General purpose, learning, CKA	Most popular; vast annotation set; community Helm chart
Traefik	Cloud-native, dynamic config	Native Kubernetes CRDs (IngressRoute); automatic Let’s Encrypt
HAProxy Ingress	High-performance L4/L7	Excellent performance; enterprise support
Cilium Gateway API	eBPF clusters	Replaces Ingress with Kubernetes Gateway API; L7 policies
Istio Gateway	Service mesh environments	Advanced traffic splitting, mTLS, observability

Essential Commands

# List all Ingress resources
kubectl get ingress
kubectl get ingress -n <namespace>
 
# Describe an Ingress (shows rules, backend, and events)
kubectl describe ingress <name>
 
# Check Ingress Controller status
kubectl get pods -n ingress-nginx
kubectl logs -n ingress-nginx deployment/ingress-nginx-controller
 
# Validate Ingress YAML without applying
kubectl apply -f ingress.yaml --dry-run=client
 
# Get the external IP of the Ingress Controller
kubectl get svc -n ingress-nginx

Troubleshooting Matrix

Symptom	Root Cause	Fix
Ingress exists but routing fails	No Ingress Controller installed	helm install ingress-nginx ... or apply official manifest
Ingress Controller upgrade failure	Breaking change in new chart version	helm rollback ingress-nginx <revision> or pin --version
404 from default backend	Host or path mismatch	Verify kubectl get ingress output; check DNS resolves to controller IP
TLS handshake error	Wrong Secret name, wrong Secret type, or expired cert	Ensure Secret is type kubernetes.io/tls; check kubectl get secret
Path not stripped	Missing rewrite-target annotation	Add nginx.ingress.kubernetes.io/rewrite-target: /
External IP <pending>	No cloud provider integration	Use NodePort for the controller Service, or install MetalLB
Annotations ignored	Wrong controller or typo	Check controller logs; verify annotation prefix matches controller

Ingress vs Gateway API

The Kubernetes community is gradually moving from Ingress to the Gateway API (a newer, more expressive standard). Gateway API introduces Gateway, HTTPRoute, and TCPRoute resources with better traffic splitting, cross-namespace routing, and role separation. However, Ingress remains the CKA exam standard and is still dominant in production.

Feature	Ingress	Gateway API
Maturity	Stable, universally supported	Beta/GA (v1 since 1.23+)
Flexibility	Limited; relies on annotations	Rich; built-in traffic splitting, weights
Cross-namespace routing	Complex	First-class support
Role separation	None	Infrastructure (Gateway) vs App (Route)
CKA exam	✅ Tested	❌ Not yet tested

Sources

• CKA Day 33 — Kubernetes Ingress Tutorial | Ingress Explained by @AbhishekVeeramalla
• CKA Day 9 — Kubernetes Services Explained
• CKA Day 32 — Kubernetes Networking Explained | CNI

Practical Practice

Exam-style hands-on tasks for this topic. Complete each task before reviewing the solution. Time yourself — CKA tasks average 5–7 minutes.

Task 1: Create a Basic Ingress You are asked to create an Ingress named web-ingress that routes app.example.com to Service web-svc on port 80 with path prefix /. Requirements: Use networking.k8s.io/v1; pathType must be Prefix. Verification: kubectl get ingress web-ingress Solution:

kubectl create ingress web-ingress --rule="app.example.com/=web-svc:80" --dry-run=client -o yaml | kubectl apply -f -

Task 2: Add TLS Termination to an Ingress You are asked to add TLS termination to the existing Ingress web-ingress using a Secret named app-tls for host app.example.com. Requirements: The Secret app-tls must already exist as type kubernetes.io/tls. Verification: kubectl describe ingress web-ingress | grep TLS Solution:

kubectl patch ingress web-ingress --type='json' -p='[{"op": "add", "path": "/spec/tls", "value":[{"hosts":["app.example.com"],"secretName":"app-tls"}]}]'
# Or edit and re-apply the modified YAML

Task 3: Troubleshoot a 404 Ingress Response An Ingress returns 404 for all requests. The Ingress resource exists and appears correct. Requirements: Verify the Ingress Controller is running and the backend Service exists. Verification: curl -H "Host: app.example.com" http://<controller-node>/ returns 200. Solution:

# 1. Verify Ingress Controller pods are running
kubectl get pods -n ingress-nginx
# 2. Verify backend Service exists and has endpoints
kubectl get svc web-svc
kubectl get endpoints web-svc
# 3. Check Ingress rules match the host and path exactly
kubectl describe ingress web-ingress

Related Pages

• Kubernetes Services — The Layer 4 backends that Ingress routes to
• Kubernetes Service Types — Why NodePort and LoadBalancer are insufficient for multi-app HTTP routing
• Kubernetes Architecture — Where Ingress sits atop kube-proxy and CNI in the cluster networking stack
• CoreDNS — Cluster DNS that resolves Ingress hostnames to the controller’s external IP
• Kubernetes Network Policies — Restrict east-west traffic between Services behind the Ingress layer
• Kubernetes Labels and Selectors — Metadata and annotations used by Ingress controllers
• Kubernetes ConfigMaps and Secrets — TLS Secrets and controller configuration
• TLS Fundamentals — Certificate management and TLS termination patterns
• Traefik and Routing — Real-world Ingress controller usage in the Web3 infrastructure project
• Kubernetes DaemonSet — Ingress Controllers may run as DaemonSets for host-network mode
• CKA Certification — Exam domain weightings and Ingress relevance
• CKA Study Roadmap — Day 33 in the 40-day learning plan
• Abhishek Veeramalla — Guest instructor for Day 33
• Helm — The canonical installation method for Ingress Controllers
• Helm Charts — Customizing Ingress Controller deployments via values and templates

---

Tags: kubernetes ingress nginx cka networking l7-routing tls gateway-api devops services annotations