Sommige toepassings moet ook data stoor, maar hulle is redelik gemaklik met die feit dat die data nie gestoor sal word na 'n herbegin nie.
Kasdienste word byvoorbeeld deur RAM beperk, maar kan ook data wat selde gebruik word, skuif na berging wat stadiger as RAM is, met min impak op algehele werkverrigting. Ander toepassings moet bewus wees daarvan dat daar 'n paar leesalleen-invoer in die lêers kan wees, soos instellings of geheime sleutels.
Kubernetes het reeds verskeie tipes , maar hul funksionaliteit is beperk tot wat in die K8's geïmplementeer word.
Efemeer het toegelaat dat Kubernetes uitgebrei word met CSI-bestuurders om ondersteuning te bied vir liggewig plaaslike volumes. Op hierdie manier is dit moontlik om te gebruik : instellings, geheime, identifikasiedata, veranderlikes, ensovoorts. CSI-drywers moet gewysig word om hierdie Kubernetes-kenmerk te ondersteun, aangesien daar aanvaar word dat gewone gestandaardiseerde drywers nie sal werk nie - maar daar word aanvaar dat sulke volumes gebruik kan word op enige nodus wat vir die peul gekies is.
Dit kan 'n probleem wees vir volumes wat aansienlike gasheerhulpbronne verbruik of vir berging wat slegs op sommige gashere beskikbaar is. Dit is hoekom Kubernetes 1.19 twee nuwe alfa-toetsvolume-kenmerke bekendstel wat konseptueel soortgelyk is aan EmptyDir-volumes:
-
kortstondige bundels vir algemene doeleindes;
-
CSI berging kapasiteit dop.
Voordele van die nuwe benadering:
-
berging kan plaaslik wees of via 'n netwerk gekoppel wees;
-
volumes kan 'n gespesifiseerde grootte hê wat nie deur die toepassing oorskry kan word nie;
-
werk met enige CSI-bestuurders wat voorsiening van volgehoue volumes ondersteun en (om kapasiteitnasporing te ondersteun) die oproep implementeer
GetCapacity; -
volumes kan aanvanklike data hê, afhangende van die drywer en instellings;
-
alle standaardbewerkings met 'n volume (skep 'n momentopname, die grootte van grootte, ens.) word ondersteun;
-
volumes kan gebruik word met enige toepassingsbeheerder wat 'n module- of volumespesifikasie aanvaar;
-
Die Kubernetes skeduleerder kies geskikte nodusse op sy eie, so dit is nie meer nodig om skeduleerderuitbreidings te voorsien en op te stel of webhooks te verander nie.
aansoeke
Daarom is kortstondige volumes vir algemene doeleindes geskik vir die volgende gebruiksgevalle:
Aanhoudende geheue as 'n plaasvervanger vir RAM vir memcached
Jongste vrystellings van memcached gebruik aanhoudende geheue (Intel Optane, ens., ongeveer. vertaler) in plaas van gewone RAM. Wanneer u memcached deur 'n toepassingsbeheerder ontplooi, kan u kortstondige volumes vir algemene doeleindes gebruik om te versoek dat 'n volume van 'n gegewe grootte vanaf PMEM toegewys word deur byvoorbeeld die CSI-bestuurder te gebruik. .
LVM plaaslike berging as 'n werkspasie
Toepassings wat werk met data wat groter as RAM is, mag dalk plaaslike berging benodig met 'n grootte of prestasiemaatstawwe wat gewone EmptyDir-volumes van Kubernetes nie kan verskaf nie. Byvoorbeeld, vir hierdie doel is dit geskryf .
Leesalleentoegang vir datavolumes
Toekenning van 'n volume kan lei tot die skepping van 'n volle volume wanneer:
-
herstel ;
-
skep ;
-
die .
Hierdie volumes kan in leesalleen-modus gemonteer word.
Hoe werk dit
Algemene Doel Efemere Volumes
'n Sleutelkenmerk van kortstondige volumes vir algemene doeleindes is die nuwe volumebron, EphemeralVolumeSource, wat al die velde bevat om 'n volumeversoek te skep (histories genoem 'n aanhoudende volumeversoek, PVC). Nuwe beheerder in kube-controller-manager kyk na die peule wat so 'n volume bron skep, en skep dan 'n PVC vir daardie peule. Vir die CSI-bestuurder lyk hierdie versoek dieselfde as die ander, so geen spesiale ondersteuning is hier nodig nie.
Solank sulke PVC's bestaan, kan hulle soos enige ander versoeke op die volume gebruik word. Daar kan veral na hulle verwys word as 'n databron wanneer 'n volume gekopieer word of 'n momentopname van 'n volume geskep word. Die PVC-voorwerp bevat ook die huidige toestand van die volume.
Die name van outomaties geskepte PVC's is vooraf gedefinieerd: dit is 'n kombinasie van die peulnaam en die volumenaam, geskei deur 'n koppelteken. Vooraf gedefinieerde name maak dit makliker om met die PVC te kommunikeer, want jy hoef nie daarna te soek as jy die peulnaam en volumenaam ken nie. Die nadeel is dat die naam dalk reeds in gebruik is, wat deur Kubernetes opgespoor word en gevolglik word die peul geblokkeer om te begin.
Om te verseker dat die volume saam met die peul uitgevee word, rig die beheerder 'n versoek aan die volume onder die eienaar. Wanneer die peul uitgevee word, werk die standaard vullisverwyderingsmeganisme, wat beide die versoek en die volume uitvee.
Versoeke word deur die stoorbestuurder deur die normale meganisme van die stoorklas ooreenstem. Alhoewel klasse met onmiddellike en laat binding (aka WaitForFirstConsumer) ondersteun word, vir kortstondige volumes maak dit sin om te gebruik WaitForFirstConsumer, dan kan die skeduleerder beide nodusgebruik en bergingbeskikbaarheid oorweeg wanneer 'n nodus gekies word. 'n Nuwe kenmerk verskyn hier.
Opsporing van bergingskapasiteit
Tipies het die skeduleerder geen kennis van waar die CSI-bestuurder die volume sal skep nie. Daar is ook geen manier vir die skeduleerder om die bestuurder direk te kontak om hierdie inligting aan te vra nie. Daarom stem die skeduleerder nodusse totdat dit een vind waarop toegang tot volumes verkry kan word (laat binding) of laat die keuse van ligging geheel en al aan die bestuurder oor (onmiddellike binding).
New CSIStorageCapacity, wat in die alfastadium is, laat toe dat die nodige data in etcd gestoor word sodat dit vir die skeduleerder beskikbaar is. In teenstelling met ondersteuning vir kortstondige volumes vir algemene doeleindes, moet jy bergingskapasiteitnasporing aktiveer wanneer jy die drywer ontplooi: external-provisioner moet die kapasiteit inligting wat van die bestuurder ontvang is via normaal publiseer GetCapacity.
As die skeduleerder 'n nodus moet kies vir 'n pod met 'n ongebonde volume wat laat binding gebruik, en die bestuurder het hierdie kenmerk tydens ontplooiing geaktiveer deur die vlag te stel CSIDriver.storageCapacity, dan sal nodusse wat nie genoeg bergingskapasiteit het nie outomaties weggegooi word. Dit werk vir beide algemene doel kortstondige en volgehoue volumes, maar nie vir CSI efemere volumes nie, want hul parameters kan nie deur Kubernetes gelees word nie.
Soos gewoonlik word onmiddellik gekoppelde volumes geskep voordat peule geskeduleer word, en hul plasing word deur die stoorbestuurder gekies, dus wanneer gekonfigureer word external-provisioner By verstek word bergingsklasse met onmiddellike binding oorgeslaan, aangesien hierdie data in elk geval nie gebruik sal word nie.
Aangesien die kubernetes-skeduleerder gedwing word om met potensieel verouderde inligting te werk, is daar geen waarborg dat kapasiteit in elke geval beskikbaar sal wees wanneer die volume geskep word nie, maar die kanse dat dit sonder herproberings geskep sal word, word nietemin vergroot.
NB Jy kan meer gedetailleerde inligting kry, sowel as veilig "oefen op die kattestand", en in die geval van 'n heeltemal onverstaanbare situasie, gekwalifiseerde tegniese ondersteuning by intensiewe kursusse ontvang - sal op 28-30 September gehou word, en vir meer gevorderde spesialiste 14–16 Oktober.
sekuriteit
CSISbergingkapasiteit
CSIStorageCapacity-voorwerpe is in naamruimtes; wanneer elke CSI-bestuurder in sy eie naamruimte uitgerol word, word dit aanbeveel om RBAC-regte tot die CSIStorageCapacity in daardie ruimte te beperk, aangesien dit duidelik is waar die data vandaan kom. Kubernetes kyk in elk geval nie daarvoor nie, en gewoonlik word bestuurders in dieselfde naamruimte geplaas, so uiteindelik word daar van die bestuurders verwag om te werk en nie verkeerde data te publiseer nie (en dit is waar my kaart misluk het, ongeveer. vertaler gebaseer op 'n bebaarde grap)
Algemene Doel Efemere Volumes
As gebruikers regte het om 'n pod te skep (direk of indirek), sal hulle ook in staat wees om kortstondige volumes vir algemene doeleindes te skep, selfs al het hulle nie regte om 'n versoek op die volume te skep nie. Dit is omdat RBAC-toestemmingkontroles toegepas word op die kontroleerder wat die PVC skep, nie op die gebruiker nie. Dit is die belangrikste verandering om by te voeg , voordat hierdie kenmerk geaktiveer word op groepe waar onbetroubare gebruikers nie regte behoort te hê om volumes te skep nie.
Voorbeeld
Skei PMEM-CSI bevat al die nodige veranderinge om 'n Kubernetes 1.19-kluster binne QEMU virtuele masjiene te laat loop met al die kenmerke in die alfa-stadium. Die bestuurderkode het nie verander nie, net die ontplooiing het verander.
Op 'n geskikte masjien (Linux, kan 'n normale gebruiker , kyk besonderhede) sal hierdie opdragte die cluster na vore bring en die PMEM-CSI-bestuurder installeer:
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
Nadat alles gewerk het, sal die uitset instruksies vir gebruik bevat:
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-voorwerpe is nie bedoel om deur mense gelees te word nie, so 'n mate van verwerking word vereis. Golang-sjabloonfilters sal die bergingsklasse wys, hierdie voorbeeld sal die naam, topologie en kapasiteit wys:
$ 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
'n Enkele voorwerp het die volgende inhoud:
$ 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>
Kom ons probeer om 'n demo-toepassing te skep met 'n enkele algemene doel kortstondige volume. Lêer inhoud 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
Nadat ons geskep is, soos in die instruksies hierbo getoon, het ons nou 'n bykomende peul en 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 eienaar - onder:
$ 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
...
Na verwagting opgedateerde inligting vir 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
As 'n ander toepassing meer as 26620Mi benodig, sal die skeduleerder nie in ag neem nie pmem-csi-pmem-govm-worker1 in elk geval.
Wat is volgende?
Albei kenmerke is nog in ontwikkeling. Verskeie toepassings is tydens alfa-toetsing oopgemaak. Die verbeteringsvoorstelskakels dokumenteer die werk wat gedoen moet word om na die beta-stadium te beweeg, asook watter alternatiewe reeds oorweeg en verwerp is:
Bron: will.com