Black Friday · 27 Nov 2026

Up to 90% off selected certifications.

One time only offer for a very precious career goal. Limited coupons, waitlist first.

Free lesson · CKAD Prep Program · Module 6: Services and networking

Write Ingress Rules for App Traffic

Apps meet the world through Ingress: hosts and paths in, backend Services out, TLS at the edge. Developers own the rules; the controller owns the serving.

11 min reading

Objectives

  • Route one host plus path rules to the right backend Services
  • Serve the app over HTTPS with a TLS secret in the same namespace
  • Debug empty ADDRESS versus certificate errors to the right layer
  • Annotate controller-specific needs without breaking portability

Why this matters

Frontend plus API plus admin console behind one domain is the standard shape, and Ingress expresses it in one object instead of three load balancers. The developer skill is writing rules that route exactly, securing them with TLS the cluster trusts, and reading failures to the right layer instead of rewriting working rules.

Concepts

Rules map host plus path to a Service name plus port. pathType Prefix on / fans out to everything below; Exact pins single endpoints for health checks and webhooks. The tls block pairs hosts with a Secret holding tls.crt plus tls.key in the Ingress namespace: mismatched hosts or cross-namespace secrets fail exactly as loudly as they should.

The controller fills status ADDRESS once serving: empty means no (or broken) controller, certificate errors with an address mean Secret or hosts trouble. Annotations tune controller behavior (rewrites, timeouts, body limits) at the cost of portability: keep them minimal and commented so the next cluster can evaluate each one.

Worked example

Shop frontend plus API plus exact health endpoint, all HTTPS:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop
  namespace: demo
  annotations: { nginx.ingress.kubernetes.io/proxy-body-size: 10m }
spec:
  tls:
  - { hosts: [shop.demo.test], secretName: shop-tls }
  rules:
  - host: shop.demo.test
    http:
      paths:
      - path: /healthz
        pathType: Exact
        backend: { service: { name: shop, port: { number: 80 } } }
      - path: /api/
        pathType: Prefix
        backend: { service: { name: shop-api, port: { number: 80 } } }
      - path: /
        pathType: Prefix
        backend: { service: { name: shop, port: { number: 80 } } }
kubectl get ingress -n demo      # ADDRESS present: controller serving
curl -k https://shop.demo.test/api/orders  # hits shop-api, not shop

Order matters to readers (exact first), and Prefix / last catches the remainder. Test each path with curl and read which backend answered before declaring the routing done.

Exam notes

TLS hosts must cover rule hosts or browsers revolt on exactly the uncovered name. Same-namespace Secret is mandatory, not advisory. And Prefix / also matches /anything: narrower rules belong above it in reading order even though matching is longest-first in most controllers.

Quick check

A 4-question self-check. Your answers stay on your device, are never stored or sent. Only a passing score (for example 3 of 4) is saved, and only to unlock lesson progress: at least 3 correct is required before a lesson counts as complete. It never counts toward any certification assessment.

Lesson feedback

No published feedback yet.

Log in and complete the lesson to leave feedback.

Exercise

Write one Ingress serving a fictional app (exact /healthz, /api/ prefix, / catch-all) over TLS, then prove each path hits the right backend with curl evidence. Break the TLS hosts list once and quote the resulting error.

Pass criteria

Three paths correct with Exact plus Prefix semantics; curl evidence per path; TLS breakage quoted with the uncovered-host reading.

Sources

Log in to track progressFree account: stores only your lesson progress and quiz results.