Joidenkin sovellusten on myös tallennettava tietoja, mutta ne ovat melko tyytyväisiä siihen, että tiedot eivät tallennu uudelleenkäynnistyksen jälkeen.
Esimerkiksi RAM rajoittaa välimuistipalveluita, mutta ne voivat myös siirtää harvoin käytettyjä tietoja RAM-muistia hitaampaan tallennustilaan, mikä ei vaikuta yleiseen suorituskykyyn. Muiden sovellusten on oltava tietoisia siitä, että tiedostoissa voi olla vain luku -syöte, kuten asetukset tai salaiset avaimet.
Kubernetesilla on jo useita tyyppejä , mutta niiden toiminnallisuus rajoittuu siihen, mikä on toteutettu K8sissa.
Efemeraalinen salli Kubernetesin laajentamisen CSI-ajureilla tukemaan kevyitä paikallisia levyjä. Tällä tavalla on mahdollista käyttää : asetukset, salaisuudet, tunnistetiedot, muuttujat ja niin edelleen. CSI-ajureita on muokattava tukemaan tätä Kubernetes-ominaisuutta, koska oletetaan, että tavalliset standardisoidut ajurit eivät toimi - mutta oletetaan, että tällaisia määriä voidaan käyttää missä tahansa podille valitussa solmussa.
Tämä voi olla ongelma taltioissa, jotka kuluttavat merkittäviä isäntäresursseja, tai tallennustilassa, joka on saatavilla vain joissakin isännissä. Siksi Kubernetes 1.19 esittelee kaksi uutta alfa-testaustilavuusominaisuutta, jotka ovat käsitteellisesti samanlaisia kuin EmptyDir-taltiot:
-
yleiskäyttöiset lyhytkestoiset volyymit;
-
CSI-tallennuskapasiteetin seuranta.
Uuden lähestymistavan edut:
-
tallennustila voi olla paikallinen tai yhdistetty verkon kautta;
-
tilavuuksilla voi olla tietty koko, jota sovellus ei voi ylittää;
-
toimii kaikkien CSI-ajureiden kanssa, jotka tukevat pysyvien määrien hallintaa ja (kapasiteetin seurannan tukemiseksi) toteuttavat kutsun
GetCapacity; -
taltioilla voi olla alkutietoja ohjaimesta ja asetuksista riippuen;
-
kaikki vakiotoiminnot äänenvoimakkuudella (kuvan luominen, koon muuttaminen jne.) ovat tuettuja;
-
volyymeja voidaan käyttää minkä tahansa sovellusohjaimen kanssa, joka hyväksyy moduulin tai tilavuusmäärityksen;
-
Kubernetes-ajastin valitsee sopivat solmut itse, joten sinun ei enää tarvitse valmistaa ja määrittää ajoituslaajennuksia tai muokata webhookeja.
Sovellusvaihtoehdot
Siksi yleiskäyttöiset lyhytaikaiset volyymit sopivat seuraaviin käyttötapauksiin:
Pysyvä muisti korvaa RAM-muistin välimuistissa
Memcachedin uusimmat julkaisut pysyvän muistin käyttäminen (Intel Optane jne., noin kääntäjä) tavallisen RAM-muistin sijaan. Kun otat memcachedin käyttöön sovellusohjaimen kautta, voit käyttää yleiskäyttöisiä lyhytaikaisia määriä pyytääksesi, että tietyn kokoinen taltio varataan PMEM:ltä esimerkiksi CSI-ohjaimen avulla. .
LVM paikallinen tallennustila työtilana
Sovellukset, jotka toimivat RAM-muistia suuremman datan kanssa, saattavat vaatia paikallista tallennustilaa, jonka koko tai suorituskykymittaukset eivät pysty tarjoamaan Kubernetesin tavalliset EmptyDir-taltiot. Esimerkiksi tätä tarkoitusta varten se kirjoitettiin .
Vain luku -käyttöoikeus tietomäärille
Volyymin allokointi voi johtaa täyden volyymin luomiseen, kun:
-
elpyminen ;
-
luominen ;
-
työ .
Nämä taltiot voidaan asentaa vain luku -tilaan.
Kuinka tämä toimii
Yleiskäyttöiset lyhytaikaiset volyymit
Yleiskäyttöisten lyhytaikaisten volyymien avainominaisuus on uusi volyymilähde, EphemeralVolumeSource, joka sisältää kaikki kentät volyymipyynnön luomiseksi (kutsutaan perinteisesti pysyväksi tilavuuspyynnöksi, PVC). Uusi ohjain sisään kube-controller-manager tarkastelee koteloita, jotka luovat tällaisen volyymilähteen, ja luo sitten PVC:n niille. CSI-ohjaimelle tämä pyyntö näyttää samalta kuin muut, joten erityistukea ei tarvita tässä.
Niin kauan kuin tällaisia PVC:itä on olemassa, niitä voidaan käyttää kuten mitä tahansa muita tilavuuspyyntöjä. Erityisesti niitä voidaan käyttää tietolähteinä kopioitaessa taltiota tai luotaessa tilannekuvaa taltiosta. PVC-objekti sisältää myös tilavuuden nykyisen tilan.
Automaattisesti luotujen PVC:iden nimet ovat ennalta määritettyjä: ne ovat yhdistelmän pod-nimen ja taltion nimen väliviivalla erotettuna. Ennalta määritetyt nimet helpottavat vuorovaikutusta PVC:n kanssa, koska sinun ei tarvitse etsiä sitä, jos tiedät pod-nimen ja taltion nimen. Huono puoli on, että nimi saattaa olla jo käytössä, minkä Kubernetes havaitsee ja seurauksena podin käynnistyminen estyy.
Varmistaakseen, että taltio poistetaan podin mukana, ohjain tekee pyynnön omistajan alla olevalle levylle. Kun pod poistetaan, tavallinen roskienkeräysmekanismi toimii, joka poistaa sekä pyynnön että äänenvoimakkuuden.
Tallennusohjain vastaa pyyntöihin tallennusluokan normaalin mekanismin kautta. Vaikka luokat, joissa on välitön ja myöhäinen sitominen (alias WaitForFirstConsumer). WaitForFirstConsumer, niin ajoittaja voi ottaa huomioon sekä solmun käytön että tallennustilan saatavuuden solmun valinnassa. Uusi ominaisuus ilmestyy tänne.
Tallennuskapasiteetin seuranta
Tyypillisesti ajastajalla ei ole tietoa siitä, missä CSI-ohjain luo levyn. Aikatauluttaja ei myöskään voi ottaa suoraan yhteyttä kuljettajaan pyytääkseen näitä tietoja. Siksi ajoittaja kyselee solmuja, kunnes se löytää sellaisen, jonka taltiot voidaan käyttää (myöhäinen sidonta) tai jättää sijainnin valinnan kokonaan ohjaimelle (välitön sidonta).
Uusi CSIStorageCapacity, joka on alfa-vaiheessa, mahdollistaa tarvittavien tietojen tallentamisen etcd:hen, jotta se on aikatauluttajan käytettävissä. Toisin kuin yleiskäyttöisten lyhytaikaisten taltioiden tuki, kun otat ohjaimen käyttöön, sinun on otettava käyttöön tallennuskapasiteetin seuranta: external-provisioner pitäisi julkaista kuljettajalta tavallisen kautta saadut kapasiteettitiedot GetCapacity.
Jos ajoittajan on valittava solmu ryhmälle, jossa on sitomaton asema ja joka käyttää myöhäistä sidontaa, ja ohjain otti tämän ominaisuuden käyttöön käyttöönoton aikana asettamalla lipun CSIDriver.storageCapacity, silloin solmut, joilla ei ole tarpeeksi tallennuskapasiteettia, hylätään automaattisesti. Tämä toimii sekä yleiskäyttöisille lyhytkestoisille että pysyville levyille, mutta ei CSI:n lyhytkestoisille levyille, koska Kubernetes ei voi lukea niiden parametreja.
Kuten tavallista, välittömästi linkitetyt taltiot luodaan ennen podien ajoittamista, ja tallennusohjain valitsee niiden sijainnin, joten määritettäessä external-provisioner Oletusarvoisesti välittömät sidotut tallennusluokat ohitetaan, koska näitä tietoja ei käytetä joka tapauksessa.
Koska kubernetes-aikataulutin on pakko työskennellä mahdollisesti vanhentuneiden tietojen kanssa, ei ole takeita siitä, että kapasiteetti on käytettävissä joka tapauksessa, kun taltio luodaan, mutta todennäköisyys, että se luodaan ilman uudelleenyrityksiä, kasvaa kuitenkin.
NB Saat tarkempaa tietoa, sekä turvallisesti “harjoittelet kissojen seisomalla”, ja täysin käsittämättömän tilanteen sattuessa saada pätevää teknistä tukea intensiivikursseilla - pidetään 28.-30. ja edistyneemmille asiantuntijoille lokakuuta 14-16.
Безопасность
CSIStorageCapacity
CSIStorageCapacity-objektit sijaitsevat nimiavaruuksissa; kun jokainen CSI-ohjain otetaan käyttöön omassa nimiavaruudessaan, on suositeltavaa rajoittaa RBAC-oikeudet CSIStorageCapacityyn kyseisessä tilassa, koska on selvää, mistä tiedot ovat peräisin. Kubernetes ei kuitenkaan tarkista tätä, ja yleensä ajurit laitetaan samaan nimiavaruuteen, joten lopulta ohjainten odotetaan toimivan eivätkä julkaise vääriä tietoja (ja tässä korttini epäonnistui, noin parrakasvitsiin perustuva kääntäjä)
Yleiskäyttöiset lyhytaikaiset volyymit
Jos käyttäjillä on oikeudet luoda pod (suoraan tai epäsuorasti), he voivat myös luoda yleiskäyttöisiä lyhytaikaisia taltioita, vaikka heillä ei olisi oikeuksia luoda pyyntöä taltiolle. Tämä johtuu siitä, että RBAC-lupatarkistuksia sovelletaan ohjaimeen, joka luo PVC:n, ei käyttäjään. Tämä on tärkein lisättävä muutos , ennen kuin otat tämän ominaisuuden käyttöön klustereissa, joissa ei-luotettavilla käyttäjillä ei pitäisi olla oikeuksia taltioiden luomiseen.
Esimerkki
Erillinen PMEM-CSI sisältää kaikki tarvittavat muutokset Kubernetes 1.19 -klusterin suorittamiseksi QEMU-virtuaalikoneissa kaikilla alfa-vaiheen ominaisuuksilla. Kuljettajakoodi ei ole muuttunut, vain käyttöönotto on muuttunut.
Sopivalla koneella (Linux, tavallinen käyttäjä voi käyttää , Katso tiedot) nämä komennot tuovat klusterin ja asentavat PMEM-CSI-ohjaimen:
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
Kun kaikki toimii, tulos sisältää käyttöohjeet:
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-objekteja ei ole tarkoitettu ihmisten luettavaksi, joten käsittelyä tarvitaan. Golang-mallisuodattimet näyttävät tallennusluokat, tämä esimerkki näyttää nimen, topologian ja kapasiteetin:
$ 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
Yhdellä objektilla on seuraava sisältö:
$ 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>
Yritetään luoda esittelysovellus, jossa on yksi yleiskäyttöinen lyhytaikainen tilavuus. Tiedoston sisältö 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
Kun olet luonut, kuten yllä olevissa ohjeissa näkyy, meillä on nyt ylimääräinen kotelo ja 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-omistaja - alla:
$ 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
...
Odotetusti päivitetyt tiedot kohteelle 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
Jos toinen sovellus tarvitsee enemmän kuin 26620Mi, ajastin ei ota huomioon pmem-csi-pmem-govm-worker1 Joka tapauksessa.
Mitä seuraavaksi?
Molemmat ominaisuudet ovat vielä kehitteillä. Alfatestauksen aikana avattiin useita sovelluksia. Parannusehdotuslinkeissä dokumentoidaan työt, jotka on tehtävä beta-vaiheeseen siirtymiseksi, sekä mitkä vaihtoehdot on jo harkittu ja hylätty:
Lähde: will.com