Khối lượng phù du với tính năng theo dõi dung lượng lưu trữ: EmptyDir trên Steroid

Khối lượng phù du với tính năng theo dõi dung lượng lưu trữ: EmptyDir trên Steroid

Một số ứng dụng cũng cần lưu trữ dữ liệu, nhưng chúng khá thoải mái với việc dữ liệu sẽ không được lưu sau khi khởi động lại.

Ví dụ: dịch vụ bộ nhớ đệm bị giới hạn bởi RAM nhưng cũng có thể di chuyển dữ liệu hiếm khi được sử dụng sang bộ nhớ chậm hơn RAM mà ít ảnh hưởng đến hiệu suất tổng thể. Các ứng dụng khác cần lưu ý rằng có thể có một số đầu vào chỉ đọc trong tệp, chẳng hạn như cài đặt hoặc khóa bí mật.

Kubernetes đã có một số loại khối lượng phù du, nhưng chức năng của chúng bị giới hạn ở những gì được triển khai trong K8.

Không lâu khối lượng CSI cho phép Kubernetes được mở rộng với trình điều khiển CSI để cung cấp hỗ trợ cho khối lượng cục bộ nhẹ. Bằng cách này có thể sử dụng cấu trúc tùy ý: cài đặt, bí mật, dữ liệu nhận dạng, biến, v.v. Trình điều khiển CSI phải được sửa đổi để hỗ trợ tính năng Kubernetes này, vì người ta cho rằng các trình điều khiển được tiêu chuẩn hóa thông thường sẽ không hoạt động - nhưng người ta cho rằng các ổ đĩa như vậy có thể được sử dụng trên bất kỳ nút nào được chọn cho nhóm.

Đây có thể là sự cố đối với các ổ đĩa tiêu thụ tài nguyên máy chủ đáng kể hoặc đối với bộ lưu trữ chỉ khả dụng trên một số máy chủ. Đó là lý do tại sao Kubernetes 1.19 giới thiệu hai tính năng khối thử nghiệm alpha mới có khái niệm tương tự như khối EmptyDir:

  • khối lượng phù du cho mục đích chung;

  • Theo dõi dung lượng lưu trữ CSI.

Ưu điểm của phương pháp mới:

  • lưu trữ có thể cục bộ hoặc được kết nối qua mạng;

  • các tập có thể có kích thước được chỉ định mà ứng dụng không thể vượt quá;

  • hoạt động với bất kỳ trình điều khiển CSI nào hỗ trợ cung cấp khối lượng liên tục và (để hỗ trợ theo dõi dung lượng) thực hiện lệnh gọi GetCapacity;

  • các ổ đĩa có thể có một số dữ liệu ban đầu tùy thuộc vào trình điều khiển và cài đặt;

  • tất cả các thao tác tiêu chuẩn với âm lượng (tạo ảnh chụp nhanh, thay đổi kích thước, v.v.) đều được hỗ trợ;

  • khối lượng có thể được sử dụng với bất kỳ bộ điều khiển ứng dụng nào chấp nhận thông số kỹ thuật mô-đun hoặc khối lượng;

  • Bộ lập lịch Kubernetes tự chọn các nút phù hợp, do đó không cần phải cung cấp và định cấu hình tiện ích mở rộng bộ lập lịch hoặc sửa đổi webhooks nữa.

Tùy chọn ứng dụng

Do đó, khối lượng tạm thời cho mục đích chung phù hợp cho các trường hợp sử dụng sau:

Bộ nhớ liên tục thay thế RAM cho memcached

Bản phát hành mới nhất của memcached hỗ trợ thêm sử dụng bộ nhớ liên tục (Intel Optane, v.v., khoảng người phiên dịch) thay vì RAM thông thường. Ví dụ: khi triển khai memcached thông qua bộ điều khiển ứng dụng, bạn có thể sử dụng các ổ đĩa tạm thời cho mục đích chung để yêu cầu phân bổ ổ đĩa có kích thước nhất định từ PMEM bằng trình điều khiển CSI. PMEM-CSI.

Bộ nhớ cục bộ LVM dưới dạng không gian làm việc

Các ứng dụng hoạt động với dữ liệu lớn hơn RAM có thể yêu cầu bộ nhớ cục bộ với kích thước hoặc số liệu hiệu suất mà các khối EmptyDir thông thường từ Kubernetes không thể cung cấp. Ví dụ, vì mục đích này nó đã được viết TopoLVM.

Quyền truy cập chỉ đọc cho khối lượng dữ liệu

Việc phân bổ một tập có thể dẫn đến việc tạo ra một tập đầy đủ khi:

Các ổ đĩa này có thể được gắn vào chế độ chỉ đọc.

Làm thế nào nó hoạt động

Khối lượng phù du cho mục đích chung

Một tính năng chính của các tập đĩa phù du cho mục đích chung là nguồn tập đĩa mới, EphemeralVolumeSource, chứa tất cả các trường để tạo yêu cầu âm lượng (trước đây gọi là yêu cầu âm lượng liên tục, PVC). Bộ điều khiển mới trong kube-controller-manager xem xét các nhóm tạo ra nguồn âm lượng như vậy, sau đó tạo PVC cho các nhóm đó. Đối với trình điều khiển CSI, yêu cầu này trông giống như các yêu cầu khác nên không cần hỗ trợ đặc biệt ở đây.

Miễn là các PVC như vậy tồn tại, chúng có thể được sử dụng như bất kỳ yêu cầu nào khác trên tập đĩa. Đặc biệt, chúng có thể được tham chiếu dưới dạng nguồn dữ liệu khi sao chép ổ đĩa hoặc tạo ảnh chụp nhanh từ ổ đĩa. Đối tượng PVC cũng chứa trạng thái hiện tại của ổ đĩa.

Tên của các PVC được tạo tự động được xác định trước: chúng là sự kết hợp giữa tên nhóm và tên ổ đĩa, được phân tách bằng dấu gạch nối. Tên được xác định trước giúp tương tác với PVC dễ dàng hơn vì bạn không cần phải tìm nó nếu bạn biết tên nhóm và tên ổ đĩa. Nhược điểm là tên này có thể đã được sử dụng, điều này bị Kubernetes phát hiện và kết quả là nhóm bị chặn khởi động.

Để đảm bảo rằng âm lượng bị xóa cùng với nhóm, bộ điều khiển sẽ đưa ra yêu cầu đối với âm lượng thuộc chủ sở hữu. Khi nhóm bị xóa, cơ chế thu gom rác tiêu chuẩn sẽ hoạt động, xóa cả yêu cầu và âm lượng.

Các yêu cầu được trình điều khiển lưu trữ khớp thông qua cơ chế thông thường của lớp lưu trữ. Mặc dù các lớp có ràng buộc ngay lập tức và muộn (còn gọi là WaitForFirstConsumer) được hỗ trợ, đối với các khối lượng phù du, việc sử dụng là hợp lý WaitForFirstConsumer, thì bộ lập lịch có thể xem xét cả việc sử dụng nút và tính khả dụng của bộ nhớ khi chọn một nút. Một tính năng mới xuất hiện ở đây.

Theo dõi dung lượng lưu trữ

Thông thường, bộ lập lịch không biết trình điều khiển CSI sẽ tạo ổ đĩa ở đâu. Người lập lịch trình cũng không có cách nào liên hệ trực tiếp với tài xế để yêu cầu thông tin này. Do đó, bộ lập lịch sẽ thăm dò các nút cho đến khi tìm thấy một nút trên đó có thể truy cập được (liên kết muộn) hoặc để lại toàn bộ việc lựa chọn vị trí cho trình điều khiển (liên kết ngay lập tức).

mới API CSIStorageCapacity, đang ở giai đoạn alpha, cho phép dữ liệu cần thiết được lưu trữ trong etcd để có sẵn cho bộ lập lịch. Không giống như hỗ trợ cho các ổ đĩa tạm thời cho mục đích chung, khi triển khai trình điều khiển, bạn phải bật tính năng theo dõi dung lượng lưu trữ: external-provisioner nên công bố thông tin dung lượng nhận được từ driver qua đường truyền thông thường GetCapacity.

Nếu người lên lịch cần chọn một nút cho một nhóm có ổ đĩa không liên kết sử dụng liên kết muộn và trình điều khiển đã bật tính năng này trong quá trình triển khai bằng cách đặt cờ CSIDriver.storageCapacity, khi đó các nút không có đủ dung lượng lưu trữ sẽ tự động bị loại bỏ. Điều này hoạt động cho cả khối lượng tạm thời và liên tục cho mục đích chung, nhưng không áp dụng cho khối lượng tạm thời CSI vì Kubernetes không thể đọc được các tham số của chúng.

Như thường lệ, các khối được liên kết ngay lập tức được tạo trước khi các nhóm được lên lịch và vị trí của chúng được trình điều khiển lưu trữ chọn, vì vậy khi định cấu hình external-provisioner Theo mặc định, các lớp lưu trữ có liên kết ngay lập tức sẽ bị bỏ qua vì dữ liệu này sẽ không được sử dụng.

Vì bộ lập lịch kubernetes buộc phải làm việc với thông tin có khả năng lỗi thời nên không có gì đảm bảo rằng dung lượng sẽ có sẵn trong mọi trường hợp khi ổ đĩa được tạo, tuy nhiên, khả năng nó sẽ được tạo mà không cần thử lại vẫn tăng lên.

NB Bạn có thể nhận được thông tin chi tiết hơn, cũng như "thực hành trên giá mèo" một cách an toàn và trong trường hợp tình huống hoàn toàn khó hiểu, hãy nhận hỗ trợ kỹ thuật đủ tiêu chuẩn tại các khóa học chuyên sâu - Cơ sở Kubernetes sẽ được tổ chức vào ngày 28-30 tháng XNUMX và dành cho các chuyên gia cao cấp hơn Kubernetes Mega Ngày 14–16 tháng XNUMX.

Безопасность

Dung lượng lưu trữ CSIS

Các đối tượng CSIStorageCapacity nằm trong không gian tên; khi triển khai từng trình điều khiển CSI trong không gian tên riêng của nó, bạn nên hạn chế các quyền RBAC đối với CSIStorageCapacity trong không gian đó vì dữ liệu đến từ đâu là rõ ràng. Kubernetes dù sao cũng không kiểm tra điều này và thường các trình điều khiển được đặt trong cùng một không gian tên, vì vậy cuối cùng các trình điều khiển dự kiến ​​sẽ hoạt động và không xuất bản dữ liệu không chính xác (và đây là lúc thẻ của tôi bị lỗi, khoảng người dịch dựa trên một trò đùa có râu)

Khối lượng phù du cho mục đích chung

Nếu người dùng có quyền tạo nhóm (trực tiếp hoặc gián tiếp), họ cũng sẽ có thể tạo các tập đĩa tạm thời cho mục đích chung ngay cả khi họ không có quyền tạo yêu cầu trên tập đĩa. Điều này là do việc kiểm tra quyền RBAC được áp dụng cho bộ điều khiển tạo PVC chứ không phải cho người dùng. Đây là thay đổi chính để thêm vào tài khoản của bạn, trước khi bật tính năng này trên các cụm nơi người dùng không tin cậy sẽ không có quyền tạo tập đĩa.

Ví dụ

Chia cành cây PMEM-CSI chứa tất cả các thay đổi cần thiết để chạy cụm Kubernetes 1.19 bên trong máy ảo QEMU với tất cả các tính năng ở giai đoạn alpha. Mã trình điều khiển không thay đổi, chỉ việc triển khai đã thay đổi.

Trên một máy phù hợp (Linux, người dùng bình thường có thể sử dụng phu bến tàu, nhìn thấy đây chi tiết), các lệnh này sẽ hiển thị cụm và cài đặt trình điều khiển PMEM-CSI:

git clone --branch=kubernetes-1-19-blog-post https://github.com/intel/pmem-csi.git
cd pmem-csi
export TEST_KUBERNETES_VERSION=1.19 TEST_FEATURE_GATES=CSIStorageCapacity=true,GenericEphemeralVolume=true TEST_PMEM_REGISTRY=intel
make start && echo && test/setup-deployment.sh

Sau khi mọi thứ hoạt động, đầu ra sẽ chứa hướng dẫn sử dụng:

The test cluster is ready. Log in with [...]/pmem-csi/_work/pmem-govm/ssh.0, run
kubectl once logged in.  Alternatively, use kubectl directly with the
following env variable:
   KUBECONFIG=[...]/pmem-csi/_work/pmem-govm/kube.config

secret/pmem-csi-registry-secrets created
secret/pmem-csi-node-secrets created
serviceaccount/pmem-csi-controller created
...
To try out the pmem-csi driver ephemeral volumes:
   cat deploy/kubernetes-1.19/pmem-app-ephemeral.yaml |
   [...]/pmem-csi/_work/pmem-govm/ssh.0 kubectl create -f -

Các đối tượng CSIStorageCapacity không phải để con người có thể đọc được nên cần phải thực hiện một số thao tác xử lý. Bộ lọc mẫu Golang sẽ hiển thị các lớp lưu trữ, ví dụ này sẽ hiển thị tên, cấu trúc liên kết và dung lượng:

$ kubectl get 
        -o go-template='{{range .items}}{{if eq .storageClassName "pmem-csi-sc-late-binding"}}{{.metadata.name}} {{.nodeTopology.matchLabels}} {{.capacity}}
{{end}}{{end}}' 
        csistoragecapacities
csisc-2js6n map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker2] 30716Mi
csisc-sqdnt map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker1] 30716Mi
csisc-ws4bv map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker3] 30716Mi

Một đối tượng duy nhất có nội dung sau:

$ kubectl describe csistoragecapacities/csisc-6cw8j
Name:         csisc-sqdnt
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  storage.k8s.io/v1alpha1
Capacity:     30716Mi
Kind:         CSIStorageCapacity
Metadata:
  Creation Timestamp:  2020-08-11T15:41:03Z
  Generate Name:       csisc-
  Managed Fields:
    ...
  Owner References:
    API Version:     apps/v1
    Controller:      true
    Kind:            StatefulSet
    Name:            pmem-csi-controller
    UID:             590237f9-1eb4-4208-b37b-5f7eab4597d1
  Resource Version:  2994
  Self Link:         /apis/storage.k8s.io/v1alpha1/namespaces/default/csistoragecapacities/csisc-sqdnt
  UID:               da36215b-3b9d-404a-a4c7-3f1c3502ab13
Node Topology:
  Match Labels:
    pmem-csi.intel.com/node:  pmem-csi-pmem-govm-worker1
Storage Class Name:           pmem-csi-sc-late-binding
Events:                       <none>

Hãy thử tạo một ứng dụng demo với một tập đĩa tạm thời cho mục đích chung. Nội dung tập tin pmem-app-ephemeral.yaml:

# This example Pod definition demonstrates
# how to use generic ephemeral inline volumes
# with a PMEM-CSI storage class.
kind: Pod
apiVersion: v1
metadata:
  name: my-csi-app-inline-volume
spec:
  containers:
    - name: my-frontend
      image: intel/pmem-csi-driver-test:v0.7.14
      command: [ "sleep", "100000" ]
      volumeMounts:
      - mountPath: "/data"
        name: my-csi-volume
  volumes:
  - name: my-csi-volume
    ephemeral:
      volumeClaimTemplate:
        spec:
          accessModes:
          - ReadWriteOnce
          resources:
            requests:
              storage: 4Gi
          storageClassName: pmem-csi-sc-late-binding

Sau khi tạo như hướng dẫn ở trên, giờ chúng ta đã có thêm pod và PVC:

$ kubectl get pods/my-csi-app-inline-volume -o wide
NAME                       READY   STATUS    RESTARTS   AGE     IP          NODE                         NOMINATED NODE   READINESS GATES
my-csi-app-inline-volume   1/1     Running   0          6m58s   10.36.0.2   pmem-csi-pmem-govm-worker1   <none>           <none>
$ kubectl get pvc/my-csi-app-inline-volume-my-csi-volume
NAME                                     STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS               AGE
my-csi-app-inline-volume-my-csi-volume   Bound    pvc-c11eb7ab-a4fa-46fe-b515-b366be908823   4Gi        RWO            pmem-csi-sc-late-binding   9m21s

Chủ sở hữu PVC - dưới:

$ kubectl get -o yaml pvc/my-csi-app-inline-volume-my-csi-volume
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  annotations:
    pv.kubernetes.io/bind-completed: "yes"
    pv.kubernetes.io/bound-by-controller: "yes"
    volume.beta.kubernetes.io/storage-provisioner: pmem-csi.intel.com
    volume.kubernetes.io/selected-node: pmem-csi-pmem-govm-worker1
  creationTimestamp: "2020-08-11T15:44:57Z"
  finalizers:
  - kubernetes.io/pvc-protection
  managedFields:
    ...
  name: my-csi-app-inline-volume-my-csi-volume
  namespace: default
  ownerReferences:
  - apiVersion: v1
    blockOwnerDeletion: true
    controller: true
    kind: Pod
    name: my-csi-app-inline-volume
    uid: 75c925bf-ca8e-441a-ac67-f190b7a2265f
...

Thông tin dự kiến ​​cập nhật cho pmem-csi-pmem-govm-worker1:

csisc-2js6n map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker2] 30716Mi
csisc-sqdnt map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker1] 26620Mi
csisc-ws4bv map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker3] 30716Mi

Nếu một ứng dụng khác cần nhiều hơn 26620Mi, bộ lập lịch sẽ không tính đến pmem-csi-pmem-govm-worker1 trong bất kỳ trường hợp nào.

Cái gì tiếp theo?

Cả hai tính năng vẫn đang được phát triển. Một số ứng dụng đã được mở trong quá trình thử nghiệm alpha. Các liên kết đề xuất cải tiến ghi lại công việc cần thực hiện để chuyển sang giai đoạn beta, cũng như những giải pháp thay thế nào đã được xem xét và từ chối:

Nguồn: www.habr.com

Thêm một lời nhận xét