Deployment as higher-level abstraction in Kubernetes - Step-by-Step Execution

Process Flow - Deployment as higher-level abstraction

Write Deployment YAML

↓

kubectl apply -f deployment.yaml

↓

Kubernetes API Server receives request

↓

Deployment Controller checks desired state

↓

ReplicaSet created/updated

↓

ReplicaSet manages Pods

↓

Pods created/updated to match desired replicas

↓

Deployment status updated

↓

User sees updated app running

This flow shows how a Deployment YAML is applied, triggering Kubernetes controllers to create ReplicaSets and Pods to match the desired state.

Execution Sample

Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-container
        image: nginx:1.21

This Deployment YAML defines 3 replicas of an nginx container labeled 'myapp'.

Process Table

Step	Action	Kubernetes Object	State Change	Result
1	Apply Deployment YAML	Deployment 'myapp-deployment'	Deployment object created in cluster	Deployment registered with desired replicas=3
2	Deployment Controller checks Deployment	Deployment 'myapp-deployment'	ReplicaSet created with selector matching Deployment	ReplicaSet created to manage Pods
3	ReplicaSet creates Pods	ReplicaSet for 'myapp-deployment'	3 Pods created with label app=myapp	Pods starting containers nginx:1.21
4	Pods become Ready	Pods managed by ReplicaSet	Pods report Ready status	Deployment status updated to available=3
5	User accesses app	Pods	Pods serve traffic	App running with 3 replicas
6	Update Deployment (e.g., image version)	Deployment 'myapp-deployment'	Deployment spec updated	Rolling update triggered
7	ReplicaSet creates new Pods	New ReplicaSet	New Pods created with updated image	Old Pods terminated gradually
8	New Pods become Ready	New Pods	Ready status reported	Deployment status updated with new version
9	Exit	Deployment	Desired state matches actual state	Deployment stable with updated Pods

💡 Deployment reaches desired state with all Pods ready and updated

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	After Step 7	Final
Deployment replicas	undefined	3	3	3	3	3
ReplicaSet Pods count	0	0	3	3	3 (old) + 3 (new)	3 (new)
Pods status	none	none	starting	Ready	starting (new), terminating (old)	Ready (new)
Deployment status	none	created	creating Pods	available=3	rolling update	available=3

Key Moments - 3 Insights

Why does the Deployment create a ReplicaSet instead of Pods directly?

The Deployment manages ReplicaSets to handle rolling updates and scaling smoothly. The ReplicaSet ensures the correct number of Pods are running. See execution_table rows 2 and 3.

What happens during a rolling update when the Deployment spec changes?

A new ReplicaSet is created with the updated spec. New Pods start while old Pods are terminated gradually to avoid downtime. See execution_table rows 6 to 8.

How does Kubernetes know when the Deployment is stable?

When the number of Ready Pods matches the desired replicas and the Deployment status reflects this, it is stable. See execution_table row 9.

Visual Quiz - 3 Questions

Look at the execution_table, at which step are the Pods first created?

A Step 2

B Step 3

C Step 4

D Step 1

💡 Hint

Check the 'Action' and 'State Change' columns in execution_table row 3.

According to variable_tracker, what is the Pods status after Step 4?

A Ready

B none

C starting

D terminating

💡 Hint

Look at the 'Pods status' row under 'After Step 4' in variable_tracker.

If the Deployment spec is updated, what happens next according to the execution_table?

A Pods are deleted immediately

B Deployment is deleted

C A rolling update is triggered with new Pods created

D Nothing changes

💡 Hint

See execution_table rows 6 to 8 describing update and rolling update.

Concept Snapshot

Deployment is a Kubernetes object that manages ReplicaSets and Pods.
You define desired state in Deployment YAML (replicas, template).
Applying Deployment creates/updates ReplicaSet which manages Pods.
Deployment enables rolling updates and scaling.
Pods are created/updated to match Deployment's desired replicas.
Deployment status shows current state of Pods and rollout.

Full Transcript

A Kubernetes Deployment is a higher-level object that manages ReplicaSets and Pods to keep your app running as you want. You write a Deployment YAML file specifying how many copies (replicas) of your app you want and what container image to use. When you apply this YAML with kubectl, Kubernetes creates a Deployment object. The Deployment controller then creates a ReplicaSet that matches the Deployment's selector. The ReplicaSet creates the Pods that run your containers. The Deployment keeps checking that the number of Pods matches the desired replicas. If you update the Deployment, Kubernetes performs a rolling update by creating new Pods with the updated spec and gradually removing old Pods. This process ensures your app stays available during updates. The Deployment status shows when all Pods are ready and the update is complete.

Practice

1. What is the main purpose of a Kubernetes Deployment?

easy

A. To provide network access to pods

B. To store data persistently across pods

C. To schedule pods on specific nodes manually

D. To manage multiple copies of an application and keep them running

Solution

1. Step 1: Understand Deployment role

   A Deployment manages the desired number of pod replicas and ensures they stay running.

2. Step 2: Compare other options

   Options A, B, and D describe Services, Persistent Volumes, and manual scheduling, which are not Deployment's main purpose.

3. Final Answer:

   To manage multiple copies of an application and keep them running -> Option D

4. Quick Check:

   Deployment manages pods = C [OK]

Hint: Deployment controls app copies and uptime [OK]

Common Mistakes:

• Confusing Deployment with Service or Volume
• Thinking Deployment schedules pods manually
• Assuming Deployment stores data

2. Which of the following is the correct minimal YAML snippet to define a Deployment selector matching pods with label app: myapp?

easy

A. selector:
matchLabels:
app: myapp

B. selector:
labels:
app: myapp

C. selector:
matchLabels:
name: myapp

D. selector:
matchExpressions:
- key: app
operator: In
values: [myapp]

Solution

1. Step 1: Recall Deployment selector syntax

   The selector must use matchLabels with key-value pairs matching pod labels.

2. Step 2: Check options

   selector: matchLabels: app: myapp uses correct matchLabels with app: myapp. selector: labels: app: myapp uses wrong key labels. selector: matchLabels: name: myapp uses wrong label key name. selector: matchExpressions: - key: app operator: In values: [myapp] uses matchExpressions which is valid but more complex and not minimal.

3. Final Answer:

   selector: matchLabels: app: myapp -> Option A

4. Quick Check:

   Use matchLabels with correct key = A [OK]

Hint: Use matchLabels with exact pod label keys [OK]

Common Mistakes:

• Using 'labels' instead of 'matchLabels'
• Mismatching label keys in selector
• Confusing matchLabels with matchExpressions

3. Given this Deployment YAML snippet, what will be the number of pods running after applying it?

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-deploy
spec:
  replicas: 3
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test
    spec:
      containers:
      - name: nginx
        image: nginx:latest

medium

A. 0 pods running due to label mismatch

B. 1 pod running

C. 3 pods running

D. Deployment will fail to create pods

Solution

1. Step 1: Check replicas and labels

   The Deployment requests 3 replicas and the selector matches pods with label app: test. The pod template labels match this exactly.

2. Step 2: Confirm pod creation

   Since labels match, Kubernetes will create 3 pods as requested.

3. Final Answer:

   3 pods running -> Option C

4. Quick Check:

   Matching labels + replicas 3 = 3 pods [OK]

Hint: Match selector and template labels to get pods [OK]

Common Mistakes:

• Assuming label mismatch causes zero pods
• Thinking Deployment fails without errors
• Ignoring replicas count

4. You applied a Deployment YAML but no pods are created. Which issue is most likely causing this?

medium

A. The Deployment metadata name is missing

B. The Deployment selector labels do not match the pod template labels

C. The replicas field is set to zero

D. The container image name is missing

Solution

1. Step 1: Understand Deployment selector importance

   The Deployment uses the selector to find pods it manages. If selector labels don't match pod template labels, no pods are created.

2. Step 2: Evaluate other options

   Missing image name causes pod creation failure but usually with errors. Replicas zero means no pods but is explicit. Missing metadata name causes YAML validation error.

3. Final Answer:

   The Deployment selector labels do not match the pod template labels -> Option B

4. Quick Check:

   Selector-template label mismatch = no pods [OK]

Hint: Check selector and template labels match exactly [OK]

Common Mistakes:

• Ignoring label mismatch
• Assuming missing image silently creates no pods
• Confusing replicas zero with label mismatch

5. You want to update your app smoothly without downtime using a Deployment. Which feature of Deployment helps achieve this?

hard

A. Rolling update strategy that replaces pods gradually

B. Manual pod deletion to force restart

C. Setting replicas to zero before update

D. Using a StatefulSet instead of Deployment

Solution

1. Step 1: Identify update strategies in Deployment

   Deployment supports rolling updates that replace pods one by one, keeping the app available.

2. Step 2: Compare other options

   Manual deletion causes downtime. Setting replicas to zero stops all pods. StatefulSet is for stateful apps, not smooth rolling updates.

3. Final Answer:

   Rolling update strategy that replaces pods gradually -> Option A

4. Quick Check:

   Rolling update = smooth app update [OK]

Hint: Rolling update replaces pods one by one [OK]

Common Mistakes:

• Deleting pods manually causes downtime
• Scaling replicas to zero stops app
• Confusing StatefulSet with Deployment update