Làm sao deploy không downtime và rollback nhanh khi có sự cố?

Ý tưởng chung: luôn có instance lành mạnh phục vụ traffic trong lúc thay phiên bản, và giữ được đường lùi.

Ba chiến lược thực tế
- Rolling update: thay dần từng phần pod cũ bằng pod mới (mặc định của Kubernetes Deployment). Cần readiness probe để chỉ route traffic khi instance mới sẵn sàng, và maxUnavailable/maxSurge để giữ đủ capacity. Đơn giản, ít tốn tài nguyên; nhược điểm là rollback chậm hơn và có lúc chạy song song 2 version.
- Blue-green: dựng full môi trường mới (green) song song với cũ (blue), test xong thì chuyển router sang green. Rollback = trỏ router về blue, gần như tức thì. Tốn gấp đôi tài nguyên khi chuyển.
- Canary: cho một tỷ lệ nhỏ traffic (1–5%) vào version mới, theo dõi error rate/latency, tăng dần nếu ổn. Bắt lỗi thật sớm với ít người dùng bị ảnh hưởng.

Health check: liveness probe restart instance treo; readiness probe quyết định có nhận traffic hay không — thiếu readiness thì rolling update vẫn gây lỗi.

DB migration tương thích ngược (expand/contract): đây là mấu chốt của zero-downtime. Vì code cũ và mới chạy song song, migration phải backward-compatible. Thêm cột thì thêm nullable trước, deploy code ghi cả hai, backfill, rồi mới bỏ cột cũ ở lần deploy sau. Không đổi/xóa cột trong cùng lần deploy đang còn code cũ chạy.

Rollback nhanh: mỗi release là artifact có version cố định → rollback = deploy lại version trước (kubectl rollout undo, hoặc chuyển router blue-green). Tách deploy khỏi migration để rollback code không kéo theo rollback schema.

Sai lầm hay gặp: migration phá vỡ tương thích ngược; không có readiness probe; rollback bằng cách sửa tay trên prod thay vì deploy lại artifact cũ.