03: Pod from YAML

03: Pod from YAML

Objective

Learn how to define a Kubernetes Pod using a YAML manifest, deploy it to the cluster, verify it is running, and interact with it using port-forwarding.

Theory

What is a Pod?

A Pod is the smallest deployable unit in Kubernetes. It represents a single instance of a running process in your cluster. A Pod encapsulates one or more containers that share:

• The same network namespace (they share an IP address and port space)
• The same storage volumes
• The same lifecycle (they are scheduled, started, and stopped together)

In most cases, you run a single container per Pod. Multi-container Pods are used for tightly coupled helper processes (covered in the next exercise).

Pod Spec Anatomy

Every Kubernetes resource manifest follows the same top-level structure:

Within spec, the key fields for a Pod are:

Pod Anatomy Diagram

graph TB
    subgraph Pod["Pod: kuard"]
        direction TB
        metadata["metadata<br/>name: kuard<br/>labels: app=kuard"]
        subgraph spec["spec"]
            subgraph container["Container: kuard"]
                image["image: ACR/kuard:1"]
                port["containerPort: 8080"]
            end
        end
    end

    style Pod fill:#e1f5fe,stroke:#0288d1,stroke-width:2px
    style spec fill:#fff3e0,stroke:#f57c00,stroke-width:1px
    style container fill:#e8f5e9,stroke:#388e3c,stroke-width:1px
    style metadata fill:#f3e5f5,stroke:#7b1fa2,stroke-width:1px

Pod Lifecycle

Pods go through the following phases:

Practical Task

Step 1: Create the Pod Manifest

Create a file called kuard-pod.yaml with the following content:

apiVersion: v1
kind: Pod
metadata:
  name: kuard
  namespace: student-XX       # Replace XX with your student number
  labels:
    app: kuard
    team: teamXX              # Replace XX with your student number
spec:
  containers:
    - name: kuard
      image: <ACR_NAME>.azurecr.io/kuard:1
      ports:
        - containerPort: 8080
          name: http
          protocol: TCP

Note: Replace <ACR_NAME> with the actual ACR name provided by the instructor, and XX with your student number.

Step 2: Deploy the Pod

kubectl apply -f kuard-pod.yaml

Expected output:

pod/kuard created

Step 3: Verify the Pod is Running

kubectl get pod kuard -n student-XX

Wait until the STATUS column shows Running:

NAME    READY   STATUS    RESTARTS   AGE
kuard   1/1     Running   0          15s

If the Pod is not running, check the events:

kubectl describe pod kuard -n student-XX

Step 4: Port-Forward to the Pod

Forward local port 8080 to the Pod’s port 8080:

kubectl port-forward pod/kuard 8080:8080 -n student-XX

Now open your browser and navigate to:

http://localhost:8080

You should see the kuard web interface. Press Ctrl+C to stop port-forwarding when you are done.

Step 5: Inspect Pod Logs

kubectl logs kuard -n student-XX

Step 6: Clean Up

kubectl delete pod kuard -n student-XX

Useful Commands

Common Problems

Best Practices

1. Always set labels — Labels are the primary mechanism for selecting and organizing resources in Kubernetes.
2. Use meaningful names — Pod names should be descriptive and follow a consistent naming convention.
3. Specify ports explicitly — Even though Kubernetes does not enforce port declarations, specifying them documents which ports your application uses.
4. Work in your namespace — Always include -n student-XX or set your default namespace to avoid conflicts with other participants.
5. Do not use Pods directly in production — Pods are ephemeral. Use Deployments or other controllers to manage Pods with desired state, replicas, and rolling updates.

Summary

In this exercise you learned:

• The structure of a Kubernetes Pod manifest (apiVersion, kind, metadata, spec)
• How to define a container with an image and ports
• How to deploy a Pod using kubectl apply
• How to verify a Pod is running with kubectl get and kubectl describe
• How to access a Pod locally using kubectl port-forward
• How to view logs and add labels to Pods

Review Questions

1. What is the relationship between a Pod and a container?
2. What happens to the Pod if the container inside it crashes?
3. Why do we specify containerPort in the Pod spec if Kubernetes does not enforce it?
4. What is the difference between kubectl get and kubectl describe?
5. Why should you not use standalone Pods in production workloads?