Project challenges / verified progress
Beacon: give it somewhere to live

The engineering notebook

Give pods a name

How does traffic find the right Beacon Pods when Pod IPs are disposable?

Loading statusStage 5 of 10

  • Workspace not ready
  • Agent not ready
Focus25:00
A small focus ritual

0 focus sessions completed. Every fourth session offers a longer break. Start each phase when you are ready.

Study time never unlocks verified lesson progress.

Loading...

Loading verified progress...

Loading GitHub account...
Phase 2 — Define the runtime contract

Step 01 of 06

Learn the concept

Pod IPs are mayflies. A Service is the name you can print in documentation without apologizing tomorrow. The wiring is just labels, which is comforting until one label is wrong.

REQUEST FINDS A POD01DNS namebeacon.beacon.svc02Servicestable virtual IP03Selectormatches pod labels04EndpointSlicecurrent pod IPs05Target portcontainer receives
A Service is stable; Pods are not. The selector chooses Pods by label, EndpointSlices record their current IPs, and DNS gives other clients a name that survives Pod replacement.
Step 01

The ideas this is made of

A Service is stable addressing over unstable Pods

Pods get IP addresses, but those addresses are disposable. A restart, reschedule or rollout creates new Pods with new IPs. A ClusterIP Service provides one stable virtual IP and DNS name inside the cluster. Traffic sent to the Service is load-balanced to the current endpoints selected by labels. The Service is not the process; it is the address and routing rule.

Selectors are the actual wiring

A Service does not point to a Deployment by name. It selects Pods whose labels match its selector. If the Deployment template label is app.kubernetes.io/name: beacon and the Service selector says the same, endpoints appear. If one character differs, the Service exists but has no backends. That failure is quiet until you inspect Endpoints or EndpointSlices.

CoreDNS turns Services into names

Inside the cluster, CoreDNS answers names like beacon.beacon.svc.cluster.local. The shorter beacon may work from the same namespace because search paths are added. The full name explains the pieces: service name, namespace, service zone and cluster domain. DNS gives clients a stable string; EndpointSlices keep that string connected to changing Pods.

port and targetPort are different promises

port is the port clients use on the Service. targetPort is the port on the selected Pod. They can be the same number, and often are, but they are not the same field. Naming the container port http and setting targetPort: http avoids mismatches when a container port changes later.

A post office box hides apartment moves
mail to: box 42
current tenants: unit 3A, unit 7C
move-out: unit 3A
move-in: unit 9B
mail still goes to box 42

The Service is the box number. EndpointSlices are the current tenant list. Nobody should mail a Pod IP directly unless they enjoy forwarding addresses as a lifestyle.

Service fields people confuse

FieldMeansBeacon value

metadata.name

DNS service name

beacon

spec.port

Client-facing port

80

targetPort

Pod container port

http

selector

Pod label query

app...=beacon

ClusterIP

Internal virtual IP

Assigned by cluster

What these are called on the job

  • ClusterIP — The default Service type: a stable virtual IP reachable inside the cluster.

  • EndpointSlice — A scalable object listing the current backend addresses for a Service.

  • CoreDNS — The cluster DNS service that resolves Kubernetes service names.

  • Headless Service — A Service with clusterIP: None that returns endpoint addresses directly, useful for stable identities.