Deployment status and history in Kubernetes - Step-by-Step Execution

Process Flow - Deployment status and history

Create Deployment

↓

Kubernetes Controller creates Pods

↓

Pods start running

↓

Check Deployment Status

↓

View Deployment History

↓

Update Deployment (optional)

↓

New ReplicaSet created

↓

Old ReplicaSet scaled down

↓

Deployment status updated

This flow shows how a Kubernetes Deployment is created, how pods are managed, how status is checked, and how history is tracked through ReplicaSets.

Execution Sample

Kubernetes

kubectl create deployment nginx --image=nginx
kubectl rollout status deployment/nginx
kubectl rollout history deployment/nginx
kubectl set image deployment/nginx nginx=nginx:1.19
kubectl rollout status deployment/nginx

This sequence creates an nginx deployment, checks its status, views its history, updates the image, and checks status again.

Process Table

Step	Command	Action	Result/Output
1	kubectl create deployment nginx --image=nginx	Create deployment named nginx with nginx image	deployment.apps/nginx created
2	kubectl rollout status deployment/nginx	Check rollout status of nginx deployment	deployment "nginx" successfully rolled out
3	kubectl rollout history deployment/nginx	View rollout history of nginx deployment	REVISION CHANGE-CAUSE 1 <none>
4	kubectl set image deployment/nginx nginx=nginx:1.19	Update nginx container image to version 1.19	deployment.apps/nginx image updated
5	kubectl rollout status deployment/nginx	Check rollout status after update	deployment "nginx" successfully rolled out
6	kubectl rollout history deployment/nginx	View updated rollout history	REVISION CHANGE-CAUSE 1 <none> 2 kubectl set image deployment/nginx nginx=nginx:1.19
7	kubectl rollout undo deployment/nginx	Rollback to previous revision	deployment.apps/nginx rolled back
8	kubectl rollout status deployment/nginx	Check rollout status after rollback	deployment "nginx" successfully rolled out

💡 Deployment is successfully rolled out or rolled back, no further updates.

Status Tracker

Variable	Start	After Step 1	After Step 4	After Step 7	Final
Deployment Image	none	nginx:latest	nginx:1.19	nginx:latest	nginx:latest
Deployment Revision	none	1	2	1	1
Deployment Status	none	Rolled out	Rolled out	Rolled out	Rolled out

Key Moments - 3 Insights

Why does the rollout history show multiple revisions?

Each deployment update creates a new revision tracked in rollout history, as seen in steps 3 and 6 where revision 1 and 2 appear.

What does 'kubectl rollout status' tell us?

It shows if the deployment is successfully rolled out or still updating, as shown in steps 2, 5, and 8 where it confirms success.

How does rollback affect the deployment image?

Rollback restores the deployment image to the previous revision's image, shown in variable_tracker where image changes back to nginx:latest after step 7.

Visual Quiz - 3 Questions

Look at the execution table at step 4. What change happens to the deployment?

A The deployment is deleted

B The deployment image is updated to nginx:1.19

C The deployment is scaled to zero pods

D The deployment status is checked

💡 Hint

Refer to the 'Action' and 'Result/Output' columns at step 4 in the execution table.

At which step does the deployment rollback occur?

A Step 5

B Step 3

C Step 7

D Step 2

💡 Hint

Look for the command 'kubectl rollout undo' in the execution table.

According to the variable tracker, what is the deployment image after step 7?

A nginx:latest

B nginx:1.19

C none

D nginx:1.20

💡 Hint

Check the 'Deployment Image' row under 'After Step 7' in the variable tracker.

Concept Snapshot

kubectl create deployment NAME --image=IMAGE  # Create deployment
kubectl rollout status deployment/NAME       # Check rollout status
kubectl rollout history deployment/NAME      # View deployment revisions
kubectl set image deployment/NAME CONTAINER=IMAGE  # Update image
kubectl rollout undo deployment/NAME          # Rollback to previous revision
Deployment status shows if pods are running as expected; history tracks changes.

Full Transcript

This visual execution traces Kubernetes deployment status and history commands. First, a deployment named nginx is created with the nginx image. The rollout status command confirms the deployment is running successfully. Rollout history shows the initial revision. Then, the deployment image is updated to nginx:1.19, creating a new revision. Status is checked again to confirm success. History now shows two revisions. A rollback command restores the deployment to the previous image and revision. The final status confirms the rollback succeeded. Variables tracked include deployment image, revision number, and status, showing how they change after each command. Key moments clarify why multiple revisions appear, what rollout status means, and how rollback affects the deployment image. Quiz questions test understanding of update, rollback, and variable states referencing the execution table and variable tracker.

Practice

1. What does the command kubectl rollout status deployment/myapp do in Kubernetes?

easy

A. It shows if the deployment named 'myapp' is successfully running or still updating.

B. It deletes the deployment named 'myapp' from the cluster.

C. It creates a new deployment named 'myapp'.

D. It lists all pods running in the cluster.

Solution

1. Step 1: Understand the command purpose

   The command kubectl rollout status checks the current status of a deployment rollout.

2. Step 2: Apply to the specific deployment

   Using deployment/myapp targets the deployment named 'myapp' to see if it is running or updating.

3. Final Answer:

   It shows if the deployment named 'myapp' is successfully running or still updating. -> Option A

4. Quick Check:

   Rollout status = Deployment running status [OK]

Hint: Use rollout status to check deployment health quickly [OK]

Common Mistakes:

• Confusing rollout status with deployment creation
• Thinking it deletes or lists pods
• Using wrong resource type after rollout status

2. Which of the following is the correct syntax to view the rollout history of a deployment named 'webapp'?

easy

A. kubectl get rollout history webapp

B. kubectl describe rollout webapp

C. kubectl rollout status deployment/webapp

D. kubectl rollout history deployment/webapp

Solution

1. Step 1: Identify the correct command for rollout history

   The command to view rollout history is kubectl rollout history.

2. Step 2: Use correct resource type and name

   Appending deployment/webapp specifies the deployment named 'webapp'.

3. Final Answer:

   kubectl rollout history deployment/webapp -> Option D

4. Quick Check:

   Rollout history syntax = kubectl rollout history deployment/name [OK]

Hint: Remember: rollout history shows past changes, rollout status shows current state [OK]

Common Mistakes:

• Using 'get' or 'describe' instead of 'rollout history'
• Omitting 'deployment/' prefix
• Confusing rollout status with rollout history

3. Given the command output:

deployment "frontend" successfully rolled out

What command was most likely run to get this output?

medium

A. kubectl get pods -l app=frontend

B. kubectl rollout history deployment/frontend

C. kubectl rollout status deployment/frontend

D. kubectl describe deployment frontend

Solution

1. Step 1: Analyze the output message

   The message says the deployment "frontend" was successfully rolled out, indicating a status check.

2. Step 2: Match output to command

   kubectl rollout status shows this success message, while history or describe commands show different outputs.

3. Final Answer:

   kubectl rollout status deployment/frontend -> Option C

4. Quick Check:

   Success rollout message = rollout status command [OK]

Hint: Success message means rollout status was checked [OK]

Common Mistakes:

• Confusing rollout history output with status output
• Assuming pod listing shows rollout success
• Using describe which shows detailed info, not status message

4. You ran kubectl rollout history deployment/api but got an error: error: deployments.apps "api" not found. What is the most likely cause?

medium

A. The Kubernetes cluster is down.

B. The deployment named 'api' does not exist in the current namespace.

C. You need to add '--all-namespaces' to see the deployment.

D. The command syntax is incorrect; 'rollout history' is invalid.

Solution

1. Step 1: Understand the error message

   The error says deployment "api" not found, meaning Kubernetes can't find that deployment in the current namespace.

2. Step 2: Check command and context

   The command syntax is correct, and cluster down would cause different errors. Missing deployment is the most likely cause.

3. Final Answer:

   The deployment named 'api' does not exist in the current namespace. -> Option B

4. Quick Check:

   Deployment not found error = deployment missing [OK]

Hint: Check deployment name and namespace if 'not found' error appears [OK]

Common Mistakes:

• Assuming syntax error when command is correct
• Forgetting namespace context
• Blaming cluster status without checking deployment

5. You want to rollback your deployment 'backend' to the previous version after a failed update. Which sequence of commands correctly checks the history and rolls back?

hard

A. kubectl rollout history deployment/backendkubectl rollout undo deployment/backend

B. kubectl rollout status deployment/backendkubectl delete deployment/backend

C. kubectl get pods -l app=backendkubectl rollout history deployment/backend

D. kubectl rollout undo deployment/backendkubectl rollout history deployment/backend

Solution

1. Step 1: Check rollout history

   Use kubectl rollout history deployment/backend to see past versions and confirm rollback target.

2. Step 2: Rollback to previous version

   Use kubectl rollout undo deployment/backend to revert to the last successful deployment.

3. Final Answer:

   kubectl rollout history deployment/backend followed by kubectl rollout undo deployment/backend -> Option A

4. Quick Check:

   History then undo = safe rollback steps [OK]

Hint: Always check history before undoing a rollout [OK]

Common Mistakes:

• Deleting deployment instead of rolling back
• Undoing before checking history
• Confusing status command with rollback