ced4568andClaude Sonnet 5
dbcc210889
root-07-m03-services-and-service-discovery — a new, full gold-standard- pattern module: the Service/Endpoints/DNS request path, choosing the right Service type. Lesson, demonstration (a Service with zero Endpoints — the single fastest diagnostic check for this failure class), knowledge check, guided exercise (ClusterIP vs. NodePort vs. LoadBalancer for three real components), a real Lab (expose-service-basics), and a reflection. root-07-m04-ingress-networkpolicy-foundations — a new PARTIAL module: Ingress and NetworkPolicy at the architectural level (the security- control framing of NetworkPolicy is deliberately deferred to ROOT 09). Lesson + knowledge check + real Labs (ingress-task, network-policy). Co-Authored-By: Claude Sonnet 5 <[email protected]>
41 lines
1.8 KiB
Markdown
41 lines
1.8 KiB
Markdown
# Launch Lab: Exposing an Application
|
|
|
|
Time to create a real Service in your disposable Lab and connect it to a real Deployment.
|
|
|
|
## What you're doing
|
|
|
|
A `redis` Deployment is running, but other Pods can't reliably reach it because Pod IPs change
|
|
whenever a Pod restarts — exactly the problem the lesson opened with. Your task is to create a
|
|
stable ClusterIP Service in front of it.
|
|
|
|
## Before you start
|
|
|
|
Recall the request path from the lesson: your Service's `selector` has to match the Deployment
|
|
Pods' actual labels, or you'll end up with the empty-Endpoints situation from the
|
|
demonstration. Check the Deployment's Pod labels before writing your Service's selector, don't
|
|
guess at them.
|
|
|
|
## Your task in this Lab
|
|
|
|
Create a ClusterIP Service exposing the `redis` Deployment on the correct port. Once it's
|
|
created, verify it the same way the demonstration did: `kubectl get service`, then `kubectl get
|
|
endpoints` to confirm it actually has a non-empty Endpoints list, not just that the Service
|
|
object exists.
|
|
|
|
This Lab has its own in-context hints if you get stuck.
|
|
|
|
When you're done, return to this module for a reflection on why service discovery is
|
|
infrastructure, not magic.
|
|
|
|
## Instructor Notes
|
|
|
|
**Classroom flow:** Encourage students to run `kubectl get endpoints` as their OWN verification
|
|
step even though the Lab's automated validation will check this too — building the habit of
|
|
checking Endpoints, not just "the Service exists," is the actual transferable skill here.
|
|
|
|
**Approximate timing:** 10-15 minutes.
|
|
|
|
**Common mistake to watch for:** a selector that matches on the wrong label key/value, or a
|
|
port/targetPort mismatch (the Service's `port` is what clients connect to; `targetPort` is what
|
|
the container actually listens on — conflating the two is a very common first-time error).
|