06 · KubernetesLab 33 / 59

Guided labkubernetes

Kubernetes Services & Service Discovery

Give disposable Pods a stable address, then break the selector and watch the endpoints empty.

Time: 45 min
Level: Beginner
Objectives: 4 objectives
Cost: Free

Start the lab Challenge

Where this fits in the platform

Already built

Kubernetes Workloads: Pod, ReplicaSet, Deployment

This lab adds

A stable name and address in front of moving pods

Which lets you

Before you start

You will need

kind or minikube
kubectl 1.28+

You do not need these already — the lab environment below provides them.

You will be able to

Explain why a Pod IP is never a valid target
Read `kubectl get endpoints` as the first debugging step
Reach a Service by DNS name from inside the cluster

Cost — Free

— runs on kind, minikube or Docker Desktop.

Nothing to pay in the browser. Open the terminal runs this against a simulated cloud — the same API calls and the same commands, with no account and no bill. The figure above applies only if you build it in your own.

The scenario#

Pods are replaced constantly and get a new IP every time. Nothing can hold a Pod IP.

A Service is the answer, and kubectl get endpoints is the single most useful command when one does not work.

Hands-on environment

Run this lab in a real terminal, free and in your browser. The environment is temporary and yours alone — break it as much as you like.

Open the terminal

Opens in Killercoda, in a new tab — keep this page open for the steps.

Run it on your own machine

Run this lab on your own machine. One command starts the environment, with everything the lab needs already installed:

You will need:

docker
kubectl
kind

git clone https://github.com/EgyKode/EgyKode-lab.git
cd EgyKode-lab
./egykode start k8s
./egykode shell

You need Docker and Git installed. Everything else runs inside the environment. The first start downloads it and takes a few minutes; later starts are seconds.

Not sure what you already have? Run: npm run doctor — it checks and changes nothing.

Anything you tick here is your own record. EgyKode cannot see inside that terminal, so the success criteria stay self-assessed even when the environment checks your work for you.

Why not just use the Pod IP?

Step 1 of 5

What you are proving: You can explain why addressing a Pod directly stops working the moment it is replaced

This step settles no success criterion on its own.

Destructive — This removes real resources. Check which environment you are in first.

Terminal

kubectl get pods -o wide         # note an IP
kubectl delete pod <name>
kubectl get pods -o wide         # the replacement has a different IP

Every rollout, eviction and node failure changes them. A Service is a stable name and virtual IP in front of whichever Pods currently match its selector.

What you are proving: You can route traffic to several Pods through one Service, and see the endpoints behind it

Marking this settles success criteria 1 and 2.

yaml

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  type: ClusterIP
  selector:
    app: web           # any Pod with this label receives traffic
  ports:
    - port: 80         # the port the Service exposes
      targetPort: 80   # the port the container listens on

Terminal

kubectl apply -f service.yaml
kubectl get svc web
kubectl get endpoints web

text

NAME   ENDPOINTS                                   AGE
web    10.244.0.6:80,10.244.0.7:80,10.244.0.8:80   5s

Endpoints are the whole story. The Service has no intelligence of its own — a controller watches for Pods matching the selector that are ready, and writes their addresses here. Everything else follows from this list.

What you are proving: You can reach a Service by name from another Pod, without an IP anywhere

Marking this settles success criterion 3.

Terminal

kubectl run client --rm -it --image=curlimages/curl --restart=Never -- sh
 
# inside the Pod:
curl -s http://web           # same namespace
curl -s http://web.default.svc.cluster.local
cat /etc/resolv.conf         # points at CoreDNS

The short name works because /etc/resolv.conf has a search path. The fully qualified form is <service>.<namespace>.svc.cluster.local, and it is what you use across namespaces.

What you are proving: You can empty an endpoint list in two different ways, and explain each

Marking this settles success criterion 4.

Way one — a selector that matches nothing:

Terminal

kubectl patch svc web -p '{"spec":{"selector":{"app":"wrong"}}}'
kubectl get endpoints web     # ENDPOINTS is <none>
kubectl patch svc web -p '{"spec":{"selector":{"app":"web"}}}'

Way two — Pods that are not ready:

yaml

        readinessProbe:
          httpGet:
            path: /nonexistent
            port: 80
          periodSeconds: 5

Terminal

kubectl get pods              # Running, but 0/1 READY
kubectl get endpoints web     # <none> — running is not the same as ready

That second case is the one that confuses people: the Pods are up, the logs look fine, and the Service returns nothing. Readiness controls endpoint membership, which is exactly what makes a rolling update safe.

What you are proving: You can choose between the Service types by what each one exposes and to whom

This step settles no success criterion on its own.

Type	Gives you	Use it for
`ClusterIP`	An internal-only address	Everything inside the cluster — the default
`NodePort`	A high port on every node	Debugging, or a load balancer in front
`LoadBalancer`	A cloud load balancer	One public entry point per Service

LoadBalancer provisions — and bills for — a real load balancer per Service. That is why production puts one Ingress in front of many ClusterIP Services rather than a LoadBalancer each.

Success criteria

0 of 4

The concept behind it

Ready to try it without help?Do the challenge

Next up

Lab 33 of 59 on the project path

Kubernetes Storage: PVC, PV and StorageClassProve a container's filesystem is disposable, then attach storage that survives, and meet the access mode that blocks a rollout.50 minIntermediate

Previous: Kubernetes Workloads: Pod, ReplicaSet, Deployment