Капацитет за съхранение, проследявани ефимерни обеми: EmptyDir на стероиди

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

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

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

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

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

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

• CSI проследяване на капацитета за съхранение.

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

• съхранението може да бъде локално или свързано чрез мрежа;

• обемите могат да имат определен размер, който не може да бъде надвишен от приложението;

• работи с всички CSI драйвери, които поддържат осигуряване на постоянни обеми и (за поддържане на проследяване на капацитет) реализират повикването GetCapacity;

• обемите може да имат някои първоначални данни в зависимост от драйвера и настройките;

• поддържат се всички стандартни операции с обем (създаване на моментна снимка, преоразмеряване и др.);

• обемите могат да се използват с всеки приложен контролер, който приема модул или спецификация на обем;

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

Опции за приложение

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

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

Най-новите версии на memcached добавена поддръжка използване на постоянна памет (Intel Optane и др., прибл. преводач) вместо обикновена RAM. Когато внедрявате memcached чрез контролер на приложения, можете да използвате ефемерни томове с общо предназначение, за да поискате обем с даден размер да бъде разпределен от PMEM, като използвате например CSI драйвера PMEM-CSI.

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

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

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

Разпределянето на том може да доведе до създаване на пълен том, когато:

• възстановяване обемна снимка;

• създаване обемни копия;

• работа контейнери за данни.

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

Как работи

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

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

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

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

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

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

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

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

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

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

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

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

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

сигурност

CSIStorageCapacity

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

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

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

Пример

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

На подходяща машина (Linux, нормален потребител може да използва докер, виж тук подробности) тези команди ще изведат клъстера и ще инсталират драйвера 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

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

Каква е следващата?

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

• KEP-1698: родови ефимерни вградени томове

• KEP-1472: Проследяване на капацитета за съхранение

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