Rolling, recreate, canary, blue-green deploy: khi nào dùng cái nào?

Rolling update (default K8s Deployment): thay pods dần dần, maxSurge: 25%, maxUnavailable: 25% — zero-downtime, dễ hiểu, hợp với stateless service phần lớn case. Recreate: kill toàn bộ pod cũ trước khi start pod mới — có downtime, dùng khi schema migration không backward-compatible (không thể chạy v1 + v2 cùng lúc). Canary: deploy version mới chỉ cho 1-5% traffic, monitor metrics, tăng dần nếu OK — phù hợp release rủi ro cao, có cơ chế rollback nhanh; cần service mesh (Istio/Linkerd) hoặc Argo Rollouts/Flagger để split traffic theo % chính xác. Blue-Green: duy trì 2 môi trường song song, switch traffic instant tại load balancer — rollback < 1s nhưng tốn 2x infra; tốt cho release lớn, smoke test green trước khi switch. Quyết định theo bối cảnh: stateless API thông thường → rolling; release rủi ro (thuật toán mới, big refactor) → canary + feature flag; cần rollback tức thời / downtime không chấp nhận được → blue-green; migration DB phá compat → recreate (chấp nhận maintenance window). Feature flags là layer trên cùng: tách deployment (đẩy code lên prod) khỏi release (bật cho user) — deploy rolling vẫn an toàn vì code mới ẩn sau flag, bật dần qua LaunchDarkly/Unleash mà không cần redeploy.

Rolling update (default K8s Deployment): replaces pods gradually with maxSurge: 25%, maxUnavailable: 25% — zero-downtime, easy to reason about, fits most stateless services. Recreate: kills all old pods before starting new ones — has downtime; used when a schema migration is not backward-compatible (cannot run v1 and v2 side by side). Canary: deploy the new version to only 1-5% of traffic, monitor metrics, then ramp up if healthy — suits high-risk releases with fast rollback; requires a service mesh (Istio/Linkerd) or Argo Rollouts/Flagger to split traffic by exact percentage. Blue-Green: maintain two parallel environments, switch traffic instantly at the load balancer — rollback in <1s but costs 2x infrastructure; great for major releases, smoke test green before the switch. Choosing by context: standard stateless API → rolling; risky release (new algorithm, large refactor) → canary + feature flag; need instant rollback or zero acceptable downtime → blue-green; DB migration breaks compatibility → recreate (accept a maintenance window). Feature flags are an extra layer: decouple deployment (push code to prod) from release (turn it on for users) — rolling deploy is still safe because the new code is hidden behind a flag, gradually enabled via LaunchDarkly/Unleash without redeploying.