🥇Efemerala volymer med spårning av lagringskapacitet: EmptyDir på steroider

Vissa appar behöver också lagra data, men de är ganska avslappnade med att informationen inte sparas efter en omstart.

Till exempel är cachetjä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 applikationer måste vara medvetna om att filer kan innehålla viss skrivskyddad inmatning, till exempel inställningar eller hemliga nycklar.

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

Kortlivad CSI-volymer tillät att Kubernetes kunde utökas med hjälp av 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, identiteter, variabler etc. CSI-drivrutiner måste modifieras för att stödja den här Kubernetes-funktionen, eftersom de vanliga standardiserade drivrutinerna inte förväntas fungera - men sådana volymer förväntas kunna användas på alla noder som valts för poden.

Detta kan vara ett problem för volymer med betydande resursförbrukning för noder eller för lagring som bara är tillgänglig på vissa noder. Det är därför Kubernetes 1.19 introducerar två nya alfavolymfunktioner som konceptuellt liknar EmptyDir-volymer:

allmänna efemära volymer;
Övervakning av CSI-lagringskapacitet.

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

lagringen 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 provisionering av beständiga volymer och (för att stödja kapacitetsspårning) implementerar anropet GetCapacity;
Volymer kan ha vissa initialdata beroende på drivrutin och parametrar;
alla typiska volymoperationer (skapa en ögonblicksbild, ändra storlek etc.) stöds;
Volymer kan användas med vilken applikationskontrollant som helst som accepterar en modul- eller volymspecifikation;
Kubernetes-schemaläggaren väljer automatiskt lämpliga noder, så det finns inget behov av att etablera och konfigurera schemaläggartillägg eller ändra webhooks.

Applikationsalternativ

Således är generella, efemära volymer lämpliga för följande användningsfall:

Persistent minne som RAM-ersättning för Memcached

Senaste memcachade utgåvor extra stöd med permanent minne (Intel Optane, etc., cirka. översättare) istället för vanligt RAM. När du distribuerar memcached via applikationskontrollanten kan du använda generella efemära volymer för att begära en volym av en given storlek från PMEM med hjälp av CSI-drivrutinen, t.ex. PMEM-CSI.

Lokal LVM-lagring som en arbetsyta

Program som arbetar med data som är större än RAM-minnet kan kräva lokal lagring med en storlek eller prestandamått som vanliga Kubernetes EmptyDir-volymer inte kan tillhandahålla. Till exempel, en TopolVM.

Skrivskyddad åtkomst för datavolymer

Volymtilldelning kan resultera i en full volym när:

restaurering volymögonblicksbild;
skapelse kopior av volymen;
arbete datafyllare.

Dessa volymer kan monteras i skrivskyddat läge.

Hur fungerar den här

Allmänna, efemära volymer

En viktig egenskap hos generella, efemära volymer är den nya volymkällan, EphemeralVolumeSource, som innehåller alla fält för att skapa en volymförfrågan (historiskt kallad en permanent volymförfrågan, PVC). Den nya kontrollanten i kube-controller-manager letar efter poddar som skapar en sådan volymkälla och skapar sedan en PVC för dessa poddar. För CSI-drivrutinen ser den här begäran ut som vilken annan som helst, så inget särskilt stöd behövs.

Även om sådana PVC:er existerar kan de användas som alla andra volymförfrågningar. De kan särskilt refereras som en datakälla när man kopierar en volym eller skapar en ögonblicksbild från en volym. PVC-objektet innehåller också volymens aktuella tillstånd.

Namnen på de automatiskt skapade PVC:erna är fördefinierade: en kombination av podnamnet och volymnamnet, separerade med ett bindestreck. Fördefinierade namn gör det enklare att interagera med PVC:n, eftersom du inte behöver slå upp den om du vet podnamnet och volymnamnet. Nackdelen är att namnet kanske redan används, vilket upptäcks av Kubernetes och resulterar i att poden inte startar.

För att säkerställa att volymen tas bort tillsammans med poden gör kontrollenheten en podägarens begäran för volymen. När poden tas bort utlöses standardmekanismen för sophämtning, vilket tar bort både begäran och volymen.

Förfrågningar tilldelas en lagringsdrivrutin via den vanliga lagringsklassmekanismen. Även om klasser med direkt- och sent bundna gränser (även kallade WaitForFirstConsumer) stöds, för kortlivade 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 den väljer en nod. Det är här en ny funktion kommer in i bilden.

Övervakning av lagringskapacitet

Vanligtvis har schemaläggaren ingen kunskap om var CSI-drivrutinen kommer att skapa volymen. Schemaläggaren har inte heller möjlighet att kontakta drivrutinen direkt för att begära denna information. Därför avsöker schemaläggaren noder tills den hittar en där volymerna kan nås (sen bindning), eller lämnar valet av plats helt till drivrutinen (omedelbar bindning).

Nytt API CSIStorageCapacity, som är i alfa, tillåter lagring av nödvändig data i etcd så att den är tillgänglig för schemaläggaren. Till skillnad från stöd för generella, efemära volymer måste spårning av lagringskapacitet vara aktiverad när drivrutinen distribueras: external-provisioner måste publicera kapacitetsinformationen som mottagits från föraren via den vanliga 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, noder som inte har tillräckligt med lagringskapacitet kommer automatiskt att tas bort. Detta fungerar för både generella, efemära och persistenta volymer, men inte för CSI-efemära volymer, eftersom deras parametrar inte kan läsas av Kubernetes.

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

Eftersom Kubernetes-schemaläggaren tvingas arbeta med potentiellt inaktuell information finns det ingen garanti för att kapaciteten kommer att vara tillgänglig i alla fall när volymen skapas, men chansen att den skapas utan återförsök ökar ändå.

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

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

CSIStorageCapacity

CSIStorageCapacity-objekt finns i namnrymder. När man rullar ut varje CSI-drivrutin till sin egen namnrymd rekommenderas det att begränsa RBAC-behörigheter för CSIStorageCapacity i den namnrymden, eftersom det är uppenbart varifrån informationen kommer. Kubernetes kontrollerar ändå inte detta, och drivrutiner distribueras vanligtvis i samma namnrymd, så i slutändan förväntas drivrutinerna fungera och inte publicera felaktig data (och här hade jag tur, översättarens anteckning baserad på ett skäggigt skämt)

Allmänna, efemära volymer

Om användare har behörighet att skapa en pod (direkt eller indirekt) kommer de också att kunna skapa generella, tillfälliga volymer även om de inte har behörighet att skapa en volymförfrågan. Detta beror på att RBAC-behörighetskontroller tillämpas på den kontrollant som skapar PVC:n, inte på användaren. Detta är den huvudsakliga ändringen som behöver göras. att redovisa, innan den här funktionen aktiveras i kluster om otillförlitliga användare inte ska ha behörighet att skapa volymer.

Exempel

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

På en lämplig bil (Linux, en vanlig användare kan använda Hamnarbetare, se här detaljer) dessa kommandon kommer att öppna 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 &amp;&amp; echo &amp;&amp; test/setup-deployment.sh

När allt har fungerat kommer resultatet att innehålla bruksanvisningar:

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. Med hjälp av Golang-mallfilter kommer lagringsklasserna att visas, i det här exemplet kommer namn, topologi och kapacitet att visas:

$ 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 allmänt användbar, kortlivad volym. Filinnehå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 skapandet, som visas i instruktionerna ovan, fick vi 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
...

Som förväntat har informationen för uppdaterats 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 alla fall.

Vad händer nu?

Båda funktionerna är fortfarande under utveckling. Flera ärenden har öppnats under alfatestning. Länkarna till förbättringsförslag dokumenterar det arbete som behöver göras för att komma till betaversionen, samt vilka alternativ som redan har övervägts och förkastats:

Källa: will.com