Deploying a production‑grade web service requires multiple concurrent instances and a controlled upgrade path. Rolling updates let you replace pods incrementally, preserving availability, while the rollback feature restores the previous revision if a new version introduces errors. The pause/resume mechanism lets you stage several changes—such as image upgrades, replica count adjustments, or resource limit modifications—and apply them as a single rollout.

Kubernetes implements these capabilities through the Deployment object, which sits above ReplicaSets in the resource hierarchy. A Deployment owns a ReplicaSet, which in turn creates Pods. Unlike a plain ReplicaSet, a Deployment tracks rollout history, supports declarative updates, and exposes commands for pause, resume, and rollback.

Deployment manifest structure

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
  labels:
    app: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web
        image: registry.example.com/web:1.0
        resources:
          limits:
            cpu: "500m"
            memory: "256Mi"

• apiVersion must be apps/v1.
• kind is Deployment, not ReplicaSet.
• spec.replicas defines the desired pod count.
• spec.selector must match the labels in spec.template.metadata.labels.
• spec.template contains the full Pod spec, including containers and resource requests.

Creating and inspecting the Deployment

1
2
3
4
5

kubectl apply -f deployment.yaml
kubectl get deployments
kubectl get replicaset
kubectl get pods
kubectl get all

kubectl apply creates the Deployment, which immediately creates a ReplicaSet and the corresponding Pods. kubectl get all lists every object in the current namespace, confirming the hierarchy: Deployment → ReplicaSet → Pods.

Managing rollouts

• Rolling update – modify the image tag or other fields in the manifest and re‑apply; the Deployment updates the underlying ReplicaSet incrementally, respecting the default maxSurge and maxUnavailable values (25 % of replicas each).
• Rollback – execute kubectl rollout undo deployment/web-server to revert to the previous revision.
• Pause/Resume – kubectl rollout pause deployment/web-server halts the rollout, allowing multiple edits before kubectl rollout resume deployment/web-server triggers a single combined update.

Corrected misconceptions

• Pods can host multiple containers, not only a single instance of an application.
• The command-line client is kubectl, not “kube control”.
• ReplicationControllers are legacy; current practice uses ReplicaSets and Deployments.
• A Deployment creates a new ReplicaSet each time its pod template changes, preserving previous ReplicaSets for rollback.
• Rolling updates do not automatically guarantee zero‑downtime; appropriate maxSurge/maxUnavailable settings and readiness probes are required to avoid service disruption.