Niektoré aplikácie potrebujú aj ukladať dáta, no celkom im vyhovuje, že po reštarte sa dáta neuložia.
Napríklad služby ukladania do vyrovnávacej pamäte sú obmedzené pamäťou RAM, ale môžu tiež presúvať údaje, ktoré sa zriedka používajú, do úložiska, ktoré je pomalšie ako pamäť RAM, s malým dopadom na celkový výkon. Iné aplikácie si musia byť vedomé toho, že v súboroch môže byť nejaký vstup len na čítanie, ako sú nastavenia alebo tajné kľúče.
Kubernetes má už niekoľko typov , ale ich funkčnosť je obmedzená na to, čo je implementované v K8.
Pominuteľné umožnilo rozšírenie Kubernetes o ovládače CSI, aby poskytovali podporu pre ľahké lokálne zväzky. Týmto spôsobom je možné použiť : nastavenia, tajomstvá, identifikačné údaje, premenné atď. Ovládače CSI musia byť upravené tak, aby podporovali túto funkciu Kubernetes, pretože sa predpokladá, že bežné štandardizované ovládače nebudú fungovať – predpokladá sa však, že takéto zväzky možno použiť na akomkoľvek uzle zvolenom pre modul.
To môže byť problém pre zväzky, ktoré spotrebúvajú značné zdroje hostiteľa alebo pre úložisko, ktoré je dostupné len na niektorých hostiteľoch. Preto Kubernetes 1.19 predstavuje dve nové funkcie testovania alfa verzie, ktoré sú koncepčne podobné objemom EmptyDir:
-
nestále objemy na všeobecné použitie;
-
Sledovanie úložnej kapacity CSI.
Výhody nového prístupu:
-
úložisko môže byť lokálne alebo pripojené cez sieť;
-
zväzky môžu mať špecifikovanú veľkosť, ktorú aplikácia nemôže prekročiť;
-
pracuje s akýmikoľvek ovládačmi CSI, ktoré podporujú poskytovanie trvalých zväzkov a (na podporu sledovania kapacity) implementujú volanie
GetCapacity; -
zväzky môžu mať nejaké počiatočné údaje v závislosti od ovládača a nastavení;
-
sú podporované všetky štandardné operácie so zväzkom (vytvorenie snímky, zmena veľkosti atď.);
-
zväzky možno použiť s akýmkoľvek aplikačným ovládačom, ktorý akceptuje špecifikáciu modulu alebo zväzku;
-
Plánovač Kubernetes vyberá vhodné uzly sám, takže už nie je potrebné poskytovať a konfigurovať rozšírenia plánovača ani upravovať webhooky.
aplikácie
Preto sú efemérne objemy na všeobecné použitie vhodné pre nasledujúce prípady použitia:
Perzistentná pamäť ako náhrada RAM za memcached
Najnovšie vydania memcached pomocou perzistentnej pamäte (Intel Optane atď., približne. prekladateľ) namiesto bežnej pamäte RAM. Pri nasadzovaní memcached cez aplikačný radič môžete použiť univerzálne efemérne zväzky a požiadať o pridelenie zväzku danej veľkosti z PMEM pomocou ovládača CSI, napr. .
Lokálne úložisko LVM ako pracovný priestor
Aplikácie, ktoré pracujú s údajmi väčšími ako RAM, môžu vyžadovať lokálne úložisko s metrikami veľkosti alebo výkonu, ktoré bežné zväzky EmptyDir od Kubernetes nedokážu poskytnúť. Napríklad na tento účel bol napísaný .
Prístup len na čítanie pre objemy údajov
Pridelenie zväzku môže viesť k vytvoreniu celého zväzku, keď:
-
zotavenie ;
-
vytváranie ;
-
práca .
Tieto zväzky je možné pripojiť v režime iba na čítanie.
Ako to funguje
Univerzálne efemérne zväzky
Kľúčovou vlastnosťou dočasných zväzkov na všeobecné účely je nový zdroj zväzkov, EphemeralVolumeSource, ktorý obsahuje všetky polia na vytvorenie požiadavky na zväzok (historicky nazývanej trvalá požiadavka na zväzok, PVC). Nový ovládač v kube-controller-manager pozrie sa na struky, ktoré vytvárajú takýto zdroj objemu, a potom pre tieto struky vytvorí PVC. Pre ovládač CSI vyzerá táto požiadavka rovnako ako ostatné, takže tu nie je potrebná žiadna špeciálna podpora.
Pokiaľ takéto PVC existujú, možno ich použiť ako akékoľvek iné požiadavky na objem. Najmä je možné na ne odkazovať ako na zdroj údajov pri kopírovaní zväzku alebo vytváraní snímky zo zväzku. Objekt PVC obsahuje aj aktuálny stav objemu.
Názvy automaticky vytvorených PVC sú preddefinované: sú kombináciou názvu pod a názvu zväzku oddelené pomlčkou. Preddefinované názvy uľahčujú interakciu s PVC, pretože ak poznáte názov modulu a názov zväzku, nemusíte ho hľadať. Nevýhodou je, že názov sa už možno používa, čo deteguje Kubernetes a v dôsledku toho je spustenie pod zablokované.
Aby sa zabezpečilo, že sa zväzok vymaže spolu s modulom, ovládač odošle požiadavku na zväzok pod vlastníkom. Po odstránení modulu funguje štandardný mechanizmus zhromažďovania odpadu, ktorý vymaže požiadavku aj zväzok.
Požiadavky sú spárované ovládačom úložného priestoru prostredníctvom bežného mechanizmu triedy úložného priestoru. Hoci triedy s okamžitou a neskorou väzbou (aka WaitForFirstConsumer) sú podporované, pre efemérne objemy má zmysel používať WaitForFirstConsumer, potom môže plánovač pri výbere uzla zvážiť využitie uzla aj dostupnosť úložiska. Objaví sa tu nová funkcia.
Sledovanie kapacity úložiska
Plánovač zvyčajne nevie, kde ovládač CSI vytvorí zväzok. Plánovač tiež nemá možnosť kontaktovať priamo vodiča a vyžiadať si tieto informácie. Preto plánovač zisťuje uzly, kým nenájde ten, na ktorom je možné pristupovať k zväzkom (neskorá väzba), alebo výber umiestnenia ponechá úplne na ovládači (okamžitá väzba).
Nový CSIStorageCapacity, ktorý je v štádiu alfa, umožňuje uložiť potrebné dáta do etcd tak, aby boli dostupné pre plánovač. Na rozdiel od podpory pre nestále zväzky na všeobecné účely musíte pri nasadzovaní ovládača povoliť sledovanie úložnej kapacity: external-provisioner by mali zverejniť informácie o kapacite prijaté od vodiča cez normálne GetCapacity.
Ak plánovač potrebuje vybrať uzol pre modul s neviazaným zväzkom, ktorý používa neskoré viazanie, a ovládač povolil túto funkciu počas nasadenia nastavením príznaku CSIDriver.storageCapacity, potom budú uzly, ktoré nemajú dostatočnú úložnú kapacitu, automaticky vyradené. Funguje to pre dočasné aj trvalé zväzky na všeobecné účely, ale nie pre pominuteľné zväzky CSI, pretože ich parametre nedokáže Kubernetes prečítať.
Ako obvykle, bezprostredne prepojené zväzky sa vytvoria pred naplánovaním modulov a ich umiestnenie vyberá ovládač úložiska, takže pri konfigurácii external-provisioner Triedy úložiska s okamžitou väzbou sa štandardne vynechávajú, pretože tieto údaje sa aj tak nepoužijú.
Keďže plánovač kubernetes je nútený pracovať s potenciálne neaktuálnymi informáciami, nie je zaručené, že kapacita bude k dispozícii v každom prípade, keď sa zväzok vytvorí, ale napriek tomu sa zvyšuje šanca, že bude vytvorený bez opakovania.
NB Môžete získať podrobnejšie informácie, ako aj bezpečne „cvičiť na mačacej lavici“ a v prípade úplne nepochopiteľnej situácie získať kvalifikovanú technickú podporu na intenzívnych kurzoch - sa bude konať 28. – 30. septembra a pre pokročilejších odborníkov 14. – 16. októbra.
zabezpečenia
CSIS kapacita úložiska
Objekty CSIStorageCapacity sa nachádzajú v menných priestoroch; pri zavádzaní každého ovládača CSI do vlastného menného priestoru sa odporúča obmedziť práva RBAC na CSIStorageCapacity v tomto priestore, pretože je zrejmé, odkiaľ údaje pochádzajú. Kubernetes to aj tak nekontroluje a ovládače sa zvyčajne umiestňujú do rovnakého menného priestoru, takže v konečnom dôsledku sa od ovládačov očakáva, že budú fungovať a nebudú zverejňovať nesprávne údaje (a tu zlyhala moja karta, približne. prekladateľ na základe bradatého vtipu)
Univerzálne efemérne zväzky
Ak majú používatelia práva na vytvorenie pod (priamo alebo nepriamo), budú tiež môcť vytvárať dočasné zväzky na všeobecné účely, aj keď nemajú práva na vytvorenie požiadavky na zväzku. Je to preto, že kontroly povolení RBAC sa aplikujú na ovládač, ktorý vytvára PVC, nie na používateľa. Toto je hlavná zmena, ktorú treba pridať pred povolením tejto funkcie v klastroch, kde by nedôveryhodní používatelia nemali mať práva na vytváranie zväzkov.
Príklad
Samostatné PMEM-CSI obsahuje všetky potrebné zmeny na spustenie klastra Kubernetes 1.19 vo virtuálnych strojoch QEMU so všetkými funkciami vo fáze alfa. Kód ovládača sa nezmenil, zmenilo sa len nasadenie.
Na vhodnom počítači (Linux, bežný používateľ môže použiť pozri podrobnosti) tieto príkazy vyvolajú 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
Keď všetko funguje, výstup bude obsahovať návod na použitie:
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 -
Objekty CSIStorageCapacity nie sú určené na čítanie ľuďmi, takže je potrebné určité spracovanie. Filtre šablón Golang zobrazia triedy úložiska, tento príklad zobrazí názov, topológiu a kapacitu:
$ 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
Jeden objekt má nasledujúci obsah:
$ 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>
Pokúsme sa vytvoriť demo aplikáciu s jediným univerzálnym efemérnym 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, máme teraz ď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 <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
Vlastník 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é aktualizované informácie 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á aplikácia potrebuje viac ako 26620Mi, plánovač nebude brať do úvahy pmem-csi-pmem-govm-worker1 v každom prípade.
Čo bude ďalej?
Obe funkcie sú stále vo vývoji. Počas alfa testovania bolo otvorených niekoľko aplikácií. Odkazy na návrh zlepšenia dokumentujú prácu, ktorú je potrebné vykonať na prechod do fázy beta, ako aj to, ktoré alternatívy už boli zvážené a zamietnuté:
Zdroj: hab.com