Deployment as higher-level abstraction in Kubernetes - Commands & Configuration

Introduction

Managing individual containers can be complex and error-prone. A Deployment in Kubernetes helps by managing groups of containers, making updates and scaling easier and safer.

When you want to run multiple copies of an application to handle more users.

When you need to update your application without downtime by rolling out changes gradually.

When you want Kubernetes to automatically restart containers if they fail.

When you want to easily roll back to a previous version if an update causes problems.

When you want to manage the desired state of your application automatically.

Config File - deployment.yaml

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deployment
  labels:
    app: example-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: example-app
  template:
    metadata:
      labels:
        app: example-app
    spec:
      containers:
      - name: example-container
        image: nginx:1.23.3
        ports:
        - containerPort: 80

This file defines a Deployment named example-deployment that runs 3 copies (replicas) of an Nginx container.

The selector and template.metadata.labels ensure the Deployment manages the right Pods.

The spec.template.spec.containers section defines the container image and port.

Commands

This command creates the Deployment in Kubernetes, telling it to start 3 copies of the Nginx container as defined in the file.

Terminal

kubectl apply -f deployment.yaml

Expected Output

deployment.apps/example-deployment created

This command lists all Deployments in the current namespace to verify that the Deployment was created successfully.

Terminal

kubectl get deployments

Expected Output

NAME                 READY   UP-TO-DATE   AVAILABLE   AGE

example-deployment   3/3     3            3           10s

This command lists all Pods managed by the Deployment using the label selector to confirm the Pods are running.

Terminal

kubectl get pods -l app=example-app

Expected Output

NAME                                READY   STATUS    RESTARTS   AGE

example-deployment-6f8d7f9d5f-abc12   1/1     Running   0          15s

example-deployment-6f8d7f9d5f-def34   1/1     Running   0          15s

example-deployment-6f8d7f9d5f-ghi56   1/1     Running   0          15s

→

-l - Filter resources by label selector

This command checks the status of the Deployment rollout to ensure all Pods are updated and running as expected.

Terminal

kubectl rollout status deployment/example-deployment

Expected Output

deployment "example-deployment" successfully rolled out

Key Concept

If you remember nothing else from this pattern, remember: a Deployment manages multiple copies of your app and handles updates safely.

Common Mistakes

Not matching the labels in the Deployment selector and Pod template.

Kubernetes won't know which Pods belong to the Deployment, so it won't manage them properly.

Ensure the labels under spec.selector.matchLabels exactly match the labels under spec.template.metadata.labels.

Applying a Deployment file without specifying the correct namespace when needed.

The Deployment might be created in the default namespace, causing confusion or conflicts.

Use the --namespace flag or set the namespace in the metadata section of the YAML file.

Changing the container image in the Deployment file but not applying the updated file.

The running Pods won't update to the new image, so changes won't take effect.

Run kubectl apply -f deployment.yaml again after changes to update the Deployment.

Summary

Create a Deployment YAML file to define how many copies of your app to run and which container image to use.

Use kubectl apply to create or update the Deployment in Kubernetes.

Verify the Deployment and its Pods are running with kubectl get commands and check rollout status for updates.

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