Rolling update: cập nhật image mà không ngắt traffic

Serial S05 · S05E18

Đây là lúc câu chuyện không còn chỉ là stateless web. Khi database và upload xuất hiện, câu hỏi “pod có chạy không?” phải nhường chỗ cho “dữ liệu đang ở đâu và restore bằng cách nào?”.

Ở S05E17, chúng ta vừa hoàn tất Helm chart giúp chúng ta đóng gói hệ thống như thế nào?. Tập này không xóa trạng thái đó; nó dùng chính baseline vừa ghi để đi tiếp.

Trả lời ngắn: Kubernetes rolling update

PVC là yêu cầu lưu trữ, không phải bản backup. Trước khi migrate, chúng ta phải quyết định workload nào nên ở trong cluster và workload nào nên ở ngoài. Trong phạm vi bài này, chúng ta chỉ thay đổi phần liên quan đến tạo release lỗi để kiểm thử rollback; mọi thành phần khác được giữ nguyên để dễ rollback.

Góc thực chiến của tập này: Tạo một release lỗi có chủ ý ở môi trường kiểm thử, theo dõi maxSurge/maxUnavailable, readiness và revision. Rolling update an toàn bắt đầu từ probe đúng chứ không chỉ từ số replica.

Điểm xuất phát và giả định

Case study dùng một VPS Ubuntu và workload Docker Compose đã chạy ổn định. Các lệnh bên dưới là khung kiểm tra cho lab; hãy thay <placeholder>, pin phiên bản sau khi đọc tài liệu hiện hành và chụp lại output trước khi áp dụng. Ubuntu VPS; Docker Compose baseline; K3s version phải pin và kiểm tra lại tại thời điểm triển khai.

Giả định cần kiểm chứng: Tạo một release lỗi có chủ ý ở môi trường kiểm thử, theo dõi maxSurge/maxUnavailable, readiness và revision. Rolling update an toàn bắt đầu từ probe đúng chứ không chỉ từ số replica.

Chúng ta thực hiện theo thứ tự nào?

1. Phân loại dữ liệu theo khả năng mất mát và thời gian phục hồi.
2. Kiểm tra StorageClass, access mode, reclaim policy và vị trí vật lý.
3. Migrate một service phụ trước database.
4. Thử restore một bản sao vào tên volume/namespace khác.

Khung lệnh kiểm tra

kubectl get storageclass
kubectl get pv,pvc -A
kubectl describe pvc <pvc>
kubectl get pods -A -o wide
# Kiểm tra dữ liệu trước/sau bằng checksum hoặc query read-only
sha256sum ./backup/sample.tar

Không nên dán cả khối lệnh mà không đọc output. Bất kỳ lệnh nào có thể thay đổi cluster nên chạy dry-run, review manifest hoặc thực hiện trong cửa sổ thay đổi đã ghi trước.

Đọc kết quả thay vì chỉ nhìn trạng thái xanh

Restore phải được xem là một bài kiểm thử có kết quả: dữ liệu đọc được, quyền file đúng, ứng dụng khởi động và checksum/query quan trọng khớp.

Artefact của tập này là Lệnh kiểm tra, file cấu hình, YAML, checklist, log hoặc runbook tương ứng với tập.. Hãy lưu nó trong repository hoặc thư mục runbook kèm timestamp, phiên bản và người thực hiện. Đây là phần giúp tập sau có dữ liệu thật để kế thừa.

Trade-off và lỗi dễ gặp

Local storage dễ hiểu nhưng gắn với node; NFS chậm có thể làm datastore/SQLite timeout; snapshot không thay thế backup độc lập. Incident PV loss cho thấy reboot và nâng cấp có thể làm lộ giả định sai.

Với database quan trọng, external managed database hoặc máy riêng đôi khi đơn giản và an toàn hơn database chạy trong cluster nhỏ.

Checklist sau khi hoàn tất

• Đã ghi lại trạng thái trước và sau thay đổi.
• Đã biết lệnh kiểm tra và log cần đọc khi lỗi.
• Đã xác định đường rollback hoặc giới hạn blast radius.
• Đã cập nhật artefact của serial, không chỉ sửa thủ công trên máy.

Trạng thái dự án sau tập này

Dự án case study liên tục: VPS Ubuntu + Docker Compose tiến dần tới K3s production nhỏ; tập này kế thừa trạng thái từ tập trước. Kết quả cần chốt trong nhật ký là: tạo release lỗi để kiểm thử rollback đã được xử lý đến mức nào, điều gì còn chưa kiểm chứng và ai có thể lặp lại thao tác.

Vấn đề còn mở cho tập sau

Nếu các kiểm tra đạt, ở tập sau chúng ta sẽ chuyển sang Rollback khi bản release mới làm ứng dụng lỗi.