Kubernetes Deployment Reading
RollingUpdate, readinessProbe, imagePullPolicy, initContainers, PodDisruptionBudget — deep reading of K8s Deployments
Kubernetes Deployment vocabulary
- RollingUpdate: maxSurge/maxUnavailable — controls how many extra/missing Pods are allowed during rollout
- readinessProbe — gates traffic; Pod only receives requests after probe passes; failure removes from Service endpoints
- imagePullPolicy: Always — pulls on every start (needed for :latest); IfNotPresent — uses cached image
- initContainers — sequential setup containers (wait-for, migrations) that must complete before main container starts
- PodDisruptionBudget — enforces minimum availability during voluntary disruptions (node drains, upgrades)
Question 0 of 5
Read this Kubernetes Deployment strategy. What does RollingUpdate mean?spec:
replicas: 4
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
- RollingUpdate — the default strategy; gradually replaces old Pods with new ones
- maxSurge: 1 — allows up to 1 extra Pod above the desired count during the update (so up to 5 total here)
- maxUnavailable: 1 — at most 1 Pod can be unavailable at any time (so at least 3 serving traffic)
- Recreate strategy — alternative: kills all old Pods before creating new ones (causes downtime but is simpler)
Read this readinessProbe configuration. When does Kubernetes start sending traffic to the Pod?containers:
- name: api
image: myapp:latest
readinessProbe:
httpGet:
path: /ready
port: 3000
initialDelaySeconds: 10
periodSeconds: 5
successThreshold: 1
failureThreshold: 3
- readinessProbe — controls whether a Pod receives traffic from Services; failing = removed from endpoints
- livenessProbe — controls whether a Pod is restarted; failing = container killed and restarted
- startupProbe — used for slow-starting apps; disables liveness/readiness until it passes
- httpGet — makes an HTTP request; 2xx/3xx = success, other = failure
- successThreshold: 1 — 1 success is enough to mark ready (default)
- failureThreshold: 3 — 3 consecutive failures before marking not-ready
What does imagePullPolicy: Always mean for a Kubernetes container?containers:
- name: api
image: myapp:latest
imagePullPolicy: Always
# vs.
- name: cache
image: redis:7.2.4
imagePullPolicy: IfNotPresent
- Always — always contacts the registry; required when using mutable tags like
:latestto ensure you get the newest image - IfNotPresent — uses the cached image on the node if it exists; only pulls if not found; efficient for stable versioned tags like
redis:7.2.4 - Never — never pulls; assumes the image is already on the node (used in air-gapped environments)
- Default behaviour — if tag is
:latestor omitted, defaults toAlways; otherwise defaults toIfNotPresent
:latest) in production to ensure reproducible deployments.Read this Kubernetes Pod spec with initContainers. What is their purpose?spec:
initContainers:
- name: wait-for-db
image: busybox
command: ['sh', '-c', 'until nc -z db 5432; do sleep 2; done']
- name: run-migrations
image: myapp:latest
command: ['npm', 'run', 'migrate']
containers:
- name: api
image: myapp:latest
- initContainers — run to completion (exit 0) before any regular containers start; if one fails, the Pod restarts
- Sequential execution — init containers run one at a time in order; each must succeed before the next starts
- Common use cases — wait for dependencies (databases, message queues), run migrations, fetch secrets, set up configs
- vs. regular containers — init containers have no readiness probes; they just need to exit 0
A colleague mentions a PodDisruptionBudget. Read this example — what does it protect against?apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: api-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: api-server
- Voluntary disruption — planned events: node drain (
kubectl drain), cluster upgrade, node scaling; these respect PDBs - Involuntary disruption — hardware failure, OOMKill; PDBs do NOT protect against these
- minAvailable: 2 — Kubernetes will not voluntarily evict a Pod if doing so would leave fewer than 2 available Pods
- maxUnavailable: 1 — alternative spec; at most 1 Pod can be unavailable at once