Lesson 0016 · 30 minutes · Cluster Setup

Route a service through a TLS-enabled Ingress

Ingress TLS is a three-part relationship: the hostname in the rule, the hostname in the TLS section, and the Secret that holds the certificate. A correct backend alone does not secure the public route.

Exam reflex: use networking.k8s.io/v1. In every HTTP path, specify pathType and the Service backend name and port explicitly.

Timed task: 20 minutes

Apply lab/lesson-16-fixture.yaml. Create lab/lesson-16-answer.yaml from scratch with a single Ingress in namespace ingress-drill.

The Ingress must meet all requirements:

Do not add a wildcard host, default backend, or controller-specific annotations. The supplied cluster has no Ingress controller, so this drill validates the API manifest and routing intent rather than an external HTTPS request.

Verification

kubectl --context kind-cks-lab apply -f .\lab\lesson-16-fixture.yaml
kubectl --context kind-cks-lab apply --dry-run=server -f .\lab\lesson-16-answer.yaml
kubectl --context kind-cks-lab -n ingress-drill get ingress orders -o yaml

After server-side dry run succeeds, apply the answer manifest for inspection. Do not expect an address or TLS handshake without an Ingress controller.

Retrieval check

Question

What must match for the TLS host in an Ingress to cover the public route?

Documentation target

Use the official Kubernetes Ingress reference to verify the v1 backend and TLS schema.

What to send me

Paste the Ingress YAML and the server-side dry-run result. I’ll check host/TLS alignment, path semantics, and backend syntax.