Deployment khác ReplicaSet như thế nào trong Kubernetes?

Trong Kubernetes, cả Deployment và ReplicaSet đều được sử dụng để quản lý vòng đời của Pod. Để vận hành vòng đời ứng dụng trong một cụm Kubernetes, hệ thống dựa vào hai thành phần quan trọng này để triển khai, duy trì và kiểm soát các Pod. Cùng Viettel IDC tìm hiểu cụ thể Deployment khác ReplicaSet như thế nào trong bài viết sau.

Deployment là gì?

Deployment là một đối tượng trong Kubernetes dùng để quản lý một nhóm Pod có cùng cấu hình, đồng thời bảo đảm số lượng bản sao Pod được duy trì theo giá trị đã khai báo. Tài nguyên này hoạt động theo mô hình khai báo, cho phép Kubernetes tự động triển khai phiên bản mới và khôi phục ứng dụng về phiên bản trước khi cần.

Khi ứng dụng được cập nhật, Deployment sẽ tạo một ReplicaSet mới dựa trên cấu hình mới rồi từng bước thay thế các Pod thuộc ReplicaSet cũ. Nếu phiên bản mới gặp lỗi, Deployment có thể sử dụng lịch sử revision để rollback về trạng thái ổn định trước đó.

ReplicaSet phía sau Deployment chịu trách nhiệm duy trì đủ số lượng Pod đang hoạt động. Khi một Pod bị lỗi hoặc bị xóa, ReplicaSet sẽ tự động tạo Pod thay thế để đưa hệ thống trở lại trạng thái mong muốn.

ReplicaSet là gì?

ReplicaSet là một đối tượng trong Kubernetes, có nhiệm vụ bảo đảm số lượng bản sao Pod đã chỉ định luôn được duy trì tại mọi thời điểm. Tài nguyên này quản lý vòng đời của Pod, đồng thời hỗ trợ mở rộng hoặc thu hẹp số lượng Pod để ứng dụng luôn hoạt động theo trạng thái mong muốn.

ReplicaSet cũng chịu trách nhiệm tạo và quản lý Pod dựa trên Pod template đã khai báo. Khi số lượng Pod thấp hơn cấu hình, ReplicaSet sẽ tạo thêm bản sao mới; ngược lại, các Pod dư thừa sẽ được xóa để đưa hệ thống về đúng số lượng yêu cầu.

Tuy nhiên, ReplicaSet không trực tiếp cung cấp cơ chế rolling update và rollback hoàn chỉnh. Trong thực tế, các chức năng này thường do Deployment đảm nhiệm bằng cách tạo ReplicaSet mới với cấu hình đã cập nhật, sau đó giảm dần số Pod thuộc ReplicaSet cũ.

Cụ thể Deployment khác ReplicaSet như thế nào?

Kubernetes Deployment khác ReplicaSet ở chỗ Deployment là đối tượng quản lý cấp cao hơn dùng để giám sát, cập nhật và quay lui phiên bản. Trong khi đó, ReplicaSet chỉ chịu trách nhiệm duy trì đúng số lượng bản sao Pod chạy ổn định.

Khác biệt về mục đích sử dụng

ReplicaSet có nhiệm vụ bảo đảm số lượng Pod thực tế luôn khớp với giá trị được khai báo trong trường replicas. Chẳng hạn, nếu hệ thống cần duy trì ba Pod nhưng một Pod gặp lỗi hoặc bị xóa, ReplicaSet sẽ tự động tạo Pod khác để bù vào vị trí còn thiếu.

Deployment có phạm vi quản lý rộng hơn vì không chỉ duy trì số lượng Pod mà còn điều phối toàn bộ vòng đời của một phiên bản ứng dụng. Mỗi khi người dùng thay đổi container image, cấu hình Pod hoặc số lượng replicas, Deployment sẽ tạo hoặc cập nhật ReplicaSet tương ứng để đưa hệ thống về trạng thái mới. Đây cũng là điểm khác biệt cốt lõi của deployment vs replicaset, bởi một bên tập trung duy trì Pod, còn bên kia phụ trách cả quy trình triển khai ứng dụng.

Mức độ kiểm soát và trừu tượng

Khi so sánh deployment vs replicaset ở góc độ vận hành, ReplicaSet mang lại khả năng kiểm soát trực tiếp hơn nhưng cũng đòi hỏi nhiều thao tác thủ công. Deployment thuận tiện hơn cho các hệ thống cần cập nhật thường xuyên và duy trì quy trình phát hành ổn định.

ReplicaSet hoạt động gần với Pod nên người quản trị có thể trực tiếp kiểm soát nhóm Pod thông qua label selector và Pod template. Cách quản lý này phù hợp khi cần quan sát rõ cơ chế Kubernetes phát hiện, thay thế và duy trì số lượng bản sao.

Deployment nằm ở lớp quản lý cao hơn, nhờ đó người dùng không phải tự tạo và điều chỉnh từng ReplicaSet trong mỗi lần phát hành. Chỉ cần khai báo trạng thái mong muốn trong Deployment, Kubernetes sẽ tự động xử lý các ReplicaSet và Pod nằm phía sau.

Cách quản lý cấu hình Pod

Khi thay đổi Pod template trong ReplicaSet, các Pod đã tồn tại không tự động được thay thế theo cấu hình mới. Người quản trị thường phải xóa các Pod cũ, tạo ReplicaSet khác hoặc xây dựng quy trình cập nhật riêng.

Với Deployment, thay đổi trong Pod template sẽ tạo ra một revision triển khai mới. Nếu container image được đổi từ myapp:v1 sang myapp:v2, Deployment sẽ tạo ReplicaSet mới, tăng dần số Pod của phiên bản mới và giảm số Pod thuộc ReplicaSet cũ.

Khả năng cập nhật ứng dụng

ReplicaSet không cung cấp sẵn chiến lược cập nhật theo từng giai đoạn. Nếu người quản trị thay thế toàn bộ Pod cùng lúc mà không có cơ chế điều phối bổ sung, ứng dụng có thể bị gián đoạn trong thời gian phiên bản mới khởi động.

Deployment hỗ trợ chiến lược RollingUpdate, cho phép tạo một số Pod mới trước khi loại bỏ Pod cũ. Tốc độ thay thế có thể được kiểm soát thông qua maxSurge và maxUnavailable, giúp cân bằng giữa tốc độ triển khai và khả năng duy trì dịch vụ.

Ngoài RollingUpdate, Deployment còn hỗ trợ chiến lược Recreate. Khi sử dụng cách này, toàn bộ Pod cũ sẽ được dừng trước khi Pod của phiên bản mới được tạo, phù hợp với ứng dụng không thể vận hành đồng thời hai phiên bản.

Khả năng rollback khi phiên bản mới gặp lỗi

ReplicaSet không lưu lịch sử triển khai nên không thể trực tiếp đưa ứng dụng trở lại phiên bản trước. Nếu cấu hình mới gặp lỗi, người quản trị phải xác định lại image và thông số cũ rồi tự thực hiện quá trình khôi phục.

Deployment lưu các revision hình thành sau mỗi lần cập nhật Pod template. Khi phiên bản mới không hoạt động ổn định, quản trị viên có thể kiểm tra lịch sử bằng kubectl rollout history và quay lại revision trước với kubectl rollout undo.

Dù có khả năng rollback, Deployment không tự đánh giá ứng dụng đã vận hành đúng về mặt nghiệp vụ hay chưa. Vì vậy, hệ thống vẫn cần kết hợp readiness probe, liveness probe, giám sát và quy trình kiểm thử trước khi đưa phiên bản mới vào production.

Khả năng quản lý ứng dụng có trạng thái

ReplicaSet không bảo đảm mỗi Pod có tên, danh tính mạng hoặc vùng lưu trữ riêng ổn định. Khi một Pod bị thay thế, Pod mới có thể mang tên khác và không giữ lại dữ liệu được lưu trong filesystem cục bộ của Pod cũ.

Deployment cũng được thiết kế chủ yếu cho ứng dụng stateless. Dữ liệu cần được tách khỏi vòng đời Pod và lưu tại cơ sở dữ liệu, object storage hoặc persistent volume để tránh mất mát khi Pod được tạo lại.

Đối với cơ sở dữ liệu phân tán hoặc workload yêu cầu danh tính Pod ổn định, thứ tự khởi tạo và vùng lưu trữ riêng, StatefulSet thường là lựa chọn phù hợp hơn. Vì vậy, khi đánh giá deployment vs replicaset trong Kubernetes, cần hiểu rằng cả hai đều không được thiết kế để trực tiếp quản lý những workload có trạng thái phức tạp.

Mức độ phức tạp khi vận hành

Cấu hình ReplicaSet tương đối gọn vì chủ yếu gồm số lượng replicas, label selector và Pod template. Tuy nhiên, sự đơn giản trong tệp YAML có thể khiến quá trình vận hành trở nên phức tạp hơn khi ứng dụng cần cập nhật thường xuyên.

Deployment có thêm các trường liên quan đến chiến lược cập nhật, lịch sử revision, thời gian chờ và trạng thái rollout. Đổi lại, Kubernetes sẽ tự động hóa phần lớn quá trình thay thế Pod, giúp giảm thao tác thủ công và hạn chế lỗi khi phát hành.

Khi nào nên sử dụng Deployment vs ReplicaSet trong Kubernetes?

Lựa chọn Deployment hay ReplicaSet phụ thuộc vào cách ứng dụng được triển khai và mức độ kiểm soát mà hệ thống yêu cầu. Trong thực tế, Deployment phù hợp với hầu hết workload thông thường, còn ReplicaSet chỉ nên được dùng trực tiếp trong một số trường hợp đặc thù.

Kết luận

Qua bài viết, bạn đã có thể xác định Deployment khác ReplicaSet như thế nào dựa trên phạm vi quản lý, khả năng cập nhật và cơ chế rollback. Trong phần lớn hệ thống thực tế, Deployment là lựa chọn phù hợp hơn, còn ReplicaSet chủ yếu được tạo và quản lý tự động ở phía sau.

Để đơn giản hóa quá trình xây dựng và vận hành cụm Kubernetes, doanh nghiệp có thể tham khảo Viettel Dedicated Kubernetes Service (vDKS). Dịch vụ cung cấp nền tảng Kubernetes được quản lý trên hạ tầng Viettel IDC, hỗ trợ khởi tạo cụm nhanh, mở rộng tài nguyên linh hoạt và giảm áp lực quản trị hạ tầng cho đội ngũ kỹ thuật.

Xem chi tiết tại: https://viettelidc.com.vn/viettel-kubernetes-service