ProHoster > Blog > Administrazioa > Biltegiratze gaitasunaren jarraipena duten bolumen iragankorrak: EmptyDir esteroideetan

Biltegiratze gaitasunaren jarraipena duten bolumen iragankorrak: EmptyDir esteroideetan

Biltegiratze gaitasunaren jarraipena duten bolumen iragankorrak: EmptyDir esteroideetan

Aplikazio batzuek ere datuak gorde behar dituzte, baina nahiko eroso daude berrabiarazi ondoren datuak ez direla gordeko.

Esaterako, RAM-ak mugatzen ditu cache-zerbitzuak, baina oso gutxitan erabiltzen diren datuak RAM baino motelagoak diren biltegiratze batera eraman ditzakete, errendimendu orokorrean eragin gutxirekin. Beste aplikazio batzuek kontutan izan behar dute fitxategietan irakurtzeko soilik sarrera batzuk egon daitezkeela, hala nola ezarpenak edo gako sekretuak.

Kubernetes-ek dagoeneko hainbat mota ditu bolumen iragankorrak, baina haien funtzionaltasuna K8etan inplementatutakora mugatzen da.

Iraunkorra CSI bolumenak Kubernetes CSI kontrolatzaileekin zabaltzea ahalbidetu zuen, tokiko bolumen arinetarako laguntza emateko. Modu honetan erabil daiteke egitura arbitrarioak: ezarpenak, sekretuak, identifikazio-datuak, aldagaiak, etab. CSI kontrolatzaileak aldatu behar dira Kubernetes funtzio hau onartzeko, ohiko kontrolatzaile estandarizatuek ez dutela funtzionatuko suposatzen baita, baina suposatzen da bolumen horiek podrako hautatutako edozein nodotan erabil daitezkeela.

Hau arazo bat izan daiteke ostalari-baliabide garrantzitsuak kontsumitzen dituzten bolumenetarako edo ostalari batzuetan soilik erabilgarri dagoen biltegiratzeko. Horregatik, Kubernetes 1.19-k bi alfa proba-bolumen ezaugarri berri aurkezten ditu, kontzeptualki EmptyDir-en bolumenen antzekoak:

  • helburu orokorreko bolumen iragankorrak;

  • CSI biltegiratze gaitasunaren jarraipena.

Ikuspegi berriaren abantailak:

  • biltegiratzea lokala edo sare baten bidez konektatuta izan daiteke;

  • bolumenek aplikazioak gainditu ezin duen tamaina zehatz bat izan dezakete;

  • Bolumen iraunkorrak hornitzea onartzen duten eta (ahalmenaren jarraipena egiteko) deia inplementatzen duten CSI kontrolatzailerekin funtzionatzen du GetCapacity;

  • bolumenek hasierako datu batzuk izan ditzakete kontrolatzailearen eta ezarpenen arabera;

  • Bolumena duten eragiketa estandar guztiak (instantanea bat sortzea, tamaina aldatzea, etab.) onartzen dira;

  • bolumenak modulu edo bolumen zehaztapen bat onartzen duen edozein aplikazio kontrolagailurekin erabil daitezke;

  • Kubernetes programatzaileak bere kabuz aukeratzen ditu nodo egokiak, beraz, jada ez dago programatzaileen luzapenak hornitu eta konfiguratu edo webhook-ak aldatzeko beharrik.

Aplikazio aukerak

Beraz, helburu orokorreko bolumen iragankorrak egokiak dira erabilera kasu hauetarako:

Memoria iraunkorra RAM ordezko gisa memcached-erako

Memcached-en azken bertsioak laguntza gehitu memoria iraunkorra erabiliz (Intel Optane, etab., gutxi gorabehera. itzultzailea) RAM arruntaren ordez. Memcached aplikazio-kontrolatzaile baten bidez zabaltzen duzunean, helburu orokorreko bolumen iragankorrak erabil ditzakezu PMEM-tik tamaina jakin bateko bolumen bat esleitzeko CSI kontrolatzailea erabiliz, adibidez. PMEM-CSI.

LVM tokiko biltegiratzea lan-eremu gisa

RAM baino handiagoak diren datuekin lan egiten duten aplikazioek Kuberneteseko EmptyDir bolumen arruntek eman ezin dituzten tamaina edo errendimendu-neurriekin biltegiratze lokala behar dute. Adibidez, horretarako idatzi zen TopoLVM.

Datu-bolumenetarako irakurtzeko soilik sarbidea

Bolumen bat esleitzeak bolumen osoa sortzea eragin dezake:

Bolumen hauek irakurtzeko soilik moduan munta daitezke.

Nola egiten du lan

Helburu orokorreko liburuki iragankorrak

Helburu orokorreko bolumen iragankorren ezaugarri nagusi bat bolumen iturri berria da, EphemeralVolumeSource, bolumen-eskaera bat sortzeko eremu guztiak biltzen dituena (historikoki bolumen-eskaera iraunkorra deitzen zaio, PVC). Kontrolagailu berria sartu kube-controller-manager bolumen-iturburu hori sortzen duten lekak aztertzen ditu, eta, ondoren, leka horientzako PVC bat sortzen du. CSI gidariarentzat, eskaera honek besteen itxura berdina du, beraz, ez da laguntza berezirik behar hemen.

Horrelako PVCak existitzen diren bitartean, bolumenaren beste edozein eskaera bezala erabil daitezke. Bereziki, datu-iturri gisa erreferentzia egin daiteke bolumen bat kopiatzean edo bolumen batetik argazki bat sortzean. PVC objektuak bolumenaren egungo egoera ere badu.

Automatikoki sortutako PVC-en izenak aurrez definituta daude: podaren izenaren eta bolumenaren izenaren konbinazioa dira, marratxo batez bereizita. Aurrez definitutako izenek PVCarekin elkarreragina errazten dute, ez duzulako bilatu beharrik pod izena eta bolumenaren izena ezagutzen badituzu. Alde txarra da izena dagoeneko erabiltzen ari dela, Kubernetes-ek detektatzen duena eta, ondorioz, poda abiaraztetik blokeatuta dagoela.

Bolumena podarekin batera ezabatzen dela ziurtatzeko, kontrolatzaileak eskaera bat egiten dio jabearen menpeko bolumenari. Pod-a ezabatzen denean, zabor bilketa-mekanismo estandarrak funtzionatzen du, eskaera eta bolumena ezabatzen dituena.

Biltegiratze-kontrolatzaileak biltegiratze-klasearen ohiko mekanismoaren bidez bat egiten du eskaerak. Nahiz eta berehalako eta beranduko lotura duten klaseak (aka WaitForFirstConsumer) onartzen dira, liburuki iragankorretarako zentzuzkoa da erabiltzeak WaitForFirstConsumer, orduan programatzaileak nodoen erabilera eta biltegiratze erabilgarritasuna kontuan har ditzake nodo bat hautatzerakoan. Ezaugarri berri bat agertzen da hemen.

Biltegiratze gaitasunaren jarraipena

Normalean, programatzaileak ez du ezagutzen CSI kontrolatzaileak bolumena non sortuko duen. Ez dago programatzaileak gidariarekin zuzenean harremanetan jartzeko modurik ere informazio hori eskatzeko. Hori dela eta, programatzaileak nodoak galdetzen ditu bolumenak zeinetan atzitu daitezkeen aurkitzen duen arte (lotura berandu) edo gidariaren esku uzten duen kokapenaren aukera erabat (berehalako lotura).

New API CSIStorageCapacity, alfa fasean dagoena, beharrezko datuak etcd-n gordetzeko aukera ematen du, programatzaileak eskuragarri egon daitezen. Helburu orokorreko bolumen iragankorretarako laguntza ez bezala, kontrolatzailea zabaltzen duzunean, biltegiratze-ahalmenaren jarraipena gaitu behar duzu: external-provisioner gidariarengandik jasotako edukierari buruzko informazioa normal bidez argitaratu beharko luke GetCapacity.

Antolatzaileak nodo bat hautatu behar badu lotu gabeko bolumen bat duen pod baterako, lotura berantiarra erabiltzen duena, eta gidariak funtzio hau gaituta badu inplementazioan bandera ezarriz CSIDriver.storageCapacity, gero biltegiratze-ahalmen nahikoa ez duten nodoak automatikoki baztertuko dira. Honek helburu orokorreko bolumen iragankor nahiz iraunkorretarako funtzionatzen du, baina ez CSI bolumen iragankorrentzat, haien parametroak Kubernetesek ezin dituelako irakurri.

Ohi bezala, berehala loturiko bolumenak sortzen dira pod-ak programatu aurretik, eta haien kokapena biltegiratze kontrolatzaileak aukeratzen du, beraz, konfiguratzean. external-provisioner Lehenespenez, berehalako lotura duten biltegiratze-klaseak saltatzen dira, datu hauek hala ere ez baitira erabiliko.

Kubernetes-en programatzailea eguneratuta egon daitekeen informazioarekin lan egitera behartuta dagoenez, ez dago bermatzen bolumena sortzen den bakoitzean edukiera erabilgarri egongo denik, baina berriro saiatu gabe sortzeko aukerak areagotu egiten dira.

Oharra Informazio zehatzagoa lor dezakezu, baita segurtasunez "katuen postuan praktikatu", eta guztiz ulertezina den egoeraren kasuan, laguntza tekniko kualifikatua jaso ikastaro trinkoetan - Kubernetes Base irailaren 28tik 30era egingo da, eta espezialista aurreratuagoentzat Kubernetes Mega Urriaren 14tik 16ra.

Π‘Π΅Π·ΠΎΠΏΠ°ΡΠ½ΠΎΡΡ‚ΡŒ

CSISbiltegiratze-gaitasuna

CSIStorageCapacity objektuak izen-espazioetan bizi dira; CSI kontrolatzaile bakoitza bere izen-eremuan zabaltzean, espazio horretan CSIStorageCapacity-ra RBAC eskubideak mugatzea gomendatzen da, datuak nondik datozen argi baitago. Kubernetes-ek ez du hori egiaztatzen hala ere, eta normalean gidariak izen-espazio berean jartzen dira, beraz, azken finean, kontrolatzaileek funtzionatuko dutela espero da eta ez dute datu okerrak argitaratzea (eta hemen nire txartelak huts egin zuen, gutxi gorabehera. txiste bizardun batean oinarritutako itzultzailea)

Helburu orokorreko liburuki iragankorrak

Erabiltzaileek pod bat sortzeko eskubiderik badute (zuzenean edo zeharka), helburu orokorreko bolumen iragankorrak ere sortu ahal izango dituzte bolumenean eskaera bat sortzeko eskubiderik ez badute ere. Hau da, RBAC baimenaren egiaztapenak PVCa sortzen duen kontrolatzaileari aplikatzen zaizkiolako, ez erabiltzaileari. Hau da gehitzeko aldaketa nagusia zure kontura, funtzio hau gaitu aurretik, fidagarriak ez diren erabiltzaileek bolumenak sortzeko eskubiderik izan behar ez duten klusterretan.

Adibidea

Bereizi adar PMEM-CSI-k QEMU makina birtualen barruan Kubernetes 1.19 kluster bat exekutatzeko beharrezkoak diren aldaketa guztiak ditu alfa faseko ezaugarri guztiekin. Gidariaren kodea ez da aldatu, inplementazioa bakarrik aldatu da.

Makina egoki batean (Linux, erabiltzaile arrunt batek erabil dezake Docker, begira Hemen xehetasunak) komando hauek clusterra agertuko dute eta PMEM-CSI kontrolatzailea instalatuko dute:

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

Guztiak funtzionatu ondoren, irteerak erabiltzeko argibideak izango ditu:

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 objektuak ez dira gizakiek irakurtzeko pentsatuta, beraz, prozesatu batzuk behar dira. Golang txantiloi-iragazkiek biltegiratze-klaseak erakutsiko dituzte, adibide honek izena, topologia eta edukiera erakutsiko ditu:

$ 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

Objektu bakar batek honako edukia du:

$ 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>

Saia gaitezen demo aplikazio bat sortzen helburu orokorreko bolumen iragankor bakar batekin. Fitxategien edukia 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

Sortu ondoren, goiko argibideetan erakusten den bezala, orain pod eta PVC gehigarri bat ditugu:

$ 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 jabea - azpian:

$ 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
...

Ustez eguneratutako informazioa 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

Beste aplikazio batek 26620Mi baino gehiago behar baditu, programatzaileak ez du kontuan hartuko pmem-csi-pmem-govm-worker1 nolanahi ere.

Zer da hurrengoa?

Bi ezaugarriak garatzen ari dira oraindik. Alfa probetan hainbat aplikazio ireki ziren. Hobekuntza-proposamenen loturek beta fasera pasatzeko egin behar den lana dokumentatzen dute, baita dagoeneko kontuan hartu eta baztertu diren alternatibak ere:

Iturria: www.habr.com

Gehitu iruzkin berria