🥇Efemérne objemy so sledovaním kapacity úložiska: EmptyDir na steroídoch

Niektoré aplikácie potrebujú uchovávať dáta, ale sú dostatočne tolerantné voči tomu, že údaje nebudú uložené po reštarte.

Napríklad služby pre cache sú obmedzené pamäťou, ale môžu tiež presúvať dáta, ktoré sa používa zriedkavo, do úložiska, ktoré funguje pomalšie ako RAM, s minimálnym vplyvom na celkový výkon. Iným aplikáciám potrebujú vedieť, že v súboroch môžu byť niektoré vstupy iba na čítanie, ako napríklad konfigurácie alebo tajné kľúče.

V Kubernetes už existuje niekoľko typov efemérnych zväzkov, ale ich funkčnosť je obmedzená na to, čo je implementované v K8s.

Efemérne zväzky CSI umožnili rozšíriť Kubernetes pomocou ovládačov CSI na zabezpečenie podpory ľahkých lokálnych zväzkov. Týmto spôsobom je možné aplikovať ľubovoľné štruktúry: konfigurácie, tajomstvá, identifikačné údaje, premenné a podobne. Ovládače CSI musia byť upravené na podporu tejto funkcie Kubernetes, pretože sa predpokladá, že bežné štandardizované ovládače nebudú fungovať — predpokladá sa, že takéto zväzky môžu byť použité na akomkoľvek uzle vybranom pre pod.

To môže byť problém pre zväzky s významnou spotrebou zdrojov uzla alebo pre úložiská dostupné iba na niektorých uzloch. Preto v Kubernetes 1.19 boli predstavené dve nové funkcie zväzkov na alfa testovanie, ktoré sú konceptuálne podobné zväzkom EmptyDir:

efemérne zväzky všeobecného účelu;
sledovanie kapacity úložiska CSI.

Výhody nového prístupu:

úložisko môže byť lokálne alebo pripojiteľné cez sieť;
zväzky môžu mať stanovenú veľkosť, ktorú nemôže aplikácia prekročiť;
funguje so všetkými ovládačmi CSI podporujúcimi poskytovanie trvalých zväzkov a (na podporu sledovania kapacity) realizujúcimi volanie GetCapacity;
zväzky môžu mať niektoré počiatočné údaje v závislosti od ovládača a parametrov;
všetky štandardné operácie so zväzkom (vytváranie snímok stavu, zmena veľkosti a pod.) sú podporované;
zväzky sa dajú použiť s akýmkoľvek aplikovaným ovládačom, ktorý akceptuje špecifikáciu modulu alebo zväzku;
Kubernetes plánovač sám vyberá vhodné uzly, takže už nie je potrebné zabezpečovať a nastavovať rozšírenia plánovača ani meniť webhooks.

Možnosti použitia

Takže efemérne objemy všeobecného použitia sú vhodné pre nasledujúce možnosti použitia:

Trvalá pamäť ako náhrada za operačnú pamäť pre memcached

Posledné vydania memcached pridali podporu používania trvalej pamäte (Intel Optane a pod., pozn. prekladateľa) namiesto obyčajnej operačnej pamäte. Pri nasadení memcached cez kontrolér aplikácií je možné pomocou efemérnych objemov všeobecného použitia vykonať požiadavku na pridelenie objemu určitej veľkosti z PMEM pomocou CSI ovládača, napríklad PMEM-CSI.

Lokálne úložisko LVM ako pracovný priestor

Aplikácie, ktoré pracujú s dátami, ktorých veľkosť presahuje veľkosť operačnej pamäte, môžu požadovať lokálne úložisko s veľkosťou alebo metrikami výkonu, ktoré nemôžu zabezpečiť bežné objemy EmptyDir od Kubernetes. Napríklad na tento účel bol napísaný TopoLVM.

Prístup iba na čítanie pre objemy s dátami

Pridelenie objemu môže viesť k vytvoreniu naplneného objemu pri:

obnovení snímku objemu;
vytvorení kópie objemu;
práci naplniteľoch dát.

Tieto objemy môžu byť pripojené v režime iba na čítanie.

Ako to funguje

Efemérne objemy všeobecného použitia

Kľúčovou charakteristikou efemérnych objemov všeobecného použitia je nový zdroj objemu, EphemeralVolumeSource, obsahujúci všetky polia na vytvorenie požiadavky na objem (historicky sa to nazýva požiadavka na trvalý objem, PVC). Nový kontrolér v kube-controller-manager prezerá pod, ktoré vytvárajú takýto zdroj objemu, a potom vytvorí PVC pre tieto pody. Pre CSI ovládač vyzerá táto požiadavka rovnako ako ostatné, takže tu nie je potrebná osobitná podpora.

Kým takéto PVC existujú — môžu sa používať ako akékoľvek iné požiadavky na objem. Predovšetkým môžu byť referenciou ako zdroj dát pri kopírovaní objemu alebo vytváraní snímku z objemu. Objekt PVC tiež obsahuje aktuálny stav objemu.

Mená automaticky vytváraných PVC sú preddefinované: je to kombinácia mena podu a mena zväzku, oddelených pomlčkou. Preddefinovanie mien uľahčuje interakciu s PVC, pretože ho netreba hľadať, ak poznáte meno podu a meno zväzku. Nevýhodou je, že meno môže už byť použité, čo Kubernetes zistí a výsledkom je zablokovanie spustenia podu.

Aby sa zabezpečilo, že zväzok sa odstráni spolu s podom, kontrolér robí pod vlastníkom žiadosti o zväzok. Keď sa pod odstráni, spúšťa sa štandardný mechanizmus upratovania, ktorý odstraňuje ako žiadosť, tak aj zväzok.

Žiadostiam sa priradí ovládač úložiska prostredníctvom bežného mechanizmu triedy úložiska. Hoci triedy s okamžitým a oneskoreným viazaním (tiež WaitForFirstConsumer) sú podporované, pre efemérne zväzky má zmysel používať WaitForFirstConsumer, potom plánovač môže zohľadniť ako využitie uzla, tak aj dostupnosť úložiska pri výbere uzla. Tu sa objavuje nová funkcia.

Sledovanie kapacity úložiska

Obvykle plánovač nemá údaje o tom, kde ovládač CSI vytvorí zväzok. Takisto nemá plánovač možnosť pripojiť sa k ovládaču priamo, aby požiadal o tieto informácie. Preto plánovač dotazuje uzly, pokiaľ nenájde ten, na ktorom môžu byť zväzky dostupné (oneskorené viazanie), alebo úplne nechá výber miesta na ovládači (okamžité viazanie).

Nový API CSIStorageCapacity, ktorý je v alfa verzii, umožňuje uchovávanie potrebných dát v etcd, aby boli dostupné plánovaču. Na rozdiel od podpory efemérnych zväzkov všeobecného určenia, pri nasadení ovládača je potrebné zapnúť sledovanie kapacity úložiska: external-provisioner musí publikovať informácie o kapacite, ktoré sú získané od ovládača prostredníctvom bežného GetCapacity.

Ak plánovaču treba vybrať uzol pre pod s nepriradeným zväzkom, používajúcim oneskorené viazanie, a ovládač pri nasadení aktivoval túto funkciu nastavením príznaku CSIDriver.storageCapacity, potom budú automaticky zamietnuté uzly, ktoré nemajú dostatočnú kapacitu úložiska. To funguje pre efemérne všeobecného určenia aj pre trvalé zväzky, ale nie pre efemérne zväzky CSI, pretože ich parametre nemôžu byť načítané Kubernetes.

Ako zvyčajne sa objemy s okamžitým priradením vytvárajú pred plánovaním podov a ich umiestnenie vyberá ovládač úložiska, takže pri konfigurácii external-provisioner sa predvolene preskakujú triedy úložiska s okamžitým priradením, pretože tieto údaje sa aj tak nebudú používať.

Keďže plánovač kubernetes je nútený pracovať s potenciálne zastaranými informáciami, nie je zaručené, že kapacita bude k dispozícii v akomkoľvek prípade, keď sa objem vytvorí, no napriek tomu sa zvyšuje pravdepodobnosť, že sa vytvorí bez opakovaných pokusov.

N.B. Podrobnejšie informácie môžete získať a bezpečne sa "trénovať na mačkách" na simuláciách, a v prípade úplne nejasnej situácie získať kvalifikovanú pomoc technickej podpory na intenzívnych školeniach — Základy Kubernetes bude sa konať 28.-30. septembra, a pre pokročilejších odborníkov Mega Kubernetes 14.-16. októbra.

Bezpečnosť

CSIStorageCapacity

Objekty CSIStorageCapacity sa nachádzajú v menných priestoroch, pri nasadzovaní každého ovládača CSI sa odporúča obmedziť práva RBAC pre CSIStorageCapacity v tomto mennom priestore, pretože je jasné, odkiaľ pochádzajú údaje. V každom prípade Kubernetes to nekontroluje a zvyčajne sú ovládače nasadené v jednom mennom priestore, takže sa očakáva, že ovládače budú fungovať a nebudú zverejňovať nesprávne údaje (a tu som mal šťastie, pozn. prekladateľa podľa motívu starej anekdoty)

Efemérne objemy všeobecného použitia

Ak majú používatelia práva na vytvorenie podu (priamo alebo nepriamo) — môžu tiež vytvoriť efemérne objemy pre všeobecné používanie, aj keď nemajú práva na vytvorenie požiadavky na objem. A to všetko preto, že kontrola práv RBAC sa uplatňuje na kontrolér, ktorý vytvára PVC, a nie na používateľa. Toto je hlavná zmena, ktorú je potrebné pridať k účtu, pred povolením tejto funkcie v klastroch, ak majú nespolehliví používatelia mať práva na vytvorenie objemov.

Príklad

Samostatná vetva v PMEM-CSI obsahuje všetky potrebné zmeny na spustenie klastru Kubernetes 1.19 vo vnútri virtuálnych strojov QEMU so všetkými funkcionalitami, ktoré sú na alpha fáze. Kód ovládača sa nezmenil, zmenila sa iba implementácia.

Na vhodnom stroji (Linux, bežný používateľ môže použiť Docker, pozrite sa na tu podrobnosti) tieto príkazy spustia klaster a nainštalujú ovládač PMEM-CSI:

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

Akonáhle všetko funguje, výstup bude obsahovať pokyny na použitie:

Testovací klaster je pripravený. Prihláste sa pomocou [...] /pmem-csi/_work/pmem-govm/ssh.0, spustite
kubectl po prihlásení. Alternatívne použite kubectl priamo s nasledujúcou env premennou:
   KUBECONFIG=[...] /pmem-csi/_work/pmem-govm/kube.config

secret/pmem-csi-registry-secrets bol vytvorený
secret/pmem-csi-node-secrets bol vytvorený
serviceaccount/pmem-csi-controller bol vytvorený
...
Ak chcete vyskúšať ovládač pmem-csi pre efemérne zväzky:
   cat deploy/kubernetes-1.19/pmem-app-ephemeral.yaml |
   [...] /pmem-csi/_work/pmem-govm/ssh.0 kubectl create -f -

Objekty CSIStorageCapacity nie sú určené na čítanie ľuďmi, takže je potrebná určité spracovanie. Pomocou šablónových filtrov v Golangu sa zobrazia triedy úložiska, v tomto príklade budú zobrazené meno, topológia a kapacita:

$ 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

Samostatný objekt má tento obsah:

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

Poďme skúsiť vytvoriť demonstračnú aplikáciu s jedným efemérnym všeobecným zväzkom. Obsah súboru 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

Po vytvorení, ako je uvedené v pokynoch vyššie, sa nám objavil ďalší pod a 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

Majiteľ PVC – 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
...

Očakávané informácie boli aktualizované pre 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

Ak inému aplikácii bude potrebné viac ako 26620Mi, plánovač to nezohľadní pmem-csi-pmem-govm-worker1 v každom prípade.

Čo ďalej?

Obe funkcie sú stále vo vývoji. Bolo otvorených niekoľko pripomienok počas alpha testovania. Pracuje sa na dokumentovaní návrhov na vylepšenia, ktoré je potrebné urobiť, aby sa prešlo do beta fázy, ako aj na alternatívach, ktoré boli už zvažované a zamietnuté:

Zdroj: habr.com