Creating Deployments with YAML in Kubernetes - Visual Walkthrough

Process Flow - Creating Deployments with YAML

Write YAML file

↓

kubectl apply -f file.yaml

↓

Kubernetes API Server receives

↓

Deployment object created

↓

ReplicaSet created

↓

Pods created and running

↓

Deployment ready

The flow starts with writing a YAML file, then applying it with kubectl, which creates a Deployment object. Kubernetes then creates ReplicaSets and Pods until the Deployment is ready.

Execution Sample

Kubernetes

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

This YAML defines a Deployment named 'myapp-deployment' with 2 replicas running nginx version 1.21.

Process Table

Step	Action	Resource Created	State Change	Output/Status
1	kubectl apply -f deployment.yaml	Deployment 'myapp-deployment'	Deployment object created in cluster	deployment.apps/myapp-deployment created
2	Kubernetes creates ReplicaSet	ReplicaSet for 'myapp-deployment'	ReplicaSet object created	replicaset.apps/myapp-deployment-xxxxx created
3	ReplicaSet creates Pods	2 Pods with label app=myapp	Pods created and starting	pod/myapp-deployment-xxxxx-1 created pod/myapp-deployment-xxxxx-2 created
4	Pods start running	Pods status changes	Pods become Ready	pod/myapp-deployment-xxxxx-1 Ready pod/myapp-deployment-xxxxx-2 Ready
5	Deployment status updated	Deployment reports ready replicas	Deployment ready with 2 replicas	deployment.apps/myapp-deployment available

💡 Deployment is ready when all replicas are running and available.

Status Tracker

Resource	Initial	After Step 1	After Step 2	After Step 3	After Step 4	Final
Deployment	None	Created	Created	Created	Created	Ready with 2 replicas
ReplicaSet	None	None	Created	Created	Created	Active with 2 pods
Pods	None	None	None	Created (2 pods)	Running (2 pods)	Ready (2 pods)

Key Moments - 3 Insights

Why does the Deployment create a ReplicaSet before Pods?

The Deployment manages ReplicaSets to control Pods. As shown in execution_table step 2, the ReplicaSet is created first to manage the desired number of Pods.

What does 'kubectl apply' do with the YAML file?

It sends the YAML to Kubernetes API Server to create or update resources. Execution_table step 1 shows the Deployment object creation after applying the YAML.

When is the Deployment considered ready?

When all Pods are running and available. Execution_table step 5 shows the Deployment status updated to ready with 2 replicas.

Visual Quiz - 3 Questions

Look at the execution_table, what resource is created immediately after applying the YAML file?

A Deployment

B Pods

C ReplicaSet

D Service

💡 Hint

Check execution_table step 1 for the resource created by 'kubectl apply'.

At which step do the Pods become Ready according to the execution_table?

A Step 2

B Step 4

C Step 3

D Step 5

💡 Hint

Look at the 'Pods start running' action in execution_table step 4.

If the replicas count in YAML is changed from 2 to 3, what changes in the variable_tracker for Pods?

A Pods remain at 2 throughout

B Pods increase to 3 after Step 1

C Pods increase to 3 after Step 3

D Pods increase to 3 after Step 5

💡 Hint

Pods are created by ReplicaSet after Step 2, see variable_tracker Pods row.

Concept Snapshot

Creating a Deployment with YAML:
- Write a YAML file with apiVersion, kind: Deployment, metadata, and spec.
- Use 'kubectl apply -f file.yaml' to create the Deployment.
- Kubernetes creates a ReplicaSet to manage Pods.
- Pods are created and run the specified container image.
- Deployment is ready when all replicas are running.

Full Transcript

To create a Deployment in Kubernetes, you write a YAML file describing the Deployment resource, including the number of replicas and container details. Then you run 'kubectl apply -f' with that YAML file. Kubernetes creates the Deployment object, which in turn creates a ReplicaSet. The ReplicaSet manages the Pods, creating the specified number of Pods running the container image. When all Pods are running and ready, the Deployment status updates to ready. This process ensures your application runs with the desired number of instances.

Practice

1. What is the main purpose of a Deployment in Kubernetes when defined using a YAML file?

easy

A. To manage and update multiple copies of an application smoothly

B. To store data persistently across pods

C. To expose an application to the internet

D. To define network policies between pods

Solution

1. Step 1: Understand Deployment role

   A Deployment manages the lifecycle of pods, ensuring the desired number of replicas run and updates happen smoothly.

2. Step 2: Compare options

   Options B, C, and D describe other Kubernetes resources (PersistentVolume, Service, NetworkPolicy), not Deployment.

3. Final Answer:

   To manage and update multiple copies of an application smoothly -> Option A

4. Quick Check:

   Deployment = Manage app replicas and updates [OK]

Hint: Deployments control app copies and updates, not storage or networking [OK]

Common Mistakes:

• Confusing Deployment with Service or PersistentVolume
• Thinking Deployment exposes apps externally
• Assuming Deployment manages network policies

2. Which of the following YAML snippets correctly sets the number of pod replicas to 3 in a Deployment?

easy

A. replicas: 3

B. replicaCount: 3

C. count: 3

D. podReplicas: 3

Solution

1. Step 1: Identify correct replicas field

   The correct field to specify pod count in Deployment YAML is replicas.

2. Step 2: Check other options

   Fields like replicaCount, count, or podReplicas are invalid and will cause errors.

3. Final Answer:

   replicas: 3 -> Option A

4. Quick Check:

   Use 'replicas' to set pod count [OK]

Hint: Use 'replicas' exactly to set pod count in Deployment YAML [OK]

Common Mistakes:

• Using incorrect field names like replicaCount
• Misspelling 'replicas' or using camelCase
• Placing replicas under wrong YAML level

3. Given this Deployment YAML snippet, what will be the label selector used to match pods?

selector:
  matchLabels:
    app: myapp
    tier: frontend

medium

A. Pods with any label app or tier

B. Pods with label app=myapp only

C. Pods with label tier=frontend only

D. Pods with labels app=myapp and tier=frontend

Solution

1. Step 1: Understand matchLabels selector

   The matchLabels requires all listed labels to match exactly for pod selection.

2. Step 2: Analyze given labels

   Both app: myapp and tier: frontend must be present on pods to match.

3. Final Answer:

   Pods with labels app=myapp and tier=frontend -> Option D

4. Quick Check:

   matchLabels means all labels must match [OK]

Hint: matchLabels requires all labels to match exactly [OK]

Common Mistakes:

• Assuming matchLabels matches any one label
• Confusing matchLabels with matchExpressions
• Ignoring one of the labels in selector

4. You wrote this Deployment YAML but your pods are not created. What is the error?

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
spec:
  replicas: 2
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
      - name: webapp
        image: nginx

medium

A. No container ports defined

B. Incorrect apiVersion for Deployment

C. Selector labels do not match template labels

D. Missing container image tag

Solution

1. Step 1: Check selector and template labels

   The selector matchLabels: app: webapp does not match template labels: app: frontend. Labels must match exactly or Deployment creation fails.

2. Step 2: Verify other fields

   Ports are optional for pod creation; apiVersion is correct; image tag defaults to latest.

3. Final Answer:

   Selector labels do not match template labels -> Option C

4. Quick Check:

   Selector must match template labels [OK]

Hint: Selector labels must exactly match template labels [OK]

Common Mistakes:

• Assuming container ports are required for pod creation
• Thinking image tag is mandatory
• Confusing apiVersion for Deployment

5. You want to update your Deployment to run 5 replicas and change the container image to 'nginx:1.21'. Which YAML snippet correctly applies both changes?

hard

A. spec:
replicas: 5
template:
spec:
containers:
- name: nginx
image: nginx:1.21

B. spec:
replicas: 5
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.21

C. spec:
replicas: 5
containers:
- name: nginx
image: nginx:1.21

D. spec:
template:
spec:
containers:
- name: nginx
image: nginx:1.21
replicas: 5

Solution

1. Step 1: Understand Deployment spec structure

   The replicas field is directly under spec. The pod template is under spec.template, which must include metadata.labels and spec.containers.

2. Step 2: Check each option's correctness

   spec:
     replicas: 5
     template:
       spec:
         containers:
         - name: nginx
           image: nginx:1.21

   misses metadata.labels under template, which is required for selector matching.

   spec:
     replicas: 5
     containers:
     - name: nginx
       image: nginx:1.21

   places containers directly under spec, which is invalid.

   spec:
     template:
       spec:
         containers:
         - name: nginx
           image: nginx:1.21
     replicas: 5

   places replicas after template, which is allowed but missing labels in template metadata.

   spec:
     replicas: 5
     template:
       metadata:
         labels:
           app: nginx
       spec:
         containers:
         - name: nginx
           image: nginx:1.21

   correctly includes replicas, template metadata labels, and container spec with updated image.

3. Final Answer:

   spec: replicas: 5, template with metadata.labels app: nginx, containers image: nginx:1.21 -> Option B

4. Quick Check:

   replicas under spec, labels in template metadata, containers in template spec [OK]

Hint: Always include labels in template metadata for selector matching [OK]

Common Mistakes:

• Omitting labels in pod template metadata
• Placing containers outside template spec
• Misplacing replicas field