Kubernetes Interview Questions on Rolling Updates

The default rollout strategy for a Kubernetes Deployment is RollingUpdate. It replaces old Pods with new ones gradually, so the application stays available during the update. Recreate must be set explicitly in spec.strategy.type if you want all old Pods stopped before new ones start.

By default, a rolling update allows at most 25 of the Deployment's Pods to be unavailable at any time during the rollout. (Express your answer as a percentage without the % sign.)

kubectl rollout undo deployment/web-app

True, the default deployment strategy in Kubernetes is RollingUpdate. If a Deployment does not set .spec.strategy.type, Kubernetes applies RollingUpdate with maxSurge and maxUnavailable both at 25%, replacing pods gradually rather than all at once.

maxSurge controls the maximum number (or percentage) of extra pods that can be created above the desired replica count during the update, while maxUnavailable controls the maximum number (or percentage) of pods that can be unavailable below the desired count at any point during the update.

The maximum is 5. maxSurge sets how many pods can be created above the desired replica count, so the ceiling is 4 + 1 = 5. maxUnavailable only limits how many old pods can be taken down at once; it does not raise the total pod ceiling above desired replicas plus maxSurge.

By default, the Kubernetes Deployment RollingUpdate strategy sets maxSurge to 25% and maxUnavailable to 25% of the desired number of replicas.

True. With maxUnavailable: 0 and maxSurge of at least 1, a Deployment's rolling update never drops Ready pods below the desired replica count. The controller starts a new pod, waits for it to pass its readiness check, and only then terminates an old one. External failures such as node crashes are outside this guarantee.

maxSurge defaults to 25% and maxUnavailable defaults to 25%. Both are percentages of the desired replica count, so the update can temporarily run up to 25% extra pods while letting up to 25% of the desired pods be unavailable.

On a template change, the Deployment creates a new ReplicaSet and shifts replicas gradually: it scales the new ReplicaSet up and the old one down a few Pods at a time, bounded by maxSurge (extra Pods allowed above desired) and maxUnavailable (how many can be missing). A new Pod only counts as available — and the old one is only removed — once it passes its readiness probe, so traffic is shifted to Pods that can actually serve. If the readiness probe is missing or wrong, Kubernetes routes traffic to not-yet-ready Pods and you get errors during the rollout, defeating the zero-downtime goal.

A readiness probe configured on the container spec prevents traffic from reaching a Pod before it is ready. The Pod must pass its readiness probe before the endpoints controller (EndpointSlice controller for the Service) adds the Pod's IP to the Service's endpoints, so traffic is only routed to Pods that report themselves ready.

1. Create (or reuse) a ReplicaSet for the new Pod template
2. Scale the new ReplicaSet up by one, within the maxSurge budget
3. Wait for the new Pod to pass its readiness probe and become available
4. Scale the old ReplicaSet down by one
5. Repeat until the new ReplicaSet is at full replicas and the old is at zero

The API server rejects the manifest with a validation error (similar to "may not be 0 when maxSurge is 0"), so the Deployment is not created or updated and no rollout starts. A rolling update must either create a new pod before removing an old one (which needs maxSurge greater than 0) or remove an old pod before creating a new one (which needs maxUnavailable greater than 0). Kubernetes validation requires at least one of these two values to be non-zero, so setting both to 0 is invalid.

The amortized cost per append is Θ(1). When the array grows from capacity c to 2c, the copy cost is c, but c cheap insertions have elapsed since the previous resize. By the accounting method, charging a constant amount per insertion (e.g., 3 coins: one for the write, two saved for the future copy) fully pays for every doubling. Over n appends the total work is O(n), so each individual append is O(1) amortized.

A pod counts as available only after it has been in the Ready condition (readiness probe passing) continuously for at least minReadySeconds seconds. The maxUnavailable budget counts pods that are not available, so a new pod that is Ready but has not yet met minReadySeconds still consumes that budget. The controller cannot remove more old pods until enough new pods become Available, so a non-zero minReadySeconds slows the rollout by forcing it to wait that duration before each further step.

A Deployment's rolling update is governed by its own maxUnavailable and maxSurge settings, not by a PodDisruptionBudget. The Deployment controller scales ReplicaSets directly and never calls the Eviction API, so a PDB with minAvailable=6 does not limit or block the rollout.

1. RollingUpdate Strategy: maxUnavailable=0, maxSurge=1. With maxUnavailable=0 the controller never terminates an old pod until a new one passes its readiness gate — total serving capacity never drops. maxSurge=1 keeps the blast radius to a single pod: if the new image is broken, only one extra pod is affected, and the rollout pauses when that pod fails readiness. 2. Readiness Probe: gRPC health check (grpc_health_probe or HTTP/2 health check) with initialDelaySeconds=75 (accounting for the ~60s warmup plus margin), periodSeconds=5, failureThreshold=3. The readiness gate ensures the pod is NOT added to the Service's Endpoints until it is genuinely warmed up — no traffic hits a cold pod. 3. Liveness Probe: Same gRPC health check but with initialDelaySeconds=120 (generous margin beyond readiness) and failureThreshold=5. This ensures liveness only kicks in after the pod should be fully operational, avoiding premature restarts during warmup. 4. preStop Lifecycle Hook: Configure a preStop hook that runs a command like sleep 15 (or a custom script that calls grpc.Server.GracefulStop() and waits). This gives the pod time after deregistration from Endpoints but before SIGTERM — allowing the kubelet to remove it from iptables/IPVS rules and the external LB's 5-second health check to mark it unhealthy before the application starts draining. 5. terminationGracePeriodSeconds=120. After the preStop hook completes, SIGTERM is sent to the main container. The gRPC server should trap SIGTERM and call GracefulStop(), which waits for existing streams to finish. 120 seconds provides ample time for streams that may take up to ~60 seconds to complete. 6. PodDisruptionBudget: minAvailable=11 (or maxUnavailable=1). This prevents a kubectl drain or autoscaler from evicting a pod while the rollout is in progress, avoiding the scenario where a voluntary eviction + rollout reduce capacity below safe levels. 7. Blast Radius & Rollback: With maxSurge=1, only one new pod is created at a time. If it fails readiness (failureThreshold×periodSeconds = 15s after the 75s initial delay), the Deployment's Progressing condition stalls and ReplicaSet shows the new pod never becomes ready. Set progressDeadlineSeconds=300 so the Deployment automatically reports a ProgressDeadlineExceeded condition, enabling automated rollback via an Argo Rollouts / Flagger controller or manual kubectl rollout undo. 8. External LB Interaction: The 5-second LB health check interval means up to ~8 seconds of stale endpoints. The preStop hook's 15-second sleep covers this window — by the time SIGTERM is delivered to the app, the LB has already stopped sending new connections. Combined with publishNotReadyAddresses=false (default) on the Service, the pod is removed from Endpoints before the preStop hook even fires, giving the LB time to converge.

The rollout proceeds normally. A Deployment rolling update creates surge pods and removes old pods as new ones become ready, without consulting the PodDisruptionBudget. PDBs only constrain voluntary evictions, such as those from kubectl drain, and the 90-second readiness delay stays well within the default 600-second progress deadline.