█
LastWrite
  • > Curriculum
  • > Pricing
  • > For Educators
  • > About
  • > Contact
Log InGet Started

Questions, concerns, bug reports, or suggestions? We read every message, write to us at [email protected].

More ways to reach us →
LastWrite

Structured computer science lessons for aspiring developers and security professionals.

[email protected]

(201) 785-7951

Mon–Fri, 9 AM–5 PM EST

Learn

  • Curriculum
  • Pricing

Company

  • About
  • For Educators & Schools
  • Contact Us

Legal

  • Terms of Service
  • Privacy Policy
© 2026 LastWrite. All rights reserved.
Curriculum/DevOps and Infrastructure/Kubernetes/Deployments in Depth
50 minIntermediate

Deployments in Depth

After this lesson, you will be able to: Configure rolling updates, rollback, and resource requests / limits on Deployments.

Deployments are how you ship K8s changes safely. Master rolling strategy + resource limits and zero-downtime deploys become the default.

Prerequisites:kubectl

Rolling update strategy in YAML

The default strategy is rolling; you control the speed.

sql
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 10
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1 # never have more than 1 Pod down at once
maxSurge: 2 # up to 2 extra Pods during rollout (12 briefly)
selector:
matchLabels: { app: myapp }
template:
metadata: { labels: { app: myapp } }
spec:
containers:
- name: web
image: myapp:1.2.0
readinessProbe:
httpGet: { path: /ready, port: 3000 }
initialDelaySeconds: 5
periodSeconds: 5
livenessProbe:
httpGet: { path: /healthz, port: 3000 }
initialDelaySeconds: 15
periodSeconds: 10

Readiness vs liveness probes (the most-confused pair)

Readiness probe: 'is this Pod ready to serve traffic?' If it fails, the Pod is removed from the Service's load balancer but NOT restarted. Use for: 'still warming up'. Liveness probe: 'is this Pod healthy? Should K8s kill and restart it?' If it fails, K8s kills the Pod. Use for: 'definitely broken, restart me'. Both probes are critical for rolling deploys. Without readiness, K8s sends traffic to a Pod that's still starting; users see 502s.

Rollouts, rollbacks, history

kubectl commands for the deploy lifecycle.

tsx
# Watch a rollout in progress
kubectl rollout status deployment/myapp
# History (each deploy = one revision)
kubectl rollout history deployment/myapp
# Rollback to previous
kubectl rollout undo deployment/myapp
# Rollback to a specific revision
kubectl rollout undo deployment/myapp --to-revision=3
# Pause a rollout mid-deploy (e.g. to investigate)
kubectl rollout pause deployment/myapp
kubectl rollout resume deployment/myapp
# Force a fresh rollout without changing the image
kubectl rollout restart deployment/myapp

Resource requests and limits

Request: the minimum CPU/memory the Pod is guaranteed. K8s won't schedule it unless a node has this much free. Limit: the maximum the Pod can use. Exceed the memory limit → OOMKilled. Exceed CPU limit → throttled. Always set requests + limits. Without them, K8s schedules poorly and one rogue Pod can starve neighbors. Sizing: start by measuring (run for a few days; check kubectl top); set request = p95 usage, limit = 2-3x request.

💡 Why your rolling deploy sometimes drops requests

Without `readinessProbe`, K8s declares a Pod ready as soon as the container starts, before the app can accept traffic. Users hit 502s during deploy. Without proper `terminationGracePeriodSeconds` + a SIGTERM handler in the app, K8s kills Pods mid-request. Users see dropped connections. Production-grade rollout: probes + graceful shutdown (handle SIGTERM, drain in-flight, then exit) + maxUnavailable: 0.

Common mistakes only experienced engineers avoid

No readiness probe → 502s on every deploy. Same endpoint for readiness + liveness. Liveness should be cheap (no DB hits); readiness can be deeper. No resource requests → noisy-neighbor problems and unpredictable scheduling. Memory limit set lower than actual peak → random OOM kills. Forgetting `--record` on imperative changes; rollout history loses context.

Quick Check

Your rollout completes but users see intermittent 502s for 30 seconds. What's the most likely cause?

Pick the canonical bug.

Sign in and purchase access to unlock this lesson.

Sign in to purchase
←kubectl
Back to Kubernetes
Services and Networking→