🥇Епхемерни тома с проследяване на капацитета на хранилището: EmptyDir на стероиди

Някои приложения също трябва да съхраняват данни, но те приемат спокойно факта, че данните няма да бъдат запазени след рестарт.

Например, услугите за кеширане са ограничени от оперативната памет, но също така могат да преместят данни, които рядко се използват, в хранилище, работещо по-бавно от оперативната памет, с минимално влияние върху общата производителност. Други приложения трябва да знаят, че в файловете могат да бъдат налични входни данни само за четене, като настройки или секретни ключове.

В Kubernetes вече съществуват няколко типа ефимерни томове, но тяхната функционалност е ограничена до това, което е реализирано в K8s.

Ефимерните тома CSI позволяват разширяване на Kubernetes чрез CSI драйвери за осигуряване на поддръжка на леки локални томове. По този начин е възможно да се използват произволни структури: настройки, секрети, идентификационни данни, променливи и т.н. CSI драйверите трябва да бъдат адаптирани за поддръжка на тази функция в Kubernetes, тъй като се предполага, че стандартните драйвери няма да работят — но се предполага, че такива томове могат да се използват на всяко възел, избрано за под.

Това може да стане проблем за томовете с значителна консумация на ресурси на възела или за хранилищата, достъпни само на някои възли. Поради това в Kubernetes 1.19 бяха представени две нови функции на томовете за алфа тестиране, концептуално подобни на томовете EmptyDir:

ефимерни томове с общо предназначение;
проследяване на капацитета на хранилището CSI.

Предимства на новия подход:

хранилището може да бъде локално или мрежово свързано;
томовете могат да имат определен размер, който приложението не може да надвиши;
работи с всякакви CSI драйвери, поддържащи предоставяне на постоянни томове и (за поддръжка на проследяване на капацитета) реализиращи повикване GetCapacity;
томовете могат да имат определени начални данни, в зависимост от драйвера и параметрите;
всички стандартни операции с томове (създаване на моментна снимка, промяна на размера и т.н.) се поддържат;
томовете могат да се използват с всеки контролер на приложения, приемащ спецификация на модула или тома;
Планировщик Kubernetes сам избира нужните възли, така че вече не е необходимо да осигурявате и настройвате разширения на планировщика и да променяте уебхукове.

Приложения

По този начин ефимерните обемни томове от общо предназначение са подходящи за следните приложения:

Постоянна памет като заместител на оперативната памет за memcached

Последни версии на memcached добавиха поддръжка на използването на постоянна памет (Intel Optane и т.н., прим. преводача) вместо обикновена оперативна памет. При внедряване на memcached чрез контролер на приложенията, можете да поискате разпределение на том с определен размер от PMEM чрез CSI драйвера, например PMEM-CSI.

Локално хранилище LVM като работно пространство

Приложенията, работещи с данни, чиито размери надвишават размера на оперативната памет, могат да поискат локално хранилище с размер или производителност, която обикновените томове EmptyDir от Kubernetes не могат да осигурят. Например, за тази цел е написан TopoLVM.

Достъп само за четене за томове с данни

Разпределението на том може да доведе до създаване на запълнен том при:

възстановяване снимка на тома;
създаване на копие на тома;
работа запълващи данни.

Тези томове могат да бъдат монтирани в режим само за четене.

Как работи това

Ефимерни томове от общо предназначение

Ключовата характеристика на ефимерните томове от общо предназначение е новият източник на тома, EphemeralVolumeSource, съдържащ всички полета за създаване на запитване към тома (исторически това се нарича запитване за постоянен том, PVC). Новият контролер в kube-controller-manager преглежда подовете, които създават такъв източник на тома, и след това създава PVC за тези подове. За CSI драйвера това запитване изглежда по същия начин, както и останалите, затова не е необходима специална поддръжка.

Докато такива PVC съществуват, те могат да бъдат използвани, както и всякакви други запитвания към тома. В частност, те могат да бъдат връзка като източник на данни при копиране на тома или създаване на снимка от тома. Обектът PVC също съдържа текущото състояние на тома.

Автоматично създадените имена PVC са предварително зададени: това е комбинация от името на пода и името на тома, разделени с тире. Предварителността на имената улеснява взаимодействието с PVC, тъй като не е нужно да се търси, ако се знае името на пода и името на тома. Недостатъкът е, че името вече може да бъде използвано, което Kubernetes открива и в резултат стартирането на пода се блокира.

За да сте сигурни, че томът се изтрива заедно с пода, контролерът прави пода собственик на заявката за тома. Когато подът се изтрие — работи стандартният механизъм за почистване, който премахва както заявката, така и тома.

Заявките се свързват с драйвера на хранилището чрез стандартния механизъм на класа на хранилището. Въпреки че класовете с незабавно и късно свързване (или WaitForFirstConsumer) се поддържат, за ефимерни томове има смисъл да се използва WaitForFirstConsumer, така че планировчикът да може да вземе предвид както използването на възли, така и наличността на хранилището при избора на възел. Тук се появява и нова функция.

Проследяване на капацитета на хранилището

Обикновено планировчикът няма данни за това къде CSI драйверът ще създаде том. Също така планировчикът няма възможност да се свърже с драйвера директно, за да поиска тази информация. Затова планировчикът запитва възлите, докато не намери такъв, на който томовете могат да бъдат достъпни (късно свързване) или напълно оставя избора на място на драйвера (незабавно свързване).

Нов API CSIStorageCapacity, който е в стадий alpha, позволява съхраняването на необходимите данни в etcd, така че да са налични за планировчика. За разлика от поддръжката на ефимерни томове общего предназначение, при внедряване на драйвера трябва да се включи проследяване на капацитета на хранилището: external-provisioner трябва да публикува информация за капацитета, получена от драйвера чрез стандартен GetCapacity.

Ако планировчикът трябва да избере възел за под с непривързан том, използващ късно свързване, а драйверът при внедряване е активирал тази функция, установявайки флага CSIDriver.storageCapacity, то автоматично ще бъдат отхвърлени възлите, които нямат достатъчен капацитет на хранилището. Това работи както за ефимерни общего предназначение, така и за постоянни томове, но не и за ефимерни томове CSI, тъй като техните параметри не могат да бъдат прочетени от Kubernetes.

Както обикновено, томовете с незабавна свързаност се създават преди планирането на подове, а тяхното местоположение се избира от драйвера за съхранение, така че при настройката, external-provisioner по подразбиране се пропускат класовете за съхранение с незабавна свързаност, тъй като тези данни все пак няма да се използват.

Тъй като планировчикът на Kubernetes е принуден да работи с потенциално остаряла информация, няма гаранции, че капацитетът ще бъде наличен по всяко време, когато томът бъдат създаден, но все пак шансовете той да бъде създаден без повторни опити се увеличават.

Забележка. По-подробна информация можете да получите, а също така безопасно да „потренирате на котките в стенд“, а в случай на напълно неразбираема ситуация, да получите квалифицирана помощ от техническа поддръжка на интензивите — Kubernetes База които ще се проведат от 28 до 30 септември, а за по-напреднали специалисти Kubernetes Мега 14-16 октомври.

Сигурност

CSIStorageCapacity

Обектите CSIStorageCapacity се намират в именни пространства, при разгръщането на всеки драйвер CSI в неговото именувано пространство е препоръчително да се ограничат правата RBAC за CSIStorageCapacity в това пространство, тъй като очевидно е откъде идват данните. Във всички случаи Kubernetes не проверява това, а обикновено драйверите се инсталират в едно именувано пространство, така че в крайна сметка се очаква драйверите да работят и да не публикуват неверни данни (и тук ми излезе картата, бележка на преводача, вдъхновена от бородат виц)

Ефимерни томове от общо предназначение

Ако потребителите имат права за създаване на под (директно или индиректно) — те също така ще могат да създават ефемерни томове с общо предназначение, дори и да нямат права за създаване на заявка за том. И всичко това, защото проверките за права RBAC се прилагат към контролера, който създава PVC, а не към потребителя. Това е основната промяна, която трябва да добавите към профила, преди да активирате тази функция в клъстери, ако ненадеждните потребители не трябва да имат права за създаване на томове.

Пример

Отделен тема в PMEM-CSI съдържа всичките необходими изменения за стартиране на клъстер Kubernetes 1.19 вътре в виртуални машини QEMU с всички функции, на етап alpha. Кодът на драйвера не е променен, само разгръщането.

На подходяща машина (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

След като всичко проработи, изходът ще съдържа инструкции за употреба:

Тестовият клъстер е готов. Влезте с [...]pmem-csi/_work/pmem-govm/ssh.0, стартирайте
kubectl след влизане. Алтернативно, използвайте kubectl директно с
следната променлива на средата:
   KUBECONFIG=[...]pmem-csi/_work/pmem-govm/kube.config

secret/pmem-csi-registry-secrets беше създаден
secret/pmem-csi-node-secrets беше създаден
serviceaccount/pmem-csi-controller беше създаден
...
За да изпробвате драйвера pmem-csi с ефимерни томове:
   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:       
Annotations:  
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:

Нека се опитаме да създадем демонстрационно приложение с един ефимерен том за общо ползване. Съдържанието на файла 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              
$ 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

Ако на друго приложение му е необходимо повече от 26620Mi, планировчикът няма да го вземе предвид pmem-csi-pmem-govm-worker1 при всякакви обстоятелства.

Какво следва?

И двете функции все още се разработват. Отворени са няколко заявки по време на alpha тестването. Документира се работата, която трябва да се свърши, за да се премине към бета етап, както и кои алтернативи вече са били разгледани и отхвърлени:

Източник: habr.com