Now that you have a Kubernetes cluster up and running, it's time to understand and work with pods and containers. Pods are the smallest deployable units in Kubernetes and the building blocks for all workloads.

Understanding Pods

A pod is a group of one or more containers with shared storage, network resources, and a specification for how to run the containers. Pods are ephemeral by nature—they're not designed to be persistent. When a pod is deleted and replaced, any data not stored in persistent storage is lost.

Containers within a pod:

Share the same network namespace (IP address and port space)
Can communicate with each other using localhost
Can share storage volumes

┌──────────────────────────────────────┐
│                 Pod                  │
│                                      │
│  ┌────────────┐     ┌────────────┐   │
│  │            │     │            │   │
│  │ Container 1│     │ Container 2│   │
│  │            │     │            │   │
│  └────────────┘     └────────────┘   │
│                                      │
│           Shared Volumes             │
│                                      │
└──────────────────────────────────────┘

Creating Your First Pod

Let's create a simple pod running an NGINX web server. Create a file named nginx-pod.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
    - name: nginx
      image: nginx:1.21
      ports:
        - containerPort: 80

This YAML defines:

The API version and kind of resource
Metadata including the pod's name and labels
A specification with one container using the nginx:1.21 image
The container exposes port 80

Apply this configuration to your cluster:

kubectl apply -f nginx-pod.yaml

Viewing and Managing Pods

Check if your pod is running:

kubectl get pods

You should see output like:

NAME        READY   STATUS    RESTARTS   AGE
nginx-pod   1/1     Running   0          42s

For more detailed information:

kubectl describe pod nginx-pod

This command shows pod details including:

Current status and conditions
Container information
Events related to the pod

Accessing Your Pod

There are several ways to access and interact with your pods:

Port Forwarding

Forward a local port to the pod's port:

kubectl port-forward nginx-pod 8080:80

Now you can access NGINX by visiting http://localhost:8080 in your browser.

Shell Access

Execute commands inside a container:

# Run a command
kubectl exec nginx-pod -- ls /usr/share/nginx/html

# Get an interactive shell
kubectl exec -it nginx-pod -- /bin/bash

Viewing Logs

Check the container logs:

kubectl logs nginx-pod

# Follow logs in real-time
kubectl logs -f nginx-pod

Multi-Container Pods

While many pods contain just a single container, there are valid use cases for multiple containers in a pod. Let's create a pod with two containers:

apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod
spec:
  containers:
    - name: web
      image: nginx:1.21
      ports:
        - containerPort: 80
      volumeMounts:
        - name: shared-data
          mountPath: /usr/share/nginx/html

    - name: content-generator
      image: alpine:3.14
      command: ['/bin/sh', '-c']
      args:
        - while true; do
          echo "<h1>The current date is $(date)</h1>" > /data/index.html;
          sleep 10;
          done
      volumeMounts:
        - name: shared-data
          mountPath: /data

  volumes:
    - name: shared-data
      emptyDir: {}

This pod has:

A web container running NGINX
A content generator container that updates the index.html every 10 seconds
A shared volume where both containers can access the same files

Apply the configuration:

kubectl apply -f multi-container-pod.yaml

After the pod is running, you can port-forward and see the content refreshing:

kubectl port-forward multi-container-pod 8080:80

Common patterns for multi-container pods include:

Sidecar: Enhances the main container (like adding logging)
Ambassador: Proxies network traffic to/from the main container
Adapter: Transforms the main container's output

Pod Lifecycle

Pods go through several phases during their lifetime:

Pending: Pod has been accepted but containers aren't running yet
Running: At least one container is running
Succeeded: All containers have terminated successfully
Failed: At least one container has terminated with failure
Unknown: The state of the pod cannot be determined

You can see a pod's phase with:

kubectl get pod nginx-pod -o wide

Container Restart Policies

The restartPolicy field determines what happens when a container exits:

Always (default): Always restart the container
OnFailure: Restart only if the container exits with a non-zero code
Never: Never restart the container

apiVersion: v1
kind: Pod
metadata:
  name: task-pod
spec:
  restartPolicy: OnFailure
  containers:
    - name: task
      image: alpine:3.14
      command: ['sh', '-c', 'echo "Task completed"; exit 0']

Init Containers

Init containers run and complete before app containers start. They're useful for setup tasks:

apiVersion: v1
kind: Pod
metadata:
  name: init-pod
spec:
  initContainers:
    - name: init-service
      image: alpine:3.14
      command: ['sh', '-c', 'until nslookup database; do echo waiting for database; sleep 2; done;']

  containers:
    - name: app
      image: nginx:1.21

In this example, the init container waits for a service named "database" to be resolvable before the main NGINX container starts.

Resource Requests and Limits

Specify resource requirements and limits for containers:

apiVersion: v1
kind: Pod
metadata:
  name: resource-pod
spec:
  containers:
    - name: app
      image: nginx:1.21
      resources:
        requests:
          memory: '64Mi'
          cpu: '250m'
        limits:
          memory: '128Mi'
          cpu: '500m'

This configuration:

Requests 64MiB of memory and 0.25 CPU cores
Limits the container to 128MiB of memory and 0.5 CPU cores

Resource requests help the scheduler place pods on nodes with sufficient resources, while limits prevent containers from using excessive resources.

Environment Variables and ConfigMaps

Pass environment variables to your containers:

apiVersion: v1
kind: Pod
metadata:
  name: env-pod
spec:
  containers:
    - name: app
      image: nginx:1.21
      env:
        - name: ENVIRONMENT
          value: 'production'
        - name: LOG_LEVEL
          value: 'info'

For more complex configuration, use ConfigMaps:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  ENVIRONMENT: 'production'
  LOG_LEVEL: 'info'
  app.properties: |
    property1=value1
    property2=value2
---
apiVersion: v1
kind: Pod
metadata:
  name: configmap-pod
spec:
  containers:
    - name: app
      image: nginx:1.21
      envFrom:
        - configMapRef:
            name: app-config
      volumeMounts:
        - name: config-volume
          mountPath: /config
  volumes:
    - name: config-volume
      configMap:
        name: app-config

Health Checks

Kubernetes supports three types of health checks:

Liveness Probe: Determines if a container is running properly
Readiness Probe: Determines if a container is ready to receive traffic
Startup Probe: Determines when a container has started successfully

apiVersion: v1
kind: Pod
metadata:
  name: healthcheck-pod
spec:
  containers:
    - name: app
      image: nginx:1.21
      ports:
        - containerPort: 80
      livenessProbe:
        httpGet:
          path: /
          port: 80
        initialDelaySeconds: 3
        periodSeconds: 10
      readinessProbe:
        httpGet:
          path: /
          port: 80
        initialDelaySeconds: 5
        periodSeconds: 5

This pod has:

A liveness probe that checks if NGINX responds at the root path
A readiness probe to determine when it can receive traffic

Security Context

Control the security settings for pods and containers:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-pod
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  containers:
    - name: app
      image: nginx:1.21
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL

This configuration:

Runs the pod processes as user ID 1000 and group ID 3000
Sets file permissions for volume mounts with group ID 2000
Prevents privilege escalation
Drops all Linux capabilities

Affinity and Anti-Affinity

Control where pods are scheduled:

apiVersion: v1
kind: Pod
metadata:
  name: affinity-pod
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: disktype
                operator: In
                values:
                  - ssd
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 100
          podAffinityTerm:
            labelSelector:
              matchExpressions:
                - key: app
                  operator: In
                  values:
                    - nginx
            topologyKey: kubernetes.io/hostname
  containers:
    - name: app
      image: nginx:1.21

This pod:

Requires scheduling on nodes with the label disktype=ssd
Prefers to avoid nodes that already have pods with the label app=nginx

Tolerations and Taints

Allow pods to schedule on tainted nodes:

apiVersion: v1
kind: Pod
metadata:
  name: toleration-pod
spec:
  tolerations:
    - key: 'dedicated'
      operator: 'Equal'
      value: 'gpu'
      effect: 'NoSchedule'
  containers:
    - name: app
      image: tensorflow/tensorflow:latest-gpu

This pod can be scheduled on nodes with the taint dedicated=gpu:NoSchedule.

Pod Disruption Budgets

Protect your applications during voluntary disruptions:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: nginx-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: nginx

This PodDisruptionBudget ensures that at least 2 pods with the label app=nginx are available during node maintenance.

Best Practices for Pods

Use controllers instead of raw pods: Direct pod creation is mainly for testing. In production, use Deployments, StatefulSets, or DaemonSets.
Keep pods focused: Follow the single-responsibility principle.
Set resource requests and limits: Always specify what resources your pods need.
Implement health checks: Use probes to help Kubernetes manage your pods.
Use labels and annotations: Labels enable selection, and annotations add useful metadata.
Don't put application state in pods: Use persistent volumes for stateful data.
Set appropriate restart policies: Choose based on your application's needs.
Define pod security contexts: Reduce the attack surface of your applications.

Using DigitalOcean for Running Kubernetes Pods

DigitalOcean Kubernetes provides an optimized platform for running your pods with features like:

Autoscaling node pools
Load balancer integration
Block storage for persistent volumes
Container registry for your images

Sign up with DigitalOcean to get $200 in free credits and start deploying your pods on a production-ready Kubernetes platform.

In the next section, we'll explore Deployments and ReplicaSets, which help you manage multiple pod instances and handle updates gracefully.

Tags