Labels and the Pharos Hold on. If Pods keep sinking and coming back with new addresses, how is a customer supposed to find your shop?! Gotcha. Nobody looks for me directly, Cyclops. (Yes, Nobody. You remember that name.) They follow the Pharos.

A gives your app one stable name and address, and spreads traffic across every healthy that wears the right label.

apiVersion: v1
kind: Service
metadata:
  name: shop            # (1) the name that never changes
spec:
  selector:
    app: shop           # (2) shine on Pods wearing this tag
  ports:
    - port: 80          # (3) the port customers use
      targetPort: 8080  # (4) the port the container listens on
1

name: inside the cluster, other Pods reach the shop simply as shop (or shop.<namespace>; chapter 4).

2

selector: the label to shine on. It must match the Pods' labels exactly, typos included.

3

port: what callers connect to on the Service.

4

targetPort: where the container is actually listening. Getting these two mixed up is the most common Service mistake.

Endpoints: who the light is on right now

Kubernetes keeps a live list of the addresses each shines on, called its endpoints. When a sinks, it drops off the list; when its replacement starts, it joins. If a doesn't work, this list is the first thing to check:

kubectl get endpointslices -l kubernetes.io/service-name=shop
# older clusters: kubectl get endpoints shop
This is the default type, ClusterIP: it only shines inside the harbor. Letting customers in from the internet is chapter 3.