Homework 11 — Ingress + cert-manager + DNS
Lesson 11 · Cloud Infrastructure & DevOps · Three tasks
These three tasks deepen the Ingress + cert-manager foundation from the lab. Task 1 is chart-level (rate limiting), Task 2 introduces dns-01 and wildcard certs, and Task 3 covers the multi-app sharing pattern. You will need a working Ingress controller and cert-manager installation from the lab.
Task 1 — Add rate-limit annotations to the Ingress
ingress-nginx supports per-IP rate limiting via the nginx.ingress.kubernetes.io/limit-rps annotation. Add this feature to the chart so the rate limit is controlled by a values key rather than hardcoded in the template.
- Add two new values keys to
values.yaml:ingress.rateLimitRps(integer, default0) — requests per second per source IP. Value0means disabled (no annotation rendered).ingress.rateLimitBurst(integer, default0) — burst multiplier. Value0falls back to the nginx default of 5.
- Update
templates/ingress.yamlto conditionally add the annotations whenrateLimitRps > 0:nginx.ingress.kubernetes.io/limit-rps: "<value>"nginx.ingress.kubernetes.io/limit-burst-multiplier: "<value>"
- Verify the template renders correctly:
helm template ... --set ingress.enabled=true --set ingress.host=test.example.com --set ingress.rateLimitRps=5should show both annotations. WithrateLimitRps=0(the default), neither annotation should appear. - If you have a running cluster, load-test with
hey -z 30s -c 50 -q 100 https://shortener.<host>/healthzand confirm 429 responses appear beyond the configured RPS.
✓ Self-check: helm template ... --set ingress.rateLimitRps=5 renders both annotations. helm template ... --set ingress.rateLimitRps=0 renders neither. helm lint passes.
Task 2 — Wildcard cert via dns-01
http-01 challenges cannot validate wildcard certificates (*.example.com) because there is no single host to serve the challenge file from. dns-01 is required for wildcards — cert-manager places a TXT record at _acme-challenge.example.com instead of serving a file.
- Write a
ClusterIssuerthat uses the Cloudflare dns-01 solver. Store the Cloudflare API token in a Kubernetes Secret:kubectl create secret generic cloudflare-api-token \ --from-literal=token=<your-token> \ -n cert-manager - Write a standalone
Certificateresource (not inferred from an Ingress) that requests*.example.comandexample.comasdnsNames, references the dns-01 ClusterIssuer, and stores the result in Secretexample-com-wildcard-tls. Place this in theshortenernamespace. - In 3–4 sentences, explain: why is dns-01 required for wildcards? What is the trade-off compared to http-01?
✓ Self-check: kubectl get certificate -n shortener shows the wildcard cert as Ready: True. kubectl describe secret example-com-wildcard-tls -n shortener lists a SAN of *.example.com.
Task 3 — A second app sharing the same Ingress controller
A key Ingress controller property is that it is cluster-wide: one controller (and one LoadBalancer) serves every app, with routing by HTTP Host header. This task adds a second app, greeter, in its own namespace, sharing the same ingress-nginx controller and the same ClusterIssuer.
- Create a namespace
greeterand deploy a simple Hello-World Service (nginx:alpineorhashicorp/http-echois fine — the routing, not the app, is the point). - Write an
Ingressresource in namespacegreeterthat:- Uses
ingressClassName: nginx. - Routes
greeter.example.comto the greeter Service on port 80. - Requests a TLS cert from
letsencrypt-prod(orletsencrypt-stagingfor testing) via thecert-manager.io/cluster-issuerannotation. - Stores the cert in Secret
greeter-tlsin namespacegreeter.
- Uses
- In 4 sentences, document the cluster-wide vs per-namespace boundary: which resources are cluster-wide and which are namespaced? Can
shortener’s TLS Secret be used bygreeter? What is the standard pattern if you want to share a wildcard cert across namespaces?
✓ Self-check: both apps’ Ingresses show ADDRESS set; both Certificates are Ready: True in their own namespaces; curl -H "Host: greeter.example.com" http://<LB-IP> routes to the greeter service.