Pods & Deployments

Understanding Pods

A pod is the smallest deployable unit — one or more containers sharing network and storage. Most pods run a single container. Multi-container pods share localhost and volumes for sidecar patterns.

Pods are ephemeral — they are created, run, and destroyed. Never manage pods directly in production. Use controllers (Deployments, StatefulSets) that create and manage pods for you.

• Pods get a unique IP within the cluster — it changes on restart
• Containers in a pod share the same network namespace
• Use labels for selection — app, version, tier are common keys

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

Writing YAML Manifests

Kubernetes manifests have four top-level fields: apiVersion, kind, metadata, and spec. apiVersion identifies the API group and version. kind specifies the resource type. Metadata holds name, labels, and annotations. Spec defines desired state.

Store manifests in git for version control and reproducibility. Use kustomize or Helm for environment-specific overrides.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  labels:
    app: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: myapp:1.0.0
          ports:
            - containerPort: 3000

Deployments

Deployments manage ReplicaSets which manage pods. Declare desired replicas and the deployment controller maintains that count. Deployments support rolling updates, rollbacks, and pause/resume.

Update an image with kubectl set image or by editing the manifest and applying. Kubernetes gradually replaces old pods with new ones during rolling updates.

kubectl apply -f deployment.yaml
kubectl get deployments
kubectl scale deployment web-app --replicas=5
kubectl set image deployment/web-app web=myapp:2.0.0
kubectl rollout status deployment/web-app
kubectl rollout undo deployment/web-app

Replica Management

ReplicaSets ensure a specified number of pod replicas are running. Deployments wrap ReplicaSets with update strategies. If a pod dies, the ReplicaSet creates a replacement automatically.

Use pod disruption budgets to prevent too many pods from being evicted during node maintenance. Anti-affinity rules spread replicas across nodes for high availability.

spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

Labels and Selectors

Labels are key-value pairs attached to resources for identification and selection. Selectors filter resources by labels — deployments use matchLabels to find their pods, services use selectors to route traffic.

Use consistent label conventions: app (application name), version (release version), and component (frontend, api, database). Recommended labels are defined in Kubernetes documentation.

metadata:
  labels:
    app: web
    version: v2
    component: frontend

# Select pods with label
kubectl get pods -l app=web
kubectl get pods -l 'app=web,version=v2'