Building Kubernetes PR Previews with Shared Pulumi Components

Pulumi · 2026 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Đăng trên blog của Pulumi (nhà cung cấp IaC); tác giả kể hệ của team mình nhưng không nêu tên sản phẩm/công ty, trang có nhãn "Guest". Mọi nhận định ghi "theo tác giả".

Bối cảnh

• Team phát triển một ứng dụng microservice trên Kubernetes, hàng trăm PR mỗi ngày; mỗi PR cần một môi trường riêng để test và review trước khi merge.
• Namespace riêng mỗi PR mới là chỗ chạy; còn phải deploy app vào, cho reviewer truy cập, cập nhật theo commit mới, gỡ khi PR đóng. Cô lập database, quyền truy cập, network policy tuỳ app và cụm.

Thay đổi chính

• Một chương trình, nhiều stack: Dev, Stage, Prod và từng PR chạy cùng một chương trình Pulumi (component resource dùng chung) trong các stack riêng, mỗi stack có cấu hình và state riêng. PR pr-1042 có namespace, host pr-1042.preview…, image build riêng. Hạ tầng dùng chung, sống lâu (cụm, ingress controller, routing) nằm ngoài stack PR và được truyền vào, vì stack PR sẽ bị xoá cả cụm.
• Vòng đời: PR mở thì CI tạo stack và pulumi up, lấy URL từ output gửi reviewer; commit mới thì up lại cùng stack; một job định kỳ đối chiếu stack PR với trạng thái PR, PR đóng quá thời gian ân hạn thì destroy và xoá stack.
• Bài học vận hành ở quy mô hàng trăm môi trường/ngày:
  • Push nhiều commit liền nhau làm hai job CI cập nhật cùng một stack, gây xung đột; giờ tuần tự hoá theo từng stack PR, khác stack thì song song, và kiểm thao tác dở trước khi chạy tiếp.
  • Webhook và job dọn dẹp có thể hỏng, để lại môi trường mồ côi; job đối chiếu định kỳ thử dọn lại. Tài nguyên bị sửa/xoá ngoài Pulumi (drift) làm destroy lỗi thì pulumi refresh rồi thử lại, và kiểm tài nguyên đã thật sự bị xoá khi provider không xác nhận.

Vì sao

• Theo tác giả: trung bình khoảng 4 phút từ pulumi up tới môi trường sẵn sàng ở URL preview (image đã build trước); dùng chung chương trình với Dev/Stage/Prod nên preview không thành một bản cài đặt riêng phải bảo trì.

Bài học cho SWE

• Môi trường tạm muốn giống production thì phải sinh từ cùng định nghĩa với production, chỉ khác cấu hình.
• Dọn dẹp dựa trên sự kiện (webhook) luôn có lúc trượt; cần vòng đối chiếu trạng thái mong muốn với thực tế.
• Cập nhật đồng thời vào cùng một state phải tuần tự hoá theo khoá.

Liên quan

• Kiểm thử độ tin cậy (chaos, fault injection, mô phỏng tất định) · Tự động hoá vận hành và auto-remediation
• Atlassian 2020 · DoorDash 2022 · Neon 2026