What is the difference between RollingUpdate and Recreate deployment strategies?
RollingUpdate replaces Pods gradually so the app stays available. Recreate kills all old Pods first and then starts new ones, causing downtime but guaranteeing two versions never run together.
Explain it simply
Changing a train's coaches. Rolling update swaps one coach at a time while the train keeps running. Recreate stops the train, swaps every coach, and restarts it.
RollingUpdate is the default. It is controlled by maxSurge (how many extra Pods may exist above desired) and maxUnavailable (how many may be missing during the update). With 4 replicas, surge 1 and unavailable 0, Kubernetes starts one new Pod, waits for it to be ready, then stops one old Pod, repeating until done. Users see no downtime, but for a while both versions serve traffic, so they must be compatible, including database schema.
Recreate is used when two versions cannot coexist, for example a breaking schema change or an app that holds an exclusive lock, and short downtime is acceptable.
Example
spec:
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
# or
# type: RecreateWhat to say in the interview
"RollingUpdate replaces Pods gradually, governed by maxSurge and maxUnavailable, for zero downtime but with two versions briefly running. Recreate stops everything first, accepting downtime when versions cannot coexist."
Common mistakes
- Using rolling updates with database changes that break the old version.