Deployments

Introduction

Deployments is a practical Kubernetes capability, not just a definition to memorize. This lesson explains the problem it solves, why teams use it in production, how it behaves under failure, and how to practice it hands-on.

Purpose of this lesson

By the end, you should be able to decide when Deployments belongs in a design, implement it with a clear manifest or command flow, and troubleshoot the most common failure modes using Kubernetes status, events, logs, metrics, and ownership relationships.

Understanding the topic

Deployments manage ReplicaSets and rollouts. They support rolling updates, rollback, revision history, and declarative application updates.

Use Deployments for stateless services that can run multiple interchangeable replicas. They are the default production abstraction for APIs, web apps, workers, and internal services.

• Read every object through metadata, spec, and status: who owns it, what should happen, and what the cluster reports actually happened.
• Connect YAML to the responsible component: scheduler, kubelet, controller manager, cloud controller, CSI driver, CNI, CoreDNS, admission webhook, or application runtime.
• Use it only when it improves a real operating concern such as availability, rollout safety, service discovery, isolation, security, cost, or developer workflow.

Visual explanation

Use this mental model when explaining the lesson during design reviews or incidents:

Deployment
  -> ReplicaSet revision 3
      -> Pods running image v3
  -> ReplicaSet revision 2
      -> scaled down but available for rollback

Step-by-step explanation

1. Identify the workload or platform problem first: availability, traffic routing, storage, configuration, identity, policy, scaling, observability, or troubleshooting.
2. Write the smallest useful desired state for Deployments; include labels, namespace, ownership, resource settings, and health checks where relevant.
3. Apply or render the change in a safe environment, then read status and events before assuming the manifest worked.
4. Break one realistic dependency such as a selector, image tag, probe, permission, quota, or endpoint and practice the recovery path.
5. Promote through Git or your release process with a rollback plan, alert coverage, and a short runbook.

Informative example

Deployment manifest: After applying it, verify both desired and observed state. A production-ready workflow should include kubectl diff, apply, describe, get events, and a rollout or health check when the object supports it.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  labels:
    app: web
    app.kubernetes.io/name: web
spec:
  revisionHistoryLimit: 3
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: app
          image: nginx:1.27-alpine
          ports:
            - name: http
              containerPort: 80
          readinessProbe:
            httpGet:
              path: /
              port: http
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /
              port: http
            initialDelaySeconds: 20
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              memory: 256Mi

Real-world use

A team deploys a new checkout API with maxUnavailable: 0, readiness checks, and automatic rollback criteria. Traffic only reaches new pods after they prove they can serve real dependencies.

Best practices

• Keep manifests reviewed in Git and treat manual cluster changes as temporary break-glass actions.
• Use standard labels such as app.kubernetes.io/name, part-of, and managed-by so selectors, dashboards, alerts, and cost reports line up.
• Attach ownership, environment, and runbook metadata before resources reach production.

Common mistakes

• Confusing resource exists with resource is healthy. Always inspect status, events, and downstream dependencies.
• Changing selectors, labels, or names casually; these are contracts between controllers, Services, policies, dashboards, and GitOps tools.
• Debugging from memory instead of reading the object: kubectl describe, events, endpoints, and controller logs usually tell the story.

Debugging tips

• A rollout can be stuck because new pods are Pending, failing probes, blocked by quota, or unable to pull images.
• Check kubectl rollout status, Deployment conditions, ReplicaSet events, and pod readiness before changing strategy values.
• If old pods disappear too early, review maxUnavailable, PodDisruptionBudgets, and readiness accuracy.

Optimization strategies

• Tune requests, limits, probes, and rollout settings from observed production behavior instead of copying defaults.
• Reduce blast radius with namespaces, quotas, PodDisruptionBudgets, topology spread, and progressive delivery.
• Automate validation with CI, policy checks, and GitOps drift detection so correctness is enforced before outages.

Advanced interview questions

Hands-on exercise

Deploy two versions of an app, watch rollout history, trigger a bad image, pause the rollout, inspect events, then undo to the previous revision.

# Suggested lab loop for Deployments
kubectl create namespace deployments-lab
kubectl -n deployments-lab apply -f lesson.yaml
kubectl -n deployments-lab get all
kubectl -n deployments-lab describe all
kubectl -n deployments-lab get events --sort-by=.lastTimestamp

Summary

Deployments becomes valuable when you connect the API object or command to real operational behavior. Practice the happy path, then deliberately break it so troubleshooting becomes evidence-driven rather than guesswork.