Why Deployment status and history in Kubernetes? - Purpose & Use Cases

The Big Idea

What if you could instantly know if your app update worked or not, without logging into servers?

The Scenario

Imagine you manually update your app on multiple servers by logging into each one and checking if the new version is running.

You try to remember which version you deployed last week and if any errors happened during deployment.

The Problem

This manual way is slow and confusing.

You might miss a server or forget which version is live.

Tracking errors or rollbacks is almost impossible without a clear history.

The Solution

Kubernetes deployment status and history give you a clear, automatic view of what version is running and what happened during each update.

You can quickly see if your app is healthy and roll back if needed.

Before vs After

✗ Before

ssh server1
check app version
ssh server2
check app version

✓ After

kubectl rollout status deployment/my-app
kubectl rollout history deployment/my-app

What It Enables

This lets you confidently manage app updates and fix problems fast without guessing.

Real Life Example

A team deploys a new app version but notices errors.

Using deployment history, they quickly find the last good version and roll back in minutes.

Key Takeaways

Manual checks are slow and error-prone.

Deployment status shows current app health automatically.

History helps track changes and roll back safely.

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