Creating Deployments with YAML in Kubernetes - Practice Exercises

Challenge - 5 Problems

💻 Command Output

intermediate

Output of kubectl apply with a Deployment YAML

You run kubectl apply -f deployment.yaml with this YAML content:

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

What is the expected output of the command?

Kubernetes

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

A error: unable to recognize "deployment.yaml"

B pod/myapp created

C service/myapp created

D deployment.apps/myapp created

💡 Hint

Think about what resource type is defined in the YAML and what kubectl reports after applying it.

The YAML defines a Deployment named 'myapp'. When you apply it, kubectl reports 'deployment.apps/myapp created' indicating the Deployment resource was created successfully.

❓ Configuration

intermediate

Correct label selector in Deployment YAML

You want to create a Deployment that manages pods labeled app: frontend. Which selector field in the Deployment spec correctly matches these pods?

A

selector:
  matchLabels:
    app: frontend

B

selector:
  matchLabels:
    app: backend

C

selector:
  matchExpressions:
  - key: app
    operator: NotIn
    values:
    - frontend

D

selector:
  matchLabels:
    tier: frontend

💡 Hint

The selector must exactly match the labels on the pods you want to manage.

The selector must match the pod labels exactly. Since pods have label 'app: frontend', the selector must be 'matchLabels: app: frontend'.

❓ Troubleshoot

advanced

Why does this Deployment fail to create pods?

You apply this Deployment YAML but no pods are created:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-deploy
spec:
  replicas: 2
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test-app
    spec:
      containers:
      - name: busybox
        image: busybox
        command: ['sleep', '3600']

What is the most likely reason pods are not created?

A The selector labels do not match the pod template labels

B The container image 'busybox' does not exist

C The replicas field must be a string, not a number

D The command field is invalid syntax

💡 Hint

Check if the selector labels and pod labels are exactly the same.

The selector expects pods with label 'app: test' but the pod template has label 'app: test-app'. This mismatch causes no pods to be created.

🔀 Workflow

advanced

Order the steps to update a Deployment image safely

Put these steps in the correct order to update a Deployment's container image with zero downtime:

A 2,1,3,4

B 1,2,4,3

C 1,4,2,3

D 4,1,2,3

💡 Hint

Think about editing first, then applying, then monitoring rollout, then verifying pods.

First edit the YAML to change the image, then apply it. Next monitor rollout status to ensure update success, finally verify pods are running the new image.

✅ Best Practice

expert

Best practice for specifying resource requests in Deployment YAML

Which option shows the best practice for specifying CPU and memory resource requests and limits in a container spec within a Deployment YAML?

A

resources:
  cpu: 500
  memory: 256

B

resources:
  requests:
    cpu: 500m
    memory: 256Mi
  limits:
    cpu: 1
    memory: 512Mi

C

resources:
  requests:
    cpu: "500m"
    memory: "256Mi"
  limits:
    cpu: "1"
    memory: "512Mi"

D

resources:
  requests:
    cpu: 0.5
    memory: 256
  limits:
    cpu: 1
    memory: 512

💡 Hint

Resource values must be strings with units like 'm' for millicores and 'Mi' for memory.

The best practice is to specify resource requests and limits as strings with units, e.g., "500m" for CPU and "256Mi" for memory. This ensures Kubernetes interprets them correctly.