Cloud & hạ tầng

Nhân bản dữ liệu hiệu quả trong Kubernetes bằng cách sử dụng ảnh chụp nhanh volume bên ngoài

Một hướng dẫn năm 2021 giải thích cách bỏ qua các hạn chế về namespace bằng cách nhập các ảnh chụp nhanh từ nhà cung cấp đám mây dưới dạng hình ảnh chuẩn (golden images) để tạo ra các môi trường phát triển nhanh chóng và cô lập.

Hình minh họa một volume dữ liệu đơn lẻ được nhân bản thành nhiều bản sao cô lập
Hình ảnh: Kubernetes Blog, giấy phép CC BY 4.0

Được dịch tự động từ bản gốc tiếng Anh.

Trong một bài đăng trên Blog Kubernetes vào tháng 9 năm 2021, Augustinas Stirbis từ CAST AI đã trình bày một phương pháp xử lý việc nhân bản dữ liệu trong các cụm tiêu tốn nhiều tài nguyên. Bài viết đề cập đến các nút thắt cổ chai về hiệu suất khi sao chép các tập dữ liệu lớn và đề xuất sử dụng VolumeSnapshots được cung cấp trước để tạo ra các môi trường phát triển cô lập một cách hiệu quả.

Chuyện gì đã xảy ra

Các nhà phát triển thường cần những bản sao chính xác của dữ liệu sản xuất để kiểm tra các thay đổi schema hoặc thực hiện các thao tác hàng loạt mà không gây rủi ro cho hệ thống đang chạy trực tiếp. Theo truyền thống, quy trình này liên quan đến việc tải dữ liệu từ lưu trữ khối xuống các nút tính toán và sau đó tải ngược lại lên lưu trữ. Quá trình này tiêu tốn đáng kể băng thông mạng, CPU và RAM, dẫn đến chu kỳ lặp lại chậm chạp và chi phí hạ tầng cao. Tăng tốc phần cứng có thể giúp ích, nhưng sự kém hiệu quả cơ bản của việc di chuyển dữ liệu qua mạng vẫn là một rào cản lớn.

Kubernetes đã giới thiệu VolumeSnapshots để giải quyết vấn đề này, đạt trạng thái General Availability (GA) ở phiên bản 1.20 sau khi bắt đầu ở giai đoạn alpha trong 1.12 và beta trong 1.17. Các ảnh chụp nhanh này tận dụng API của nhà cung cấp lưu trữ để nhân bản các volume dữ liệu. Đối với các hệ thống on-premise, đây thường là một thao tác metadata chỉ trỏ một đĩa mới đến một ảnh chụp nhanh bất biến, chỉ lưu lại các khác biệt. Trong các đám mây công cộng, các ảnh chụp nhanh được lưu trữ trong object storage và được sao chép ngược lại vào block storage. Mặc dù điều này vẫn sử dụng tài nguyên tính toán và mạng ở phía nhà cung cấp, nó giảm bớt gánh nặng cho chính cụm Kubernetes, khiến thao tác trở nên tức thời đối với người dùng.

Tuy nhiên, tồn tại một hạn chế về thiết kế: VolumeSnapshots được gắn với namespace. Kubernetes ngăn chặn các pod trong một namespace mount các PersistentVolumeClaims (PVCs) trong namespace khác nhằm đảm bảo sự cô lập giữa các tenant. Điều này có nghĩa là một ảnh chụp nhanh được tạo trong namespace sản xuất không thể được tham chiếu trực tiếp bởi namespace phát triển. Việc tạo các volume trùng lặp trong cùng một namespace là khả thi nhưng rủi ro, vì nó làm tăng nguy cơ tham chiếu nhầm bản sao và làm suy yếu các biện pháp kiểm soát truy cập.

Cách thức hoạt động

Giải pháp được đề xuất bỏ qua các hạn chế về namespace của Kubernetes bằng cách tạo một "golden snapshot" (ảnh chụp nhanh chuẩn) từ bên ngoài. Thay vì sử dụng API Kubernetes để chụp ảnh ban đầu, quản trị viên sử dụng các công cụ của nhà cung cấp đám mây để ghi lại trạng thái đĩa. Ảnh chụp nhanh bên ngoài này sau đó được nhập vào Kubernetes dưới dạng VolumeSnapshotContent, một tài nguyên có phạm vi toàn cụm (cluster-scoped) không bị ràng buộc với một namespace cụ thể. Nội dung này đóng vai trò như một cầu nối, cho phép nhiều namespace tham chiếu cùng một nguồn dữ liệu cơ sở.

Hình từ bài viết gốc: Efficient data cloning in Kubernetes using external volume snapshots
Hình từ bài viết gốc · Kubernetes Blog · CC BY 4.0

Sau khi VolumeSnapshotContent được thiết lập, các nhóm có thể tạo một VolumeSnapshot trong namespace cụ thể của họ, ánh xạ tới nội dung toàn cục này. Từ đó, họ tạo một PersistentVolumeClaim dựa trên ảnh chụp nhanh đó. PVC này sau đó có thể được mount bởi các deployment hoặc stateful set trong môi trường phát triển. Mỗi nhóm nhận được một bản sao dữ liệu duy nhất, có thể ghi được, trong khi ảnh chụp nhanh chuẩn gốc vẫn giữ nguyên trạng thái bất biến và được chia sẻ hiệu quả trong toàn bộ cụm.

Chi tiết chính

  • VolumeSnapshots đã trở thành Generally Available trong Kubernetes phiên bản 1.20, sau khi trải qua giai đoạn alpha ở 1.12 và beta ở 1.17.
  • Việc nhân bản dữ liệu bằng các phương pháp tải xuống-tải lên truyền thống tiêu thụ lượng lưu lượng mạng và tài nguyên tính toán quá mức so với các ảnh chụp nhanh ở cấp độ lưu trữ.
  • VolumeSnapshots của Kubernetes được thiết kế theo namespace, ngăn chặn việc mount PVC chéo namespace trực tiếp để bảo vệ sự cô lập tenant.
  • Giải pháp tình thế liên quan đến việc cung cấp trước một ảnh chụp nhanh thông qua các công cụ CLI của nhà cung cấp đám mây như AWS CLI hoặc gcloud, bên ngoài Kubernetes.
  • Quản trị viên nhập ID ảnh chụp nhanh bên ngoài dưới dạng VolumeSnapshotContent, một tài nguyên cluster-scoped có thể được tham chiếu bởi bất kỳ namespace nào.
  • Mỗi nhóm tạo một VolumeSnapshot cục bộ và PVC ánh xạ tới VolumeSnapshotContent toàn cục, đảm bảo các bản sao dữ liệu giống hệt nhau nhưng được cô lập.

Tại sao điều này quan trọng

Đối với các kỹ sư phần mềm và SRE quản lý các ứng dụng nặng dữ liệu, phương pháp này giảm đáng kể thời gian và chi phí liên quan đến việc khởi động các môi trường staging hoặc thử nghiệm. Bằng cách tránh nhu cầu di chuyển các tập dữ liệu lớn qua mạng lặp đi lặp lại, các nhóm có thể lặp lại nhanh hơn trên các thay đổi schema cơ sở dữ liệu và các tính năng đòi hỏi nhiều dữ liệu. Nó cũng phù hợp với các thực hành bảo mật tốt nhất bằng cách giữ các namespace sản xuất bị khóa chặt trong khi vẫn cung cấp cho nhà phát triển các tập dữ liệu thực tế.

Hình từ bài viết gốc: Efficient data cloning in Kubernetes using external volume snapshots
Hình từ bài viết gốc · Kubernetes Blog · CC BY 4.0

Việc hiểu rõ sự khác biệt giữa các tài nguyên theo namespace như VolumeSnapshots và các tài nguyên cluster-scoped như VolumeSnapshotContent là rất quan trọng cho các hoạt động Kubernetes nâng cao. Mô hình này minh họa cách tận dụng các khả năng của nhà cung cấp đám mây song song với các lớp trừu tượng của Kubernetes để vượt qua các hạn chế của nền tảng. Nó nhấn mạnh tầm quan trọng của việc biết khi nào cần bước ra ngoài API Kubernetes để đạt được hiệu suất và tính linh hoạt tối ưu.

Bạn có thể làm gì

  • Xác định PersistentVolumeClaim trong namespace sản xuất của bạn đóng vai trò là nguồn cho bản sao dữ liệu chuẩn.
  • Sử dụng console hoặc CLI của nhà cung cấp đám mây để tạo một ảnh chụp nhanh của đĩa cơ sở, ghi nhớ ID ảnh chụp nhanh.
  • Tạo một manifest VolumeSnapshotContent trong Kubernetes tham chiếu đến ID ảnh chụp nhanh bên ngoài từ nhà cung cấp đám mây của bạn.
  • Định nghĩa một VolumeSnapshot trong mỗi namespace phát triển mục tiêu, liên kết với VolumeSnapshotContent toàn cụm.
  • Tạo một PersistentVolumeClaim trong namespace phát triển sử dụng VolumeSnapshot cục bộ làm nguồn dữ liệu.
  • Triển khai ứng dụng hoặc stateful set cơ sở dữ liệu của bạn bằng PVC mới để xác minh rằng bản sao dữ liệu có thể truy cập được và được cô lập.

Công cụ từ cửa hàng Bytechap

Đọc tiếp

Tất cả bài viết