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.
The default strategy is rolling; you control the speed.
apiVersion: apps/v1kind: Deploymentmetadata:name: myappspec:replicas: 10strategy:type: RollingUpdaterollingUpdate:maxUnavailable: 1 # never have more than 1 Pod down at oncemaxSurge: 2 # up to 2 extra Pods during rollout (12 briefly)selector:matchLabels: { app: myapp }template:metadata: { labels: { app: myapp } }spec:containers:- name: webimage: myapp:1.2.0readinessProbe:httpGet: { path: /ready, port: 3000 }initialDelaySeconds: 5periodSeconds: 5livenessProbe:httpGet: { path: /healthz, port: 3000 }initialDelaySeconds: 15periodSeconds: 10
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.
kubectl commands for the deploy lifecycle.
# Watch a rollout in progresskubectl rollout status deployment/myapp# History (each deploy = one revision)kubectl rollout history deployment/myapp# Rollback to previouskubectl rollout undo deployment/myapp# Rollback to a specific revisionkubectl rollout undo deployment/myapp --to-revision=3# Pause a rollout mid-deploy (e.g. to investigate)kubectl rollout pause deployment/myappkubectl rollout resume deployment/myapp# Force a fresh rollout without changing the imagekubectl rollout restart deployment/myapp
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.
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.
Pick the canonical bug.
Sign in and purchase access to unlock this lesson.