Chạy database trên Kubernetes. Nên hay không nên?

quynhpham

Hiện nay, ngày càng có nhiều ứng dụng được triển khai trong các container trên Kubernetes, đến mức Kubernetes được gọi là Linux của Cloud. Bất chấp tất cả sự tăng trưởng đó trên application layer, data layer (lớp dữ liệu) đã không còn phổ biến với công nghệ ảo hóa sử dụng container (containerization) . Điều đó không có gì đáng ngạc nhiên, vì khối lượng công việc container hóa vốn phải có khả năng phục hồi để restart, scaling, ảo hóa và các ràng buộc khác. Vì vậy, xử lý những thứ như cơ sở dữ liệu, tính khả dụng cho các lớp khác của ứng dụng và dự phòng cho database có thể đòi hỏi các yêu cầu rất cụ thể. Điều đó gây khó khăn để chạy database trong một môi trường phân tán (distributed environment).

390
Tuy nhiên, data layer đang được chú ý nhiều hơn, vì nhiều developer muốn coi cơ sở hạ tầng dữ liệu giống như ngăn xếp ứng dụng. Các nhà khai thác muốn sử dụng những công cụ chung cho database và ứng dụng, đồng thời nhận được các lợi ích giống như lớp ứng dụng trong lớp dữ liệu: quay vòng nhanh và lặp lại giữa các môi trường. Bài viết này sẽ trả lời câu hơi “Khi nào và loại cơ sở dữ liệu nào có thể chạy hiệu quả trên Kubernetes?”

Trước khi đi sâu vào các vấn đề cần cân nhắc để chạy cơ sở dữ liệu trên Kubernetes, cùng tóm tắt lại các tùy chọn của Kubernetes để chạy cơ sở dữ liệu trên Google Cloud Platform (GCP) và những gì chúng được sử dụng tốt nhất.

• Quản lý cơ sở dữ liệu đầy đủ, bao gồm Cloud Spanner, Cloud Bigtable và Cloud SQL trong số những cơ sở dữ liệu khác. Đây là lựa chọn ở mức thâp (low-ops), vì Google Cloud xử lý nhiều tác vụ bảo trì như: sao lưu, vá lỗi và chia tỉ lệ. Là developer hoặc operator, bạn không cần quan tâm đến những vấn đề đó, mà chỉ cần tạo cơ sở dữ liệu, xây dựng ứng dụng của mình và để Google Cloud mở rộng quy mô cho bạn. Tức là bạn có thể không có quyền truy cập vào phiên bản chính xác của database, tiện ích mở rộng hoặc flavor chính xác của database mà bạn muốn.

(Người dịch: Flavor là một phần cứng có sẵn của một máy chủ. Nó xác định kích thước của một máy chủ ảo được khởi chạy.)

• “Do-it-yourself” trên máy ảo. Điều này có thể mô tả được tốt nhất tùy chọn full-ops, nơi bạn chịu trách nhiệm hoàn toàn cho việc xây dựng cơ sở dữ liệu của mình, xác định kích thước, quản lý độ tin cậy, thiết lập sao lưu... Tất nhiên nó sẽ bao gồm nhiều công việc, nhưng bạn có tất cả các tính năng và flavor database theo ý của bạn.
• Chạy database trên Kubernetes. Chạy một database trên Kubernetes gần giống với tùy chọn full-ops, nhưng bạn có thêm một số lợi ích về mặt tự động hóa mà Kubernetes cung cấp để duy trì việc chạy ứng dụng cơ sở dữ liệu. Điều quan trọng cần nhớ là các pod (các container của ứng dụng CSDL) là nhất thời, vì vậy khả năng khởi động lại hoặc thất bại của ứng dụng cơ sở dữ liệu cao hơn. Ngoài ra, một số tác vụ quản trị dành riêng cho cơ sở dữ liệu khác: Sao lưu, chia tỉ lệ, điều chỉnh, v.v., khác nhau do các abstraction được thêm vào đi kèm với công nghệ ảo hóa containerization.

Một số tip để chạy cơ sở dữ liệu trên Kubernetes

- Hãy suy nghĩ về cơ sở dữ liệu nào bạn sẽ chạy, và nó sẽ hoạt động hiệu quả hơn như nào trước khi lựa chọn định tuyến Kubernetes.
Vì các pods là trọng yếu, nên khả năng xảy ra các vấn đề chuyển đổi dự phòng cao hơn một cơ sở dữ liệu được lưu trữ hoặc quản lý đầy đủ theo truyền thống. Sẽ dễ dàng hơn để chạy database trên Kubernetes nếu nó bao gồm các khái niệm như sharding (tách dữ liệu), các lựa chọn chịu lỗi (failover selection) và sao chép được tích hợp vào DNA của nó (ví dụ: ElasticSearch, Cassandra hoặc MongoDB). Một số dự án nguồn mở cung cấp các tài nguyên và operator tùy chỉnh để giúp quản lý cơ sở dữ liệu.

- Tiếp theo, hãy xem xét chức năng, vai trò của CSDL với ứng dụng và Doanh nghiệp của bạn. Cơ sở dữ liệu đang lưu trữ nhiều transient layer và Cache layer phù hợp hơn với Kubernetes. Các data layer loại đó thường có khả năng phục hồi cao hơn, được tích hợp vào các ứng dụng, giúp mang lại trải nghiệm tổng thể tốt hơn.

- Cuối cùng, hãy chắc chắn rằng bạn hiểu các chế độ sao chép có sẵn trong cơ sở dữ liệu. Các chế độ sao chép không đồng bộ sẽ dẫn tới mất dữ liệu, vì các giao dịch có thể được cam kết với cơ sở dữ liệu chính mà không phải các cơ sở dữ liệu thứ cấp. Vì vậy, hãy chắc chắn để hiểu liệu bạn có thể chịu mất dữ liệu hay không và mức độ chấp nhận được với ứng dụng của bạn.

Sau khi đánh giá tất cả những cân nhắc đó, bạn có thể sẽ kết thúc với một sơ đồ quyết định như sau:

389


Cách triển khai cơ sở dữ liệu trên Kubernetes

Bây giờ, hãy cùng đào sâu vào chi tiết hơn về cách triển khai cơ sở dữ liệu trên Kubernetes bằng StatefulSets. Với Statefulset, dữ liệu của bạn có thể được lưu trữ trên các persistent volumes, tách ứng dụng cơ sở dữ liệu khỏi persistent storage, do đó, khi một pod (như ứng dụng cơ sở dữ liệu) được tạo lại, tất cả dữ liệu vẫn ở đó. Ngoài ra, khi một nhóm được tạo lại trong Statefulset, nó sẽ giữ cùng tên, do đó bạn có một điểm cuối (endpoint) nhất quán để kết nối. Dữ liệu liên tục và đặt tên nhất quán là hai trong số những lợi ích lớn nhất của StatefulSets. Bạn có thể kiểm tra tài liệu Kubernetes để biết thêm chi tiết.

Nếu bạn cần chạy một cơ sở dữ liệu không phù hợp với mô hình của cơ sở dữ liệu thân thiện với Kubernetes (như MySQL hoặc PostgreQuery), hãy cân nhắc sử dụng Kubernetes Operators hoặc các dự án bao bọc các cơ sở dữ liệu đó bằng các tính năng bổ sung. Các operators sẽ giúp bạn chạy các cơ sở dữ liệu đó và thực hiện các nhiệm vụ bảo trì cơ sở dữ liệu như sao lưu và sao chép. Đối với MySQL nói riêng, hãy xem Trình điều khiển Oracle MySQL và Crunchy Data cho PostgreQuery.

Các operator sử dụng các tài nguyên và bộ điều khiển tùy chỉnh để hiển thị các hoạt động dành riêng cho ứng dụng thông qua Kubernetes API. Ví dụ: để thực hiện sao lưu bằng Crunchy Data, chỉ cần thực hiện sao lưu
Mã:
pgo backup [cluster_name]
Để thêm bản sao Postgres, hãy sử dụng
Mã:
pgo scale cluster [cluster_name]
.

Có một số dự án khác có thể tìm hiểu thêm, chẳng hạn như Patroni cho PostgreSQL. Các dự án này sử dụng các operator, nhưng tiến thêm một bước. Họ đã xây dựng nhiều công cụ xung quanh cơ sở dữ liệu tương ứng để hỗ trợ hoạt động của họ bên trong Kubernetes. Chúng có thể bao gồm các tính năng bổ sung như sharding, leader election và chức năng chuyển đổi dự phòng cần thiết để triển khai thành công MySQL hoặc PostgreQuery trong Kubernetes.

Mặc dù việc chạy một cơ sở dữ liệu trong Kubernetes đang đạt được sức hút, nó vẫn còn xa so với một lĩnh vực khoa học chính xác. Có rất nhiều công việc đang được thực hiện trong lĩnh vực này, vì vậy hãy chú ý khi các công nghệ và công cụ phát triển theo hướng làm cho việc chạy cơ sở dữ liệu trong Kubernetes trở nên bình thường hơn nhiều.

Khi bạn đã sẵn sàng để bắt đầu, hãy xem GCP Marketplace để biết các giải pháp và operator mà cơ sở dữ liệu được triển khai dễ dàng có thể triển khai đến các cụm GCP hoặc Kubernetes ở bất cứ đâu.
Nguồn:
 
Top