Let's follow Sarah's journey from her first Pod to mastering scheduling, probes, and resource management. By the end, you will be able to do everything she learns -- and pass the CKA/CKAD exam questions about it.

What Is a Pod?

Sarah's Docker experience taught her to think in containers. But Kubernetes wraps containers in something bigger...

• A Pod is the smallest deployable unit in Kubernetes (not a container!)
• Most Pods run a single container, but multi-container Pods are common for sidecars
• Pods are ephemeral -- they can be killed and replaced at any time
• Every Pod gets its own IP address within the cluster

Anatomy of a Pod

Sarah opens the documentation and sees this structure. Let's break it down piece by piece.

Sarah's First Pod YAML

Sarah writes her very first Pod manifest:

apiVersion: v1
kind: Pod
metadata:
  name: my-api
  labels:
    app: my-api
    tier: backend
spec:
  containers:
  - name: api
    image: nginx:1.25
    ports:
    - containerPort: 80
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

Every Kubernetes object follows the same pattern: apiVersion, kind, metadata, spec.

Declarative vs Imperative

Sarah has two ways to create her Pod. Understanding the difference is fundamental to Kubernetes thinking.

kubectl run my-api --image=nginx:1.25
kubectl expose pod my-api --port=80

kubectl apply -f pod.yaml

Pod Lifecycle

Sarah deploys her Pod and watches it go through several phases. Here's what happens behind the scenes...

Multi-Container Pod Patterns

Sarah's teammate asks: "Can I run a log shipper next to my app in the same Pod?" Absolutely -- that is the sidecar pattern.

spec:
  containers:
  - name: app
    image: my-app:1.0
  - name: log-shipper        # sidecar container
    image: fluentd:latest
    volumeMounts:
    - name: logs
      mountPath: /var/log/app
  volumes:
  - name: logs
    emptyDir: {}

Init Containers

Before Sarah's API can start, it needs to wait for the database to be ready. Init containers solve this perfectly.

Common use cases:

• Wait for a dependent service to be available
• Pre-populate shared volumes with data
• Run database migrations before the app starts
• Fetch secrets or config from a vault

spec:
  initContainers:
  - name: wait-for-db
    image: busybox:1.36
    command: ['sh', '-c',
      'until nslookup postgres.default.svc.cluster.local; do
        echo "Waiting for DB..."; sleep 2;
      done']
  containers:
  - name: api
    image: my-api:1.0

Namespaces

Sarah's cluster is shared by multiple teams. How do they keep their resources from colliding?

# Create a namespace
kubectl create namespace dev

# Deploy to a namespace
kubectl apply -f pod.yaml -n dev

# List pods in a namespace
kubectl get pods -n dev

# List across all namespaces
kubectl get pods -A

Note: Not all resources are namespaced. Nodes, PersistentVolumes, and ClusterRoles are cluster-scoped. Check with kubectl api-resources --namespaced=false.

Labels & Selectors

Sarah has 50 Pods running. How does she find, group, and manage them? Labels are the answer.

metadata:
  labels:
    app: my-api
    tier: backend
    env: production
    version: v2

# Equality-based
kubectl get pods -l app=my-api

# Set-based
kubectl get pods -l 'env in (prod,staging)'

# Multiple conditions (AND)
kubectl get pods -l app=my-api,tier=backend

Annotations

While labels are for identification and selection, annotations store non-identifying metadata.

metadata:
  annotations:
    kubernetes.io/change-cause: "Update to v2"
    prometheus.io/scrape: "true"
    prometheus.io/port: "9090"
    description: "Main API service"

Knowledge Check: Pods Basics

Let's see what you have learned so far

Environment Variables

Sarah needs to pass database credentials and feature flags to her app. Kubernetes offers several ways to inject configuration.

env:
- name: DB_HOST
  value: "postgres.default.svc"
- name: LOG_LEVEL
  value: "info"

env:
- name: DB_PASSWORD
  valueFrom:
    secretKeyRef:
      name: db-credentials
      key: password
- name: APP_CONFIG
  valueFrom:
    configMapKeyRef:
      name: app-config
      key: config.json

ConfigMaps: Externalizing Configuration

ConfigMaps decouple configuration from container images. Change config without rebuilding.

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  DATABASE_URL: "postgres://db.default.svc:5432/mydb"
  LOG_LEVEL: "info"
  config.yaml: |
    server:
      port: 8080
      timeout: 30s

Three ways to consume ConfigMaps:

envFrom:
- configMapRef:
    name: app-config

volumes:
- name: cfg
  configMap:
    name: app-config

env:
- name: LOG_LEVEL
  valueFrom:
    configMapKeyRef:
      name: app-config
      key: LOG_LEVEL

Secrets

Sarah's app needs a database password. She knows better than to put it in plain YAML...

# Create a Secret imperatively
kubectl create secret generic db-creds \
  --from-literal=username=admin \
  --from-literal=password=S3cureP@ss!

# Or declaratively (values must be base64-encoded)
apiVersion: v1
kind: Secret
metadata:
  name: db-creds
type: Opaque
data:
  username: YWRtaW4=        # base64 of "admin"
  password: UzNjdXJlUEBzcyE=

Resource Requests & Limits

Sarah's Pod is eating all the memory on a shared node, affecting other teams. Time to set boundaries.

resources:
  requests:
    memory: "128Mi"
    cpu: "250m"   # 0.25 CPU core

resources:
  limits:
    memory: "256Mi"
    cpu: "500m"   # 0.5 CPU core

LimitRanges & ResourceQuotas

Cluster admins use these to enforce resource governance across namespaces.

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
spec:
  limits:
  - default:
      cpu: "500m"
      memory: "256Mi"
    defaultRequest:
      cpu: "100m"
      memory: "128Mi"
    type: Container

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    pods: "20"

Health Probes: Is Your App Actually Working?

Sarah's Pod is "Running" but users are getting 503 errors. The container started, but the app inside hasn't finished initializing. Kubernetes needs a way to know when the app is truly ready.

Probe Types & Configuration

Three mechanisms to check health:

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 15
  periodSeconds: 10
  failureThreshold: 3

readinessProbe:
  tcpSocket:
    port: 3306
  initialDelaySeconds: 5
  periodSeconds: 10

livenessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5

Restart Policies

What happens when a container exits? The restartPolicy field determines the behavior.

Knowledge Check: Config & Lifecycle

Test your understanding of environment, probes, and resources

How Scheduling Works

Sarah has 10 nodes in her cluster. When she creates a Pod, how does Kubernetes decide which node it lands on? Enter the kube-scheduler -- the matchmaker of the cluster.

The scheduling process:

1. Filtering -- eliminate nodes that don't meet the Pod's requirements (insufficient resources, wrong labels, taints)
2. Scoring -- rank remaining nodes by preference (spreading, affinity, resource balance)
3. Binding -- assign the Pod to the highest-scoring node

All of this happens in milliseconds. You can influence it but rarely need to override it.

nodeSelector: The Simplest Scheduling Constraint

Want your Pod on a specific type of node? Use nodeSelector -- it matches Pod to node labels.

# First, label your node
kubectl label node worker-1 disktype=ssd

# Then reference it in your Pod spec
apiVersion: v1
kind: Pod
metadata:
  name: fast-io-app
spec:
  nodeSelector:
    disktype: ssd
  containers:
  - name: app
    image: my-app:1.0

For more complex placement logic, use node affinity (coming up next).

Node Affinity: Advanced Node Selection

Node affinity is a more expressive version of nodeSelector. It supports soft preferences and complex expressions.

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: topology.kubernetes.io/zone
            operator: In
            values: ["us-east-1a", "us-east-1b"]
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 80
        preference:
          matchExpressions:
          - key: node-type
            operator: In
            values: ["high-memory"]

Operators: In, NotIn, Exists, DoesNotExist, Gt, Lt

Pod Affinity & Anti-Affinity

Sarah wants her web Pods close to her cache Pods (for low latency) but spread across zones (for high availability). Pod affinity and anti-affinity solve both.

affinity:
  podAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchLabels:
          app: redis
      topologyKey: kubernetes.io/hostname

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      podAffinityTerm:
        labelSelector:
          matchLabels:
            app: web
        topologyKey: topology.kubernetes.io/zone

Taints & Tolerations

Some nodes in Sarah's cluster are reserved for GPU workloads only. How does she keep regular Pods off those nodes?

# Apply a taint
kubectl taint nodes gpu-node-1 \
  gpu=true:NoSchedule

# Remove a taint (note the minus)
kubectl taint nodes gpu-node-1 \
  gpu=true:NoSchedule-

spec:
  tolerations:
  - key: "gpu"
    operator: "Equal"
    value: "true"
    effect: "NoSchedule"

Taint Effects

Three effects determine how strictly the taint is enforced:

Topology Spread Constraints

Sarah's Pods keep landing on the same node. If that node goes down, all replicas are lost. She needs to spread them evenly.

spec:
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        app: web
  - maxSkew: 1
    topologyKey: kubernetes.io/hostname
    whenUnsatisfiable: ScheduleAnyway
    labelSelector:
      matchLabels:
        app: web

Knowledge Check: Scheduling

How well do you understand Pod placement?

Manual Scheduling with nodeName

In rare cases, you can bypass the scheduler entirely by setting nodeName directly.

apiVersion: v1
kind: Pod
metadata:
  name: manual-pod
spec:
  nodeName: worker-node-3   # Bypasses the scheduler entirely
  containers:
  - name: app
    image: nginx:1.25

When is this useful?

• Debugging scheduler issues
• Static Pods (managed by kubelet directly, not the API server)
• Testing on a specific node during development

Static Pods

Sarah notices some Pods in kube-system that she can't delete through kubectl. These are static Pods -- managed directly by the kubelet on each node.

Priority & Preemption

The cluster is full and Sarah's critical payment service can't get scheduled. But there are lower-priority batch jobs running. Priority classes to the rescue.

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
preemptionPolicy: PreemptLowerPriority
description: "For critical production workloads"

# Reference in Pod spec
spec:
  priorityClassName: high-priority
  containers:
  - name: payment-service
    image: payment:2.0

Pod Disruption Budgets (PDB)

The ops team is draining nodes for maintenance. Sarah's API has 3 replicas, and she wants to guarantee at least 2 are always available during the disruption.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-pdb
spec:
  minAvailable: 2          # OR use maxUnavailable: 1
  selector:
    matchLabels:
      app: my-api

Applies to voluntary disruptions only: node drains, rolling updates, cluster autoscaler. Does NOT protect against involuntary disruptions like hardware failures.

Designing Good Health Checks

Sarah's team has been bitten by poorly configured probes. Here are the lessons they learned.

Container Lifecycle Hooks

Kubernetes lets you run code at two points in a container's lifecycle:

lifecycle:
  postStart:
    exec:
      command: ["/bin/sh", "-c", "echo 'Started' >> /var/log/lifecycle.log"]
  preStop:
    httpGet:
      path: /shutdown
      port: 8080

Knowledge Check: Probes & Advanced Topics

Almost there -- test your advanced knowledge

Security Contexts

The security team reviewed Sarah's deployment and flagged that her containers are running as root. Time to lock things down.

spec:
  securityContext:           # Pod-level settings
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000
  containers:
  - name: app
    image: my-app:1.0
    securityContext:         # Container-level settings
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]
        add: ["NET_BIND_SERVICE"]

Service Accounts

Pods use ServiceAccounts to authenticate with the Kubernetes API. Every Pod gets one.

# Create a service account
kubectl create serviceaccount my-app-sa

# Use it in a Pod
spec:
  serviceAccountName: my-app-sa
  automountServiceAccountToken: false  # Disable if not needed
  containers:
  - name: app
    image: my-app:1.0

Debugging Pods: Sarah's Toolkit

Things will go wrong. Here is the debugging playbook Sarah keeps handy.

# Check Pod status and events
kubectl describe pod my-api

# View container logs (current and previous crash)
kubectl logs my-api
kubectl logs my-api --previous
kubectl logs my-api -c sidecar   # specific container

# Exec into a running container
kubectl exec -it my-api -- /bin/sh

# Debug with ephemeral container (K8s 1.25+)
kubectl debug -it my-api --image=busybox --target=app

# View resource usage
kubectl top pod my-api

# Check events in namespace
kubectl get events --sort-by=.lastTimestamp

Essential kubectl Commands

# Generate YAML without creating
kubectl run nginx --image=nginx \
  --dry-run=client -o yaml

# Apply from file
kubectl apply -f pod.yaml

# Delete
kubectl delete pod my-api
kubectl delete -f pod.yaml

# Edit live resource
kubectl edit pod my-api

# List with extra info
kubectl get pods -o wide

# JSON output + jq
kubectl get pod my-api -o json | jq '.status'

# Watch for changes
kubectl get pods -w

# Sort by restart count
kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'

Putting It All Together: Sarah's Production Pod

After everything she learned, here is Sarah's production-ready Pod manifest. Notice how it incorporates labels, probes, resources, security, and more.

apiVersion: v1
kind: Pod
metadata:
  name: my-api
  namespace: production
  labels:
    app: my-api
    tier: backend
    version: v2
  annotations:
    prometheus.io/scrape: "true"
spec:
  serviceAccountName: my-api-sa
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
  containers:
  - name: api
    image: my-api:2.0
    ports:
    - containerPort: 8080
    resources:
      requests: { cpu: "250m", memory: "128Mi" }
      limits:   { cpu: "500m", memory: "256Mi" }
    livenessProbe:
      httpGet: { path: /healthz, port: 8080 }
      initialDelaySeconds: 10
      periodSeconds: 15
    readinessProbe:
      httpGet: { path: /readyz, port: 8080 }
      initialDelaySeconds: 5
      periodSeconds: 5
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: env
            operator: In
            values: ["production"]

Sarah's Next Question

Sarah's production Pod is running beautifully. But she realizes something troubling...

Final Knowledge Check

Comprehensive review of Pods, Containers, and Scheduling