შენახვის მოცულობა თვალყურს ადევნებს ეფემერულ მოცულობებს: EmptyDir სტეროიდებზე

ზოგიერთ აპლიკაციას ასევე სჭირდება მონაცემების შენახვა, მაგრამ მათთვის საკმაოდ კომფორტულია ის ფაქტი, რომ მონაცემები არ შეინახება გადატვირთვის შემდეგ.

მაგალითად, ქეშირების სერვისები შეზღუდულია ოპერატიული მეხსიერებით, მაგრამ ასევე შეუძლიათ გადაიტანონ მონაცემები, რომლებიც იშვიათად გამოიყენება მეხსიერებაში, რომელიც უფრო ნელია ვიდრე RAM, რაც მცირე გავლენას ახდენს მთლიან შესრულებაზე. სხვა აპლიკაციებმა უნდა იცოდნენ, რომ ფაილებში შეიძლება იყოს მხოლოდ წაკითხვადი შეყვანა, როგორიცაა პარამეტრები ან საიდუმლო გასაღებები.

Kubernetes-ს უკვე აქვს რამდენიმე ტიპი ეფემერული ტომები, მაგრამ მათი ფუნქციონირება შემოიფარგლება იმით, რაც დანერგილია K8-ებში.

ეფემერული CSI ტომები დაუშვა Kubernetes-ის გაფართოება CSI დრაივერებით, რათა უზრუნველყოს მსუბუქი ლოკალური ტომების მხარდაჭერა. ამ გზით შესაძლებელია მისი გამოყენება თვითნებური სტრუქტურები: პარამეტრები, საიდუმლოებები, საიდენტიფიკაციო მონაცემები, ცვლადები და ა.შ. CSI დრაივერები უნდა შეიცვალოს Kubernetes-ის ამ ფუნქციის მხარდასაჭერად, რადგან არ არის მოსალოდნელი რეგულარული სტანდარტიზებული დრაივერების მუშაობა - მაგრამ მოსალოდნელია, რომ ასეთი ტომი გამოყენებული იქნება პოდისთვის შერჩეულ ნებისმიერ კვანძზე.

ეს შეიძლება იყოს პრობლემა ტომებისთვის, რომლებიც მოიხმარენ მნიშვნელოვან ჰოსტის რესურსებს ან შენახვისთვის, რომელიც ხელმისაწვდომია მხოლოდ ზოგიერთ ჰოსტზე. სწორედ ამიტომ Kubernetes 1.19 შემოაქვს ორი ახალი ალფა ტესტირების მოცულობის მახასიათებლებს, რომლებიც კონცეპტუალურად ჰგავს EmptyDir ტომებს:

• ზოგადი დანიშნულების ეფემერული ტომები;

• CSI შენახვის სიმძლავრის თვალყურის დევნება.

ახალი მიდგომის უპირატესობები:

• შენახვა შეიძლება იყოს ლოკალური ან დაკავშირებული ქსელის საშუალებით;

• ტომებს შეიძლება ჰქონდეს მითითებული ზომა, რომლის გადაჭარბებაც არ შეიძლება აპლიკაციის მიერ;

• მუშაობს ნებისმიერ CSI დრაივერთან, რომელიც მხარს უჭერს მუდმივი მოცულობის უზრუნველყოფას და (სიმძლავრის თვალთვალის მხარდასაჭერად) ახორციელებს ზარს GetCapacity;

• ტომს შეიძლება ჰქონდეს გარკვეული საწყისი მონაცემები დრაივერისა და პარამეტრების მიხედვით;

• ყველა სტანდარტული ოპერაცია მოცულობით (სნეპშოტის შექმნა, ზომის შეცვლა და ა.შ.) მხარდაჭერილია;

• ტომი შეიძლება გამოყენებულ იქნას ნებისმიერი აპლიკაციის კონტროლერთან, რომელიც ეთანხმება მოდულის ან მოცულობის სპეციფიკაციას;

• Kubernetes-ის დამგეგმავი დამოუკიდებლად ირჩევს შესაფერის კვანძებს, ასე რომ თქვენ აღარ დაგჭირდებათ გრაფიკის გაფართოებების უზრუნველყოფა და კონფიგურაცია და ვებ-ჰუკების შეცვლა.

პროგრამები

ამიტომ, ზოგადი დანიშნულების ეფემერული ტომები შესაფერისია შემდეგი გამოყენების შემთხვევებისთვის:

მუდმივი მეხსიერება, როგორც შემცვლელი RAM-ისთვის memcached-ისთვის

memcached-ის უახლესი გამოშვებები დაემატა მხარდაჭერა მუდმივი მეხსიერების გამოყენებით (Intel Optane და ა.შ., დაახლ. მთარგმნელი) ჩვეულებრივი ოპერატიული მეხსიერების ნაცვლად. აპლიკაციის კონტროლერის მეშვეობით memcached-ის განლაგებისას, შეგიძლიათ გამოიყენოთ ზოგადი დანიშნულების ეფემერული ტომები, რათა მოითხოვოთ მოცემული ზომის მოცულობა PMEM-დან CSI დრაივერის გამოყენებით, მაგალითად. PMEM-CSI.

LVM ადგილობრივი საცავი, როგორც სამუშაო ადგილი

აპლიკაციებს, რომლებიც მუშაობენ RAM-ზე დიდ მონაცემებთან, შეიძლება მოითხოვონ ლოკალური მეხსიერება ზომით ან შესრულების მეტრიკით, რომელსაც ჩვეულებრივი Kubernetes EmptyDir ტომი ვერ უზრუნველყოფს. მაგალითად, ამ მიზნით დაიწერა TopoLVM.

მხოლოდ წაკითხვადი წვდომა მონაცემთა მოცულობებისთვის

მოცულობის განაწილებამ შეიძლება გამოიწვიოს სრული ტომის შექმნა, როდესაც:

• აღდგენა მოცულობის სნეპშოტი;

• შექმნა მოცულობის ასლები;

• მუშაობა მონაცემთა ადგილის დამფუძნებლები.

ამ ტომების დამონტაჟება შესაძლებელია მხოლოდ წაკითხვის რეჟიმში.

როგორ აკეთებს ამას მუშაობა

ზოგადი დანიშნულების ეფემერული ტომები

ზოგადი დანიშნულების ეფემერული ტომების ძირითადი მახასიათებელია მოცულობის ახალი წყარო, EphemeralVolumeSource, შეიცავს ყველა ველს მოცულობის მოთხოვნის შესაქმნელად (ისტორიულად უწოდებენ მუდმივ მოცულობის მოთხოვნას, PVC). შემოვიდა ახალი კონტროლერი kube-controller-manager უყურებს წიპწებს, რომლებიც ქმნიან ასეთი მოცულობის წყაროს, და შემდეგ ქმნის PVC-ს ამ ჯიშებისთვის. CSI დრაივერისთვის ეს მოთხოვნა ისევე გამოიყურება, როგორც სხვები, ამიტომ აქ განსაკუთრებული მხარდაჭერა არ არის საჭირო.

სანამ ასეთი PVCs არსებობს, ისინი შეიძლება გამოყენებულ იქნას, როგორც ნებისმიერი სხვა მოთხოვნა მოცულობაზე. კერძოდ, მათი მითითება შესაძლებელია მონაცემთა წყაროდ ტომის კოპირებისას ან ტომიდან სნეპშოტის შექმნისას. PVC ობიექტი ასევე შეიცავს მოცულობის ამჟამინდელ მდგომარეობას.

ავტომატურად შექმნილი PVC-ების სახელები წინასწარ არის განსაზღვრული: ისინი წარმოადგენს პოდის სახელისა და მოცულობის სახელის კომბინაციას, გამოყოფილი დეფისით. წინასწარ განსაზღვრული სახელები აადვილებს PVC-თან ურთიერთობას, რადგან თქვენ არ გჭირდებათ მისი ძებნა, თუ იცით პოდის სახელი და მოცულობის სახელი. მინუსი ის არის, რომ სახელი შეიძლება უკვე გამოყენებულია, რასაც კუბერნეტისი აღმოაჩენს და შედეგად პოდი იბლოკება გაშვებისთვის.

იმის უზრუნველსაყოფად, რომ ტომი წაშლილია პოდთან ერთად, კონტროლერი უგზავნის მოთხოვნას მფლობელის ქვეშ არსებულ მოცულობას. როდესაც პოდი წაიშლება, მუშაობს ნაგვის შეგროვების სტანდარტული მექანიზმი, რომელიც წაშლის მოთხოვნასაც და მოცულობასაც.

მოთხოვნები შესატყვისია შენახვის დრაივერის მიერ შენახვის კლასის ნორმალური მექანიზმით. მიუხედავად იმისა, რომ კლასები დაუყოვნებელი და გვიან სავალდებულოა (aka WaitForFirstConsumer) მხარდაჭერილია, ეფემერული ტომებისთვის აზრი აქვს გამოყენებას WaitForFirstConsumer, მაშინ დამგეგმავმა შეიძლება გაითვალისწინოს როგორც კვანძის გამოყენება, ასევე შენახვის ხელმისაწვდომობა კვანძის არჩევისას. აქ გამოჩნდება ახალი ფუნქცია.

შენახვის სიმძლავრის თვალყურის დევნება

როგორც წესი, დამგეგმავმა არ იცის სად შექმნის CSI დრაივერი მოცულობას. ასევე არ არსებობს საშუალება, რომ დამგეგმავი პირდაპირ დაუკავშირდეს მძღოლს, რომ მოითხოვოს ეს ინფორმაცია. ამიტომ, დაგეგმავი აგროვებს კვანძებს მანამ, სანამ არ იპოვის ერთს, რომელზედაც შეიძლება წვდომა იყოს ტომებზე (გვიან შეკვრა) ან ადგილმდებარეობის არჩევანს მთლიანად დრაივერს უტოვებს (დაუყოვნებლივ შეკვრა).

ახალი API CSIStorageCapacity, რომელიც ალფა სტადიაშია, საშუალებას იძლევა საჭირო მონაცემები შეინახოს etcd-ში ისე, რომ ის ხელმისაწვდომი იყოს დამგეგმავისთვის. ზოგადი დანიშნულების ეფემერული ტომების მხარდაჭერისგან განსხვავებით, დრაივერის დაყენებისას უნდა ჩართოთ შენახვის შესაძლებლობების თვალყურის დევნება: external-provisioner უნდა გამოაქვეყნოს მძღოლისგან მიღებული ტევადობის ინფორმაცია ნორმალურად GetCapacity.

თუ დამგეგმავმა უნდა აირჩიოს კვანძი პოდისთვის შეუზღუდავი მოცულობით, რომელიც იყენებს გვიან დაკავშირებას და დრაივერმა ჩართო ეს ფუნქცია განლაგების დროს დროშის დაყენებით CSIDriver.storageCapacity, მაშინ კვანძები, რომლებსაც არ აქვთ საკმარისი შენახვის მოცულობა, ავტომატურად გაუქმდება. ეს მუშაობს როგორც ზოგადი დანიშნულების ეფემერულ, ასევე მუდმივ ტომებზე, მაგრამ არა CSI ეფემერულ ტომებზე, რადგან მათი პარამეტრების წაკითხვა შეუძლებელია Kubernetes-ის მიერ.

ჩვეულებისამებრ, დაუყოვნებლივ დაკავშირებული ტომები იქმნება პოდების დაგეგმვამდე და მათ განთავსებას ირჩევს შენახვის დრაივერი, ასე რომ, კონფიგურაციისას external-provisioner ნაგულისხმევად, შენახვის კლასები დაუყოვნებელი დაკავშირებით გამოტოვებულია, რადგან ეს მონაცემები მაინც არ იქნება გამოყენებული.

მას შემდეგ, რაც kubernetes განრიგი იძულებულია იმუშაოს პოტენციურად მოძველებულ ინფორმაციასთან, არ არსებობს გარანტია იმისა, რომ მოცულობა ხელმისაწვდომი იქნება ყველა შემთხვევაში, როდესაც ტომი შეიქმნება, მაგრამ შანსი იმისა, რომ ის შეიქმნას ხელახალი ცდების გარეშე, მაინც იზრდება.

NB შეგიძლიათ მიიღოთ უფრო დეტალური ინფორმაცია, ასევე უსაფრთხოდ „ივარჯიშეთ კატების სადგამზე“ და სრულიად გაუგებარი სიტუაციის შემთხვევაში მიიღოთ კვალიფიციური ტექნიკური დახმარება ინტენსიურ კურსებზე - კუბერნეტის ბაზა ჩატარდება 28-30 სექტემბერს, ხოლო უფრო მოწინავე სპეციალისტებისთვის Kubernetes Mega 14–16 ოქტომბერი.

უსაფრთხოების

CSISstorage Capacity

CSIStorageCapacity ობიექტები განლაგებულია სახელთა სივრცეში; თითოეული CSI დრაივერის საკუთარ სახელთა სივრცეში გადატანისას, რეკომენდებულია RBAC უფლებების შეზღუდვა CSIStorageCapacity ამ სივრცეში, რადგან აშკარაა, საიდან მოდის მონაცემები. Kubernetes ამას მაინც არ ამოწმებს და, როგორც წესი, დრაივერები მოთავსებულია იმავე სახელების სივრცეში, ასე რომ, საბოლოო ჯამში, დრაივერებმა უნდა იმუშაონ და არ გამოაქვეყნონ არასწორი მონაცემები (და ეს არის ადგილი, სადაც ჩემი ბარათი ვერ მოხერხდა, დაახლ. მთარგმნელი წვერიან ხუმრობაზე დაფუძნებული)

ზოგადი დანიშნულების ეფემერული ტომები

თუ მომხმარებლებს აქვთ უფლება შექმნან pod (პირდაპირ ან ირიბად), მათ ასევე შეეძლებათ შექმნან ზოგადი დანიშნულების ეფემერული ტომები, მაშინაც კი, თუ მათ არ აქვთ უფლება შექმნან მოთხოვნა მოცულობაზე. ეს იმიტომ ხდება, რომ RBAC ნებართვის შემოწმებები გამოიყენება კონტროლერზე, რომელიც ქმნის PVC-ს და არა მომხმარებლისთვის. ეს არის მთავარი ცვლილება დასამატებლად თქვენს ანგარიშზე, ამ ფუნქციის ჩართვამდე კლასტერებზე, სადაც არასანდო მომხმარებლებს არ უნდა ჰქონდეთ ტომების შექმნის უფლება.

მაგალითი

ცალკე ყლორტი PMEM-CSI შეიცავს ყველა საჭირო ცვლილებას Kubernetes 1.19 კლასტერის გასაშვებად QEMU ვირტუალურ აპარატებში ყველა ფუნქციით ალფა ეტაპზე. მძღოლის კოდი არ შეცვლილა, შეიცვალა მხოლოდ განლაგება.

შესაფერის აპარატზე (Linux, ჩვეულებრივ მომხმარებელს შეუძლია გამოიყენოს docker, შეხედე აქ დეტალები) ეს ბრძანებები გამოიტანს კლასტერს და დააინსტალირებს 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

მას შემდეგ რაც ყველაფერი მუშაობს, გამომავალი შეიცავს გამოყენების ინსტრუქციას:

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 -

CSIStorageCapacity ობიექტები არ არის განკუთვნილი ადამიანების წასაკითხად, ამიტომ საჭიროა გარკვეული დამუშავება. Golang შაბლონის ფილტრები აჩვენებს შენახვის კლასებს, ეს მაგალითი აჩვენებს სახელს, ტოპოლოგიას და მოცულობას:

$ 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

ერთ ობიექტს აქვს შემდეგი შინაარსი:

$ 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>

შევეცადოთ შევქმნათ დემო აპლიკაცია ერთი ზოგადი დანიშნულების ეფემერული მოცულობით. ფაილის შინაარსი 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

შექმნის შემდეგ, როგორც ზემოთ მოყვანილ ინსტრუქციებშია ნაჩვენები, ახლა გვაქვს დამატებითი პოდიუმი და 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

PVC მფლობელი - ქვეშ:

$ 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
...

მოსალოდნელია განახლებული ინფორმაცია 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

თუ სხვა აპლიკაციას სჭირდება 26620 Mi-ზე მეტი, დამგეგმავი არ გაითვალისწინებს pmem-csi-pmem-govm-worker1 ნებისმიერ შემთხვევაში.

რა არის შემდეგი?

ორივე ფუნქცია ჯერ კიდევ დამუშავების პროცესშია. ალფა ტესტირების დროს გაიხსნა რამდენიმე აპლიკაცია. გაუმჯობესების წინადადების ბმულები ადასტურებს სამუშაოს, რომელიც უნდა გაკეთდეს ბეტა ეტაპზე გადასასვლელად, ასევე, რომელი ალტერნატივები უკვე განიხილება და უარყოფილია:

• KEP-1698: ზოგადი ეფემერული შიდა ტომები

• KEP-1472: Storage Capacity Tracking

წყარო: www.habr.com