06 · KubernetesLab 32 / 59

Guided labkubernetes

Kubernetes Workloads: Pod, ReplicaSet, Deployment

Watch a Deployment create a ReplicaSet create Pods, then delete each in turn and see which come back.

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

Start the lab Challenge

Where this fits in the platform

Already built

Production-Grade Multi-Stage Dockerfile for Django & Gunicorn

This lab adds

The application as a Deployment that survives a deleted pod

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 the Deployment → ReplicaSet → Pod ownership chain
Perform a rolling update and roll it back
Match a selector to labels, and recognise when they do not

Cost — Free

— runs on kind, minikube or Docker Desktop. No cloud account needed.

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#

Ingress, HPA and NetworkPolicy all assume you know what a Pod is and what owns it. This lab builds that, by creating each object and then deleting it to see what the cluster does about it.

Deleting things on purpose is the fastest way to learn what is watching.

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.

Run it on AWS

This lab builds real cloud infrastructure, so it needs your own AWS account. Follow the cost and cleanup notes above — the resources are yours, and so is the bill.

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.

A cluster on your laptop

Step 1 of 5

What you are proving: You can create a cluster on your own machine to work against

This step settles no success criterion on its own.

Terminal

kind create cluster --name fundamentals
kubectl cluster-info
kubectl get nodes

What you are proving: You can explain why a bare Pod is not something you deploy

This step settles no success criterion on its own.

yaml

apiVersion: v1
kind: Pod
metadata:
  name: solo
spec:
  containers:
    - name: web
      image: nginx:1.27-alpine

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

Terminal

kubectl apply -f pod.yaml
kubectl get pod solo
kubectl delete pod solo
kubectl get pods          # gone, and nothing replaced it

That is the lesson: a bare Pod is not watched by anything. When it dies, it stays dead.

What you are proving: You can run a Deployment and name the ReplicaSet that owns its Pods, and show which deletions are repaired

Marking this settles success criteria 1 and 2.

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web           # which Pods this Deployment owns
  template:
    metadata:
      labels:
        app: web         # must match the selector above
    spec:
      containers:
        - name: web
          image: nginx:1.27-alpine
          ports:
            - containerPort: 80

Terminal

kubectl apply -f deployment.yaml
kubectl get deploy,rs,pods

Read the names in that output — the chain is visible in them:

text

deployment.apps/web              3/3
replicaset.apps/web-6d4c8f9b7    3         <- created by the Deployment
pod/web-6d4c8f9b7-x2k9p                    <- created by the ReplicaSet
pod/web-6d4c8f9b7-lm4tq
pod/web-6d4c8f9b7-9wqzr

The Deployment manages ReplicaSets. The ReplicaSet keeps a count of Pods. The Pod runs the container. Each layer watches the one below.

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

Terminal

kubectl delete pod -l app=web --field-selector status.phase=Running | head -1
kubectl get pods -w         # a replacement appears within seconds; Ctrl-C

What you are proving: You can roll out a change without losing availability, and undo it

Marking this settles success criterion 3.

Terminal

kubectl set image deployment/web web=nginx:1.28-alpine
kubectl rollout status deployment/web
kubectl get rs              # two ReplicaSets now — old scaled to 0

The old ReplicaSet is kept at zero replicas. That is what makes the next command instant:

Terminal

kubectl rollout undo deployment/web
kubectl rollout history deployment/web

Rolling back does not rebuild anything. It scales the previous ReplicaSet back up and the new one down — seconds, not a redeploy.

What you are proving: You can produce a Deployment that creates zero Pods, and explain why

Marking this settles success criterion 4.

Change the selector so it no longer matches the template labels:

yaml

  selector:
    matchLabels:
      app: web-typo        # template still says app: web

Terminal

kubectl apply -f broken.yaml

On an existing Deployment the API server rejects it — the selector is immutable. Create it under a new name and you get a Deployment reporting 0/3 with no error anywhere, because it owns nothing.

A Deployment that creates no Pods is almost always a label mismatch. They are matched as plain strings, and a typo produces silence rather than a complaint.

Maintained by others, on Killercoda. Useful for extra repetition on one tool — it does not complete this lab or settle any criterion above.

Kubernetes scenarios
Kubernetes 101a set of beginner exercises

Success criteria

0 of 4

The concept behind it

Ready to try it without help?Do the challenge

Next up

Lab 32 of 59 on the project path

Kubernetes Services & Service DiscoveryGive disposable Pods a stable address, then break the selector and watch the endpoints empty.Why next: The application as a Deployment that survives a deleted pod45 minBeginner

Previous: Automated Jenkins Server & Toolchain Provisioning