Rolling update trong Kubernetes hoạt động ra sao? Cơ chế và ví dụ

Làm thế nào để cập nhật ứng dụng mà không gây gián đoạn dịch vụ? Cơ chế Rolling update trong Kubernetes chính là câu trả lời giúp thay thế các Pod cũ bằng Pod mới một cách cuốn chiếu, đảm bảo hệ thống luôn sẵn sàng 24/7. Hãy cùng Viettel IDC tìm hiểu chi tiết Rolling update trong Kubernetes hoạt động ra sao và cách tối ưu hóa cơ chế này.

Tìm hiểu Rolling update trong Kubernetes là gì?

Rolling update trong Kubernetes là cơ chế cập nhật ứng dụng tự động, cho phép triển khai phiên bản mới một cách tuần tự (cuốn chiếu) mà không gây gián đoạn dịch vụ. Nó thay thế dần các Pod cũ bằng Pod mới theo từng đợt, đảm bảo hệ thống luôn sẵn sàng phục vụ người dùng.

Cơ chế Rolling update trong Kubernetes hoạt động ra sao?

Cơ chế hoạt động của Rolling update trong Kubernetes (quy trình cập nhật cuốn chiếu) được vận hành dựa trên nguyên tắc thay thế dần dần các thực thể cũ bằng các thực thể mới nhằm đảm bảo hệ thống không bị gián đoạn dịch vụ. Chúng ta hãy phân tích kỹ các giai đoạn cùng ví dụ cụ thể:

Giai đoạn 1: Tiếp nhận yêu cầu và tính toán tài nguyên

Khi bạn phát lệnh cập nhật một Deployment (ví dụ: nâng cấp phiên bản ứng dụng từ v1 lên v2), Kubernetes Deployment Controller sẽ không tắt đồng loạt các Pod cũ. Thay vào đó, nó sẽ dựa vào hai tham số cấu hình quan trọng trong file YAML là maxSurge (số lượng Pod tối đa có thể tạo vượt mức) và maxUnavailable (số lượng Pod tối đa có thể tạm thời không khả dụng) để tính toán số lượng Pod cần quản lý trong mỗi đợt cuốn chiếu. Theo mặc định, cả hai giá trị này đều là 25%.

Ví dụ thực tế: Giả sử hệ thống của bạn đang chạy một Deployment gồm 4 Pod phiên bản v1. Với cấu hình mặc định (25%), Kubernetes tính toán rằng tại một thời điểm, nó chỉ được phép tạo thêm tối đa 1 Pod mới ($4 \times 25\% = 1$) và chỉ được phép hạ tối đa 1 Pod cũ xuống.

Giai đoạn 2: Khởi tạo Pod mới và kiểm tra trạng thái (Readiness Probe)

Kubernetes sẽ tiến hành bước "cuốn chiếu" đầu tiên bằng cách ra lệnh cho ReplicaSet mới khởi tạo một số lượng Pod chạy phiên bản v2 trên các Node còn trống tài nguyên. Điểm mấu chốt ở đây là các Pod v2 mới này sẽ chưa nhận lưu lượng truy cập (traffic) ngay lập tức. Kubernetes sẽ giữ chúng ở trạng thái chờ và liên tục thực hiện các bài kiểm tra trạng thái hoạt động (Readiness Probes) để đảm bảo ứng dụng bên trong container đã khởi động hoàn toàn và không gặp lỗi khởi chạy.

Tiếp tục với cấu hình ở trên, Kubernetes sẽ tạo thêm 1 Pod v2 mới (lúc này tổng số Pod tạm thời tăng lên thành 5). Hệ thống sẽ đợi khoảng vài mươi giây để Pod v2 này chuyển sang trạng thái Running và vượt qua vòng kiểm tra Readiness Probe một cách an toàn.

Giai đoạn 3: Chuyển đổi lưu lượng truy cập và thu hồi Pod cũ

Ngay sau khi xác nhận Pod phiên bản v2 đầu tiên đã hoạt động ổn định, Kube-Proxy và Endpoints Controller của Kubernetes Service sẽ cập nhật lại danh sách định tuyến. Hệ thống bắt đầu chuyển một phần traffic của người dùng sang Pod v2 mới này. Đồng thời, nhận thấy số lượng Pod an toàn đã tăng lên, Kubernetes sẽ ra lệnh chấm dứt (terminate) và xóa bỏ 1 Pod chạy phiên bản v1 cũ để cân bằng lại số lượng bản sao mong muốn.

Quay trở lại với ví dụ, khi Pod v2 đầu tiên sẵn sàng, Service sẽ chia sẻ một phần traffic sang cho nó. Ngay lập tức, 1 Pod v1 cũ sẽ bị xóa đi. Lúc này hệ thống quay về trạng thái có tổng cộng 4 Pod, nhưng cơ cấu đã thay đổi: gồm 3 Pod v1 và 1 Pod v2.

Giai đoạn 4: Lặp lại vòng lặp cuốn chiếu cho đến khi hoàn tất

Quy trình tạo Pod mới, kiểm tra độ sẵn sàng, chuyển traffic và xóa Pod cũ sẽ được Kubernetes lặp đi lặp lại một cách tuần tự theo từng đợt (từng cụm nhỏ) giống như một làn sóng cuốn chiếu. Quá trình này diễn ra liên tục cho đến khi không còn Pod v1 nào tồn tại và toàn bộ hệ thống được thay thế hoàn toàn bằng phiên bản v2. Do luôn có các Pod hoạt động song song xuyên suốt quá trình nên người dùng cuối sẽ không gặp bất kỳ gián đoạn nào (Zero Downtime).

Trong tình huống giả định đã đề cập lúc trước, tiếp tục vòng lặp, Kubernetes lại tạo thêm Pod v2 thứ hai và xóa đi Pod v1 thứ hai (hệ thống có 2 Pod v1, 2 Pod v2). Quá trình lặp lại cho đến đợt cuối cùng, toàn bộ 4 Pod đều chạy phiên bản v2 ổn định. Lúc này, quy trình cập nhật cuốn chiếu chính thức kết thúc thành công.

Hướng dẫn các bước thực hiện Rolling update trong Kubernetes

Trước khi bắt đầu, hãy đảm bảo bạn đang sử dụng một Terminal hỗ trợ cú pháp POSIX (như Bash trên Linux/macOS hoặc WSL/Git Bash trên Windows).

Bước 1: Kiểm tra trạng thái hiện tại của Deployment và Pod 

Trước khi tiến hành nâng cấp, bạn cần kiểm tra xem hệ thống hiện tại đang chạy phiên bản nào và có bao nhiêu Pod đang hoạt động bình thường.

Để liệt kê các Deployment hiện có, bạn chạy lệnh:

Lệnh này giúp bạn xác định chính xác tên của Deployment cần cập nhật. Tiếp theo, bạn kiểm tra danh sách các Pod đang chạy bằng lệnh:

Cuối cùng, để xem chi tiết thông tin và phiên bản Image hiện tại, bạn hãy sử dụng lệnh:

Hãy cuộn chuột tìm trường Image: trong kết quả trả về để biết phiên bản hiện tại của container (ví dụ: v1).

Bước 2: Tiến hành cập nhật cuốn chiếu (Rolling Update) 

Để thực hiện Rolling Update trong Kubernetes, bạn sẽ sử dụng lệnh kubectl set image để chỉ định một Image (hoặc thẻ tag) mới cho container bên trong Deployment. Cú pháp lệnh cập nhật Image cụ thể như sau:

Lệnh này yêu cầu Deployment có tên là kubernetes-bootcamp thay đổi Image của container (cũng tên là kubernetes-bootcamp) sang phiên bản mới là :v2. Ngay sau khi bạn nhấn Enter, Kubernetes sẽ âm thầm kích hoạt quy trình rolling update. Hệ thống tự động tạo ra Pod mới chạy bản v2, chờ nó sẵn sàng rồi mới tiến hành xóa (terminate) Pod chạy bản v1.

Bước 3: Xác thực quá trình nâng cấp ứng dụng 

Trong quá trình hệ thống đang chuyển giao, bạn có thể chủ động theo dõi tiến độ cập nhật xem có suôn sẻ hay không.

Bạn có thể kiểm tra trạng thái cập nhật theo thời gian thực bằng lệnh:

Màn hình sẽ hiển thị thông báo tiến trình cho đến khi tất cả các Pod mới được triển khai thành công. Sau đó, bạn kiểm tra lại danh sách Pod để đảm bảo các Pod cũ đã bị xóa thông qua lệnh:

Bạn sẽ thấy các Pod cũ chuyển sang trạng thái Terminating và biến mất, thay vào đó là các Pod mới với trạng thái Running. Nếu ứng dụng được mở ra bên ngoài thông qua một Service (ví dụ NodePort), bạn có thể gửi yêu cầu liên tục bằng lệnh curl để kiểm tra lưu lượng truy cập (Traffic):

Kết quả trả về từ các Pod sẽ đồng loạt hiển thị nội dung của phiên bản v2, chứng minh hệ thống đã chuyển đổi traffic mượt mà.

Bước 4: Hoàn tác dữ liệu (Rollback) khi xảy ra lỗi 

Một trong những điểm ưu việt nhất của Rolling update Kubernetes là khả năng quay xe (Rollback) cực kỳ nhanh chóng nếu phiên bản mới bị lỗi hoặc không tồn tại.

Giả sử bạn vô tình cập nhật nhầm lên một phiên bản lỗi (ví dụ tag không tồn tại là :v10):

Khi kiểm tra lại bằng lệnh kubectl get pods, bạn sẽ thấy các Pod mới bị kẹt ở trạng thái ImagePullBackOff (không thể tải được image). Để khắc phục ngay lập tức và đưa hệ thống về trạng thái ổn định trước đó, bạn chỉ cần chạy lệnh:

Kết quả: Kubernetes sẽ ngay lập tức hủy bỏ bản cập nhật lỗi và khôi phục (rollback) toàn bộ hệ thống về phiên bản hoạt động ổn định gần nhất (v2). Bạn có thể dùng lại lệnh kubectl get pods và kubectl describe pods để xác nhận ứng dụng đã an toàn.

Kết luận

Hiểu rõ Rolling update trong Kubernetes hoạt động ra sao giúp bạn làm chủ quy trình triển khai ứng dụng mà không gây gián đoạn dịch vụ. Để tối ưu hóa và đơn giản hóa việc vận hành các cụm Kubernetes trên hạ tầng chuẩn quốc tế, doanh nghiệp có thể tham khảo dịch vụ Viettel Dedicated Kubernetes Service (vDKS). Đây là giải pháp tự động hóa toàn diện giúp đơn giản hóa việc quản lý cụm K8s trên hạ tầng đạt chuẩn quốc tế, tiết kiệm tối đa chi phí vận hành và thời gian triển khai cho đội ngũ DevOps.

Tham khảo chi tiết tại: : https://viettelidc.com.vn/viettel-kubernetes-service