التحديثات التدريجية وعمليات التراجع

Updating every Pod at once causes downtime. A rolling update replaces Pods gradually so the app stays available throughout the change.

A Deployment owns a ReplicaSet. Changing the Pod template makes the Deployment create a new ReplicaSet and shift Pods from old to new at a controlled pace.

Change the image and the Deployment starts a rollout automatically.

The strategy is tuned by two values: maxSurge (extra Pods allowed above desired) and maxUnavailable (Pods allowed to be down) during the rollout.

Track progress and confirm it finished cleanly.

A new Pod only receives traffic once its readiness probe passes. Without good probes, broken Pods can still get traffic during a rollout.

Pause a rollout to verify a canary subset, then resume.

Kubernetes keeps a revision history you can inspect.

If the new version misbehaves, roll back to the previous revision instantly.

Target an exact revision from the history list.

Control how many old ReplicaSets are retained for rollback with revisionHistoryLimit in the Deployment spec.

Test what you have learned.

You learned how Deployments perform rolling updates via ReplicaSets, how maxSurge/maxUnavailable and readiness probes control safety, and how to pause, watch, and rollout undo to recover fast.