PROJECT:
Restaurant Company
DEADLINE:
Be ready to present this lab in the next class.
==================================================
LAB OBJECTIVE
The goal of this lab is NOT to copy commands.
The goal is to understand the complete Continuous Deployment process:
GitHub
↓
Jenkins
↓
AWS
↓
EKS
↓
Kubernetes Deployment
↓
ReplicaSet
↓
Pods
↓
Service
↓
Application
During this lab you will:
- Verify your Kubernetes environment
- Deploy an application
- Understand Deployment, ReplicaSet, and Pods
- Test Kubernetes self-healing
- Scale an application
- Perform a Rolling Update
- Investigate Kubernetes Events
- Work with health probes
- Intentionally break a deployment
- Troubleshoot ImagePullBackOff
- Troubleshoot application failures
- Practice rollback
- Run the deployment through Jenkins
- Present and explain what you learned
==================================================
IMPORTANT RULE
DO NOT immediately ask AI to fix an error.
When you receive an error:
- Read the error
- Check Pod status
- Run describe
- Read Events
- Check logs
- Explain what you think happened
- Then research the solution
Your instructor will ask:
"How did you know what the problem was?"
You must be able to answer.
==================================================
PART 1 — VERIFY YOUR ENVIRONMENT
Before deploying anything, verify your environment.
Check AWS:
aws sts get-caller-identity
Check AWS CLI:
aws --version
Check kubectl:
kubectl version --client
Check your Kubernetes context:
kubectl config current-context
Check cluster nodes:
kubectl get nodes
EXPECTED RESULT:
Your Kubernetes nodes should be:
Ready
Take a screenshot.
Screenshot name:
01-cluster-nodes
QUESTION TO ANSWER:
What does Ready mean for a Kubernetes Node?
==================================================
PART 2 — VERIFY THE NAMESPACE
Check namespaces:
kubectl get namespaces
Check our production namespace:
kubectl get namespace restaurant-prod
If the namespace does not exist and you have namespace.yaml:
kubectl apply -f namespace.yaml
Now run:
kubectl get pods
Then run:
kubectl get pods -n restaurant-prod
QUESTION:
Why can these two commands return different results?
YOUR ANSWER SHOULD EXPLAIN:
default namespace
vs
restaurant-prod namespace
Take a screenshot:
02-namespace
==================================================
PART 3 — DEPLOY THE APPLICATION
From your CD repository, inspect the Kubernetes files.
You should understand files such as:
namespace.yaml
configmap.yaml
secrets.yaml
serviceaccount.yaml
deployment.yaml
service.yaml
pdb.yaml
networkpolicy.yaml
ingress.yaml
Your repository may not contain every optional resource.
Apply the required resources.
Example:
kubectl apply -f namespace.yaml
kubectl apply -f configmap.yaml -n restaurant-prod
kubectl apply -f secrets.yaml -n restaurant-prod
kubectl apply -f serviceaccount.yaml -n restaurant-prod
kubectl apply -f deployment.yaml -n restaurant-prod
kubectl apply -f service.yaml -n restaurant-prod
If your project includes additional working resources, apply them as instructed.
Now check:
kubectl get all -n restaurant-prod
Then:
kubectl get pods -n restaurant-prod -o wide
EXPECTED RESULT:
Your application Pods should eventually show:
Running
and:
READY 1/1
Take a screenshot:
03-application-running
==================================================
PART 4 — UNDERSTAND THE KUBERNETES HIERARCHY
Run:
kubectl get deployment -n restaurant-prod
Then:
kubectl get replicasets -n restaurant-prod
Then:
kubectl get pods -n restaurant-prod
Study the output.
You should understand:
Deployment
↓
ReplicaSet
↓
Pods
↓
Containers
QUESTION:
Who creates the ReplicaSet?
QUESTION:
Who maintains the required number of Pods?
QUESTION:
Does Jenkins continuously manage individual Pods?
Be prepared to explain these answers.
Take a screenshot:
04-deployment-replicaset-pods
==================================================
PART 5 — INSPECT THE DEPLOYMENT
Run:
kubectl describe deployment restaurant-company \
-n restaurant-prod
Find:
Replicas
Image
Labels
Selector
Strategy
Conditions
Events
Now inspect the Deployment YAML.
Find:
replicas
image
containerPort
resources
startupProbe
readinessProbe
livenessProbe
strategy
Write one sentence explaining each one.
Example:
replicas:
Defines how many application Pods Kubernetes should maintain.
DO NOT copy definitions from the internet.
Explain them in your own words.
==================================================
PART 6 — SELF-HEALING LAB
Check your Pods:
kubectl get pods -n restaurant-prod
Choose ONE Pod.
Copy its name.
Delete it:
kubectl delete pod POD-NAME -n restaurant-prod
Immediately run:
kubectl get pods -n restaurant-prod -w
WATCH WHAT HAPPENS.
You should see:
Old Pod deleted
↓
Kubernetes detects missing replica
↓
New Pod created
↓
Container starts
↓
New Pod becomes Ready
Stop watch mode with:
Ctrl + C
Take BEFORE and AFTER screenshots.
05-self-healing-before
06-self-healing-after
QUESTION:
Why did the Pod come back?
QUESTION:
Did Jenkins create the replacement Pod?
QUESTION:
What Kubernetes component was responsible for maintaining the desired number of Pods?
==================================================
PART 7 — MANUAL SCALING
Check current replicas:
kubectl get deployment restaurant-company \
-n restaurant-prod
Now scale to 5:
kubectl scale deployment restaurant-company \
--replicas=5 \
-n restaurant-prod
Watch:
kubectl get pods -n restaurant-prod -w
Wait until all Pods are Ready.
Press:
Ctrl + C
Verify:
kubectl get deployment restaurant-company \
-n restaurant-prod
QUESTION:
What was the desired state before scaling?
QUESTION:
What is the desired state now?
Now scale back to 3:
kubectl scale deployment restaurant-company \
--replicas=3 \
-n restaurant-prod
Verify:
kubectl get pods -n restaurant-prod
Take screenshot:
07-scaling
==================================================
PART 8 — SERVICE AND PODS
Check Service:
kubectl get service -n restaurant-prod
Describe the Service:
kubectl describe service restaurant-company \
-n restaurant-prod
Now run:
kubectl get pods -n restaurant-prod --show-labels
Look at:
Selector
and:
Labels
QUESTION:
How does the Service know which Pods should receive traffic?
Now check endpoints:
kubectl get endpoints -n restaurant-prod
You should understand:
Service
↓
Selector
↓
Pod Labels
↓
Matching Pods
Take screenshot:
08-service
==================================================
PART 9 — HEALTH PROBES
Open:
deployment.yaml
Find:
startupProbe
readinessProbe
livenessProbe
For each probe, write what question it answers.
STARTUP PROBE:
Has my application finished starting?
READINESS PROBE:
Is my application ready to receive traffic?
LIVENESS PROBE:
Is my application still healthy?
Now inspect a Pod:
kubectl describe pod POD-NAME -n restaurant-prod
Find information about:
Readiness
Liveness
Startup
QUESTION:
Can a container be Running but the Pod still show:
0/1 Ready?
Explain why.
==================================================
PART 10 — ROLLING UPDATE LAB
Before restarting, open another terminal.
Run:
kubectl get pods -n restaurant-prod -w
In the first terminal run:
kubectl rollout restart deployment/restaurant-company \
-n restaurant-prod
WATCH CAREFULLY.
You should see Kubernetes gradually create new Pods and terminate old Pods.
After the rollout:
kubectl rollout status deployment/restaurant-company \
-n restaurant-prod
Then:
kubectl get pods -n restaurant-prod
QUESTION:
Why didn't Kubernetes delete every Pod at the same time?
Open deployment.yaml and find:
strategy:
type: RollingUpdate
Find:
maxSurge
maxUnavailable
Explain both values in your own words.
Take screenshot:
09-rolling-update
==================================================
PART 11 — BREAK THE DEPLOYMENT
Now we are going to intentionally create an incident.
THIS IS PART OF THE LAB.
Open:
deployment.yaml
FIRST:
Save your current working image value somewhere.
Example:
ACCOUNT_ID.dkr.ecr.REGION.amazonaws.com/restaurant-company:latest
Now intentionally change the tag to something that does not exist.
Example:
ACCOUNT_ID.dkr.ecr.REGION.amazonaws.com/restaurant-company:broken-version
Save the file.
Apply:
kubectl apply -f deployment.yaml \
-n restaurant-prod
Now watch:
kubectl get pods -n restaurant-prod
Wait.
You may see:
ErrImagePull
or:
ImagePullBackOff
DO NOT FIX IT YET.
==================================================
PART 12 — TROUBLESHOOT IMAGEPULLBACKOFF
Imagine this is production.
You are the DevOps Engineer.
You cannot simply say:
"It doesn't work."
STEP 1:
kubectl get pods -n restaurant-prod
Copy the failing Pod name.
STEP 2:
kubectl describe pod POD-NAME \
-n restaurant-prod
Go to:
Events
Read the error.
QUESTION:
What exactly is Kubernetes trying to do?
QUESTION:
Why is the image pull failing?
QUESTION:
Is this an application-code problem or an image/deployment problem?
Take screenshot:
10-imagepullbackoff
Now fix deployment.yaml.
Restore the correct image.
Apply again:
kubectl apply -f deployment.yaml \
-n restaurant-prod
Check:
kubectl rollout status deployment/restaurant-company \
-n restaurant-prod
Then:
kubectl get pods -n restaurant-prod
Everything should return to:
Running
1/1 Ready
Take screenshot:
11-fixed-deployment
==================================================
PART 13 — PRACTICE LOG TROUBLESHOOTING
Choose a healthy Pod:
kubectl get pods -n restaurant-prod
View its logs:
kubectl logs POD-NAME \
-n restaurant-prod
Now understand this command:
kubectl logs POD-NAME \
-n restaurant-prod \
--previous
QUESTION:
When would you use --previous?
ANSWER IN YOUR OWN WORDS.
You should understand the difference:
kubectl describe
↓
Kubernetes-level information and Events
kubectl logs
↓
Application/container output
==================================================
PART 14 — CHECK KUBERNETES EVENTS
Run:
kubectl get events \
-n restaurant-prod \
--sort-by=.metadata.creationTimestamp
Study the events.
Look for events related to:
Scheduling
Image pulling
Container creation
Container start
Pod deletion
Scaling
Rolling updates
QUESTION:
Why are Kubernetes Events useful during troubleshooting?
Take screenshot:
12-events
==================================================
PART 15 — ROLLOUT HISTORY
Run:
kubectl rollout history deployment/restaurant-company \
-n restaurant-prod
Study the revisions.
Then check:
kubectl rollout status deployment/restaurant-company \
-n restaurant-prod
QUESTION:
What is a rollout?
QUESTION:
What is a revision?
QUESTION:
Why is deployment history useful?
Take screenshot:
13-rollout-history
==================================================
PART 16 — ROLLBACK PRACTICE
Before doing this section, make sure your application is healthy.
Check:
kubectl get pods -n restaurant-prod
Then:
kubectl rollout history deployment/restaurant-company \
-n restaurant-prod
Practice the rollback command:
kubectl rollout undo deployment/restaurant-company \
-n restaurant-prod
Watch:
kubectl get pods -n restaurant-prod -w
Then verify:
kubectl rollout status deployment/restaurant-company \
-n restaurant-prod
IMPORTANT:
After the exercise, make sure the Deployment is using the intended working image/configuration.
QUESTION:
When would you perform a rollback in production?
QUESTION:
Why might rollback be better than trying to fix a broken release directly in production?
==================================================
PART 17 — JENKINS CD
Now that you understand the Kubernetes commands manually, use Jenkins.
Open Jenkins.
Run the Restaurant Company CD pipeline.
Observe each stage.
You should understand what Jenkins is doing during:
Checkout
Verify Tools
AWS Authentication
Connect to EKS
Create Namespace
Apply Configuration
Deploy Application
Apply Production Resources
Apply Ingress
Verify Rollout
Verify Deployment
IMPORTANT QUESTION:
Why did we learn the kubectl commands manually if Jenkins can do everything automatically?
Expected idea:
Automation is useful only when you understand what is being automated.
If Jenkins fails, a DevOps Engineer must know how to troubleshoot the underlying AWS and Kubernetes operations.
Take screenshot:
14-jenkins-success
==================================================
PART 18 — VERIFY AFTER JENKINS
A green Jenkins pipeline does not mean you should stop checking.
Run:
kubectl get deployment -n restaurant-prod
kubectl get pods -n restaurant-prod
kubectl get services -n restaurant-prod
kubectl rollout status deployment/restaurant-company \
-n restaurant-prod
Optional:
kubectl get ingress -n restaurant-prod
Your goal:
Verify that the deployment is actually healthy.
==================================================
PART 19 — FINAL ARCHITECTURE
You must be able to draw and explain this WITHOUT reading notes:
Developer
↓
GitHub
↓
CI
↓
Tests
↓
SonarQube
↓
Trivy
↓
Docker Build
↓
AWS ECR
↓
Docker Image
========================
CD STARTS
Jenkins
↓
AWS Authentication
↓
AWS EKS
↓
Namespace
↓
ConfigMap / Secret
↓
ServiceAccount
↓
Deployment
↓
ReplicaSet
↓
Pods
↓
Containers
↓
Service
↓
Ingress / Load Balancer
↓
Users
==================================================
PART 20 — INCIDENT CHALLENGE
For each scenario, explain:
- What does the error mean?
- What command would you run first?
- What would you investigate?
- How would you fix or recover?
SCENARIO 1:
Pod status:
ImagePullBackOff
SCENARIO 2:
Pod status:
CrashLoopBackOff
SCENARIO 3:
Pod status:
Pending
SCENARIO 4:
Pod status:
Running
but:
READY 0/1
SCENARIO 5:
All Pods are:
Running 1/1
but users cannot access the application.
SCENARIO 6:
Jenkins deployed a new version successfully, but customers immediately report application errors.
For Scenario 6, think about:
Rollout status
Logs
Events
Application health
Rollback
==================================================
PART 21 — PRESENTATION ASSIGNMENT
NEXT CLASS:
EVERY STUDENT MUST PRESENT THEIR LAB.
Presentation time:
5–7 minutes per student.
Do NOT read definitions from Google.
Do NOT read this document during your entire presentation.
Explain the project as if you are a DevOps Engineer explaining your deployment to your team.
Your presentation should include:
- ARCHITECTURE
Draw:
GitHub
↓
CI
↓
ECR
↓
Jenkins
↓
EKS
↓
Deployment
↓
ReplicaSet
↓
Pods
↓
Service
↓
Users
- DEPLOYMENT
Explain:
What Jenkins does
What Kubernetes does
What ECR does
- SELF-HEALING
Show:
You deleted one Pod.
Explain:
Why Kubernetes created another one.
- SCALING
Show:
3 Pods
↓
5 Pods
↓
3 Pods
Explain:
What desired state means.
- ROLLING UPDATE
Explain:
How Kubernetes replaces application versions without intentionally taking every replica down at once.
- TROUBLESHOOTING
Show your ImagePullBackOff screenshot.
Explain:
What you broke
What status you saw
What command you used
What Events showed
How you identified the root cause
How you fixed it
- ROLLBACK
Explain:
When a DevOps Engineer would roll back a production deployment.
==================================================
PART 22 — SCREENSHOTS TO SUBMIT
Submit these screenshots:
01-cluster-nodes
02-namespace
03-application-running
04-deployment-replicaset-pods
05-self-healing-before
06-self-healing-after
07-scaling
08-service
09-rolling-update
10-imagepullbackoff
11-fixed-deployment
12-events
13-rollout-history
14-jenkins-success
Do not submit screenshots only.
You must understand what each screenshot demonstrates.
==================================================
PART 23 — README
Create a file in your repository:
WEEKEND-LAB.md
Document:
Your name
Project name
Architecture
What you deployed
What each major Kubernetes resource does
Self-healing test
Scaling test
Rolling update test
The error you intentionally created
How you troubleshot it
How you fixed it
Rollback test
What you learned
==================================================
PART 24 — FINAL QUESTIONS
Before coming to class, make sure you can answer these without searching:
What is CI?
What is CD?
What is Jenkins responsible for?
What is ECR responsible for?
What is EKS?
What is a Kubernetes Deployment?
What is a ReplicaSet?
What is a Pod?
What is desired state?
What is self-healing?
What happens when a Pod dies?
What is a Service?
How does Service find Pods?
What is ConfigMap?
What is Secret?
What is ServiceAccount?
What is Startup Probe?
What is Readiness Probe?
What is Liveness Probe?
What is Rolling Update?
What is maxSurge?
What is maxUnavailable?
What is HPA?
What is PDB?
What is NetworkPolicy?
What is ImagePullBackOff?
What is CrashLoopBackOff?
What is the difference between describe and logs?
How do you check Kubernetes Events?
How do you check rollout status?
How do you perform rollback?
Why should we verify an application after Jenkins reports SUCCESS?
==================================================
FINAL GOAL
By the end of this weekend lab, you should NOT say:
"I know how to run kubectl commands."
You should be able to say:
"I understand the Kubernetes deployment lifecycle.
I can deploy an application through Jenkins to EKS.
I understand how Deployment, ReplicaSet, Pods, and Services work together.
I can verify application health.
I can test Kubernetes self-healing and scaling.
I understand Rolling Updates.
I can use kubectl get, describe, logs, events, and rollout commands for troubleshooting.
I can identify an ImagePullBackOff problem.
I understand how to investigate CrashLoopBackOff.
I can recover from a bad deployment using rollback.
Most importantly, I can explain WHY I am performing each step."
==================================================
CLEANUP / COST REMINDER
AWS resources can generate charges.
Follow the instructor's cleanup instructions for the shared/class environment.
Do NOT delete a shared EKS cluster, VPC, Load Balancer, ECR repository, or other shared AWS resource unless you were specifically instructed to do so.
If you created your own temporary AWS resources for this lab, verify what is still running after you finish.
Top comments (0)