Introduction
A Pod runs containers, but a Pod by itself is not the usual way to run an application in Kubernetes. A Deployment describes the desired state for an application and creates a ReplicaSet, which then creates and maintains the Pods.
In this lab, you will create your first Deployment, wait for it to become available, inspect the Deployment, ReplicaSet, and Pods it creates, and then observe how the Deployment restores Pods after deletion. This is the foundation for later CKAD topics such as scaling, rolling updates, rollback, and application exposure.
Prepare a Deployment Namespace
In this step, you will prepare a clean namespace for Deployment practice and make it the default namespace for your commands.
Start in /home/labex/project. You will not need to write a manifest in this lab, but using the same workspace keeps the course consistent.
mkdir -p /home/labex/project
cd /home/labex/project
Check that the Kubernetes API server is reachable. If the VM has just started and this command fails, wait a few seconds and run it again until the node is Ready.
kubectl get nodes --request-timeout=5s
Expected output includes:
NAME STATUS ROLES AGE VERSION
labex-v135 Ready control-plane ... v1.35...
Pods need the cluster networking plugin before they can become Ready. Wait for the Calico node Pod before creating application workloads.
kubectl wait --namespace kube-system --for=condition=Ready pod -l k8s-app=calico-node --timeout=120s
Expected output:
pod/calico-node-... condition met
Create a namespace named ckad-prep-deployments:
kubectl create namespace ckad-prep-deployments
The command should confirm creation:
namespace/ckad-prep-deployments created
Set this namespace as the current context namespace:
kubectl config set-context --current --namespace=ckad-prep-deployments
Confirm the current namespace:
kubectl config view --minify --output 'jsonpath={..namespace}'; echo
Expected output:
ckad-prep-deployments
Create the Deployment
In this step, you will create a Deployment named web-demo with two replicas.
The kubectl create deployment command asks Kubernetes to create a Deployment object. The --image option sets the container image in the Pod template, and --replicas=2 asks the Deployment to keep two matching Pods running.
kubectl create deployment web-demo --image=registry.k8s.io/pause:3.10.1 --replicas=2
Expected output:
deployment.apps/web-demo created
Wait for the Deployment rollout to finish. For a new Deployment, rollout status means Kubernetes created the ReplicaSet and the requested Pods became available.
kubectl rollout status deployment/web-demo --timeout=90s
The output may include short waiting messages while the Pods become available. It should end with:
deployment "web-demo" successfully rolled out
Now inspect the Deployment summary:
kubectl get deployment web-demo
Expected output includes:
NAME READY UP-TO-DATE AVAILABLE AGE
web-demo 2/2 2 2 ...
Inspect the ReplicaSet and Pods
In this step, you will inspect the objects created below the Deployment.
A Deployment does not run containers directly. It creates a ReplicaSet, and the ReplicaSet creates Pods. The Deployment selector and Pod template labels connect these objects together.
First, inspect the selector label and template label on the Deployment. JSONPath prints only the selected fields, which keeps the output focused.
kubectl get deployment web-demo -o 'jsonpath={.spec.selector.matchLabels.app}{" "}{.spec.template.metadata.labels.app}{"\n"}'
Expected output:
web-demo web-demo
The first value is the Deployment selector label. The second value is the label placed on Pods from the template. They match, so the Deployment can manage those Pods.
List the ReplicaSet created by the Deployment:
kubectl get replicasets -l app=web-demo
Expected output includes:
NAME DESIRED CURRENT READY AGE
web-demo-... 2 2 2 ...
Now list the Pods selected by the same label:
kubectl get pods -l app=web-demo --show-labels
Expected output includes two running Pods:
NAME READY STATUS RESTARTS AGE LABELS
web-demo-... 1/1 Running 0 ... app=web-demo,pod-template-hash=...
web-demo-... 1/1 Running 0 ... app=web-demo,pod-template-hash=...
Finally, show the owner kind for each Pod. Each Pod is owned by a ReplicaSet, not directly by the Deployment.
kubectl get pods -l app=web-demo -o 'custom-columns=NAME:.metadata.name,OWNER:.metadata.ownerReferences[0].kind,PHASE:.status.phase'
Expected output:
NAME OWNER PHASE
web-demo-... ReplicaSet Running
web-demo-... ReplicaSet Running
Observe Desired State Recovery
In this step, you will delete the current Pods and watch the Deployment restore the desired state.
This is the key difference between a single Pod and a Deployment. If you delete standalone Pods, they are gone. If you delete Pods managed by a Deployment, the Deployment notices that the actual state no longer matches the desired state and creates replacements.
Delete the Pods selected by app=web-demo. The --wait=false option returns immediately after sending the delete request, so you can observe recovery without waiting for every old Pod to disappear first.
kubectl delete pods -l app=web-demo --wait=false
Expected output includes:
pod "web-demo-..." deleted from ckad-prep-deployments namespace
pod "web-demo-..." deleted from ckad-prep-deployments namespace
Wait for the Deployment to become available again:
kubectl wait --for=condition=Available deployment/web-demo --timeout=90s
Expected output:
deployment.apps/web-demo condition met
List the Pods again:
kubectl get pods -l app=web-demo
Expected output includes two running Pods. The names may be different because the ReplicaSet created replacements.
NAME READY STATUS RESTARTS AGE
web-demo-... 1/1 Running 0 ...
web-demo-... 1/1 Running 0 ...
Check the Deployment summary one more time:
kubectl get deployment web-demo
Expected output includes:
NAME READY UP-TO-DATE AVAILABLE AGE
web-demo 2/2 2 2 ...
Summary
You created a Deployment, waited for its rollout, inspected its selector and Pod template labels, found the ReplicaSet and Pods it created, and observed desired state recovery after deleting the Pods. These ideas prepare you for the next Deployment labs, where you will change replica counts, update applications, and manage rollout behavior.
