# 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).