Biltegiratze gaitasunaren jarraipena duten bolumen iragankorrak: EmptyDir esteroideetan

Biltegiratze gaitasunaren jarraipena duten bolumen iragankorrak: EmptyDir esteroideetan

Aplikazio batzuek datuak gorde behar dituzte, baina nahiko lasai daude berrabiarazi ondoren datuak ez direla gordeko kontuan hartuta.

Adibidez, cache zerbitzuak RAM memoriak mugatzen ditu, baina gutxitan erabiltzen diren datuak RAMa baino motelagoa den biltegira eraman ditzakete, errendimendu orokorrean eragin txikia izanik. Beste aplikazioek kontuan izan behar dute fitxategiek irakurtzeko soilik diren sarrerako datu batzuk izan ditzaketela, hala nola ezarpenak edo gako sekretuak.

Kubernetesek hainbat mota ditu dagoeneko bolumen iragankorrak, baina haien funtzionaltasuna K8s-etan inplementatutakora mugatuta dago.

Iragankorra CSI bolumenak Kubernetes CSI kontrolatzaileak erabiliz zabaltzea ahalbidetu zuen tokiko bolumen arinentzako laguntza emateko. Horri esker, erabiltzea posible da egitura arbitrarioak: ezarpenak, sekretuak, identitate-datuak, aldagaiak eta abar. CSI kontrolatzaileak aldatu behar dira Kubernetes funtzio hau onartzeko, kontrolatzaile estandarrek ez baitute funtzionatzea espero, baina bolumen horiek pod-erako hautatutako edozein nodotan erabilgarri egotea espero da.

Hau arazo bat izan daiteke nodoen baliabideen kontsumo handia duten bolumenentzat edo nodo batzuetan bakarrik eskuragarri dagoen biltegiratzearentzat. Beraz, Kubernetes 1.19-k bi alfa bolumen-ezaugarri berri aurkezten ditu, kontzeptualki EmptyDir bolumenen antzekoak:

  • helburu orokorreko bolumen iragankorrak;

  • CSI biltegiratze-ahalmenaren monitorizazioa.

Ikuspegi berriaren onurak:

  • biltegiratzea lokala edo sare baten bidez konektatuta izan daiteke;

  • Bolumenek aplikazioak gainditu ezin dezakeen tamaina zehatz bat izan dezakete;

  • Bolumen iraunkorrak hornitzea onartzen duen edozein CSI kontrolatzailerekin funtzionatzen du eta (ahalmenaren jarraipena laguntzeko) deia ezartzen du GetCapacity;

  • Bolumenek hasierako datu batzuk izan ditzakete gidariaren eta parametroen arabera;

  • bolumen-eragiketa tipiko guztiak (argazki bat sortzea, tamaina aldatzea, etab.) onartzen dira;

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

  • Kubernetes programatzaileak automatikoki hautatzen ditu nodo egokiak, beraz, ez dago programatzailearen luzapenak hornitu eta konfiguratu edo webhook-ak aldatu beharrik.

Aplikazio aukerak

Beraz, helburu orokorreko bolumen efimeroak egokiak dira aplikazio-eszenatoki hauetarako:

Memoria iraunkorra memcached-aren RAM ordezko gisa

Azken memcached bertsioak laguntza gehigarria memoria iraunkorra erabiliz (Intel Optane, etab., gutxi gorabehera. itzultzailea) RAM arruntaren ordez. Aplikazio-kontrolagailuaren bidez memcached-a zabaltzean, helburu orokorreko bolumen efimeroak erabil ditzakezu PMEM-etik tamaina jakin bateko bolumen baten esleipena eskatzeko CSI kontrolatzailea erabiliz, adibidez. PMEM-CSI.

LVM biltegiratze lokala lan-eremu gisa

RAM memoria baino handiagoak diren datuekin lan egiten duten aplikazioek tokiko biltegiratzea behar izan dezakete, Kubernetes EmptyDir bolumen arruntek eman ezin dituzten tamaina edo errendimendu metrikekin. Adibidez, TopoLVM.

Datu-bolumenetarako irakurketa-sarbidea soilik

Bolumen-esleipenak bolumen osoa eman dezake honako kasu hauetan:

Bolumen hauek irakurketa soilik moduan muntatu daitezke.

Nola egiten du lan

Helburu orokorreko bolumen efimeroak

Helburu orokorreko bolumen iragankorren ezaugarri nagusietako bat bolumen-iturri berria da, EphemeralVolumeSource, bolumen-eskaera bat sortzeko eremu guztiak dituena (historikoki bolumen-eskaera iraunkorra, PVC deitua). Kontrolatzaile berria hemen kube-controller-manager Bolumen-iturri hori sortzen duten podak bilatzen ditu eta gero PVCak sortzen ditu pod horientzat. CSI kontrolatzailearentzat, eskaera hau beste edozein bezalakoa da, beraz, ez da laguntza berezirik behar.

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

Automatikoki sortutako PVCen izenak aurrez definituta daude: pod izenaren eta bolumen izenaren konbinazioa, marratxo batez bereizita. Aurrez definitutako izenek PVCarekin elkarreragina errazten dute, pod izena eta bolumen izena ezagutzen badira bilatu beharrik ez dagoelako. Alde txarra da izena dagoeneko erabiltzen ari dela, eta Kubernetesek hori detektatzen du, pod-a abiaraztea eragotziz.

Bolumena pod-arekin batera ezabatzen dela ziurtatzeko, kontrolatzaileak bolumenaren eskaera bat egiten dio pod-aren jabeari. Pod-a ezabatzen denean, zabor bilketa mekanismo estandarra aktibatzen da, eskaera eta bolumena ezabatuz.

Eskaerak biltegiratze-kontrolatzaile batera mapatzen dira biltegiratze-klaseen mekanismo normalaren bidez. Berehalako eta beranduko lotura duten klaseak (hau da, WaitForFirstConsumer) onartzen dira, bolumen iragankorretarako zentzuzkoa da erabiltzea WaitForFirstConsumer, orduan programatzaileak nodoaren erabilera eta biltegiratze erabilgarritasuna kontuan har ditzake nodo bat hautatzerakoan. Hemen agertzen da funtzio berri bat.

Biltegiratze-ahalmenaren monitorizazioa

Normalean, programatzaileak ez daki non sortuko duen CSI gidariak bolumena. Ez du inolako modurik gidariarekin zuzenean harremanetan jartzeko informazio hori eskatzeko. Hori dela eta, programatzaileak nodoak galdekatzen ditu bolumenak atzitu daitezkeen bat aurkitu arte (lotura berantiarra) edo kokapenaren hautaketa erabat gidariari uzten dio (lotura berehalakoa).

New API CSIStorageCapacity, gaur egun alfa bertsioan dagoenak, beharrezko datuak etcd-n gordetzea ahalbidetzen du, programatzaileak eskuragarri izan ditzan. Bolumen efimero orokorretarako laguntza ez bezala, biltegiratze-ahalmenaren jarraipena gaituta egon behar da kontrolatzailea zabaltzean: external-provisioner gidariarengandik ohiko bidez jasotako edukiera-informazioa argitaratu behar du GetCapacity.

Programatzaileak lotura berantiarra erabiltzen duen bolumen lotu gabeko pod baterako nodo bat hautatu behar badu, eta gidariak funtzio hau gaitu badu inplementazioan zehar bandera ezarriz CSIDriver.storageCapacity, biltegiratze-ahalmen nahikorik ez duten nodoak automatikoki baztertuko dira. Honek helburu orokorreko bolumen iragankor eta iraunkorrentzat balio du, baina ez CSI bolumen iragankorrentzat, Kubernetesek ezin baititu haien parametroak irakurri.

Ohi bezala, pod-ak programatu aurretik berehala lotutako bolumenak sortzen dira, eta haien kokapena biltegiratze-gidariak aukeratzen du, beraz, konfiguratzerakoan external-provisioner Berez, berehalako lotura duten biltegiratze klaseak saltatzen dira, datuak ez baitira nolanahi ere erabiliko.

Kubernetes programatzailea informazio zaharkituarekin lan egitera behartuta dagoenez, ez dago bermerik bolumena sortzen denean edukiera beti eskuragarri egongo denik, baina hala ere handitzen dira berriro saiakerarik gabe sortzeko aukerak.

Oharra Informazio zehatzagoa lor dezakezu, baita segurtasunez "katuentzako euskarrian praktikatu" ere, eta egoera guztiz argi ez badago, laguntza tekniko kualifikatua jaso dezakezu ikastaro intentsiboetan - Kubernetes Base irailaren 28tik 30era izango da, eta espezialista aurreratuagoentzat Kubernetes Mega Urriaren 14tik 16ra.

Безопасность

CSI biltegiratze-ahalmena

CSIStorageCapacity objektuak izen-espazioetan daude. CSI kontrolatzaile bakoitza bere izen-espazioan zabaltzean, gomendagarria da CSIStorageCapacity-ren RBAC baimenak izen-espazio horretan mugatzea, datuak nondik datozen agerikoa baita. Kubernetesek ez du hau egiaztatzen nolanahi ere, eta kontrolatzaileak normalean izen-espazio berean zabaltzen dira, beraz, azken finean, kontrolatzaileek funtzionatzea eta datu okerrak ez argitaratzea espero da (eta hemen izan dut zortea). itzultzailearen oharra txiste ezagun batean oinarrituta)

Helburu orokorreko bolumen efimeroak

Erabiltzaileek pod bat sortzeko baimena badute (zuzenean edo zeharka), helburu orokorreko bolumen efimeroak ere sortu ahal izango dituzte, bolumen-eskaera bat sortzeko baimenik ez izan arren. Hau da RBAC baimen-egiaztapenak PVC sortzen duen kontrolatzaileari aplikatzen zaizkiolako, ez erabiltzaileari. Hau da egin behar den aldaketa nagusia. kontura., funtzio hau klusterretan gaitu aurretik, erabiltzaile fidagarri ez direnek bolumenak sortzeko baimenik ez badute.

Adibidea

Bereizi adar PMEM-CSI-k Kubernetes 1.19 kluster bat QEMU makina birtualen barruan alfa funtzio guztiekin exekutatzeko beharrezko aldaketa guztiak ditu. Kontrolatzailearen kodea aldatu gabe jarraitzen du, inplementazio prozesua bakarrik aldatu da.

Auto egoki batean (Linux, erabiltzaile normal batek erabil dezake Docker, begiratu Hemen xehetasunak) komando hauek klusterra piztuko 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

Dena ondo 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 daude gizakiek irakurtzeko pentsatuta, beraz, prozesaketa batzuk behar dira. Golang txantiloi-iragazkiak erabiliz, biltegiratze-klaseak bistaratuko dira. Adibide honetan, izena, topologia eta edukiera bistaratuko dira:

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

Saiatu gaitezen demo aplikazio bat sortzen helburu orokorreko bolumen efimero bakarrarekin. Fitxategiaren 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

Goiko argibideetan erakusten den bezala, sortu ondoren, pod eta PVC gehigarri bat lortu genuen:

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

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

Espero bezala, informazioa eguneratu da 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 funtzioak oraindik garapen fasean daude. Hainbat txartel ireki ziren alfa probak egiten ari zirela. Hobekuntza-iradokizunen estekek beta bertsiora igarotzeko behar den lana dokumentatzen dute, baita dagoeneko kontuan hartu eta baztertutako alternatibak ere:

Iturria: www.habr.com

Erosi hosting fidagarria DDoS babesa duten guneetarako, VPS VDS zerbitzariak 🔥 Erosi webguneentzako ostatu fidagarria DDoS babesarekin, VPS VDS zerbitzariak | ProHoster