🥇Ephemere volumes met opslagcapaciteit tracking: EmptyDir op steroïden

Sommige applicaties moeten ook gegevens opslaan, maar ze zijn redelijk relaxed over het feit dat deze gegevens niet worden bewaard na een herstart.

Bijvoorbeeld, cache-services zijn beperkt in RAM, maar kunnen ook gegevens verplaatsen die zelden worden gebruikt naar opslag die langzamer werkt dan RAM, met een minimale impact op de algehele prestaties. Andere applicaties moeten weten dat er mogelijk enkele alleen-lezen invoergegevens in de bestanden zitten, zoals instellingen of geheime sleutels.

In Kubernetes zijn er al verschillende types ephemerale volumes, maar hun functionaliteit is beperkt tot wat is geïmplementeerd in K8s.

Ephemerale CSI-volumes hebben het mogelijk gemaakt om Kubernetes uit te breiden met CSI-drivers voor ondersteuning van lichtgewicht lokale volumes. Op deze manier kunnen willekeurige structuren: instellingen, geheimen, identificatiegegevens, variabelen, enzovoorts. CSI-drivers moeten worden aangepast om deze functie van Kubernetes te ondersteunen, aangezien wordt verondersteld dat standaard drivers niet zullen werken — maar het is bedoeld dat dergelijke volumes op elke gekozen node voor de pod kunnen worden gebruikt.

Dit kan problematisch zijn voor volumes die veel middelen van de node verbruiken of voor opslag die alleen op bepaalde nodes beschikbaar is. Daarom zijn in Kubernetes 1.19 twee nieuwe volume-functies geïntroduceerd voor alfa-testen, conceptueel vergelijkbaar met EmptyDir-volumes:

ephemerale volumes voor algemeen gebruik;
opslagcapaciteit van CSI bijhouden.

De voordelen van deze nieuwe aanpak:

opslag kan lokaal zijn of netwerkverbonden;
volumes kunnen een specifieke grootte hebben die niet door de applicatie kan worden overschreden;
werkt met elke CSI-driver die permanente volumes aanbiedt en (voor ondersteuning van capaciteitsmonitoring) de aanroep GetCapacity;
volumes kunnen enkele initiële gegevens bevatten, afhankelijk van de driver en parameters;
alle standaardvolumewerking (snapshot-creatie, resizing, enz.) wordt ondersteund;
volumes kunnen worden gebruikt met elke applicatiecontroller die een module- of volumespecificatie accepteert;
De Kubernetes-planner selecteert zelf de geschikte knooppunten, zodat je niet langer de planner-extensies hoeft te configureren of webhooks hoeft te wijzigen.

Toepassingsmogelijkheden

Dus zijn efemere volumes van algemeen gebruik geschikt voor de volgende toepassingen:

Vaste opslag als vervanging van het RAM-geheugen voor memcached

Laatste versies van memcached hebben ondersteuning toegevoegd voor het gebruik van vaste opslag (Intel Optane en dergelijke, opmerking van de vertaler) in plaats van gewoon RAM. Bij het implementeren van memcached via de applicatiecontroller kan met behulp van efemere volumes van algemeen gebruik een verzoek worden gedaan voor het toewijzen van een volume van een bepaalde grootte uit PMEM met behulp van de CSI-driver, bijvoorbeeld PMEM-CSI.

Lokale opslag LVM als werkruimte

Applicaties die werken met gegevens waarvan de grootte groter is dan het RAM-geheugen, kunnen lokale opslag aanvragen met een grootte of prestaties die reguliere EmptyDir-volumes van Kubernetes niet kunnen bieden. Bijvoorbeeld, hiervoor is TopoLVM.

Alleen-lezen toegang voor datavolumes

Het toewijzen van een volume kan leiden tot het creëren van een gevuld volume bij:

Deze volumes kunnen in alleen-lezen modus worden gemonteerd.

Hoe het werkt

Efemere volumes van algemeen gebruik

Een sleuteleigenschap van efemere volumes van algemeen gebruik is de nieuwe volume-bron, EphemeralVolumeSource, die alle velden bevat voor het indienen van een verzoek om een volume (historisch wordt dit een verzoek om een vast volume, PVC, genoemd). Een nieuwe controller in kube-controller-manager doorzoekt pods die een dergelijke volumebron maken en maakt vervolgens PVC voor deze pods. Voor de CSI-driver ziet dit verzoek er hetzelfde uit als de andere, zodat er hier geen speciale ondersteuning nodig is.

Zolang dergelijke PVC's bestaan, kunnen ze worden gebruikt zoals alle andere volumeverzoeken. In het bijzonder kunnen ze als een gegevensbron worden gebruikt bij het kopiëren van een volume of bij het maken van een snapshot van een volume. Het PVC-object bevat ook de huidige status van het volume.

De namen van automatisch aangemaakte PVC's zijn vooraf gedefinieerd: dit is een combinatie van de podnaam en de volumenaam, gescheiden door een koppelteken. De vooraf gedefinieerde namen maken interactie met PVC's eenvoudiger, omdat je deze niet hoeft te zoeken als je de podnaam en volumenaam kent. Het nadeel is dat de naam al in gebruik kan zijn, wat door Kubernetes wordt ontdekt en daardoor het starten van de pod wordt geblokkeerd.

Om ervoor te zorgen dat het volume samen met de pod wordt verwijderd, maakt de controller de pod de eigenaar van de aanvraag voor het volume. Wanneer de pod wordt verwijderd, wordt het standaard garbage collection mechanisme geactiveerd, dat zowel de aanvraag als het volume verwijdert.

Aanvragen worden gekoppeld aan de opslagdriver via het gebruikelijke opslagclass mechanisme. Hoewel klassen met onmiddellijke en late binding (ook bekend als WaitForFirstConsumer) worden ondersteund, is het logisch om voor tijdelijke volumes WaitForFirstConsumer, te gebruiken, zodat de planner zowel het gebruik van de knoop als de beschikbaarheid van de opslag kan overwegen bij het kiezen van een knoop. Hier komt ook een nieuwe functie naar voren.

Opslagcapaciteit tracking

Meestal heeft de planner geen gegevens over waar de CSI-driver het volume zal aanmaken. De planner heeft ook geen mogelijkheid om rechtstreeks contact op te nemen met de driver om deze informatie op te vragen. Daarom ondervraagt de planner knopen totdat hij er een vindt waar de volumes beschikbaar kunnen zijn (late binding), of laat hij de keuze van locatie volledig over aan de driver (om onmiddellijke binding).

Nieuwe API CSIStorageCapacity, momenteel in alpha-fase, maakt het mogelijk om de benodigde gegevens op te slaan in etcd, zodat deze beschikbaar zijn voor de planner. In tegenstelling tot de ondersteuning voor tijdelijke algemeen beschikbare volumes, moet bij de implementatie van de driver opslagcapaciteit tracking worden ingeschakeld: external-provisioner moet informatie over de capaciteit publiceren, verkregen van de driver via de gebruikelijke GetCapacity.

Als de planner een knoop moet kiezen voor een pod met een niet-gebonden volume dat gebruikmaakt van late binding, en de driver deze functie heeft geactiveerd bij de implementatie door de vlag CSIDriver.storageCapacity, worden knopen met onvoldoende opslagcapaciteit automatisch uitgesloten. Dit werkt voor zowel tijdelijke algemeen beschikbare als permanente volumes, maar niet voor tijdelijke CSI-volumes, omdat hun parameters niet door Kubernetes kunnen worden gelezen.

Zoals gewoonlijk worden volumes met onmiddellijke binding gemaakt voordat de pods worden ingepland, en de plaatsing wordt gekozen door de opslagdriver, dus bij de configuratie external-provisioner worden standaard opslagklassen met onmiddellijke binding overgeslagen, omdat deze gegevens toch niet zullen worden gebruikt.

Aangezien de Kubernetes-scheduler gedwongen is om te werken met potentieel verouderde informatie, is er geen garantie dat capaciteit beschikbaar zal zijn op het moment dat het volume wordt aangemaakt. Desondanks neemt de kans dat het zonder herhaalde pogingen wordt aangemaakt toe.

N.B. U kunt meer gedetailleerde informatie verkrijgen en veilig oefenen in een testomgeving, en in het geval van een onduidelijke situatie gekwalificeerde technische ondersteuning krijgen tijdens de intensives — Kubernetes Basis die plaatsvindt van 28-30 september, en voor meer gevorderde specialisten Kubernetes Mega van 14–16 oktober.

Beveiliging

CSIStorageCapacity

De CSIStorageCapacity-objecten bevinden zich in namespaces, en bij het uitrollen van elke CSI-driver is het aanbevolen om de RBAC-rechten voor CSIStorageCapacity in deze namespace te beperken, omdat het duidelijk is waar de gegevens vandaan komen. In ieder geval controleert Kubernetes dit niet, en meestal worden drivers in dezelfde namespace geplaatst, dus uiteindelijk wordt verwacht dat de drivers goed functioneren en geen onjuiste gegevens publiceren (en hier kwam mijn kaart goed van pas, opmerking van de vertaler geïnspireerd door een oude mop)

Efemere volumes van algemeen gebruik

Als gebruikers rechten hebben om een pod aan te maken (direct of indirect) — kunnen ze ook tijdelijke volumes van algemene doeleinden aanmaken, zelfs als ze geen rechten hebben om een volume-aanroep aan te maken. Dit komt omdat de RBAC-rechten worden toegepast op de controller die de PVC aanmaakt, en niet op de gebruiker. Dit is de belangrijkste wijziging die moet worden toegevoegd aan het account, voordat deze functie in clusters wordt ingeschakeld, als onbetrouwbare gebruikers geen rechten mogen hebben om volumes aan te maken.

Voorbeeld

Een aparte tak in PMEM-CSI bevat alle benodigde wijzigingen om een Kubernetes-cluster 1.19 in QEMU-virtuele machines te draaien met alle functies in de alpha-fase. De driver-code is niet gewijzigd, alleen de implementatie is aangepast.

Op een geschikte machine (Linux, een reguliere gebruiker kan gebruiken Docker, zie here details) zullen deze commando's het cluster opzetten en de PMEM-CSI-driver installeren:

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

Nadat alles is uitgevoerd, bevat de output instructies voor gebruik:

De testcluster is gereed. Log in met [...]\/pmem-csi\/_work\/pmem-govm\/ssh.0, voer uit
kubectl zodra ingelogd. Gebruik anders direct kubectl met de
volgende omgevingsvariabele:
   KUBECONFIG=[...]\/pmem-csi\/_work\/pmem-govm\/kube.config

secret\/pmem-csi-registry-secrets is aangemaakt
secret\/pmem-csi-node-secrets is aangemaakt
serviceaccount\/pmem-csi-controller is aangemaakt
...
Om de pmem-csi driver ephemeral volumes uit te proberen:
   cat deploy\/kubernetes-1.19\/pmem-app-ephemeral.yaml |
   [...]\/pmem-csi\/_work\/pmem-govm\/ssh.0 kubectl create -f -

De objecten CSIStorageCapacity zijn niet bedoeld voor menselijke leesbaarheid, dus er is enige verwerking nodig. Met behulp van sjabloonfilters in Golang worden de opslagklassen weergegeven, in dit voorbeeld worden naam, topologie en capaciteit weergegeven:

$ 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

Een afzonderlijk object heeft de volgende inhoud:

$ kubectl describe csistoragecapacities\/csisc-6cw8j
Naam:         csisc-sqdnt
Namespace:    default
Labels:       
Annotaties:  
API Versie:  storage.k8s.io\/v1alpha1
Capaciteit:     30716Mi
Soort:         CSIStorageCapacity
Metadata:
  Aanmaak Tijdstip:  2020-08-11T15:41:03Z
  Genereer Naam:       csisc-
  Beheerde Velden:
    ...
  Eigenaar Referenties:
    API Versie:     apps\/v1
    Controller:      waar
    Soort:            StatefulSet
    Naam:            pmem-csi-controller
    UID:             590237f9-1eb4-4208-b37b-5f7eab4597d1
  Hulpbron Versie:  2994
  Zelf Link:         \/apis\/storage.k8s.io\/v1alpha1\/namespaces\/default\/csistoragecapacities\/csisc-sqdnt
  UID:               da36215b-3b9d-404a-a4c7-3f1c3502ab13
Node Topologie:
  Match Labels:
    pmem-csi.intel.com/node:  pmem-csi-pmem-govm-worker1
Opslagklasse Naam:           pmem-csi-sc-late-binding
Gebeurtenissen:

Laten we proberen een demonstratie-applicatie te maken met één ephemeral volume voor algemeen gebruik. De inhoud van het bestand 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

Na het aanmaken, zoals hierboven aangegeven, hebben we een extra pod en PVC gekregen:

$ kubectl get pods\/my-csi-app-inline-volume -o wide
NAAM                       KLAAR   STATUS    HERSTARTS   LEVENSDUUR   IP          NODE                         GENOMINEERDE NODE   KLAARHEIDSGATES
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
NAAM                                     STATUS   VOLUME                                     CAPACITEIT   TOEGANGSMODES   OPSLAGKLASSE               LEVENSDUUR
my-csi-app-inline-volume-my-csi-volume   Bound    pvc-c11eb7ab-a4fa-46fe-b515-b366be908823   4Gi        RWO            pmem-csi-sc-late-binding   9m21s

De eigenaar van de PVC is de 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
...

De informatie is zoals verwacht bijgewerkt voor 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

Als een andere applicatie meer dan 26620Mi nodig heeft, zal de planner dit niet overwegen pmem-csi-pmem-govm-worker1 onder alle omstandigheden.

Wat nu?

Beide functies zijn nog in ontwikkeling. Er zijn verschillende verzoeken geopend tijdens de alpha-tests. De links met voorstellen voor verbeteringen documenteren het werk dat nodig is om naar de beta-fase over te gaan, evenals welke alternatieven al zijn overwogen en afgewezen:

Bron: habr.com