Home/Learn/Kubernetes/Pods, Deployments & ReplicaSets

Pods, Deployments & ReplicaSets

Beginner

Workloads

A Pod is the smallest deployable unit in Kubernetes. A Deployment manages a set of identical Pods via a ReplicaSet, handling rolling updates, rollbacks, and self-healing.

Overview

You almost never create Pods directly in production — you create Deployments. A Deployment declares the desired state (image, replicas, update strategy) and Kubernetes makes it happen. Internally, a Deployment manages a ReplicaSet, which manages the actual Pod replicas. When you update the Deployment (new image), Kubernetes creates a new ReplicaSet and gradually migrates traffic from old pods to new ones — this is a rolling update. Old ReplicaSets are kept for rollback. Pods themselves are ephemeral — if one crashes, the ReplicaSet creates a replacement.

Pod — The Atomic Unit

A Pod is one or more tightly-coupled containers sharing a network namespace (same IP) and storage volumes. Containers in a Pod communicate via localhost.

pod.yaml — Pod manifest

# pod.yaml — you rarely create pods directly, but good to understand

apiVersion: v1

kind: Pod

metadata:

  name: my-app

  labels:

    app: my-app

    version: v1.2.3

spec:

  containers:

    - name: app

      image: myregistry/my-app:v1.2.3

      ports:

        - containerPort: 8080

      env:

        - name: LOG_LEVEL

          value: "info"

      resources:

        requests:             # guaranteed minimum (scheduler uses this)

          memory: "128Mi"

          cpu: "250m"         # 250 millicores = 0.25 CPU

        limits:               # hard maximum (OOM kill / CPU throttle)

          memory: "512Mi"

          cpu: "1000m"        # 1000m = 1 full CPU core

      readinessProbe:

        httpGet:

          path: /health

          port: 8080

        initialDelaySeconds: 5

        periodSeconds: 10

      livenessProbe:

        httpGet:

          path: /health

          port: 8080

        initialDelaySeconds: 15

        failureThreshold: 3



# kubectl apply -f pod.yaml

# kubectl get pods

# kubectl describe pod my-app

# kubectl delete pod my-app

Deployment — Managing Pod Replicas

A Deployment wraps a Pod template with a replica count and update strategy. It is the standard way to run stateless applications in Kubernetes.

deployment.yaml — Deployment manifest

# deployment.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

  name: my-app

  namespace: production

spec:

  replicas: 3                      # run 3 identical pods

  selector:

    matchLabels:

      app: my-app                  # manage pods with this label



  strategy:

    type: RollingUpdate

    rollingUpdate:

      maxSurge: 1                  # create 1 extra pod before killing old

      maxUnavailable: 0            # never go below 3 pods during update



  template:                        # pod template

    metadata:

      labels:

        app: my-app                # must match selector.matchLabels

    spec:

      containers:

        - name: app

          image: myregistry/my-app:v1.2.3

          ports:

            - containerPort: 8080

          resources:

            requests: { memory: "128Mi", cpu: "250m" }

            limits:   { memory: "512Mi", cpu: "1" }

          readinessProbe:

            httpGet: { path: /health, port: 8080 }

            initialDelaySeconds: 5



# Rolling update: change the image

kubectl set image deployment/my-app app=myregistry/my-app:v1.2.4



# Or edit the YAML and re-apply

# kubectl apply -f deployment.yaml



# Watch rollout progress

kubectl rollout status deployment/my-app

# Waiting for deployment "my-app" rollout to finish: 1 out of 3 new replicas updated...

# deployment "my-app" successfully rolled out

Rollout & Rollback

Kubernetes keeps rollout history. Rolling back is instant — it just scales up the previous ReplicaSet and scales down the current one.

bash — rollout, rollback, scale commands

# View rollout history

kubectl rollout history deployment/my-app

# REVISION  CHANGE-CAUSE

# 1         <none>

# 2         Update to v1.2.4

# 3         Update to v1.2.5



# Rollback to previous version

kubectl rollout undo deployment/my-app

# deployment.apps/my-app rolled back



# Rollback to specific revision

kubectl rollout undo deployment/my-app --to-revision=2



# Pause a rolling update (canary inspection window)

kubectl rollout pause deployment/my-app

# ... inspect pods ...

kubectl rollout resume deployment/my-app



# Deployment â†’ ReplicaSet relationship

kubectl get rs                           # see all ReplicaSets

# NAME                DESIRED  CURRENT  READY

# my-app-6d8f9b7c44   3        3        3    â† current

# my-app-5f7c8d9a11   0        0        0    â† previous (kept for rollback)



# Scale manually

kubectl scale deployment/my-app --replicas=5



# Restart all pods (rolling restart without changing the image)

kubectl rollout restart deployment/my-app

Key Points to Remember

1Pod is the smallest K8s unit — one or more containers sharing a network namespace.
2Never create bare Pods in production — use Deployments so K8s can self-heal them.
3Deployment â†’ ReplicaSet â†’ Pods: Deployment manages update strategy; ReplicaSet manages replica count.
4resource.requests: what the pod is guaranteed; resource.limits: the hard cap.
5RollingUpdate with maxUnavailable: 0 ensures zero downtime — K8s creates new pods before killing old.
6Rollback is instant and free — K8s keeps old ReplicaSets and just shifts the replica count.

Interview Questions

What is the relationship between a Deployment, ReplicaSet, and Pod?

What happens when a Pod crashes in Kubernetes?

Ask Aria about Pods, Deployments & ReplicaSets

Your personal AI tutor — ask anything about this concept

Revision Status

Personal Notes

Discussion

Loading discussion…

What is Kubernetes & Why Orchestration?

Services & Networking