Deployments
A Deployment manages a ReplicaSet, which manages Pods. You declare the desired state (image, replicas, strategy); the controller makes it happen. Updates roll forward; failed deploys can roll back.
Deployment, rolling update, rollback
EXAMPLE
# 1) Minimal Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
labels: { app: web }
spec:
replicas: 3
selector:
matchLabels: { app: web }
template:
metadata:
labels: { app: web }
spec:
containers:
- name: web
image: myapp:1.4.2
ports: [{ containerPort: 3000 }]
env:
- name: NODE_ENV
value: production
resources:
requests: { cpu: 100m, memory: 128Mi }
limits: { cpu: 500m, memory: 512Mi }
readinessProbe:
httpGet: { path: /health, port: 3000 }
periodSeconds: 5
livenessProbe:
httpGet: { path: /health, port: 3000 }
initialDelaySeconds: 30
periodSeconds: 30
# 2) Rolling update — zero-downtime by default
spec:
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 0 # never lose capacity
maxSurge: 1 # one extra pod during the roll
# 3) Recreate strategy — for stateful apps that can't run both versions
spec:
strategy:
type: Recreate
# 4) Apply + watch
kubectl apply -f web.yaml
kubectl rollout status deployment/web --timeout=120s
kubectl get deployments,replicasets,pods
# 5) Update the image — declarative or imperative
kubectl set image deployment/web web=myapp:1.4.3
# OR change the YAML and re-apply
# Rollout begins automatically.
# 6) Rollback if something broke
kubectl rollout history deployment/web
kubectl rollout undo deployment/web # back one revision
kubectl rollout undo deployment/web --to-revision=3
kubectl rollout pause deployment/web # freeze mid-rollout
kubectl rollout resume deployment/web
# 7) Scale
kubectl scale deployment/web --replicas=10
# 8) Pair with a HorizontalPodAutoscaler
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata: { name: web-hpa }
spec:
scaleTargetRef: { apiVersion: apps/v1, kind: Deployment, name: web }
minReplicas: 3
maxReplicas: 50
metrics:
- type: Resource
resource: { name: cpu, target: { type: Utilization, averageUtilization: 70 } }
# 9) Disruption budget — protect availability during node drains
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata: { name: web-pdb }
spec:
minAvailable: 2
selector: { matchLabels: { app: web } }
# 10) Best practices
# • Set requests + limits — predictable scheduling + OOM safety
# • Readiness probe gates traffic; liveness restarts hung pods
# • Image tag → SHA digest in prod for immutable rollouts
# • Pair PDB with HPA so autoscale-down doesn't violate availability
Why it matters
Set maxUnavailable: 0 for traffic-serving services — the new replica must be ready before old ones get evicted. Combine with a real readiness probe and rollouts become invisible to users.
Tip: Tweak the snippet with Try it Yourself », then sit the quiz at the bottom of the page.
Example
Example
apiVersion: apps/v1
kind: Deployment
metadata: { name: api }
spec:
replicas: 3
selector: { matchLabels: { app: api } }
template:
metadata: { labels: { app: api } }
spec: { containers: [{ name: api, image: api:1.0 }] }
Try it Yourself »
Exercise
Apply a YAML manifest.
kubectl
-f deployment.yaml
Five letters.
Discussion
Loading…