ProHoster > Log > administrasjon > Ephemeral Volumes with Storage Capacity Tracking: EmptyDir på steroider

Ephemeral Volumes with Storage Capacity Tracking: EmptyDir på steroider

Ephemeral Volumes with Storage Capacity Tracking: EmptyDir på steroider

Noen applikasjoner trenger også å lagre data, men de er ganske komfortable med at dataene ikke blir lagret etter en omstart.

For eksempel er cachingtjenester begrenset av RAM, men kan også flytte data som sjelden brukes til lagring som er tregere enn RAM, med liten innvirkning på den generelle ytelsen. Andre applikasjoner må være klar over at det kan være noen skrivebeskyttet inndata i filene, for eksempel innstillinger eller hemmelige nøkler.

Kubernetes har allerede flere typer flyktige volumer, men funksjonaliteten deres er begrenset til det som er implementert i K8s.

Ephemeral CSI-volumer tillot Kubernetes å bli utvidet med CSI-drivere for å gi støtte for lette lokale volumer. På denne måten er det mulig å bruke vilkårlige strukturer: innstillinger, hemmeligheter, identifikasjonsdata, variabler og så videre. CSI-drivere må modifiseres for å støtte denne Kubernetes-funksjonen, siden det antas at vanlige standardiserte drivere ikke vil fungere – men det antas at slike volumer kan brukes på hvilken som helst node valgt for poden.

Dette kan være et problem for volumer som bruker betydelige vertsressurser eller for lagring som bare er tilgjengelig på enkelte verter. Det er derfor Kubernetes 1.19 introduserer to nye alfatestingsvolumfunksjoner som konseptuelt ligner på EmptyDir-volumer:

  • flyktige volumer for generelle formål;

  • CSI lagringskapasitet sporing.

Fordeler med den nye tilnærmingen:

  • lagring kan være lokal eller koblet til via et nettverk;

  • volumer kan ha en spesifisert størrelse som ikke kan overskrides av applikasjonen;

  • fungerer med alle CSI-drivere som støtter klargjøring av vedvarende volumer og (for å støtte kapasitetssporing) implementere samtalen GetCapacity;

  • volumer kan ha noen innledende data avhengig av driveren og innstillingene;

  • alle standard operasjoner med et volum (opprette et øyeblikksbilde, endre størrelse osv.) støttes;

  • volumer kan brukes med enhver applikasjonskontroller som godtar en modul- eller volumspesifikasjon;

  • Kubernetes-planleggeren velger passende noder på egen hånd, slik at du ikke lenger trenger å klargjøre og konfigurere planleggerutvidelser og endre webhooks.

Bruksområder

Derfor er flyktige volumer for generelle formål egnet for følgende brukstilfeller:

Vedvarende minne som erstatning for RAM for memcached

Siste utgivelser av memcached lagt til støtte bruker vedvarende minne (Intel Optane, etc., ca. oversetter) i stedet for vanlig RAM. Når du distribuerer memcached gjennom en applikasjonskontroller, kan du bruke flyktige volumer for generelle formål for å be om at et volum av en gitt størrelse tildeles fra PMEM ved å bruke CSI-driveren, for eksempel PMEM-CSI.

LVM lokal lagring som et arbeidsområde

Apper som fungerer med data som er større enn RAM kan kreve lokal lagring med en størrelse eller ytelsesmålinger som vanlige EmptyDir-volumer fra Kubernetes ikke kan gi. For eksempel ble det skrevet for dette formålet TopoLVM.

Skrivebeskyttet tilgang for datavolumer

Tildeling av et volum kan resultere i opprettelse av et fullt volum når:

Disse volumene kan monteres i skrivebeskyttet modus.

Hvordan fungerer det

Kortvarige bind for generelle formål

Et nøkkeltrekk ved flyktige volumer for generell bruk er den nye volumkilden, EphemeralVolumeSource, som inneholder alle feltene for å opprette en volumforespørsel (historisk kalt en vedvarende volumforespørsel, PVC). Ny kontroller inne kube-controller-manager ser på podene som lager en slik volumkilde, og lager deretter en PVC for disse podene. For CSI-driveren ser denne forespørselen ut som de andre, så det er ikke nødvendig med spesiell støtte her.

Så lenge slike PVC-er eksisterer, kan de brukes som alle andre forespørsler på volumet. Spesielt kan de refereres til som en datakilde når du kopierer et volum eller lager et øyeblikksbilde fra et volum. PVC-objektet inneholder også den nåværende tilstanden til volumet.

Navnene på automatisk opprettede PVC-er er forhåndsdefinert: de er en kombinasjon av podnavnet og volumnavnet, atskilt med en bindestrek. Forhåndsdefinerte navn gjør det lettere å samhandle med PVC-en fordi du ikke trenger å lete etter den hvis du kjenner podnavnet og volumnavnet. Ulempen er at navnet kanskje allerede er i bruk, noe som oppdages av Kubernetes og som et resultat blokkeres poden fra å starte.

For å sikre at volumet slettes sammen med poden, sender kontrolleren en forespørsel til volumet under eieren. Når poden slettes, kjøres standard søppelinnsamlingsmekanismen, som sletter både forespørselen og volumet.

Forespørsler matches av lagringsdriveren gjennom den vanlige mekanismen til lagringsklassen. Selv om klasser med umiddelbar og sen binding (aka WaitForFirstConsumer) støttes, for flyktige volumer er det fornuftig å bruke WaitForFirstConsumer, så kan planleggeren vurdere både nodebruk og lagringstilgjengelighet når du velger en node. En ny funksjon vises her.

Sporing av lagringskapasitet

Vanligvis har planleggeren ingen kunnskap om hvor CSI-driveren vil opprette volumet. Det er heller ingen måte for planleggeren å kontakte sjåføren direkte for å be om denne informasjonen. Derfor spør planleggeren noder til den finner en som volumer kan nås på (sen binding) eller overlater valget av plassering helt til sjåføren (umiddelbar binding).

Ny API CSIStorageCapacity, som er i alfastadiet, gjør at de nødvendige dataene kan lagres i etcd slik at de er tilgjengelige for planleggeren. I motsetning til støtte for flyktige volumer for generelle formål, må du aktivere sporing av lagringskapasitet når du distribuerer driveren: external-provisioner skal publisere kapasitetsinformasjonen mottatt fra sjåføren via normal GetCapacity.

Hvis planleggeren trenger å velge en node for en pod med et ubundet volum som bruker sen binding, og driveren aktivert denne funksjonen under distribusjon ved å sette flagget CSIDriver.storageCapacity, vil noder som ikke har nok lagringskapasitet automatisk bli forkastet. Dette fungerer for både flyktige og vedvarende volum for generelle formål, men ikke for flyktige CSI-volumer fordi deres parametere ikke kan leses av Kubernetes.

Som vanlig opprettes umiddelbart koblede volumer før pods planlegges, og deres plassering velges av lagringsdriveren, så når du konfigurerer external-provisioner Som standard hoppes lagringsklasser med umiddelbar binding over, siden disse dataene uansett ikke vil bli brukt.

Siden kubernetes-planleggeren er tvunget til å jobbe med potensielt utdatert informasjon, er det ingen garanti for at kapasitet vil være tilgjengelig i alle tilfeller når volumet opprettes, men sjansene for at det opprettes uten gjenforsøk øker likevel.

NB Du kan få mer detaljert informasjon, samt trygt "øve på kattestativet", og i tilfelle en helt uforståelig situasjon, motta kvalifisert teknisk støttehjelp på intensivkurs - Kubernetes Base holdes 28.-30. september, og for mer avanserte spesialister Kubernetes Mega 14.–16. oktober.

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

CSIStorageCapacity

CSIStorageCapacity-objekter ligger i navnerom; når du ruller ut hver CSI-driver i sitt eget navneområde, anbefales det å begrense RBAC-rettigheter til CSIStorageCapacity i det rommet siden det er åpenbart hvor dataene kommer fra. Kubernetes sjekker ikke for dette uansett, og vanligvis plasseres drivere i samme navneområde, så til syvende og sist forventes det at driverne fungerer og ikke publiserer feil data (og det er her kortet mitt mislyktes, ca. oversetter basert på en skjeggete vits)

Kortvarige bind for generelle formål

Hvis brukere har rettigheter til å lage en pod (direkte eller indirekte), vil de også kunne lage flyktige volumer for generelle formål selv om de ikke har rettigheter til å opprette en forespørsel på volumet. Dette er fordi RBAC-tillatelseskontroller brukes på kontrolleren som lager PVC, ikke på brukeren. Dette er hovedendringen å legge til til kontoen din, før du aktiverer denne funksjonen på klynger der uklarerte brukere ikke skal ha rettigheter til å opprette volumer.

Eksempel

Skille gren PMEM-CSI inneholder alle nødvendige endringer for å kjøre en Kubernetes 1.19-klynge i virtuelle QEMU-maskiner med alle funksjonene i alfastadiet. Driverkoden er ikke endret, bare distribusjonen er endret.

På en passende maskin (Linux, kan en vanlig bruker bruke Docker, se her detaljer) vil disse kommandoene hente frem 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

Etter at alt fungerer, vil utgangen inneholde instruksjoner for bruk:

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 ment å leses av mennesker, så noe behandling er nødvendig. Golang-malfiltre vil vise lagringsklassene, dette eksemplet vil vise navn, topologi og kapasitet:

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

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

La oss prøve å lage en demoapplikasjon med et enkelt flyktig volum for generell bruk. Filinnhold 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

Etter opprettelsen, som vist i instruksjonene ovenfor, har vi nå 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-eier - 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 oppdatert informasjon for 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 annen applikasjon trenger mer enn 26620Mi, tar ikke planleggeren hensyn pmem-csi-pmem-govm-worker1 i alle fall.

Hva blir det neste?

Begge funksjonene er fortsatt under utvikling. Flere applikasjoner ble åpnet under alfatesting. Forbedringsforslagslenkene dokumenterer arbeidet som må gjøres for å gå over til betastadiet, samt hvilke alternativer som allerede er vurdert og avvist:

Kilde: www.habr.com

Legg til en kommentar