Nekatere aplikacije morajo tudi shranjevati podatke, vendar jim je povsem všeč dejstvo, da se podatki po ponovnem zagonu ne bodo shranili.
Na primer, storitve predpomnjenja so omejene z RAM-om, vendar lahko tudi premaknejo podatke, ki se redko uporabljajo, v shrambo, ki je počasnejša od RAM-a, z majhnim vplivom na splošno zmogljivost. Druge aplikacije se morajo zavedati, da so lahko v datotekah nekateri vnosi samo za branje, kot so nastavitve ali skrivni ključi.
Kubernetes ima že več vrst , vendar je njihova funkcionalnost omejena na tisto, kar je implementirano v K8s.
Efemerno je omogočil razširitev Kubernetesa z gonilniki CSI za zagotavljanje podpore za lahke lokalne nosilce. Na ta način je mogoče uporabiti : nastavitve, skrivnosti, identifikacijski podatki, spremenljivke itd. Gonilnike CSI je treba spremeniti, da bodo podpirali to funkcijo Kubernetes, saj se od navadnih standardiziranih gonilnikov ne pričakuje, da bodo delovali – vendar se pričakuje, da bodo takšni nosilci uporabni v katerem koli vozlišču, izbranem za pod.
To je lahko težava pri nosilcih, ki porabijo znatne vire gostitelja, ali pri pomnilniku, ki je na voljo samo na nekaterih gostiteljih. Zato Kubernetes 1.19 uvaja dve novi funkciji alfa preskusne količine, ki sta konceptualno podobni nosilcem EmptyDir:
-
efemerne knjige za splošne namene;
-
Sledenje zmogljivosti shranjevanja CSI.
Prednosti novega pristopa:
-
shranjevanje je lahko lokalno ali povezano prek omrežja;
-
nosilci imajo lahko določeno velikost, ki je aplikacija ne more preseči;
-
deluje z vsemi gonilniki CSI, ki podpirajo zagotavljanje trajnih nosilcev in (za podporo sledenju zmogljivosti) izvajajo klic
GetCapacity; -
nosilci imajo lahko nekaj začetnih podatkov, odvisno od gonilnika in nastavitev;
-
podprte so vse standardne operacije z nosilcem (ustvarjanje posnetka, spreminjanje velikosti itd.);
-
količine je mogoče uporabiti s katerim koli aplikacijskim krmilnikom, ki sprejme specifikacijo modula ali nosilca;
-
Razporejevalnik Kubernetes sam izbere ustrezna vozlišča, tako da ni več potrebe po zagotavljanju in konfiguriranju razširitev razporejevalnika ali spreminjanju spletnih kavljev.
Možnosti aplikacije
Zato so efemerne količine za splošni namen primerne za naslednje primere uporabe:
Trajni pomnilnik kot zamenjava za RAM za memcached
Najnovejše izdaje memcached z uporabo trajnega pomnilnika (Intel Optane itd., pribl. prevajalec) namesto običajnega RAM-a. Ko uvajate memcached prek krmilnika aplikacij, lahko uporabite efemerne nosilce splošnega namena, da zahtevate, da se nosilec določene velikosti dodeli iz PMEM z uporabo gonilnika CSI, na primer .
Lokalni pomnilnik LVM kot delovni prostor
Aplikacije, ki delujejo s podatki, ki so večji od RAM-a, lahko zahtevajo lokalni pomnilnik z meritvami velikosti ali zmogljivosti, ki jih običajni nosilci EmptyDir iz Kubernetesa ne morejo zagotoviti. Na primer, za ta namen je bilo napisano .
Dostop samo za branje za količine podatkov
Dodelitev nosilca lahko povzroči ustvarjanje celotnega nosilca, kadar:
-
okrevanje ;
-
ustvarjanje ;
-
Delo .
Te nosilce je mogoče namestiti v načinu samo za branje.
Kako to deluje
Efemerni zvezki za splošni namen
Ključna značilnost efemernih zvezkov za splošno uporabo je nov vir zvezkov, EphemeralVolumeSource, ki vsebuje vsa polja za ustvarjanje zahteve za količino (zgodovinsko imenovana zahteva za trajno količino, PVC). Nov krmilnik v kube-controller-manager pogleda stroke, ki ustvarjajo tak vir glasnosti, in nato ustvari PVC za te stroke. Za gonilnik CSI je ta zahteva enaka kot druge, zato tukaj ni potrebna posebna podpora.
Dokler taki PVC-ji obstajajo, jih je mogoče uporabljati kot vse druge zahteve na nosilcu. Zlasti se lahko nanje sklicujete kot na vir podatkov pri kopiranju nosilca ali ustvarjanju posnetka iz nosilca. PVC objekt vsebuje tudi trenutno stanje volumna.
Imena samodejno ustvarjenih PVC-jev so vnaprej določena: so kombinacija imena sklopa in imena nosilca, ločenih z vezajem. Vnaprej določena imena olajšajo interakcijo s PVC-jem, saj vam ga ni treba iskati, če poznate ime sklopa in ime nosilca. Slaba stran je, da je ime morda že v uporabi, kar zazna Kubernetes in posledično je blok blokiran pri zagonu.
Za zagotovitev, da je nosilec izbrisan skupaj s podom, krmilnik pošlje zahtevo nosilcu pod lastnikom. Ko se pod izbriše, deluje standardni mehanizem za zbiranje smeti, ki izbriše tako zahtevo kot nosilec.
Gonilnik za shranjevanje se ujema z zahtevami prek običajnega mehanizma razreda za shranjevanje. Čeprav so razredi s takojšnjo in pozno vezavo (aka WaitForFirstConsumer) so podprti, za efemerne količine jih je smiselno uporabiti WaitForFirstConsumer, potem lahko razporejevalnik pri izbiri vozlišča upošteva uporabo vozlišča in razpoložljivost pomnilnika. Tu se pojavi nova funkcija.
Sledenje zmogljivosti shranjevanja
Razporejevalnik običajno ne ve, kje bo gonilnik CSI ustvaril glasnost. Prav tako ni možnosti, da bi načrtovalec neposredno stopil v stik z voznikom in zahteval te informacije. Zato razporejevalnik anketira vozlišča, dokler ne najde tistega, na katerem je mogoče dostopati do nosilcev (pozno povezovanje), ali izbiro lokacije v celoti prepusti gonilniku (takojšnje povezovanje).
Novo CSIStorageCapacity, ki je v fazi alfa, omogoča shranjevanje potrebnih podatkov v etcd, tako da so na voljo razporejevalniku. Za razliko od podpore za efemerne nosilce splošnega namena, ko uvedete gonilnik, morate omogočiti sledenje zmogljivosti shranjevanja: external-provisioner mora objaviti informacije o zmogljivosti, ki jih prejme od voznika prek običajne GetCapacity.
Če mora razporejevalnik izbrati vozlišče za pod z nevezanim nosilcem, ki uporablja pozno povezovanje, in je gonilnik omogočil to funkcijo med uvajanjem z nastavitvijo zastavice CSIDriver.storageCapacity, bodo vozlišča, ki nimajo dovolj pomnilniške zmogljivosti, samodejno zavržena. To deluje tako za kratkotrajne kot za obstojne nosilce splošnega namena, ne pa tudi za kratkotrajne nosilce CSI, ker Kubernetes ne more prebrati njihovih parametrov.
Kot običajno se takoj povezani nosilci ustvarijo, preden so sklopi razporejeni, njihovo postavitev pa izbere gonilnik za shranjevanje, tako da pri konfiguriranju external-provisioner Privzeto so pomnilniški razredi s takojšnjo vezavo preskočeni, ker ti podatki vseeno ne bodo uporabljeni.
Ker je razporejevalnik kubernetes prisiljen delati s potencialno zastarelimi informacijami, ni nobenega zagotovila, da bo zmogljivost na voljo v vsakem primeru, ko je nosilec ustvarjen, vendar so možnosti, da bo ustvarjen brez ponovnih poskusov, vseeno povečane.
Opomba: Lahko dobite podrobnejše informacije, pa tudi varno "vadite na stojnici za mačke" in v primeru popolnoma nerazumljive situacije prejmete kvalificirano tehnično pomoč na intenzivnih tečajih - bo 28.-30., za višje specialiste pa 14.–16. oktober.
varnost
CSIStorageCapacity
Objekti CSIStorageCapacity se nahajajo v imenskih prostorih; pri uvajanju vsakega gonilnika CSI v lastnem imenskem prostoru je priporočljivo omejiti pravice RBAC na CSIStorageCapacity v tem prostoru, saj je očitno, od kod prihajajo podatki. Kubernetes tega tako ali tako ne preveri in običajno so gonilniki postavljeni v isti imenski prostor, tako da se na koncu pričakuje, da bodo gonilniki delovali in ne bodo objavljali napačnih podatkov (in tukaj je moja kartica odpovedala, pribl. prevajalec na podlagi bradate šale)
Efemerni zvezki za splošni namen
Če imajo uporabniki pravice za ustvarjanje sklopa (neposredno ali posredno), bodo lahko ustvarili tudi efemerne nosilce za splošni namen, tudi če nimajo pravic za ustvarjanje zahteve na nosilcu. To je zato, ker se preverjanja dovoljenj RBAC uporabljajo za krmilnik, ki ustvari PVC, ne za uporabnika. To je glavna sprememba, ki jo je treba dodati , preden omogočite to funkcijo v gručah, kjer nezaupljivi uporabniki ne bi smeli imeti pravic za ustvarjanje nosilcev.
Primer
Ločeno PMEM-CSI vsebuje vse potrebne spremembe za zagon gruče Kubernetes 1.19 znotraj virtualnih strojev QEMU z vsemi funkcijami v fazi alfa. Koda gonilnika se ni spremenila, spremenila se je le uvedba.
Na ustreznem računalniku (Linux, lahko uporablja običajen uporabnik , poglej podrobnosti) bodo ti ukazi prikazali gručo in namestili gonilnik 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
Ko vse deluje, bo rezultat vseboval navodila za uporabo:
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 -
Objekti CSIStorageCapacity niso namenjeni branju s strani ljudi, zato je potrebna določena obdelava. Filtri predlog Golang bodo prikazali razrede shranjevanja, ta primer bo prikazal ime, topologijo in zmogljivost:
$ 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
Posamezen objekt ima naslednjo vsebino:
$ 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>
Poskusimo ustvariti predstavitveno aplikacijo z enim efemernim nosilcem splošnega namena. Vsebina datoteke 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
Po ustvarjanju, kot je prikazano v zgornjih navodilih, imamo zdaj dodaten pod in 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
Lastnik PVC - pod:
$ 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
...
Pričakovano posodobljeni podatki za 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
Če druga aplikacija potrebuje več kot 26620Mi, razporejevalnik ne bo upošteval pmem-csi-pmem-govm-worker1 v vsakem primeru.
Kaj sledi?
Obe funkciji sta še v razvoju. Med testiranjem alfa je bilo odprtih več aplikacij. Povezave predloga izboljšave dokumentirajo delo, ki ga je treba opraviti za prehod na stopnjo beta, pa tudi, katere alternative so bile že obravnavane in zavrnjene:
Vir: www.habr.com