ProHoster > blogg > administration > Efemära volymer med spårning av lagringskapacitet: EmptyDir på steroider

Efemära volymer med spårning av lagringskapacitet: EmptyDir på steroider

Efemära volymer med spårning av lagringskapacitet: EmptyDir på steroider

Vissa applikationer behöver också lagra data, men de är ganska bekväma med att data inte kommer att sparas efter en omstart.

Till exempel är cachningstjänster begränsade av RAM, men kan också flytta data som sällan används till lagring som är långsammare än RAM, med liten inverkan på den totala prestandan. Andra program måste vara medvetna om att det kan finnas viss skrivskyddad indata i filerna, till exempel inställningar eller hemliga nycklar.

Kubernetes har redan flera typer flyktiga volymer, men deras funktionalitet är begränsad till vad som är implementerat i K8s.

Kortlivad CSI-volymer tillät Kubernetes att utökas med CSI-drivrutiner för att ge stöd för lätta lokala volymer. På så sätt är det möjligt att använda godtyckliga strukturer: inställningar, hemligheter, identifieringsdata, variabler och så vidare. CSI-drivrutiner måste modifieras för att stödja denna Kubernetes-funktion, eftersom det antas att vanliga standardiserade drivrutiner inte kommer att fungera - men det antas att sådana volymer kan användas på vilken nod som helst som valts för podden.

Detta kan vara ett problem för volymer som förbrukar betydande värdresurser eller för lagring som bara är tillgänglig på vissa värdar. Det är därför Kubernetes 1.19 introducerar två nya alfatestningsvolymfunktioner som konceptuellt liknar EmptyDir-volymer:

  • kortvariga volymer för allmänna ändamål;

  • Spårning av CSI-lagringskapacitet.

Fördelar med det nya tillvägagångssättet:

  • lagring kan vara lokal eller ansluten via ett nätverk;

  • volymer kan ha en specificerad storlek som inte kan överskridas av applikationen;

  • fungerar med alla CSI-drivrutiner som stöder tillhandahållande av beständiga volymer och (för att stödja kapacitetsspårning) implementera samtalet GetCapacity;

  • volymer kan ha vissa initiala data beroende på drivrutinen och inställningarna;

  • alla standardoperationer med en volym (skapa en ögonblicksbild, ändra storlek, etc.) stöds;

  • volymer kan användas med vilken applikationsstyrenhet som helst som accepterar en modul- eller volymspecifikation;

  • Kubernetes schemaläggare väljer lämpliga noder på egen hand, så det finns inte längre något behov av att tillhandahålla och konfigurera schemaläggartillägg eller ändra webhooks.

Programalternativ

Därför är kortvariga volymer för allmänna ändamål lämpliga för följande användningsfall:

Beständigt minne som ersättning för RAM för memcached

Senaste utgåvorna av memcached lagt till stöd använder beständigt minne (Intel Optane, etc., cirka. översättare) istället för vanligt RAM. När du distribuerar memcached via en applikationskontroller kan du använda tillfälliga volymer för allmänna ändamål för att begära att en volym av en given storlek allokeras från PMEM med CSI-drivrutinen, till exempel PMEM-CSI.

LVM lokal lagring som arbetsyta

Applikationer som arbetar med data som är större än RAM-minne kan kräva lokal lagring med en storlek eller prestandamått som vanliga EmptyDir-volymer från Kubernetes inte kan tillhandahålla. Till exempel skrevs det för detta ändamål TopoLVM.

Skrivskyddad åtkomst för datavolymer

Tilldelning av en volym kan resultera i att en full volym skapas när:

Dessa volymer kan monteras i skrivskyddat läge.

Hur fungerar den här

Kortvariga volymer för allmänna ändamål

En nyckelfunktion för kortvariga volymer för allmänna ändamål är den nya volymkällan, EphemeralVolumeSource, som innehåller alla fält för att skapa en volymbegäran (historiskt kallad en beständig volymbegäran, PVC). Ny styrenhet in kube-controller-manager tittar på baljorna som skapar en sådan volymkälla och skapar sedan en PVC för dessa baljor. För CSI-drivrutinen ser denna begäran ut på samma sätt som de andra, så här behövs ingen speciell support.

Så länge sådana PVC finns kan de användas som alla andra önskemål på volymen. I synnerhet kan de refereras till som en datakälla när du kopierar en volym eller skapar en ögonblicksbild från en volym. PVC-objektet innehåller också volymens aktuella tillstånd.

Namnen på automatiskt skapade PVC-skivor är fördefinierade: de är en kombination av podnamnet och volymnamnet, åtskilda av ett bindestreck. Fördefinierade namn gör det lättare att interagera med PVC eftersom du inte behöver leta efter det om du känner till podnamnet och volymnamnet. Nackdelen är att namnet kanske redan används, vilket upptäcks av Kubernetes och som ett resultat blockeras podden från att starta.

För att säkerställa att volymen raderas tillsammans med podden, gör kontrollern en begäran till volymen under ägaren. När podden raderas fungerar den vanliga sophämtningsmekanismen, vilket tar bort både begäran och volymen.

Förfrågningar matchas av lagringsdrivrutinen genom den normala mekanismen för lagringsklassen. Även om klasser med omedelbar och sen bindning (aka WaitForFirstConsumer) stöds, för efemära volymer är det vettigt att använda WaitForFirstConsumer, då kan schemaläggaren ta hänsyn till både nodanvändning och lagringstillgänglighet när du väljer en nod. En ny funktion visas här.

Spårning av lagringskapacitet

Vanligtvis har schemaläggaren ingen kunskap om var CSI-drivrutinen kommer att skapa volymen. Det finns inte heller något sätt för schemaläggaren att kontakta föraren direkt för att begära denna information. Därför kontrollerar schemaläggaren noder tills den hittar en på vilken volymer kan nås (sen bindning) eller överlåter valet av plats helt till föraren (omedelbar bindning).

Nytt API CSIStorageCapacity, som är i alfastadiet, tillåter att nödvändig data lagras i etcd så att den är tillgänglig för schemaläggaren. Till skillnad från stöd för tillfälliga volymer för allmänna ändamål måste du aktivera spårning av lagringskapacitet när du distribuerar drivrutinen: external-provisioner ska publicera kapacitetsinformationen som erhållits från föraren via normal GetCapacity.

Om schemaläggaren behöver välja en nod för en pod med en obunden volym som använder sen bindning, och drivrutinen aktiverade den här funktionen under distributionen genom att ställa in flaggan CSIDriver.storageCapacity, då kommer noder som inte har tillräckligt med lagringskapacitet att kasseras automatiskt. Detta fungerar för både korttidsvolymer för allmänt bruk och beständiga volymer, men inte för tillfälliga volymer för CSI eftersom deras parametrar inte kan läsas av Kubernetes.

Som vanligt skapas omedelbart länkade volymer innan poddar schemaläggs, och deras placering väljs av lagringsdrivrutinen, så vid konfigurering external-provisioner Som standard hoppas lagringsklasser med omedelbar bindning över, eftersom dessa data ändå inte kommer att användas.

Eftersom kubernetes-schemaläggaren tvingas arbeta med potentiellt inaktuell information finns det ingen garanti för att kapacitet kommer att finnas tillgänglig i alla fall när volymen skapas, men chanserna att den skapas utan omförsök ökar ändå.

NB Du kan få mer detaljerad information, samt säkert "öva på kattstället", och i händelse av en helt obegriplig situation, få kvalificerad teknisk supporthjälp på intensivkurser - Kubernetes bas kommer att hållas den 28-30 september, och för mer avancerade specialister Kubernetes Mega 14–16 oktober.

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

CSIStorageCapacity

CSIStorageCapacity-objekt finns i namnutrymmen; när man rullar ut varje CSI-drivrutin i sitt eget namnområde, rekommenderas att begränsa RBAC-rättigheter till CSIStorageCapacity i det utrymmet eftersom det är uppenbart var data kommer ifrån. Kubernetes kontrollerar inte detta i alla fall, och vanligtvis placeras drivrutiner i samma namnutrymme, så i slutändan förväntas drivrutinerna fungera och inte publicera felaktiga data (och det var här mitt kort misslyckades, cirka. översättare baserad på ett skäggigt skämt)

Kortvariga volymer för allmänna ändamål

Om användare har rättigheter att skapa en pod (direkt eller indirekt), kommer de också att kunna skapa tillfälliga volymer för allmänna ändamål även om de inte har rättigheter att skapa en begäran på volymen. Detta beror på att RBAC-behörighetskontroller tillämpas på styrenheten som skapar PVC, inte på användaren. Detta är huvudändringen att lägga till till ditt konto, innan du aktiverar den här funktionen på kluster där opålitliga användare inte ska ha rättigheter att skapa volymer.

Exempel

Separat gren PMEM-CSI innehåller alla nödvändiga ändringar för att köra ett Kubernetes 1.19-kluster i virtuella QEMU-maskiner med alla funktioner i alfastadiet. Förarkoden har inte ändrats, bara distributionen har ändrats.

På en lämplig maskin (Linux kan en normal användare använda Hamnarbetare, se här detaljer) kommer dessa kommandon att ta fram klustret och installera PMEM-CSI-drivrutinen:

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 allt har fungerat kommer utgången att innehålla instruktioner för användning:

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-objekt är inte avsedda att läsas av människor, så viss bearbetning krävs. Golang-mallfilter visar lagringsklasserna, det här exemplet visar namn, topologi och 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

Ett enskilt objekt har följande innehåll:

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

Låt oss försöka skapa en demoapplikation med en kortvarig volym för allmänt bruk. Filens innehåll 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 att ha skapat, som visas i instruktionerna ovan, har vi nu en extra pod och 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-ägare - 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
...

Förväntas uppdaterad information för 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

Om en annan applikation behöver mer än 26620Mi, tar inte schemaläggaren hänsyn pmem-csi-pmem-govm-worker1 hur som helst.

Vad händer nu?

Båda funktionerna är fortfarande under utveckling. Flera applikationer öppnades under alfatestning. Förbättringsförslagslänkarna dokumenterar det arbete som behöver göras för att gå över till betastadiet, samt vilka alternativ som redan har övervägts och förkastats:

Källa: will.com

Lägg en kommentar