Working with Pods

Pods are the smallest deployable units in Kubernetes. Let’s explore what they are and how to work with them.

What is a Pod?

A Pod represents a single instance of a running process in your cluster. Pods contain one or more containers that share:

• Network namespace (IP address and ports)
• Storage volumes
• Configuration

Pod Lifecycle

Pods go through several phases:

• Pending - Pod accepted but containers not yet created
• Running - At least one container is running
• Succeeded - All containers terminated successfully
• Failed - All containers terminated, at least one failed
• Unknown - Pod state cannot be determined

Creating Your First Pod

Create a simple Pod using kubectl:

kubectl run nginx --image=nginx:latest

View the Pod:

kubectl get pods
kubectl get pods -o wide

Pod YAML Definition

Here’s a complete Pod definition:

apiVersion: v1
kind: Pod
metadata:
  name: my-app
  labels:
    app: my-app
    environment: development
spec:
  containers:
  - name: app-container
    image: nginx:1.21
    ports:
    - containerPort: 80
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
    env:
    - name: ENVIRONMENT
      value: "development"

Apply the Pod:

kubectl apply -f pod.yaml

Multi-Container Pods

Pods can run multiple containers that work together:

apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod
spec:
  containers:
  - name: app
    image: myapp:1.0
    ports:
    - containerPort: 8080
  - name: sidecar
    image: logger:1.0
    volumeMounts:
    - name: logs
      mountPath: /var/log
  volumes:
  - name: logs
    emptyDir: {}

Common Sidecar Patterns

• Logging - Collect and ship logs
• Monitoring - Export metrics
• Proxy - Handle network traffic
• Adapter - Transform data format

Inspecting Pods

Get detailed information:

# Describe a Pod
kubectl describe pod my-app

# View logs
kubectl logs my-app

# View logs from specific container
kubectl logs my-app -c app-container

# Follow logs
kubectl logs -f my-app

# Execute commands in Pod
kubectl exec my-app -- ls /
kubectl exec -it my-app -- /bin/bash

Pod Networking

Each Pod gets its own IP address:

# Get Pod IP
kubectl get pod my-app -o jsonpath='{.status.podIP}'

# Test connectivity
kubectl run test --image=busybox -it --rm -- wget -O- http://POD_IP

Resource Management

Set resource requests and limits:

• Requests - Guaranteed resources
• Limits - Maximum resources allowed

resources:
  requests:
    memory: "64Mi"
    cpu: "250m"
  limits:
    memory: "128Mi"
    cpu: "500m"

Health Checks

Liveness Probe

Checks if container is alive:

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 3
  periodSeconds: 3

Readiness Probe

Checks if container is ready to serve traffic:

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5

Startup Probe

For slow-starting containers:

startupProbe:
  httpGet:
    path: /startup
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

Pod Management

Common operations:

# Delete a Pod
kubectl delete pod my-app

# Delete all Pods with label
kubectl delete pods -l app=my-app

# Force delete
kubectl delete pod my-app --grace-period=0 --force

# Port forward to Pod
kubectl port-forward my-app 8080:80

Best Practices

1. One process per container - Keep containers focused
2. Use health checks - Enable automatic recovery
3. Set resource limits - Prevent resource exhaustion
4. Use labels - Organize and query Pods
5. Avoid privileged containers - Minimize security risks
6. Use specific image tags - Avoid latest in production

Troubleshooting

Common issues and solutions:

# Pod stuck in Pending
kubectl describe pod my-app  # Check events

# Pod keeps restarting
kubectl logs my-app --previous  # View previous logs

# CrashLoopBackOff
kubectl describe pod my-app  # Check restart count and reason

# ImagePullBackOff
kubectl describe pod my-app  # Check image name and pull secrets

Next Steps

While Pods are fundamental, they’re rarely created directly in production. Next, we’ll explore Deployments - the recommended way to manage Pods.