LEARN. PRACTICE. GROW.Concept and mechanism
A Deployment reconciles replicas and supports updating the Pod template. maxSurge limits extra replicas and maxUnavailable limits unavailability during RollingUpdate. These values guarantee neither cluster capacity, functional readiness, nor exact traffic percentage. A canary selected by the same Service can receive a different share from its Pod ratio because of persistent connections and distribution mechanisms. Define per-version criteria, including errors and latency, before increasing exposure.
Guided application
Helm can install or upgrade releases with explicit values; Kustomize composes bases and overlays. Review the resulting manifest and target before applying. In blue/green, validate the new version before changing traffic selection and retain a plan for in-flight connections. Restoring an earlier template does not undo database changes. For a migration release, agree version compatibility, recovery, and the decision to proceed or return. Observe new Pods when readiness blocks rollout, preserving healthy replicas during diagnosis.
With four replicas and 25% for both limits, the strategy allows one extra replica and one unavailable replica. Confirm capacity and functional health before using that allowance.
Common pitfalls
Removing readiness to complete a rollout; assessing only global averages; promising data rollback through rollout undo.
Related topics: Application observability and maintenance · Configuration, secrets, and identity
A rollout is validated only when application, traffic, and data satisfy agreed criteria.
Reference: Deployments · CKAD Kubernetes v1.35