Pod Creation and Label Solutions

Exercise 1: Create a Pod Imperatively and Declaratively

This exercise walks through the foundational CKAD workflow: generate YAML from an imperative command, modify it, and apply it declaratively.

Step 1: Generate the Pod Manifest

kubectl run nginx --image=nginx:1.25 --dry-run=client -o yaml > pod.yaml

This command does three things:

• kubectl run nginx --image=nginx:1.25 — constructs a Pod resource named nginx with a single container running nginx:1.25.
• --dry-run=client — tells kubectl to validate the resource definition locally without sending it to the API server. No Pod is created.
• -o yaml — outputs the resource definition in YAML format instead of the default human-readable confirmation.

The redirect > pod.yaml writes the output to a file. Open it to inspect:

cat pod.yaml

Expected output:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: nginx
  name: nginx
spec:
  containers:
  - image: nginx:1.25
    name: nginx
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

Notice that kubectl run automatically adds the label run: nginx. This is a default behavior — the label key run matches the subcommand, and the value matches the Pod name. You can override this with --labels or -l, but the default is useful for quick identification.

Also notice the creationTimestamp: null and status: {} fields. These are placeholders that the API server populates when the resource is created. You can leave them in the file or remove them — kubectl apply ignores them either way.

Step 2: Add the env: dev Label

Open pod.yaml in your editor and add env: dev under metadata.labels:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: nginx
    env: dev
  name: nginx
spec:
  containers:
  - image: nginx:1.25
    name: nginx
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

The label env: dev sits at the same indentation level as run: nginx — both are children of the labels mapping. YAML indentation errors are the most common manifest mistake. If env is indented differently from run, the parser treats it as a different structure and the apply fails.

Step 3: Apply the Manifest

kubectl apply -f pod.yaml

Expected output:

pod/nginx created

The API server received the manifest, validated it, persisted it to etcd, and the scheduler assigned it to a node. The kubelet on that node is now pulling the nginx:1.25 image and starting the container.

Step 4: Verify the Pod is Running

kubectl get pods

Expected output (after a few seconds):

NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          10s

The READY column shows 1/1 — one container requested, one container running. The STATUS column shows Running, confirming the container started successfully. If you see ContainerCreating, the image is still being pulled. If you see ErrImagePull, the image name or tag is wrong.

Step 5: Verify the Labels

kubectl get pod nginx --show-labels

Expected output:

NAME    READY   STATUS    RESTARTS   AGE   LABELS
nginx   1/1     Running   0          30s   env=dev,run=nginx

Both labels are present: run=nginx (from the imperative generation) and env=dev (from your manual edit). The --show-labels flag appends a LABELS column to the output — without it, labels are hidden from the default kubectl get view.

What Could Go Wrong

• Indentation error in YAML: If env is not aligned with run, the parser rejects the file with an error like error: error parsing pod.yaml: error converting YAML to JSON: yaml: line X: did not find expected key.
• Pod already exists: If you ran kubectl run nginx before generating the YAML (without --dry-run), the Pod already exists. kubectl apply will update it, but if you used kubectl create -f pod.yaml, it fails with AlreadyExists. Delete the existing Pod first: kubectl delete pod nginx.
• Image pull failure: If you typed nginx:1.25 incorrectly (e.g., nginx:1.225), the kubelet cannot pull the image. Check with kubectl describe pod nginx and look at the Events section.

---

Exercise 2: Add Labels to a Running Pod

This exercise demonstrates imperative label management — adding, overwriting, and removing labels on a live resource.

Step 1: Add Two Labels

kubectl label pod nginx tier=frontend version=v1

Expected output:

pod/nginx labeled

This command modifies the Pod’s metadata in etcd without restarting the container. Labels are metadata — changing them does not affect the running process inside the container. The kubelet does not even notice the change.

You can add multiple labels in a single command by listing them space-separated. Each is applied atomically — either all succeed or none do.

Step 2: Verify the Labels

kubectl get pod nginx --show-labels

Expected output:

NAME    READY   STATUS    RESTARTS   AGE   LABELS
nginx   1/1     Running   0          2m    env=dev,run=nginx,tier=frontend,version=v1

Four labels are now present. The order in the output is alphabetical by key, not in the order they were added.

Step 3: Overwrite the env Label

kubectl label pod nginx env=staging --overwrite

Expected output:

pod/nginx labeled

The --overwrite flag is required when changing the value of an existing label. Without it, kubectl refuses the operation to prevent accidental overwrites:

error: 'env' already has a value (dev), and --overwrite is false

This safety mechanism matters in production but is purely a speed consideration on the exam — always include --overwrite when modifying existing labels to avoid the error-and-retry cycle.

Step 4: Remove the version Label

kubectl label pod nginx version-

Expected output:

pod/nginx labeled

The trailing minus sign (-) after the key name tells kubectl to remove that label. No value is specified because you are deleting, not setting. The syntax is key-, not key= or key=null.

Step 5: Confirm the Final Label Set

kubectl get pod nginx --show-labels

Expected output:

NAME    READY   STATUS    RESTARTS   AGE   LABELS
nginx   1/1     Running   0          3m    env=staging,run=nginx,tier=frontend

Three labels remain: env has been changed from dev to staging, version has been removed, and run and tier are unchanged.

Alternative: Labels in YAML

You could also modify labels by editing the manifest and re-applying:

kubectl edit pod nginx

This opens the Pod’s live YAML in your default editor. Change the labels, save, and exit — kubectl applies the changes. On the exam, kubectl label is faster for single-label changes. kubectl edit is faster when you need to change multiple fields simultaneously.

What Could Go Wrong

• Forgetting --overwrite: The error message tells you exactly what happened and what to do. Read it — exam errors are not cryptic, they are instructive.
• Typo in the label key for removal: kubectl label pod nginx vresion- succeeds silently (the label vresion does not exist, so there is nothing to remove). Always verify with --show-labels after modifications.
• Wrong Pod name: If you have multiple Pods and target the wrong one, the labels land on the wrong resource. Use kubectl get pods --show-labels to verify before and after.