ProHoster > Blog > administration > Lagerkapacitet sporede flygtige volumener: EmptyDir på steroider

Lagerkapacitet sporede flygtige volumener: EmptyDir på steroider

Lagerkapacitet sporede flygtige volumener: EmptyDir på steroider

Nogle applikationer skal også gemme data, men de er ret komfortable med, at dataene ikke bliver gemt efter en genstart.

For eksempel er cachetjenester begrænset af RAM, men kan også flytte data, der sjældent bruges, til lager, der er langsommere end RAM, med ringe indflydelse på den samlede ydeevne. Andre programmer skal være opmærksomme på, at der kan være nogle skrivebeskyttede input i filerne, såsom indstillinger eller hemmelige nøgler.

Kubernetes har allerede flere typer flygtige bind, men deres funktionalitet er begrænset til det, der er implementeret i K8'erne.

Ephemeral CSI-volumener tillod Kubernetes at blive udvidet med CSI-drivere for at understøtte lette lokale volumener. På denne måde er det muligt at bruge vilkårlige strukturer: indstillinger, hemmeligheder, identifikationsdata, variabler og så videre. CSI-drivere skal modificeres for at understøtte denne Kubernetes-funktion, da det antages, at almindelige standardiserede drivere ikke vil fungere - men det antages, at sådanne volumener kan bruges på enhver node valgt til poden.

Dette kan være et problem for enheder, der bruger betydelige værtsressourcer, eller for lager, der kun er tilgængelig på nogle værter. Det er derfor, Kubernetes 1.19 introducerer to nye alfa-testvolumenfunktioner, der konceptuelt ligner EmptyDir-volumener:

  • flygtige bind til generelle formål;

  • CSI-lagerkapacitetssporing.

Fordele ved den nye tilgang:

  • lagring kan være lokalt eller forbundet via et netværk;

  • volumener kan have en specificeret størrelse, der ikke kan overskrides af applikationen;

  • fungerer med alle CSI-drivere, der understøtter levering af vedvarende volumener og (for at understøtte kapacitetssporing) implementerer opkaldet GetCapacity;

  • volumener kan have nogle indledende data afhængigt af driveren og indstillingerne;

  • alle standardoperationer med en volumen (oprettelse af et snapshot, ændring af størrelse osv.) understøttes;

  • volumener kan bruges med enhver applikationscontroller, der accepterer en modul- eller volumenspecifikation;

  • Kubernetes-planlæggeren vælger egnede noder alene, så der er ikke længere behov for at klargøre og konfigurere planlægningsudvidelser eller ændre webhooks.

Applikationsindstillinger

Derfor er flygtige volumener til generelle formål egnede til følgende anvendelsessager:

Vedvarende hukommelse som erstatning for RAM til memcached

Seneste udgivelser af memcached tilføjet støtte ved hjælp af vedvarende hukommelse (Intel Optane osv., ca. oversætter) i stedet for almindelig RAM. Når du implementerer memcached gennem en applikationscontroller, kan du bruge kortvarige volumener til generelle formål til at anmode om, at en volumen af ​​en given størrelse allokeres fra PMEM ved hjælp af CSI-driveren, f.eks. PMEM-CSI.

LVM lokalt lager som et arbejdsområde

Programmer, der arbejder med data, der er større end RAM, kan kræve lokal lagring med en størrelse eller ydeevnemålinger, som almindelige EmptyDir-volumener fra Kubernetes ikke kan levere. For eksempel blev det skrevet til dette formål TopoLVM.

Skrivebeskyttet adgang til datamængder

Tildeling af en volumen kan resultere i oprettelse af en fuld volumen, når:

Disse volumener kan monteres i skrivebeskyttet tilstand.

Hvordan fungerer denne her

Kortvarige bind til generelle formål

Et nøgletræk ved kortvarige volumener til generelle formål er den nye volumenkilde, EphemeralVolumeSource, der indeholder alle felterne til at oprette en volumenanmodning (historisk kaldet en persistent volume request, PVC). Ny controller ind kube-controller-manager ser på de pods, der skaber en sådan volumenkilde, og laver derefter en PVC til disse pods. For CSI-driveren ser denne anmodning ud som de andre, så der er ikke behov for særlig support her.

Så længe sådanne PVC'er eksisterer, kan de bruges som alle andre forespørgsler på volumen. De kan især henvises til som en datakilde, når du kopierer en diskenhed eller laver et snapshot fra en diskenhed. PVC-objektet indeholder også volumenets aktuelle tilstand.

Navnene på automatisk oprettede PVC'er er foruddefinerede: de er en kombination af podnavnet og volumennavnet, adskilt af en bindestreg. Foruddefinerede navne gør det lettere at interagere med PVC, fordi du ikke behøver at lede efter det, hvis du kender podnavnet og volumennavnet. Ulempen er, at navnet muligvis allerede er i brug, hvilket bliver opdaget af Kubernetes, og som følge heraf er poden blokeret fra at starte.

For at sikre, at volumen slettes sammen med poden, sender controlleren en anmodning til volumen under ejeren. Når poden slettes, fungerer standardaffaldsindsamlingsmekanismen, som sletter både anmodningen og volumen.

Anmodninger matches af lagerdriveren gennem lagerklassens normale mekanisme. Selvom klasser med øjeblikkelig og sen binding (aka WaitForFirstConsumer) understøttes, for flygtige mængder giver det mening at bruge WaitForFirstConsumer, så kan planlæggeren overveje både nodebrug og lagertilgængelighed, når der vælges en node. En ny funktion vises her.

Sporing af lagerkapacitet

Planlæggeren har typisk ingen viden om, hvor CSI-driveren vil oprette volumen. Der er heller ingen måde for planlæggeren at kontakte chaufføren direkte for at anmode om disse oplysninger. Derfor spørger skemalæggeren noder, indtil den finder en, hvor der kan tilgås bind (sen binding) eller overlader valget af placering helt til føreren (umiddelbar binding).

Nyt API CSIStorageCapacity, som er i alfastadiet, gør det muligt at lagre de nødvendige data i etcd, så de er tilgængelige for planlæggeren. I modsætning til understøttelse af kortvarige volumener til generelle formål, skal du aktivere lagerkapacitetssporing, når du implementerer driveren: external-provisioner skal offentliggøre kapacitetsoplysningerne modtaget fra chaufføren via alm GetCapacity.

Hvis planlæggeren skal vælge en node til en pod med en ubundet volumen, der bruger sen binding, og driveren aktiverede denne funktion under implementeringen ved at indstille flaget CSIDriver.storageCapacity, så vil noder, der ikke har nok lagerkapacitet, automatisk blive kasseret. Dette virker for både kortvarige og vedvarende volumener til generelle formål, men ikke for flygtige CSI-volumener, fordi deres parametre ikke kan læses af Kubernetes.

Som sædvanlig oprettes umiddelbart forbundne volumener, før pods planlægges, og deres placering vælges af lagerdriveren, så når du konfigurerer external-provisioner Som standard springes lagerklasser med øjeblikkelig binding over, da disse data alligevel ikke vil blive brugt.

Da kubernetes-planlæggeren er tvunget til at arbejde med potentielt forældede informationer, er der ingen garanti for, at kapacitet vil være tilgængelig i alle tilfælde, når volumen oprettes, men chancerne for, at den bliver oprettet uden genforsøg, øges alligevel.

NB Du kan få mere detaljeret information, samt sikkert "øve dig på kattestanden", og i tilfælde af en helt uforståelig situation modtage kvalificeret teknisk support assistance på intensive kurser - Kubernetes Base afholdes den 28.-30. september, og for mere avancerede specialister Kubernetes Mega 14.–16. oktober.

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

CSIS StorageCapacity

CSIStorageCapacity-objekter ligger i navnerum; når hver CSI-driver udrulles i sit eget navneområde, anbefales det at begrænse RBAC-rettigheder til CSIStorageCapacity i dette rum, da det er tydeligt, hvor dataene kommer fra. Kubernetes tjekker alligevel ikke efter dette, og sædvanligvis placeres drivere i det samme navneområde, så i sidste ende forventes driverne at virke og ikke offentliggøre forkerte data (og det er her, mit kort fejlede, ca. oversætter baseret på en skægget joke)

Kortvarige bind til generelle formål

Hvis brugere har rettigheder til at oprette en pod (direkte eller indirekte), vil de også være i stand til at oprette kortvarige volumener til generelle formål, selvom de ikke har rettigheder til at oprette en anmodning på volumen. Dette skyldes, at RBAC-tilladelsestjek anvendes på den controller, der skaber PVC'en, ikke på brugeren. Dette er den vigtigste ændring, der skal tilføjes til din konto, før du aktiverer denne funktion på klynger, hvor upålidelige brugere ikke bør have rettigheder til at oprette volumener.

Eksempel

Adskille gren PMEM-CSI indeholder alle de nødvendige ændringer for at køre en Kubernetes 1.19-klynge inde i QEMU virtuelle maskiner med alle funktionerne i alfa-stadiet. Driverkoden er ikke ændret, kun implementeringen er ændret.

På en passende maskine (Linux, kan en normal bruger bruge Docker, se her detaljer) vil disse kommandoer hente klyngen frem og installere PMEM-CSI-driveren:

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

Når alt virker, vil outputtet indeholde instruktioner til brug:

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-objekter er ikke beregnet til at blive læst af mennesker, så en vis behandling er påkrævet. Golang skabelonfiltre viser lagerklasserne, dette eksempel viser navn, topologi og kapacitet:

$ 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

Et enkelt objekt har følgende indhold:

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

Lad os prøve at skabe en demoapplikation med et enkelt kortvarigt volumen til generelle formål. Filens indhold 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

Efter at have oprettet, som vist i instruktionerne ovenfor, har vi nu en ekstra pod og 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 ejer - under:

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

Forventet opdateret information vedr 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

Hvis en anden applikation har brug for mere end 26620Mi, vil planlæggeren ikke tage højde for det pmem-csi-pmem-govm-worker1 i hvert fald.

Hvad er det næste?

Begge funktioner er stadig under udvikling. Adskillige applikationer blev åbnet under alfa-testning. Forbedringsforslagets links dokumenterer det arbejde, der skal gøres for at gå til betastadiet, samt hvilke alternativer, der allerede er blevet overvejet og afvist:

Kilde: www.habr.com

Tilføj en kommentar