Tweet
DevSecOps (Phần 13): Disposability – Vì sao Kubernetes có thể "xóa" Container của bạn bất cứ lúc nào?
Hãy tưởng tượng một Pod trong Kubernetes đang phục vụ hàng nghìn người dùng.
Đột nhiên Kubernetes quyết định xóa Pod đó và tạo một Pod mới.
Nghe có vẻ nguy hiểm?
Thực tế, đây là cách mà Kubernetes hoạt động mỗi ngày.
Điều này chỉ có thể thực hiện được nếu ứng dụng được thiết kế theo Yếu tố thứ 9 của 12-Factor App:
Hay nói cách khác:
Disposability là gì?
Trong các bài trước, chúng ta đã biết rằng ứng dụng hiện đại thường gồm nhiều Process hoặc Container có thể được tạo hoặc hủy bất kỳ lúc nào.
Điều đó có nghĩa là:
Đó chính là khái niệm Disposability.
Thay vì cố giữ cho một Process tồn tại mãi mãi, hệ thống được thiết kế để việc thay thế Process trở nên an toàn và nhanh chóng.
Khởi động càng nhanh càng tốt
Một ứng dụng lý tưởng chỉ mất vài giây từ khi khởi động đến khi sẵn sàng nhận yêu cầu.
Điều này mang lại nhiều lợi ích:
Nếu mỗi lần khởi động phải mất vài phút, khả năng mở rộng và tự phục hồi của hệ thống sẽ bị ảnh hưởng đáng kể.
Shutdown cũng quan trọng như Startup
Nhiều người chỉ quan tâm đến việc khởi động ứng dụng.
Nhưng trong DevSecOps, cách ứng dụng dừng hoạt động cũng quan trọng không kém.
Một ứng dụng không nên bị tắt ngay lập tức khi nhận yêu cầu dừng.
Thay vào đó, nó cần thực hiện Graceful Shutdown.
Quy trình thường diễn ra như sau:
Nhận tín hiệu dừng
│
▼
Ngừng nhận Request mới
│
▼
Hoàn thành các Request đang xử lý
│
▼
Giải phóng tài nguyên
│
▼
Thoát an toàn
Nhờ vậy, người dùng đang sử dụng dịch vụ sẽ không bị gián đoạn giữa chừng.
SIGTERM là gì?
Trong Linux, khi Process Manager muốn dừng một tiến trình, hệ điều hành thường gửi tín hiệu SIGTERM.
Khác với SIGKILL, SIGTERM cho phép ứng dụng:
Sau đó Process mới kết thúc.
Chính cơ chế này giúp việc triển khai phiên bản mới hoặc thay thế Container diễn ra an toàn hơn.
Web Server sẽ làm gì khi Shutdown?
Đối với một Web Process, quy trình Graceful Shutdown thường như sau:
Application
│
▼
Ngừng lắng nghe trên Port
│
▼
Từ chối Request mới
│
▼
Hoàn thành các Request hiện tại
│
▼
Thoát
Người dùng đang thực hiện giao dịch sẽ không bị cắt ngang, trong khi các yêu cầu mới sẽ được chuyển sang những instance khác còn đang hoạt động.
Worker Process cũng phải Shutdown đúng cách
Không chỉ Web Process, các Worker Process xử lý tác vụ nền cũng cần dừng một cách an toàn.
Ví dụ:
Worker nên:
Điều này giúp tránh mất dữ liệu hoặc xử lý trùng lặp.
Nếu Process chết đột ngột thì sao?
Không phải lúc nào ứng dụng cũng có cơ hội Shutdown một cách "đẹp".
Một Process có thể bị dừng do:
Trong những trường hợp này, các công việc chưa hoàn thành không nên bị mất.
Một giải pháp phổ biến là sử dụng Job Queue làm Backing Service.
Ví dụ:
Nếu Worker bị dừng giữa chừng, công việc có thể được đưa trở lại hàng đợi để một Worker khác tiếp tục xử lý khi sẵn sàng.
Disposability là nền tảng của Cloud Native
Khả năng khởi động nhanh và dừng an toàn giúp các nền tảng như Docker và Kubernetes thực hiện hiệu quả nhiều tác vụ tự động:
Các Container có thể được tạo mới, thay thế hoặc loại bỏ liên tục mà người dùng hầu như không nhận thấy sự thay đổi.
DevSecOps và Disposability
Disposability giúp ứng dụng trở nên linh hoạt và bền bỉ hơn trước các thay đổi của hạ tầng. Khi mỗi Process có thể khởi động nhanh, dừng an toàn và sẵn sàng bị thay thế bất cứ lúc nào, doanh nghiệp sẽ triển khai phiên bản mới nhanh hơn, mở rộng hệ thống dễ dàng hơn và giảm thiểu rủi ro khi xảy ra sự cố.
Đây là một nguyên tắc cốt lõi của Cloud Native và DevSecOps: thay vì cố gắng giữ cho từng máy chủ hay từng Container tồn tại mãi mãi, hãy xây dựng ứng dụng để mọi Process đều có thể bị thay thế bất kỳ lúc nào mà dịch vụ vẫn hoạt động ổn định. Chính tư duy này tạo nên khả năng tự phục hồi (Self-Healing) và tính sẵn sàng cao (High Availability) của các nền tảng hiện đại như Kubernetes.
Hãy tưởng tượng một Pod trong Kubernetes đang phục vụ hàng nghìn người dùng.
Đột nhiên Kubernetes quyết định xóa Pod đó và tạo một Pod mới.
Nghe có vẻ nguy hiểm?
Thực tế, đây là cách mà Kubernetes hoạt động mỗi ngày.
Điều này chỉ có thể thực hiện được nếu ứng dụng được thiết kế theo Yếu tố thứ 9 của 12-Factor App:
Maximize robustness with fast startup and graceful shutdown.
Hay nói cách khác:
Ứng dụng phải khởi động thật nhanh và dừng thật "đẹp".
Disposability là gì?
Trong các bài trước, chúng ta đã biết rằng ứng dụng hiện đại thường gồm nhiều Process hoặc Container có thể được tạo hoặc hủy bất kỳ lúc nào.
Điều đó có nghĩa là:
- Process không phải tài nguyên quý hiếm.
- Có thể tạo mới trong vài giây.
- Có thể dừng bất cứ lúc nào.
- Có thể thay thế ngay lập tức nếu xảy ra sự cố.
Đó chính là khái niệm Disposability.
Thay vì cố giữ cho một Process tồn tại mãi mãi, hệ thống được thiết kế để việc thay thế Process trở nên an toàn và nhanh chóng.
Khởi động càng nhanh càng tốt
Một ứng dụng lý tưởng chỉ mất vài giây từ khi khởi động đến khi sẵn sàng nhận yêu cầu.
Điều này mang lại nhiều lợi ích:
- Triển khai phiên bản mới nhanh hơn.
- Auto Scaling phản ứng nhanh khi lượng truy cập tăng.
- Thay thế Process bị lỗi gần như ngay lập tức.
- Giảm thời gian gián đoạn dịch vụ.
Nếu mỗi lần khởi động phải mất vài phút, khả năng mở rộng và tự phục hồi của hệ thống sẽ bị ảnh hưởng đáng kể.
Shutdown cũng quan trọng như Startup
Nhiều người chỉ quan tâm đến việc khởi động ứng dụng.
Nhưng trong DevSecOps, cách ứng dụng dừng hoạt động cũng quan trọng không kém.
Một ứng dụng không nên bị tắt ngay lập tức khi nhận yêu cầu dừng.
Thay vào đó, nó cần thực hiện Graceful Shutdown.
Quy trình thường diễn ra như sau:
Nhận tín hiệu dừng
│
▼
Ngừng nhận Request mới
│
▼
Hoàn thành các Request đang xử lý
│
▼
Giải phóng tài nguyên
│
▼
Thoát an toàn
Nhờ vậy, người dùng đang sử dụng dịch vụ sẽ không bị gián đoạn giữa chừng.
SIGTERM là gì?
Trong Linux, khi Process Manager muốn dừng một tiến trình, hệ điều hành thường gửi tín hiệu SIGTERM.
Khác với SIGKILL, SIGTERM cho phép ứng dụng:
- Nhận biết yêu cầu dừng.
- Hoàn thành các công việc đang xử lý.
- Giải phóng tài nguyên.
- Đóng kết nối.
- Lưu trạng thái nếu cần.
Sau đó Process mới kết thúc.
Chính cơ chế này giúp việc triển khai phiên bản mới hoặc thay thế Container diễn ra an toàn hơn.
Web Server sẽ làm gì khi Shutdown?
Đối với một Web Process, quy trình Graceful Shutdown thường như sau:
Application
│
▼
Ngừng lắng nghe trên Port
│
▼
Từ chối Request mới
│
▼
Hoàn thành các Request hiện tại
│
▼
Thoát
Người dùng đang thực hiện giao dịch sẽ không bị cắt ngang, trong khi các yêu cầu mới sẽ được chuyển sang những instance khác còn đang hoạt động.
Worker Process cũng phải Shutdown đúng cách
Không chỉ Web Process, các Worker Process xử lý tác vụ nền cũng cần dừng một cách an toàn.
Ví dụ:
- Gửi Email.
- Xử lý Queue.
- Đồng bộ dữ liệu.
- Xử lý ảnh hoặc video.
Worker nên:
- Hoàn thành công việc đang thực hiện nếu có thể.
- Giải phóng khóa (Lock) trên tài nguyên.
- Kết thúc giao dịch (Transaction) đúng cách.
- Không nhận thêm công việc mới trước khi dừng.
Điều này giúp tránh mất dữ liệu hoặc xử lý trùng lặp.
Nếu Process chết đột ngột thì sao?
Không phải lúc nào ứng dụng cũng có cơ hội Shutdown một cách "đẹp".
Một Process có thể bị dừng do:
- Máy chủ gặp sự cố.
- Lỗi phần cứng.
- Mất điện.
- Hệ điều hành bị lỗi.
- Container bị hủy đột ngột.
Trong những trường hợp này, các công việc chưa hoàn thành không nên bị mất.
Một giải pháp phổ biến là sử dụng Job Queue làm Backing Service.
Ví dụ:
- Beanstalkd.
- RabbitMQ.
- Kafka.
- Amazon SQS.
Nếu Worker bị dừng giữa chừng, công việc có thể được đưa trở lại hàng đợi để một Worker khác tiếp tục xử lý khi sẵn sàng.
Disposability là nền tảng của Cloud Native
Khả năng khởi động nhanh và dừng an toàn giúp các nền tảng như Docker và Kubernetes thực hiện hiệu quả nhiều tác vụ tự động:
- Rolling Update.
- Blue-Green Deployment.
- Canary Deployment.
- Auto Scaling.
- Self-Healing.
Các Container có thể được tạo mới, thay thế hoặc loại bỏ liên tục mà người dùng hầu như không nhận thấy sự thay đổi.
DevSecOps và Disposability
Disposability giúp ứng dụng trở nên linh hoạt và bền bỉ hơn trước các thay đổi của hạ tầng. Khi mỗi Process có thể khởi động nhanh, dừng an toàn và sẵn sàng bị thay thế bất cứ lúc nào, doanh nghiệp sẽ triển khai phiên bản mới nhanh hơn, mở rộng hệ thống dễ dàng hơn và giảm thiểu rủi ro khi xảy ra sự cố.
Đây là một nguyên tắc cốt lõi của Cloud Native và DevSecOps: thay vì cố gắng giữ cho từng máy chủ hay từng Container tồn tại mãi mãi, hãy xây dựng ứng dụng để mọi Process đều có thể bị thay thế bất kỳ lúc nào mà dịch vụ vẫn hoạt động ổn định. Chính tư duy này tạo nên khả năng tự phục hồi (Self-Healing) và tính sẵn sàng cao (High Availability) của các nền tảng hiện đại như Kubernetes.
Attached Files