Blue-Green Deployment là gì? Cách hoạt động và triển khai trong Kubernetes

Mỗi lần cập nhật ứng dụng đều tiềm ẩn nguy cơ gián đoạn dịch vụ, phát sinh lỗi hoặc kéo dài thời gian khôi phục. Blue-Green Deployment là gì và vì sao mô hình hai môi trường lại giúp doanh nghiệp phát hành phiên bản mới an toàn hơn? Cùng Viettel IDC làm rõ cơ chế hoạt động, kiến trúc, ưu nhược điểm và cách triển khai Blue-Green Deployment trong Kubernetes.

Blue-Green Deployment là gì?

Blue-Green Deployment là chiến lược triển khai phần mềm sử dụng hai môi trường có cấu hình tương đương, được gọi là Blue và Green. Một môi trường vận hành phiên bản ứng dụng hiện tại, trong khi môi trường còn lại chứa phiên bản mới chuẩn bị phát hành.

Tại cùng một thời điểm, chỉ một môi trường trực tiếp phục vụ người dùng. Sau mỗi lần cập nhật, Blue và Green có thể hoán đổi vai trò cho nhau nên tên gọi không cố định cho phiên bản cũ hoặc mới. Mô hình này tạo ra không gian riêng để triển khai bản phát hành tiếp theo mà không tác động trực tiếp đến hệ thống đang hoạt động.

Blue-Green Deployment hoạt động như thế nào?

Cơ chế hoạt động của Blue-Green Deployment vận hành bằng cách duy trì song song hai môi trường có cấu hình gần tương đương. Một môi trường đang phục vụ người dùng, trong khi môi trường còn lại được dùng để triển khai và kiểm tra phiên bản mới trước khi chuyển lưu lượng truy cập.

- Duy trì phiên bản hiện tại trên môi trường Blue: Blue tiếp tục tiếp nhận toàn bộ traffic và bảo đảm ứng dụng hoạt động ổn định trong thời gian chuẩn bị bản phát hành mới.

- Triển khai phiên bản mới lên môi trường Green: Mã nguồn, cấu hình và các thành phần liên quan được đưa lên Green mà không làm gián đoạn môi trường đang vận hành.

- Kiểm thử môi trường Green: Đội ngũ kỹ thuật kiểm tra chức năng, hiệu suất, khả năng kết nối và mức độ ổn định để phát hiện lỗi trước khi phát hành chính thức.

- Chuyển traffic từ Blue sang Green: Sau khi Green đáp ứng các tiêu chí đặt ra, load balancer, router hoặc lớp điều phối sẽ chuyển yêu cầu của người dùng sang phiên bản mới.

- Theo dõi và rollback khi cần: Hệ thống tiếp tục giám sát lỗi, độ trễ và các chỉ số vận hành. Nếu Green gặp sự cố, traffic có thể được chuyển trở lại Blue để khôi phục phiên bản ổn định.

Kiến trúc của chiến lược Blue-Green Deployment

Kiến trúc Blue-Green Deployment được hình thành từ hai môi trường ứng dụng vận hành song song, cùng lớp điều phối lưu lượng, cơ sở dữ liệu và hệ thống giám sát. Các thành phần phối hợp với nhau để bảo đảm phiên bản mới có thể được kiểm tra độc lập trước khi thay thế môi trường đang phục vụ người dùng.

Môi trường Blue

Blue là môi trường production đang chạy phiên bản ổn định và tiếp nhận toàn bộ lưu lượng truy cập. Trong thời gian bản cập nhật được triển khai ở Green, môi trường Blue vẫn hoạt động bình thường để dịch vụ không bị gián đoạn.

Ngay cả khi traffic đã được chuyển sang phiên bản mới, Blue thường vẫn được duy trì tạm thời. Cách tổ chức này tạo sẵn một phương án dự phòng, giúp đội ngũ vận hành nhanh chóng quay lại bản cũ nếu phát sinh lỗi.

Môi trường Green

Khác với Blue, môi trường Green được dành cho phiên bản chuẩn bị phát hành. Cấu hình tại đây cần tương đồng với production để kết quả kiểm thử phản ánh sát điều kiện vận hành thực tế.

Đội ngũ kỹ thuật có thể kiểm tra chức năng, hiệu suất và khả năng tích hợp trước khi cho người dùng truy cập. Khi đáp ứng đầy đủ tiêu chí, Green sẽ tiếp nhận traffic và trở thành môi trường production mới.

Lớp điều phối lưu lượng

Quá trình chuyển đổi giữa Blue và Green được thực hiện thông qua load balancer, reverse proxy, DNS hoặc Ingress Controller. Lớp điều phối quyết định môi trường nào sẽ nhận yêu cầu mà không cần thay đổi cách người dùng truy cập ứng dụng.

Sau khi Green được xác nhận ổn định, cấu hình định tuyến sẽ chuyển lưu lượng từ Blue sang phiên bản mới. Trong trường hợp phát hiện sự cố, traffic có thể được đưa trở lại Blue để khôi phục dịch vụ trong thời gian ngắn.

Cơ sở dữ liệu

Hai môi trường thường dùng chung cơ sở dữ liệu hoặc kết nối với các nguồn dữ liệu được đồng bộ. Vì vậy, mọi thay đổi về schema cần được thiết kế cẩn thận để cả phiên bản cũ và mới đều có thể xử lý dữ liệu trong giai đoạn chuyển tiếp.

Nếu cấu trúc dữ liệu chỉ tương thích với Green, quá trình rollback về Blue có thể không diễn ra thuận lợi. Đây cũng là lý do database thường được xem là thành phần cần kiểm soát chặt nhất trong kiến trúc Blue-Green Deployment.

Hệ thống giám sát

Bên cạnh hạ tầng triển khai, hệ thống monitoring giúp theo dõi trạng thái của phiên bản mới trước và sau khi chuyển traffic. Các chỉ số như tỷ lệ lỗi, thời gian phản hồi, mức sử dụng tài nguyên và tình trạng kết nối được dùng để đánh giá độ ổn định của Green.

Dữ liệu giám sát cũng là cơ sở để quyết định tiếp tục vận hành hay quay lại Blue. Nhờ đó, quá trình phát hành không phụ thuộc hoàn toàn vào kiểm thử ban đầu mà còn được kiểm chứng bằng hiệu suất thực tế.

Ưu nhược điểm của Blue-Green Deployment là gì?

Blue-Green Deployment giúp giảm rủi ro khi phát hành phiên bản mới nhờ duy trì song song hai môi trường. Tuy nhiên, mô hình cũng đòi hỏi nhiều tài nguyên hơn và cần kiểm soát chặt chẽ dữ liệu, cấu hình cùng quá trình chuyển đổi traffic.

Triển khai Blue-Green Deployment trong Kubernetes như thế nào?

Trong Kubernetes, Blue-Green Deployment có thể được xây dựng bằng hai Deployment chạy song song, tương ứng với hai phiên bản Blue và Green. Ví dụ dưới đây sử dụng Nginx để mô phỏng hai phiên bản ứng dụng. Blue đang phục vụ người dùng, trong khi Green chứa bản cập nhật mới chuẩn bị phát hành.

Bước 1: Tạo môi trường Blue

Trước tiên, tạo Deployment blue chạy phiên bản hiện tại của ứng dụng. Nhãn version: blue giúp Kubernetes nhận diện đúng nhóm Pod thuộc môi trường này.

Tiếp theo, tạo Service dành riêng cho Blue:

Service sử dụng label selector để xác định những Pod sẽ tiếp nhận lưu lượng. Vì selector chứa version: blue, các yêu cầu gửi đến blue-service chỉ được chuyển tới phiên bản Blue. Kubernetes Service cung cấp một địa chỉ truy cập ổn định ngay cả khi các Pod phía sau được tạo lại hoặc thay đổi.

Áp dụng cấu hình bằng lệnh:

Bước 2: Tạo môi trường Green

Môi trường Green có cấu trúc gần giống Blue nhưng sử dụng image của phiên bản mới. Hai Deployment có thể cùng tồn tại trong cluster mà không ảnh hưởng lẫn nhau nhờ bộ nhãn riêng.

Tạo thêm Service để truy cập và kiểm thử Green:

Sau đó triển khai hai tài nguyên:

Kiểm tra trạng thái:

Khi các Pod của Green đều ở trạng thái Running và Ready, phiên bản mới đã sẵn sàng cho bước kiểm thử.

Bước 3: Tạo địa chỉ production và test bằng Ingress

Ingress được dùng để định tuyến hai tên miền đến hai Service khác nhau. Trong ví dụ này, app.example.com là địa chỉ production, còn test-app.example.com dành cho bản Green.

Áp dụng cấu hình:

Lúc này, người dùng truy cập app.example.com vẫn nhận phiên bản Blue, trong khi đội ngũ kỹ thuật có thể kiểm tra Green thông qua test-app.example.com. Ingress ánh xạ các yêu cầu HTTP hoặc HTTPS đến Service dựa trên hostname và đường dẫn. Cluster cũng cần có Ingress Controller phù hợp, bởi chỉ tạo tài nguyên Ingress sẽ chưa đủ để xử lý lưu lượng thực tế.

Bước 4: Kiểm thử phiên bản Green

Trước khi chuyển traffic production, Green cần được kiểm tra về chức năng, kết nối, hiệu suất và khả năng xử lý dữ liệu. Đội ngũ vận hành có thể truy cập tên miền thử nghiệm hoặc gửi yêu cầu trực tiếp bằng curl:

Ngoài kiểm thử thủ công, bước này có thể được tích hợp với pipeline CI/CD để chạy unit test, integration test, smoke test hoặc health check tự động.

Có thể kiểm tra thêm trạng thái triển khai bằng lệnh:

Chỉ nên tiếp tục chuyển đổi khi Green vượt qua toàn bộ tiêu chí đã đặt ra. Nếu kiểm thử thất bại, đội ngũ có thể cập nhật lại image hoặc xóa Green mà không ảnh hưởng đến phiên bản Blue đang phục vụ người dùng.

Bước 5: Chuyển traffic từ Blue sang Green

Khi Green đã ổn định, chỉnh sửa Ingress để địa chỉ production trỏ đến green-service. Đồng thời, địa chỉ kiểm thử có thể được chuyển ngược về blue-service nhằm giữ phiên bản cũ làm phương án dự phòng.

Cập nhật lại Ingress:

Sau khi cấu hình có hiệu lực, yêu cầu từ app.example.com sẽ được chuyển đến Green. Blue không bị xóa mà tiếp tục tồn tại trong cluster để hỗ trợ rollback khi cần.

Bước 6: Theo dõi và rollback

Sau khi Green trở thành production, cần theo dõi tỷ lệ lỗi, thời gian phản hồi, log ứng dụng và mức sử dụng tài nguyên. Bạn có thể kiểm tra nhanh bằng các lệnh:

Nếu phiên bản mới phát sinh lỗi nghiêm trọng, rollback được thực hiện bằng cách đưa backend của app.example.com trở lại blue-service, sau đó áp dụng lại manifest Ingress:

Traffic sẽ quay về Blue mà không cần xây dựng hoặc triển khai lại phiên bản cũ. Sau khi Green hoạt động ổn định trong khoảng thời gian theo dõi, Blue có thể được cập nhật để chuẩn bị cho lần phát hành tiếp theo.

Kết luận

Qua nội dung trên, Blue-Green Deployment là gì đã được làm rõ từ cơ chế hoạt động, kiến trúc đến cách triển khai trong Kubernetes. Khi kết hợp cùng quy trình kiểm thử, giám sát và quản lý dữ liệu phù hợp, chiến lược này giúp doanh nghiệp giảm rủi ro, rút ngắn thời gian chuyển đổi và chủ động hơn trong mỗi lần phát hành.