🥇Tillfälliga volymer med lagringskapacitetsspårning: EmptyDir på steroider

Vissa applikationer behöver också lagra data, men de är ganska avslappnade när det gäller att data inte sparas efter omstart.

Till exempel, cache-tjänster är begränsade av RAM-minnet, men de kan också flytta data som sällan används till lagring som fungerar långsammare än RAM, med liten effekt på den övergripande prestandan. Andra applikationer behöver veta att filer kan ha vissa skrivskyddade indata, såsom inställningar eller hemliga nycklar.

I Kubernetes finns det redan flera typer av efemära volymer, men deras funktionalitet är begränsad till vad som är implementerat i K8s.

Efemära volymer CSI har möjliggjort att utöka Kubernetes med CSI-drivrutiner för att stödja lätta lokala volymer. På detta sätt är det möjligt att använda vilka strukturer som helst: inställningar, hemligheter, identitetsdata, variabler och så vidare. CSI-drivrutiner måste anpassas för att stödja denna funktioner i Kubernetes, eftersom man förväntar sig att vanliga standardiserade drivrutiner inte kommer att fungera - men man förväntar sig att sådana volymer kan användas på vilken nod som helst som valts för podden.

Detta kan bli ett problem för volymer med betydande resursförbrukning på noden eller för lagring som endast är tillgänglig på vissa noder. Därför introducerades i Kubernetes 1.19 två nya volymfunktioner för alfa-testning, konceptuellt liknande tomma volymer:

efemära volymer av allmänt bruk;
lagringskapacitetsspårning för CSI.

Fördelarna med den nya metoden:

lagringen kan vara lokal eller ansluten via nätverk;
volymer kan ha en angiven storlek som inte får överskridas av applikationen;
fungerar med alla CSI-drivrutiner som stöder tillhandahållande av beständiga volymer och (för att stödja kapacitetsövervakning) implementerar anropet GetCapacity;
volymer kan ha vissa initiala data, beroende på drivrutinen och parametrarna;
alla typiska operationer på volymen (skapa snapshots, ändra storlek, osv.) stöds;
volymer kan användas med vilken applikationskontrollerare som helst som accepterar modul- eller volymspecifikation.
Kubernetes-schemaläggaren väljer själv lämpliga noder, så det är inte längre nödvändigt att tillhandahålla och konfigurera schemaläggarutvidgningar eller ändra webhooks.

Användningsalternativ

Därför passar efemära volymer av allmän typ för följande användningsalternativ:

Permanent minne som ersättning för RAM för memcached

De senaste versionerna av memcached har lagt till stöd för användning av permanent minne (Intel Optane m.fl., översättarens anm.) istället för vanligt RAM. Vid distribution av memcached via applikationskontroller kan man med hjälp av efemära volymer av allmän typ begära tilldelning av en volym med angiven storlek från PMEM med CSI-drivrutinen, till exempel PMEM-CSI.

Lokal LVM-lagring som arbetsyta

Applikationer som arbetar med data vars storlek överskrider storleken på RAM kan begära lokal lagring med storlek eller prestandamått som inte kan tillhandahållas av vanliga EmptyDir-volymer från Kubernetes. Till exempel har detta syfte skapat TopoLVM.

Skrivskyddad åtkomst för datavolymer

Tilldelning av en volym kan leda till skapandet av en fylld volym vid:

återställning av en volymavbildning;
skapande av en volymkopiering;
arbetet datasträngar.

Dessa volymer kan monteras i skrivskyddat läge.

Hur det fungerar

Efemära volymer av allmän type

En nyckelfunktion för efemära volymer av allmän typ är en ny volymkälla, EphemeralVolumeSource, som innehåller alla fält för att skapa en begäran om volym (historiskt kallad begäran om permanent volym, PVC). Den nya kontrolleraren i kube-controller-manager granskar poddar som skapar sådana volymkällor och skapar sedan PVC för dessa poddar. För CSI-drivrutinen verkar denna begäran likadant som övriga, så här behövs ingen särskild support.

Så länge sådana PVC finns — kan de användas precis som andra volymförfrågningar. Specifikt kan de refereras som datakälla vid kopiering av volymer eller skapande av avbildningar från en volym. PVC-objektet innehåller också det aktuella tillståndet för volymen.

Namnen på automatiskt skapade PVC:er är fördefinierade: det är en kombination av poddnamn och volymnamn, åtskilda med ett bindestreck. Denna fördefiniering av namn förenklar interaktionen med PVC, eftersom man inte behöver leta efter det om man känner till poddnamnet och volymnamnet. En nackdel är att namnet redan kan ha använts, vilket upptäckts av Kubernetes, vilket resulterar i att podden inte kan startas.

För att säkerställa att volymen tas bort tillsammans med podden, gör kontrollern podden till ägare av volymförfrågan. När podden tas bort, träder den normala skräprensningsmekanismen i kraft, som tar bort både förfrågan och volymen.

Förfrågningar matchas med lagringsdrivrutinen genom den vanliga mekanismen för lagringsklasser. Även om klasser för omedelbar och sen bindning (de) WaitForFirstConsumer) stöds, är det meningsfullt att använda WaitForFirstConsumer, vilket gör att schemaläggaren kan ta hänsyn till både nodens resursanvändning och lagringstillgång vid val av nod. Här introduceras en ny funktion.

Övervakning av lagringskapacitet

Normalt har schemaläggaren ingen information om var CSI-drivrutinen kommer att skapa volymen. Schemaläggaren har inte heller möjlighet att direkt kontakta drivrutinen för att begära denna information. Därför frågar schemaläggaren noder tills den hittar en där volymer kan vara tillgängliga (sen bindning), eller helt lämnar valet av plats till drivrutinen (omedelbar bindning).

Ny API CSIStorageCapacity, som är i alpha-stadiet, möjliggör lagring av nödvändiga data i etcd, så att de är tillgängliga för schemaläggaren. Till skillnad från stödet för generiska efemära volymer måste lagringskapacitetsövervakning aktiveras vid driftsättning av drivrutinen: external-provisioner måste publicera kapacitetsinformation som erhållits från drivrutinen genom den vanliga GetCapacity.

Om schemaläggaren behöver välja en nod för en podd med en icke-bunden volym som använder sen bindning, och drivrutinen aktiverade denna funktion vid driftsättning genom att ställa in flaggan CSIDriver.storageCapacity, så kommer noder som inte har tillräcklig lagringskapacitet automatiskt att avvisas. Detta fungerar både för generiska efemära volymer och permanenta volymer, men inte för efemära CSI-volymer, eftersom deras egenskaper inte kan läsas av Kubernetes.

Som vanligt skapas volymer med omedelbar bindning innan poddar planeras, och deras placering väljs av lagringsdrivrutinen, så vid konfiguration external-provisioner överses som standard lagringsklasser med omedelbar bindning eftersom dessa data ändå inte kommer att användas.

Eftersom Kubernetes schemaläggaren måste arbeta med potentiellt föråldrad information finns det ingen garanti för att kapaciteten kommer att vara tillgänglig när volymen skapas, men chanserna att den skapas utan omförsök ökar.

N.B. Du kan få mer detaljerad information och säkert "träna på katter i en testmiljö", samt få kvalificerad hjälp från supporten vid evenemang som är helt oklara — Kubernetes Grund det äger rum den 28-30 september, och för mer avancerade specialister Kubernetes Mega 14–16 oktober.

Säkerhet

CSIStorageCapacity

CSIVolumeCapacity-objekt finns i namnområden, och vid distribution av varje CSIdrivare rekommenderas det att begränsa RBAC-rättigheter för CSIVolumeCapacity i detta namnområde, eftersom det tydligt framgår varifrån data kommer. I alla fall kontrollerar Kubernetes detta inte, och vanligtvis installeras drivrutiner i ett enda namnområde, så i slutändan förväntas drivrutinerna fungera och inte publicera felaktiga data (och här kom min karta in, översättarens anm. baserat på en gammal historia)

Efemära volymer av allmän type

Om användare har rätt att skapa en podd (direkt eller indirekt) kan de också skapa temporära allmänna volymer även om de inte har rätt att skapa en begäran om volym. Och allt beror på att RBAC-rättighetskontroller appliceras på controllern som skapar PVC:n, inte på användaren. Detta är en grundläggande ändring som måste läggas till till kontot, innan den här funktionen aktiveras i kluster där opålitliga användare inte bör ha rätt att skapa volymer.

Exempel

Ett separat tråd i PMEM-CSI innehåller alla nödvändiga ändringar för att köra Kubernetes-klustret 1.19 inne i virtuella QEMU-maskiner med alla funktioner som är i alpha-stadium. Drivrutinskoden har inte ändrats, endast distributionen.

På lämplig maskin (Linux, en vanlig användare kan använda Docker, se ). Ett typiskt exempel på användning: detaljer) dessa kommandon kommer att starta 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 utskriften att innehålla instruktioner för användning:

Testklustret är klart. Logga in med [...] /pmem-csi/_work/pmem-govm/ssh.0, kör
kubectl när du är inloggad. Alternativt kan du använda kubectl direkt med följande miljövariabel:
   KUBECONFIG=[...] /pmem-csi/_work/pmem-govm/kube.config

secret/pmem-csi-registry-secrets skapad
secret/pmem-csi-node-secrets skapad
serviceaccount/pmem-csi-controller skapad
...
För att testa pmem-csi-drivrutinen för tillfälliga volymer:
   cat deploy/kubernetes-1.19/pmem-app-ephemeral.yaml |
   [...] /pmem-csi/_work/pmem-govm/ssh.0 kubectl create -f -

Objektet CSIStorageCapacity är inte avsett för läsning av människor, så viss bearbetning behövs. Med hjälp av mallfilter på Golang kommer lagringsklasser att visas, i det här exemplet visas 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:       
Annotations:  
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:

Låt oss försöka skapa en demonstrationsapplikation med en allmän tillfällig volym. Innehållet 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 skapandet, enligt instruktionen 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              
$ 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

Ägaren av PVC är podden:

$ 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äntad information har uppdaterats 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, kommer schemaläggaren inte att ta hänsyn till det. pmem-csi-pmem-govm-worker1 I vilket fall som helst.

Vad händer härnäst?

Båda funktionerna är fortfarande under utveckling. Flera ärenden har öppnats under alpha-testning. Dokumentation pågår kring förslag som har inkommit för förbättringar, vilket arbete som behöver göras för att gå till beta-stadiet, samt vilka alternativ som redan har övervägts och avvisats:

Källa: habr.com