Некаторым прыкладанням таксама трэба захоўваць дадзеныя, але яны дастаткова спакойна ставяцца да таго, што дадзеныя не будуць захаваны пасля перазапуску.
Напрыклад сэрвісы для кэшавання абмежаваныя па аператыўнай памяці, але таксама могуць перамяшчаць дадзеныя, якія рэдка выкарыстоўваюцца, у сховішча, якое працуе павольней, чым аператыўная памяць, з невялікім уплывам на агульную прадукцыйнасць. Іншым прыкладанням трэба ведаць, што ў файлах могуць быць некаторыя ўваходныя дадзеныя толькі для чытання, напрыклад наладкі або сакрэтныя ключы.
У Kubernetes ужо ёсць некалькі тыпаў , Але іх функцыянальнасць абмежавана тым, што рэалізавана ў K8s.
Эфемерныя дазволілі пашыраць Kubernetes з дапамогай драйвераў CSI для забеспячэння падтрымкі легкаважных лакальных тамоў. Гэтым спосабам можна выкарыстоўваць : наладкі, сакрэты, дадзеныя для ідэнтыфікацыі, зменныя і гэтак далей. CSI драйверы павінны быць дапрацаваны для падтрымкі гэтай функцыі Kubernetes, паколькі мяркуецца, што звычайныя стандартызаваныя драйверы не будуць працаваць – але мяркуецца, што такія тамы можна выкарыстоўваць на любым вузле, абраным для пода.
Гэта можа стаць праблемай для тамоў са значным спажываннем рэсурсаў вузла ці для сховішча, даступнага толькі на некаторых вузлах. Таму ў Kubernetes 1.19 прадстаўлены дзве новыя функцыі тамоў для альфа-тэставанні, канцэптуальна падобных на тамы EmptyDir:
-
эфемерныя тамы агульнага прызначэння;
-
адсочванне ёмістасці сховішчы CSI.
Перавагі новага падыходу:
-
сховішча можа быць лакальным, альбо якія падключаюцца па сетцы;
-
тамы могуць мець зададзены памер, які не можа быць перавышаны дадаткам;
-
працуе з любымі драйверамі CSI, якія падтрымліваюць прадастаўленне пастаянных тамоў і (для падтрымкі адсочвання ёмістасці) рэалізуюць выклік
GetCapacity; -
тамы могуць мець некаторыя пачатковыя дадзеныя, якія залежаць ад драйвера і параметраў;
-
усе тыпавыя аперацыі з томам (стварэнне здымка стану, змена памеру і да т.п.) падтрымліваюцца;
-
тамы можна выкарыстоўваць з любым кантролерам прыкладанняў, якія прымаюць спецыфікацыю модуля або тамы;
-
планавальнік Kubernetes сам выбірае прыдатныя вузлы, таму больш не трэба забяспечваць і наладжваць пашырэнні планавальніка і змяняць webhooks.
варыянты прымянення
Такім чынам эфемерныя тамы агульнага прызначэння падыходзяць для наступных варыянтаў ужывання:
Пастаянная памяць у якасці замены аператыўнай памяці для memcached
Апошнія выпускі memcached выкарыстання сталай памяці (Intel Optane і да т.п., заўв. перакладчыка) замест звычайнай аператыўнай памяці. Пры разгортванні memcached праз кантролер прыкладанняў можна з дапамогай эфемерных тамоў агульнага прызначэння зрабіць запыт на вылучэнне тома зададзенага памеру з PMEM з дапамогай CSI драйвера, напрыклад .
Лакальнае сховішча LVM у якасці працоўнай прасторы
Прыкладанні, якія працуюць з дадзенымі, памер якіх перавышае памер аператыўнай памяці, могуць запытваць лакальнае сховішча з памерам ці метрыкамі прадукцыйнасці, якія не могуць забяспечыць звычайныя тамы EmptyDir ад Kubernetes. Напрыклад, для гэтай мэты быў напісаны .
Доступ толькі для чытання для тамоў з дадзенымі
Вылучэнне тома можа прывесці да стварэння запоўненага тома пры:
-
аднаўленні ;
-
стварэнні ;
-
працы .
Гэтыя тамы могуць быць змантаваны ў рэжыме толькі для чытання.
Як гэта працуе
Эфемерныя тамы агульнага прызначэння
Ключавой асаблівасцю эфемерных тамоў агульнага прызначэння з'яўляецца новая крыніца тома, EphemeralVolumeSource, які змяшчае ўсе палі для стварэння запыту да таго (гістарычна гэта называецца запыт на пастаянны том, PVC). Новы кантролер у kube-controller-manager праглядае поды, якія ствараюць такую крыніцу тома, а затым стварае PVC для гэтых подаў. Для CSI драйвера гэты запыт выглядае гэтак жа, як і астатнія, таму тут не трэба асаблівай падтрымкі.
Пакуль такія PVC існуюць - могуць выкарыстоўвацца, як і любыя іншыя запыты на тым. У прыватнасці яны могуць быць спасылкай у якасці крыніцы дадзеных пры капіяванні тома або стварэнні здымка з тома. Аб'ект PVC таксама змяшчае бягучы стан тома.
Імёны аўтаматычна ствараных PVC прадвызначаны: гэта камбінацыя імя пода і імя тома, падзеленых паміж сабой злучком. Наканаванне імёнаў спрашчае ўзаемадзеянне з PVC, паколькі яго не трэба шукаць, калі вядома імя пода і імя тома. Недахопам з'яўляецца тое, што імя ўжо можа быць выкарыстана, што выяўляецца Kubernetes і ў выніку запуск пода блакуецца.
Для таго, каб быць упэўненым у тым, што том выдаляецца разам з подам, кантролер робіць пад уладальнікам запыту на тым. Калі пад выдаляецца - адпрацоўвае штатны механізм уборкі смецця, які выдаляе як запыт, так і тым.
Запытам ставіцца ў адпаведнасць драйвер сховішчы праз звычайны механізм класа сховішчы. Хоць класы з неадкладным і познім звязваннем (яны ж WaitForFirstConsumer) падтрымліваюцца, для эфемерных тамоў мае сэнс выкарыстоўваць WaitForFirstConsumer, тады планавальнік можа ўлічыць як выкарыстанне вузла, так і даступнасць сховішчы пры выбары вузла. Тутака ж з'яўляецца новая функцыя.
Адсочванне ёмістасці сховішча
Звычайна планавальнік не мае дадзеных аб тым, дзе CSI драйвер створыць том. Таксама ў планавальніка няма магчымасці звязацца з драйверам напрамую для запыту гэтай інфармацыі. Таму планавальнік апытвае вузлы датуль, пакуль не знойдзе той, на якім тамы могуць быць даступнымі (пазней звязванне), альбо цалкам пакіне выбар месца за драйверам (неадкладнае звязванне).
Новы CSIStorageCapacity, які знаходзіцца ў стадыі alpha, дазваляе захоўванне патрэбных дадзеных у etcd, так што яны даступныя планавальніку. У адрозненне ад падтрымкі эфемерных тамоў агульнага прызначэння пры разгортванні драйвера трэба ўлучыць адсочванне ёмістасці сховішчы: external-provisioner павінен апублікаваць інфармацыю аб ёмістасці, атрымоўваную ад драйвера праз звычайны GetCapacity.
Калі планавальніку трэба абраць вузел для пода з непрывязаным томам, выкарыстоўвалым позняе звязванне, а драйвер пры разгортванні актываваў гэтую функцыю усталёўваючы сцяг CSIDriver.storageCapacity, то будуць аўтаматычна адкінуты вузлы, у якіх няма дастаткова ёмістасці сховішчы. Гэта працуе як для эфемерных агульнага прызначэння, так і сталых тамоў, але не для эфемерных тамоў CSI, паколькі іх параметры не могуць быць прачытаныя Kubernetes.
Як звычайна, тамы з неадкладнымі звязваннем ствараюцца перад планаваннем подаў, а іх размяшчэнне выбіраецца драйверам сховішча, таму пры наладзе external-provisioner па-змаўчанні прапускаюцца класы захоўвання з неадкладным звязваннем, паколькі гэтыя дадзеныя ўсё роўна не будуць выкарыстоўвацца.
Паколькі планавальнік kubernetes змушаны працаваць з патэнцыйна састарэлай інфармацыяй, няма гарантый, што ёмістасць будзе даступная ў любым выпадку калі том будзе стварацца, але, тым не менш, шанцы, што ён будзе створаны без паўторных спроб, павялічваюцца.
NB Больш падрабязную інфармацыю вы зможаце атрымаць, а таксама бяспечна «патрэніравацца на котках стэндзе», а ў выпадку зусім ужо незразумелай сітуацыі атрымаць кваліфікаваную дапамогу тэхпадтрымкі на інтэнсіўах. пройдзе 28-30 верасня, а для больш прасунутых адмыслоўцаў 14-16 кастрычніка.
бяспеку
CSIStorageCapacity
Аб'екты CSIStorageCapacity знаходзяцца ў прасторах імёнаў, пры раскочванні кожнага драйвера CSI у сваёй прасторы імёнаў рэкамендуецца абмежаваць правы RBAC для CSIStorageCapacity у гэтай прасторы, паколькі відавочна, адкуль прыходзяць дадзеныя. У любым выпадку Kubernetes не правярае гэта, а звычайна драйверы ставяцца ў адной прасторы імёнаў, так што ў канчатковым выніку чакаецца, што драйвера будуць працаваць і не будуць публікаваць няслушныя дадзеныя (і тут мне карта папёрла, заўв. перакладчыка па матывах барадатага анекдота)
Эфемерныя тамы агульнага прызначэння
Калі карыстачы маюць правы для стварэння пода (наўпрост ці апасродкавана) - яны таксама змогуць стварыць эфемерныя тамы агульнага прызначэння нават калі ў іх няма правоў на стварэнне запыту на тым. А ўсё таму, што праверкі мае рацыю RBAC ужываюцца да кантролера, які стварае PVC, а не да карыстача. Гэта асноўная змена, якую трэба дадаць , перад уключэннем гэтай функцыі ў кластарах, калі ненадзейныя карыстальнікі не павінны мець права на стварэнне тамоў.
Прыклад
Асобная у PMEM-CSI утрымоўвае ўсе патрэбныя змены для запуску кластара Kubernetes 1.19 усярэдзіне віртуальных машын QEMU са ўсімі функцыямі, змешчанымі на alpha стадыі. Код драйвера не змяняўся, памянялася толькі разгортванне.
На прыдатнай машыне (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 пры любым раскладзе.
Што далей?
Абедзве функцыі ўсё яшчэ ў распрацоўцы. Было адкрыта некалькі заявак пры alpha-тэставанні. Па спасылках з прапановамі па паляпшэннях вядзецца дакументаванне працы, якую трэба зрабіць, каб перайсці ў стадыю beta, а таксама якія альтэрнатывы былі ўжо разгледжаны і адхіленыя:
Крыніца: habr.com