Có một số cách để định cấu hình lưu trữ dữ liệu cho các ứng dụng chạy trên cụm Kubernetes. Một số trong số chúng đã lỗi thời, một số khác xuất hiện khá gần đây. Trong bài viết này, chúng ta sẽ xem xét khái niệm về ba tùy chọn để kết nối hệ thống lưu trữ, trong đó có tùy chọn gần đây nhất - kết nối qua Giao diện lưu trữ container.
Phương pháp 1: Chỉ định PV trong bảng kê khai nhóm
Một bảng kê khai điển hình mô tả một nhóm trong cụm Kubernetes:
Các phần của tệp kê khai mô tả ổ đĩa nào được kết nối và vị trí được đánh dấu bằng màu.
Trong phần khối lượnggắn kết cho biết các điểm gắn kết (mountPath) - thư mục nào bên trong vùng chứa mà ổ đĩa cố định sẽ được gắn vào, cũng như tên của ổ đĩa.
Trong phần x liệt kê tất cả các tập được sử dụng trong nhóm. Chỉ định tên của từng ổ đĩa, cũng như loại (trong trường hợp của chúng tôi: awsElasticBlockStore) và các tham số kết nối. Những tham số nào được liệt kê trong tệp kê khai tùy thuộc vào loại ổ đĩa.
Cùng một ổ đĩa có thể được gắn đồng thời vào nhiều thùng chứa nhóm. Bằng cách này, các quy trình ứng dụng khác nhau có thể truy cập cùng một dữ liệu.
Phương thức kết nối này được phát minh ngay từ đầu, khi Kubernetes mới ở giai đoạn sơ khai và ngày nay phương thức này đã lỗi thời.
Có một số vấn đề khi sử dụng nó:
- tất cả các tập phải được tạo thủ công; Kubernetes không thể tạo bất cứ thứ gì cho chúng tôi;
- các tham số truy cập cho mỗi ổ là duy nhất và chúng phải được chỉ định trong bảng kê khai của tất cả các nhóm sử dụng ổ;
- để thay đổi hệ thống lưu trữ (ví dụ: chuyển từ AWS sang Google Cloud), bạn cần thay đổi cài đặt và loại ổ đĩa được gắn trong tất cả các bảng kê khai.
Tất cả điều này rất bất tiện, vì vậy trong thực tế, phương pháp này chỉ được sử dụng để kết nối một số loại tập đặc biệt: configMap, secret, EmptyDir, HostPath:
-
configMap và secret là các khối dịch vụ cho phép bạn tạo một khối chứa các tệp từ tệp kê khai Kubernetes trong vùng chứa.
-
EmptyDir là một ổ đĩa tạm thời, chỉ được tạo trong suốt thời gian tồn tại của nhóm. Thuận tiện sử dụng để kiểm tra hoặc lưu trữ dữ liệu tạm thời. Khi một nhóm bị xóa, ổ đĩa trốngDir cũng bị xóa và tất cả dữ liệu sẽ bị mất.
-
HostPath - cho phép bạn gắn bất kỳ thư mục nào vào đĩa cục bộ của máy chủ nơi ứng dụng đang chạy bên trong vùng chứa ứng dụng, bao gồm /etc/kubernetes. Đây là một tính năng không an toàn nên các chính sách bảo mật thường cấm sử dụng các ổ đĩa thuộc loại này. Nếu không, ứng dụng của kẻ tấn công sẽ có thể gắn thư mục HTC Kubernetes vào bên trong vùng chứa của nó và đánh cắp tất cả các chứng chỉ cụm. Thông thường, các ổ đĩa hostingPath chỉ được phép sử dụng bởi các ứng dụng hệ thống chạy trong không gian tên kube-system.
được đưa ra trong tài liệu.
Phương pháp 2. Kết nối với lò sưởi SC/PVC/PV
Một phương thức kết nối thay thế là khái niệm lớp Lưu trữ, PersistentVolumeClaim, PersistentVolume.
Lớp lưu trữ lưu trữ các thông số kết nối vào hệ thống lưu trữ dữ liệu.
PersentlyVolumeClaim mô tả các yêu cầu cho những gì ứng dụng cần.
PersentlyVolume lưu trữ các tham số truy cập và trạng thái âm lượng.
Bản chất của ý tưởng: trong bảng kê khai nhóm, chúng chỉ ra một tập thuộc loại PersistentVolumeClaim và cho biết tên của thực thể này trong tham số ClaimName.
Tệp kê khai PersistentVolumeClaim mô tả các yêu cầu về khối lượng dữ liệu mà ứng dụng yêu cầu. Bao gồm:
- kích thước đĩa;
- phương thức truy cập: ReadWriteOnce hoặc ReadWriteMany;
- liên kết đến lớp Storage - trong hệ thống lưu trữ dữ liệu nào chúng ta muốn tạo ổ đĩa.
Tệp kê khai lớp Lưu trữ lưu trữ loại và tham số của kết nối với hệ thống lưu trữ. Khối lập phương cần chúng để gắn âm lượng vào nút của nó.
Tệp kê khai PersistentVolume cho biết lớp Lưu trữ và các tham số truy cập cho một ổ đĩa cụ thể (ID ổ đĩa, đường dẫn, v.v.).
Khi tạo PVC, Kubernetes xem xét kích thước ổ đĩa và lớp lưu trữ được yêu cầu rồi chọn PersistentVolume miễn phí.
Nếu không có các PV như vậy, Kubernetes có thể khởi chạy một chương trình đặc biệt - Nhà cung cấp (tên của nó được chỉ định trong lớp Lưu trữ). Chương trình này kết nối với hệ thống lưu trữ, tạo một ổ đĩa có kích thước được yêu cầu, nhận mã định danh và tạo một tệp kê khai PersistentVolume trong cụm Kubernetes, được liên kết với PersistentVolumeClaim.
Tất cả tập hợp trừu tượng này cho phép bạn xóa thông tin về hệ thống lưu trữ mà ứng dụng đang làm việc từ cấp bảng kê khai ứng dụng đến cấp quản trị.
Tất cả các tham số để kết nối với hệ thống lưu trữ dữ liệu đều nằm trong lớp Lưu trữ do quản trị viên cụm chịu trách nhiệm. Tất cả những gì bạn cần làm khi chuyển từ AWS sang Google Cloud là đổi tên của lớp Storage thành PVC trong tệp kê khai ứng dụng. Khối lượng ổn định để lưu trữ dữ liệu sẽ được tạo tự động trong cụm bằng chương trình Nhà cung cấp.
Phương pháp 3: Giao diện lưu trữ container
Tất cả mã tương tác với các hệ thống lưu trữ khác nhau đều là một phần của lõi Kubernetes. Việc phát hành các bản sửa lỗi hoặc chức năng mới gắn liền với các bản phát hành mới; mã phải được thay đổi đối với tất cả các phiên bản Kubernetes được hỗ trợ. Tất cả điều này rất khó để duy trì và thêm chức năng mới.
Để giải quyết vấn đề, các nhà phát triển từ Cloud Foundry, Kubernetes, Mesos và Docker đã tạo Giao diện lưu trữ container (CSI) - một giao diện hợp nhất đơn giản mô tả sự tương tác của hệ thống quản lý container và trình điều khiển đặc biệt (Trình điều khiển CSI) hoạt động với một thiết bị cụ thể. hệ thống lưu trữ. Tất cả mã để tương tác với hệ thống lưu trữ đã được chuyển từ lõi Kubernetes sang một hệ thống riêng biệt.
.
Thông thường, CSI Driver gồm có XNUMX thành phần: Node Plugin và Controller plugin.
Plugin Node chạy trên mỗi nút và chịu trách nhiệm gắn các ổ đĩa cũng như thực hiện các thao tác trên chúng. Plugin Trình điều khiển tương tác với hệ thống lưu trữ: tạo hoặc xóa ổ đĩa, gán quyền truy cập, v.v.
Hiện tại, các trình điều khiển cũ vẫn còn trong kernel Kubernetes, nhưng chúng không còn được khuyến nghị sử dụng nữa và mọi người nên cài đặt Trình điều khiển CSI dành riêng cho hệ thống mà chúng sẽ hoạt động.
Sự đổi mới có thể khiến những người đã quen với việc thiết lập lưu trữ dữ liệu thông qua lớp Storage sợ hãi, nhưng trên thực tế, không có gì khủng khiếp xảy ra. Đối với các lập trình viên, không có gì thực sự thay đổi - họ chỉ làm việc với tên lớp Storage và sẽ tiếp tục làm như vậy. Đối với quản trị viên, cài đặt biểu đồ trợ giúp đã được thêm vào và cấu trúc cài đặt đã thay đổi. Nếu trước đây các cài đặt được nhập trực tiếp vào lớp Lưu trữ thì bây giờ trước tiên chúng phải được đặt trong biểu đồ lãnh đạo, sau đó là trong lớp Lưu trữ. Nếu bạn nhìn vào nó, không có gì xấu xảy ra cả.
Hãy lấy một ví dụ để xem những lợi ích bạn có thể nhận được bằng cách chuyển sang kết nối hệ thống lưu trữ Ceph bằng trình điều khiển CSI.
Khi làm việc với Ceph, plugin CSI cung cấp nhiều tùy chọn hơn để làm việc với hệ thống lưu trữ so với trình điều khiển tích hợp sẵn.
- Tạo đĩa động. Thông thường, các đĩa RBD chỉ được sử dụng ở chế độ RWO, nhưng CSI cho Ceph cho phép chúng được sử dụng ở chế độ RWX. Một số nhóm trên các nút khác nhau có thể gắn cùng một đĩa RDB trên các nút của chúng và hoạt động song song với chúng. Công bằng mà nói, không phải mọi thứ đều sáng sủa như vậy - đĩa này chỉ có thể được kết nối dưới dạng thiết bị khối, có nghĩa là bạn sẽ phải điều chỉnh ứng dụng để hoạt động với nó ở chế độ đa truy cập.
- Tạo ảnh chụp nhanh. Trong cụm Kubernetes, bạn có thể tạo một bảng kê khai với yêu cầu tạo ảnh chụp nhanh. Plugin CSI sẽ nhìn thấy nó và chụp ảnh nhanh từ đĩa. Dựa vào đó, bạn có thể tạo bản sao lưu hoặc bản sao của PersistentVolume.
- Tăng kích thước đĩa về bộ lưu trữ và PersistentVolume trong cụm Kubernetes.
- Hạn ngạch. Trình điều khiển CephFS được tích hợp trong Kubernetes không hỗ trợ hạn ngạch, nhưng các plugin CSI mới với Ceph Nautilus mới nhất có thể kích hoạt hạn ngạch trên các phân vùng CephFS.
- Số liệu. Plugin CSI có thể cung cấp cho Prometheus nhiều số liệu khác nhau về khối lượng nào được kết nối, hoạt động liên lạc nào đang diễn ra, v.v.
- Nhận biết cấu trúc liên kết. Cho phép bạn chỉ định trong tệp kê khai cách cụm được phân bổ theo địa lý và tránh kết nối hệ thống lưu trữ ở Amsterdam với các nhóm đang chạy ở Luân Đôn.
Cách kết nối Ceph với cụm Kubernetes qua CSI, xem . Bạn cũng có thể đăng ký , sẽ ra mắt vào ngày 15 tháng XNUMX.
Tác giả bài viết: Sergey Bondarev, kiến trúc sư hành nghề tại Southbridge, Quản trị viên Kubernetes được chứng nhận, một trong những nhà phát triển kubespray.
Một chút Post Scriptum không phải để quảng cáo mà vì lợi ích...
PS Sergey Bondarev dẫn đầu hai khóa học chuyên sâu: đã cập nhật 28-30 tháng XNUMX và nâng cao Ngày 14–16 tháng XNUMX.
Nguồn: www.habr.com