🥇Ephemeral volume med lagerkapacitets sporing: EmptyDir på steroider

Nogle applikationer har også brug for at gemme data, men de er forholdsvis ligeglade med, at dataene ikke vil blive gemt efter genstart.

For eksempel er caching-tjenester begrænset af den tilgængelige hukommelse, men de kan også flytte data, der sjældent anvendes, til lager, der fungerer langsommere end RAM, med en minimal indvirkning på den samlede ydeevne. Andre applikationer har brug for at vide, at nogle filer kan indeholde data, der kun er til læsning, som for eksempel indstillinger eller hemmelige nøgler.

I Kubernetes er der allerede flere typer efemære volumener, men deres funktionalitet er begrænset til det, der er implementeret i K8s.

Efemære CSI-volumener har gjort det muligt at udvide Kubernetes med CSI-drivere for at sikre støtte til letvægts lokale volumener. På denne måde kan der anvendes vilkårlige strukturer: indstillinger, hemmeligheder, identitetsdata, variabler og så videre. CSI-drivere skal tilpasses for at understøtte denne funktion i Kubernetes, da man forventer, at almindelige standardiserede drivere ikke vil fungere — men det forventes, at sådanne volumener kan bruges på enhver node, der er valgt til pod.

Dette kan blive et problem for volumener med betydeligt ressourcetræk fra noden eller for lager, der kun er tilgængeligt på nogle noder. Derfor introducerer Kubernetes 1.19 to nye volumenfunktioner til alpha-testning, konceptuelt ligesom EmptyDir-volumener:

efemære volumener til generelt brug;
overvågning af CSI-lagerkapacitet.

Fordele ved den nye tilgang:

lager kan være lokalt eller netværksforbundet;
volumener kan have en specificeret størrelse, der ikke må overskrides af applikationen;
det fungerer med alle CSI-drivere, der understøtter levering af permanente volumener og (til støtte for kapacitetsovervågning) implementerer kaldet GetCapacity;
volumener kan have nogle indledende data afhængigt af driver og parametre;
alle standardoperationer med volumener (oprettelse af snapshot, ændring af størrelse, osv.) understøttes;
volumener kan bruges med enhver applikationscontroller, der accepterer modul- eller volumen-specifikationer;
Kubernetes-planlæggeren vælger selv passende noder, så det er ikke længere nødvendigt at sikre og konfigurere planlæggerudvidelser og ændre webhooks.

Anvendelsesmuligheder

Således er efemære volumener til generel brug velegnede til følgende anvendelsesmuligheder:

Permanent hukommelse som erstatning for RAM til memcached

Seneste udgivelser af memcached tilføjede support for brugen af permanent hukommelse (Intel Optane osv., oversætterens bemærkning) i stedet for almindelig RAM. Når memcached implementeres via en applikationscontroller, kan man ved hjælp af efemære volumener anmode om tildeling af et volumens størrelse fra PMEM ved hjælp af CSI-driveren, for eksempel PMEM-CSI.

Lokal lagring LVM som arbejdsområde

Applikationer, der arbejder med data, hvis størrelse overstiger størrelsen på RAM, kan anmode om lokal lagring med størrelser eller ydelsesmetrikker, som almindelige EmptyDir-volumener fra Kubernetes ikke kan levere. For eksempel blev TopoLVM.

Læseadgang for data volumener

Tildelingen af et volumen kan føre til oprettelsen af et fyldt volumen ved:

gendannelse af et snapshots af et volumen;
oprettelse af en kopi af et volumen;
arbejde data fyldstoffer.

Disse volumener kan monteres i skrivebeskyttet tilstand.

Hvordan fungerer det

Efemære volumener til generel brug

En nøglefunktion ved efemære volumener til generel brug er den nye volumenkilde, EphemeralVolumeSource, der indeholder alle felter til at oprette en anmodning til volumenet (historisk kaldet anmodning om permanent volumen, PVC). Den nye controller i kube-controller-manager gennemgår pods, der opretter en sådan volumenkilde, og skaber derefter en PVC for disse pods. For CSI-driveren ser denne anmodning ligesom de øvrige anmodninger ud, så der er ikke behov for særlig støtte her.

Så længe sådanne PVC'er eksisterer - kan de bruges som enhver anden volumensanmodning. Især kan de refereres til som datakilde, når et volumen kopieres eller et snapshot tages af et volumen. PVC-objektet indeholder også den nuværende tilstand af volumenet.

Navne på automatisk oprettede PVC'er er foruddefinerede: det er en kombination af podnavn og volumenavn adskilt af en bindestreg. Den foruddefinerede navnekombination gør det nemmere at arbejde med PVC, da det ikke er nødvendigt at lede efter det, hvis podnavn og volumenavn er kendt. Ulempen er, at navnet allerede kan være i brug, hvilket Kubernetes opdager, og som resultat blokeres pod-implementeringen.

For at sikre, at volumenet slettes sammen med pod'en, gør controlleren pod'en til ejer af anmodningen om volumenet. Når pod'en slettes, aktiveres den normale opsamlingsmekanisme, som sletter både anmodningen og volumenet.

Anmodningerne tilknyttes lagermodtageren via en almindelig mekanisme for lagerklasse. Selvom klasser med øjeblikkelig og forsinket binding (også kaldet WaitForFirstConsumer) understøttes, giver det mening at bruge WaitForFirstConsumer, så planlæggeren kan tage hensyn til både nodens brug og lagerets tilgængelighed ved valg af node. Her introduceres en ny funktion.

Lagerkapacitetsopsporing

Normalt har planlæggeren ikke data om, hvor CSI-driveren vil oprette volumenet. Derudover har planlæggeren ikke mulighed for at kontakte driveren direkte for at anmode om disse oplysninger. Derfor spørger planlæggeren noderne, indtil den finder en, hvor volumenet kan være tilgængeligt (forsinket binding) eller lader driveren helt bestemme placeringen (øjeblikkelig binding).

Ny API CSIStorageCapacity, som er i alpha-fasen, muliggør opbevaring af nødvendige data i etcd, så de er tilgængelige for planlæggeren. I modsætning til støtte til generelle temporære volumen kræver implementeringen af driveren aktivering af lagerkapacitetsopsporing: external-provisioner skal offentliggøre kapacitetsoplysninger, modtaget fra driveren via den almindelige GetCapacity.

Hvis planlæggeren skal vælge en node til pod'en med et uforbundet volumen, der bruger forsinket binding, og driveren aktiverede denne funktion ved implementering ved at sætte flaget CSIDriver.storageCapacity, vil noder uden tilstrækkelig lagerkapacitet automatisk blive udelukket. Dette gælder både generelle temporære og permanente volumener, men ikke for CSI-temporære volumener, da deres egenskaber ikke kan aflæses af Kubernetes.

Som vanlig oprettes volume med øjeblikkelig binding før planlægning af pods, og deres placering vælges af lagringsdriveren, så når du konfigurerer external-provisioner sprækkes lagringsklasser med øjeblikkelig binding som standard, da disse data alligevel ikke vil blive brugt.

Da Kubernetes-planlæggeren er tvunget til at arbejde med potentielt forældede oplysninger, er der ingen garantier for, at kapaciteten vil være tilgængelig, når volume oprettes, men chancerne for, at det bliver oprettet uden forsøg, stiger dog.

N.B. Du vil kunne få mere information og sikkert "træne på katte i en testbench", og i tilfælde af en helt uforståelig situation få kvalificeret support ved intensivkurser — Kubernetes Basis som finder sted den 28.-30. september, og for mere avancerede specialister Kubernetes Mega 14-16 oktober.

Sikkerhed

CSIStorageCapacity

CSIStorageCapacity-objekter er placeret i navnerum, når hver CSI-driver rulles ud, anbefales det at begrænse RBAC-rettigheder for CSIStorageCapacity i dette navnerum, da det er klart, hvor dataene kommer fra. Under alle omstændigheder tjekker Kubernetes ikke dette, og normalt installeres drivere i ét navnerum, så det forventes, at driverne fungerer og ikke offentliggør forkerte data (og her fik jeg kortet til at passe, note fra oversætteren inspireret af en gammel vits)

Efemære volumener til generel brug

Hvis brugerne har rettigheder til at oprette en pod (direkte eller indirekte) — vil de også kunne oprette ephemeral volume til generelt brug, selvom de ikke har rettigheder til at oprette en forespørgsel om volume. Og alt dette fordi RBAC-rettighederne gælder for controlleren, der opretter PVC, og ikke for brugeren. Det er den grundlæggende ændring, der skal tilføjes til kontoen, før denne funktion aktiveres i klynger, hvis usikre brugere ikke skal have rettigheder til at oprette volume.

Eksempel

Separat tråd i PMEM-CSI indeholder alle nødvendige ændringer for at køre en Kubernetes-klynge 1.19 inde i QEMU-virtuelmaskiner med alle funktioner, der er i alfa-stadiet. Driverkoden er ikke ændret, kun implementeringen er blevet ændret.

På en passende maskine (Linux, almindelig bruger kan bruge Docker, se her detaljer) vil disse kommandoer starte klyngen 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 er sat op, vil output indeholde instruktioner til brug:

Testklusteret er klar. Log ind med [...]\/pmem-csi\/_work\/pmem-govm\/ssh.0, kør
kubectl når du er logget ind. Alternativt kan du bruge kubectl direkte med
følgende miljøvariabel:
   KUBECONFIG=[...]\/pmem-csi\/_work\/pmem-govm\/kube.config

secret\/pmem-csi-registry-secrets oprettet
secret\/pmem-csi-node-secrets oprettet
serviceaccount\/pmem-csi-controller oprettet
...
For at prøve pmem-csi driverens ephemeral volumes:
   cat deploy\/kubernetes-1.19\/pmem-app-ephemeral.yaml |
   [...]\/pmem-csi\/_work\/pmem-govm\/ssh.0 kubectl create -f -

Objekter af typen CSIStorageCapacity er ikke beregnet til menneskelig læsning, så der kræves en vis behandling. Med hjælpe af skabelonfiltre i Golang vil lagerklasser blive vist, i dette eksempel vil navn, topologi og kapacitet blive vist:

$ 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 separat objekt har følgende indhold:

$ kubectl describe csistoragecapacities\/csisc-6cw8j
Navn:         csisc-sqdnt
Namespace:    default
Labels:       
Annotations:  
API Version:  storage.k8s.io\/v1alpha1
Kapacitet:     30716Mi
Type:         CSIStorageCapacity
Metadata:
  Oprettelsestidspunkt:  2020-08-11T15:41:03Z
  Generere navn:       csisc-
  Forvaltede felter:
    ...
  Ejerreferencer:
    API Version:     apps\/v1
    Controller:      true
    Type:            StatefulSet
    Navn:            pmem-csi-controller
    UID:             590237f9-1eb4-4208-b37b-5f7eab4597d1
  Ressourceversion:  2994
  Selvlink:         \/apis\/storage.k8s.io\/v1alpha1\/namespaces\/default\/csistoragecapacities\/csisc-sqdnt
  UID:               da36215b-3b9d-404a-a4c7-3f1c3502ab13
Nodetopologi:
  Match Labels:
    pmem-csi.intel.com\/node:  pmem-csi-pmem-govm-worker1
Lagerklasse navn:           pmem-csi-sc-late-binding
Begivenheder:

Lad os prøve at oprette en demonstrationsapplikation med én ephemeral volumne af generel anvendelse. Indholdet i filen 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 oprettelse, som vist i instruktionen ovenfor, har vi fået en ekstra pod og PVC:

$ kubectl get pods\/my-csi-app-inline-volume -o wide
NAVN                       KLAR   STATUS    GENSTARTS   ALDER     IP          NODE                         NODENAVN   LÆSNINGSGATE
my-csi-app-inline-volume   1\/1     Kører   0          6m58s   10.36.0.2   pmem-csi-pmem-govm-worker1              
$ kubectl get pvc\/my-csi-app-inline-volume-my-csi-volume
NAVN                                     STATUS   VOLUME                                     KAPACITET   ADGANGSMÅDER   STORAGECLASS               ALDER
my-csi-app-inline-volume-my-csi-volume   Bundet    pvc-c11eb7ab-a4fa-46fe-b515-b366be908823   4Gi        RWO            pmem-csi-sc-late-binding   9m21s

Ejer af 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
...

Forventet opdateret information til 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 dette i betragtning pmem-csi-pmem-govm-worker1 under alle omstændigheder.

Hvad nu?

Begge funktioner er stadig under udvikling. Der er blevet åbnet flere anmodninger under alpha-testen. Der dokumenteres arbejde via links med forslag til forbedringer for, hvordan man kan gå til beta-fasen, samt hvilke alternativer der allerede er blevet overvejet og afvist:

Kilde: habr.com