Step 01 of 06
Learn the concept
The last step is satisfyingly recursive. Beacon gets an HTTPS entrance, then points its own monitoring at that entrance and watches the certificate. A mirror is not a full observability strategy, but it catches spinach in your teeth.
The ideas this is made of
Ingress is routing intent, not the router
An Ingress object declares host and path routing rules. It does nothing useful until an ingress controller watches it and configures a real proxy. In this course, ingress-nginx is that controller. The Ingress says beacon.localtest.me should route to the Beacon Service; nginx receives traffic and makes that rule real.
LoadBalancer, NodePort and Ingress solve different edges
A Service of type LoadBalancer asks the infrastructure for an external load balancer. On kind, there is no cloud load balancer unless you add one. NodePort opens a high port on nodes. Ingress uses a controller to route HTTP(S) by host and path, usually to ClusterIP Services. It is the common web edge pattern.
TLS certificates need a controller too
cert-manager watches Certificate objects and creates or renews Secrets containing TLS material. In production it may use ACME and Let's Encrypt. On a local kind cluster, a self-signed Issuer is enough to learn the object model. The important mechanism is ownership: certificate desired state becomes a Secret the Ingress can use.
Beacon can monitor its own edge
The satisfying loop is simple: Beacon is exposed through an Ingress with TLS, then Beacon is configured to probe that same hostname and certificate expiry. A monitor watching itself is not sufficient for production, but it proves the entire path: DNS name, ingress controller, Service, Pod, TLS Secret and expiry parsing.
visitor asks for: beacon.example
lobby checks directory
sends visitor to suite 7427
certificate on the door proves the nameThe Ingress controller is the lobby. The Ingress object is the directory entry. The Service is the suite number that keeps working when occupants change desks.
Three ways in
| Edge type | Best for | Local kind note |
|---|---|---|
ClusterIP | Inside cluster only | Used behind Ingress |
NodePort | Direct node port | Useful but clumsy |
LoadBalancer | Cloud load balancer | Needs provider or MetalLB |
Ingress | HTTP host/path routing | Use ingress-nginx |
Certificate | TLS Secret lifecycle | Use cert-manager |
What these are called on the job
Ingress — A Kubernetes object declaring HTTP and HTTPS routing by host and path.
Ingress controller — The running proxy/controller that implements Ingress objects, such as ingress-nginx.
Issuer — A cert-manager object that knows how to issue certificates.
Certificate — A cert-manager desired-state object that produces a Kubernetes TLS Secret.