Kiểm thử connection draining khi rolling deployment

Khi instance bị loại khỏi pool, load balancer cần ngừng cấp kết nối/request mới nhưng cho công việc đang chạy hoàn tất trong giới hạn. Nếu process thoát trước khi control plane cập nhật, client nhận reset. Nếu drain quá dài, deployment chậm và instance lỗi có thể tiếp tục phục vụ.

HTTP/2 multiplexing và WebSocket làm khái niệm “kết nối đang hoạt động” khác HTTP/1.1. Một TCP connection có thể mang nhiều stream; chỉ đếm connection chưa đủ để biết request nào bị cắt.

Topology gồm load generator ngoài cluster, DNS hoặc global load balancer nếu có, regional load balancer/ingress, service và ít nhất ba instance. Gắn instance ID vào response header và correlation ID vào request để xác định request nào đến pod đang drain.

Thu timestamp ở orchestrator, load balancer, application và client. Đồng hồ lệch sẽ làm xuất hiện nghịch lý như process exit trước request start. Mốc quan trọng gồm T0 bắt đầu rollout, T1 readiness fail, T2 request mới cuối cùng, T3 request cũ cuối cùng hoàn tất và T4 process exit.

Khóa deployment strategy, maxUnavailable, maxSurge, health-check interval, unhealthy threshold, deregistration delay, preStop hook và terminationGracePeriod. Ghi rõ keep-alive, max connection age, HTTP/2 GOAWAY, idle timeout và client retry.

Traffic profile cần request ngắn, request chậm, upload/download, WebSocket và burst. Tách lỗi do capacity giảm trong rollout khỏi lỗi drain bằng cách giữ headroom và chạy một lượt không thay đổi version.

• Biến: Health-check cadence · Giá trị cần ghi: interval × threshold · Rủi ro: Endpoint removal trễ
• Biến: Deregistration delay · Giá trị cần ghi: giây · Rủi ro: Cắt request hoặc rollout kéo dài
• Biến: Grace period · Giá trị cần ghi: giây · Rủi ro: Process exit sớm
• Biến: Request duration · Giá trị cần ghi: p50/p99/max · Rủi ro: Drain không phủ tail
• Biến: Protocol · Giá trị cần ghi: H1/H2/WebSocket · Rủi ro: Khác hành vi đóng kết nối
• Biến: Client retry · Giá trị cần ghi: on/off, policy · Rủi ro: Che giấu request loss

Đo success rate theo từng giây, connection reset, 5xx/499, deadline exceeded, retry amplification, p99 latency, số request mới sau T1, số request đang chạy bị cắt và rollout duration. KPI capacity gồm active instance, CPU, queue và saturation trong lúc maxUnavailable có hiệu lực.

Không chỉ nhìn tỷ lệ lỗi tổng. Một deployment 10 phút với 20 lỗi có thể bị dashboard làm tròn thành 99,99%. Bằng chứng cần event-level trace chứa request ID, instance ID, start/end time và kết quả.

• Traffic: HTTP/1.1 ngắn · Điều phải chứng minh: Không cấp request mới sau removal · Pass/fail cần xác lập: Không reset ngoài policy
• Traffic: HTTP/1.1 dài · Điều phải chứng minh: Request hoàn tất trong grace · Pass/fail cần xác lập: Không bị process cắt
• Traffic: HTTP/2 · Điều phải chứng minh: Stream mới/đang chạy xử lý đúng · Pass/fail cần xác lập: GOAWAY/reconnect có kiểm soát
• Traffic: WebSocket · Điều phải chứng minh: Chính sách drain rõ ràng · Pass/fail cần xác lập: Client reconnect đúng budget
• Traffic: Upload lớn · Điều phải chứng minh: Không mất dữ liệu âm thầm · Pass/fail cần xác lập: Error có thể quan sát
• Traffic: Burst lúc rollout · Điều phải chứng minh: Capacity còn đủ · Pass/fail cần xác lập: p99 và error trong SLO

Trước hết chạy baseline không rollout. Sau đó rollout cùng image để chỉ kiểm tra lifecycle. Tiếp theo rollout image mới dưới steady load và burst. Cuối cùng mô phỏng process chậm shutdown và instance unhealthy để phân biệt graceful với forced termination.

• 1. Đồng bộ thời gian, bật trace và response instance ID.
• 2. Warm-up pool, giữ load ở mức có headroom.
• 3. Chạy baseline 10–15 phút.
• 4. Kích hoạt rollout một instance mỗi lần.
• 5. Bắn request có thời lượng vượt các quantile đã chọn.
• 6. Theo dõi T1–T4 và request mới cuối cùng trên instance.
• 7. Lặp với HTTP/2 và WebSocket.
• 8. Tăng burst tại thời điểm capacity giảm.
• 9. Thử rollback và forced termination.
• 10. Xuất trace, event orchestrator, LB log và bảng pass/fail.

• Readiness đổi trước khi process nhận tín hiệu thoát.
• LB propagation delay đã được đo, không chỉ giả định.
• Grace period lớn hơn tail request theo policy.
• Ứng dụng ngừng nhận việc mới khi draining.
• HTTP/2 GOAWAY và WebSocket reconnect đã thử.
• Client retry không che lỗi và có budget.
• Capacity còn đủ khi maxUnavailable áp dụng.
• Dashboard có instance ID và correlation ID.
• Rollback sử dụng cùng tiêu chí nghiệm thu.
• Runbook có ngưỡng tự động dừng rollout.

Hành vi khác nhau giữa load balancer, ingress controller, orchestrator và phiên bản. Không suy diễn một timeout tối ưu cho mọi ứng dụng. Request có side effect cần idempotency; retry sau reset có thể tạo giao dịch trùng dù availability nhìn có vẻ tốt.

Lab không tái hiện đầy đủ DNS cache, cross-zone traffic, autoscaling hoặc network path production. Kết luận phải ghi image, manifest, phiên bản controller, LB mode, client library và traffic profile.

• Connection draining: Ngừng nhận việc mới trong khi hoàn tất việc đang chạy.
• Readiness: Tín hiệu instance có đủ điều kiện nhận traffic.
• Deregistration delay: Thời gian LB duy trì kết nối sau khi loại target.
• Grace period: Cửa sổ trước khi process bị buộc dừng.
• GOAWAY: Frame HTTP/2 báo peer không nên tạo stream mới.
• Rolling deployment: Thay instance theo từng phần để duy trì dịch vụ.