Deployments

Understand Kubernetes Deployments for stateless applications, rolling updates, replica management, rollout status, and rollback.

Last reviewed: June 2026

·Kubernetes 1.28+kubectl 1.28+Helm 3+Managed Kubernetes: EKS, AKS, GKE
✅
Quick Understanding: A Deployment manages stateless Pods through ReplicaSets. It is the default object for rolling out scalable application services safely.

🔍 What Is It?

A Deployment is a higher-level Kubernetes controller for stateless workloads.

It manages ReplicaSets, desired replicas, Pod templates, rolling updates, rollout history, and rollback behavior.

🎯 Why Do We Need It?

Teams need a safe way to run multiple copies of an application and update them without downtime.

Deployments provide declarative rollout control and self-healing for common web APIs and services.

Common developer mistakes:

  • →Treating Kubernetes YAML as copy-paste configuration instead of production architecture
  • →Ignoring requests, limits, health probes, security context, and rollout behavior
  • →Debugging only the Pod while forgetting Services, DNS, NetworkPolicies, nodes, and admission controls
  • →Manually changing live objects without updating Git or infrastructure automation

🏗️ What Happens in Real Projects?

An enterprise API team deploys a container image through a Deployment with four replicas, readiness probes, resource requests, and rolling update settings. CI updates the image tag through GitOps. Prometheus and CloudWatch observe rollout health.

If error rate rises, the team rolls back to the previous ReplicaSet.

⚙️ How It Works

A Deployment owns ReplicaSets. When the Pod template changes, the Deployment creates a new ReplicaSet and gradually shifts replicas from old to new according to the rollout strategy.

Readiness probes determine when new Pods are safe to receive traffic.

💻 Example

Deployment manifest — A stateless API Deployment with rolling update controls.

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders-api
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  selector:
    matchLabels:
      app: orders-api
  template:
    metadata:
      labels:
        app: orders-api
    spec:
      containers:
        - name: api
          image: registry.company.com/orders-api:1.24.0
          ports:
            - containerPort: 8080

🤔 Common Confusions

❓ Are Deployments for databases?

Usually no. Use StatefulSets or managed databases for stateful workloads needing stable identity and storage.

❓ Does Deployment rollback restore database schema?

No. Deployment rollback only changes workload template. Data migrations require separate strategy.

❓ Do Deployments create Services?

No. Services are separate objects that select Pods by labels.

🚨 Common Production Issues

**No readiness probe** causes bad rollouts because Kubernetes thinks Pods are ready too early.

**Bad rollout settings** take down too many replicas at once.

**Image tag reuse** makes rollback unclear.

**Schema migration mismatch** breaks old or new app versions during rollout.

✅ Best Practices

Use Deployments for stateless services

Set readiness probes and resource requests

Use immutable image tags or digests

Tune maxSurge and maxUnavailable for availability needs

Use PodDisruptionBudgets for important services

Separate database migrations from app rollout strategy

🏛️ Architect's Note

Senior Architect's Perspective

Deployments make application change safer, but only if the app exposes truthful readiness and remains compatible during mixed-version rollout windows.

💬 Frequently Asked Questions

Interview: How would you explain Deployments in a real Kubernetes project?

Deployments should be explained through the workload it supports, the Kubernetes object relationships, the failure modes, the security controls, and how it is observed and rolled back in production.

Interview: What production mistake do developers commonly make with Deployments?

The common mistake is making the object work once, then skipping ownership, resource sizing, rollout safety, monitoring, least privilege, and recovery behavior.

How do I check rollout status?

Use kubectl rollout status deployment/<name> and inspect events, ReplicaSets, and Pod readiness.

How do I rollback a Deployment?

Use kubectl rollout undo deployment/<name>, assuming revision history is available and the previous image still exists.

🎯 Key Takeaways

1Deployments manage stateless workloads
2They create and manage ReplicaSets
3Rolling updates depend on readiness and strategy settings
4Rollback is workload-level, not database-level

🎯 Practice this topic in interviews

↗ Where this topic fits

Sources

Sources / References

Use these Kubernetes references to verify the concept in official docs and continue into the most relevant SplashRide pages.

Related SplashRide pages