Některé aplikace také potřebují ukládat data, ale jsou dost klidné ohledně toho, že data nebudou uchována po restartu.
Například služby pro mezipaměť jsou omezeny pamětí RAM, ale také mohou přesouvat data, která se zřídka používají, do úložiště, které funguje pomaleji než paměť RAM, s malým vlivem na celkový výkon. Jiným aplikacím je třeba vědět, že v souborech mohou být některé vstupy pouze pro čtení, například konfigurace nebo tajné klíče.
V Kubernetes již existuje několik typů , ale jejich funkčnost je omezena tím, co je implementováno v K8s.
Efemérní umožnily rozšířit Kubernetes pomocí ovladačů CSI pro zajištění podpory lehkých lokálních objemů. Tímto způsobem je možné aplikovat : konfigurace, tajemství, identifikační data, proměnné a podobně. Ovladače CSI musí být upraveny pro podporu této funkce Kubernetes, protože se předpokládá, že běžné standardizované ovladače nebudou fungovat — ale je předpokládáno, že tyto objemy mohou být používány na libovolném uzlu vybraném pro pod.
To může představovat problém pro objemy s významnou spotřebou zdrojů uzlu nebo pro úložiště dostupné pouze na některých uzlech. Proto v Kubernetes 1.19 byly představeny dvě nové funkce objemů pro alfa testování, které jsou koncepčně podobné objemům EmptyDir:
efemérní objemy pro všeobecné použití;
sledování kapacity úložiště CSI.
Výhody nového přístupu:
úložiště může být lokální nebo připojitelné přes síť;
objemy mohou mít stanovenou velikost, kterou aplikace nemůže překročit;
funguje s jakýmikoli ovladači CSI, které podporují poskytování trvalých objemů a (pro podporu sledování kapacity) implementují volání
GetCapacity;objemy mohou mít některá počáteční data, závislá na ovladači a parametrech;
všechny standardní operace s objemem (vytváření snímků stavu, změna velikosti atd.) jsou podporovány;
objemy lze použít s jakýmkoli ovladačem aplikací, který přijímá specifikaci modulu nebo objemu;
Kubernetes scheduler si sám vybírá vhodné uzly, takže už není potřeba zajišťovat a konfigurovat rozšíření scheduleru a měnit webhooks.
Možnosti použití
Tímto způsobem jsou efemérní objemy obecného použití vhodné pro následující možnosti použití:
Trvalá paměť jako náhrada za operační paměť pro memcached
Poslední verze memcached použití trvalé paměti (Intel Optane apod., pozn. překladatele) namísto běžné operační paměti. Při nasazení memcached prostřednictvím aplikačního ovladače lze s pomocí efemérních objemů obecného použití požádat o přidělení objemu dané velikosti z PMEM pomocí CSI ovladače, například .
Místní úložiště LVM jako pracovní prostor
Aplikace pracující s daty, jejichž velikost přesahuje velikost operační paměti, mohou požadovat místní úložiště s velikostí nebo metrikami výkonu, které běžné objemy EmptyDir od Kubernetes nemohou zaručit. Například k tomuto účelu byl napsán .
Přístup pouze pro čtení k objemům s daty
Přidělení objemu může vést ke vzniku zaplněného objemu při:
obnovení ;
vytvoření ;
práci .
Tyto objemy mohou být připojeny v režimu pouze pro čtení.
Jak to funguje
Efemérní objemy obecného použití
Klíčovou vlastností efemérních objemů obecného použití je nový zdroj objemu, EphemeralVolumeSource, obsahující všechna pole pro vytvoření žádosti o objem (historicky se tomu říká žádost o trvalý objem, PVC). Nový kontrolér v kube-controller-manager prohlíží pody, které vytvářejí takový zdroj objemu, a poté vytváří PVC pro tyto pody. Pro CSI ovladač vypadá tato žádost jako ostatní, takže zde není potřeba žádnou zvláštní podporu.
Pokud takové PVC existují, mohou být používána jako jakékoli jiné žádosti o objem. Zejména mohou být použita jako odkaz na zdroj dat při kopírování objemu nebo vytváření snímku z objemu. Objekt PVC také obsahuje aktuální stav objemu.
Jména automaticky vytvářených PVC jsou předdefinována: jedná se o kombinaci názvu podu a názvu svazku oddělenou pomlčkou. Předdefinovanost názvů usnadňuje práci s PVC, neboť není třeba je hledat, když znáte název podu a název svazku. Nevýhodou je, že název již může být použit, což Kubernetes zjistí a v důsledku toho je spuštění podu zablokováno.
Aby bylo zajištěno, že svazek bude odstraněn spolu s podom, kontroler dělá pod vlastníkem žádosti o svazek. Když je pod odstraněn, spustí se běžný mechanismus úklidu, který odstraní jak žádost, tak svazek.
Žádostem je přiřazen ovladač úložiště prostřednictvím běžného mechanismu třídy úložiště. Ačkoli se podporují třídy s okamžitým a pozdějším propojením (tyto), WaitForFirstConsumer) pro efemérní svazky dává smysl použít WaitForFirstConsumer, poté může plánovač zohlednit jak využití uzlu, tak dostupnost úložiště při výběru uzlu. Zde se objevuje nová funkce.
Sledování kapacity úložiště
Obvykle plánovač nemá data o tom, kde ovladač CSI vytvoří svazek. Také plánovač nemá možnost kontaktovat ovladač přímo za účelem požádání o tyto informace. Proto plánovač dotazuje uzly, dokud nenajde ten, na kterém mohou být svazky dostupné (pozdější propojení), nebo plně nechá výběr místa na ovladači (okamžité propojení).
Nový CSIStorageCapacity, který je ve stádiu alpha, umožňuje ukládání potřebných dat do etcd, takže jsou dostupná pro plánovač. Na rozdíl od podpory efemérních svazků obecného určení je při nasazení ovladače nutné zapnout sledování kapacity úložiště: external-provisioner musí zveřejnit informace o kapacitě, získané od ovladače prostřednictvím běžného GetCapacity.
Pokud musí plánovač vybrat uzel pro pod s nepřipojeným svazkem používajícím pozdější propojení a ovladač tuto funkci aktivoval při nasazení nastavením příznaku CSIDriver.storageCapacity, budou automaticky vyloučeny uzly, které nemají dostatečnou kapacitu úložiště. To funguje jak pro efemérní obecného určení, tak pro trvalé svazky, ale ne pro efemérní svazky CSI, protože jejich parametry není možné přečíst pomocí Kubernetes.
Jak obvykle, svazky s okamžitým propojením jsou vytvářeny před plánováním podů a jejich umístění je vybíráno ovladačem úložiště, takže při nastavení external-provisioner implicitně se vynechávají třídy úložiště s okamžitým propojením, protože tato data stejně nebudou používána.
Jelikož plánovač Kubernetes musí pracovat s potenciálně zastaralými informacemi, není zaručeno, že kapacita bude k dispozici, kdykoli bude svazek vytvářen, ale přesto existují vyšší šance, že bude vytvořen bez opětovných pokusů.
N.B. Podrobnější informace získáte, a také bezpečně "vyzkoušet na cat standu", a v případě zcela nejasné situace dostanete kvalifikovanou pomoc technické podpory na intenzivech — proběhne 28.-30. září, a pro pokročilejší specialisty 14–16. října.
Bezpečnost
CSIStorageCapacity
Objekty CSIStorageCapacity se nacházejí v názvových prostorech, při nasazování každého ovladače CSI je doporučeno omezit práva RBAC pro CSIStorageCapacity v tomto prostoru, protože je zřejmé, odkud data pocházejí. V každém případě Kubernetes toto nekontroluje, a obvykle jsou ovladače umístěny v jednom názvovém prostoru, takže se očekává, že ovladače budou fungovat a nebudou publikovat nesprávná data (a tady jsem měl štěstí, pozn. překladatele podle motivů starého vtipu)
Efemérní objemy obecného použití
Pokud mají uživatelé práva k vytvoření podu (přímo nebo nepřímo) — také budou moci vytvořit efemérní svazky obecného použití, i když nemají práva vytvářet žádost o svazek. A to proto, že kontroly práv RBAC se aplikují na kontrolér, který vytváří PVC, a ne na uživatele. To je základní změna, kterou je třeba přidat , před aktivací této funkce v clusterech, pokud nespolehliví uživatelé nemají mít práva na vytváření svazků.
Příklad
Samostatná v PMEM-CSI obsahuje všechny potřebné změny pro spuštění clustere Kubernetes 1.19 uvnitř virtuálních strojů QEMU se všemi funkcemi, které se nachází ve fázi alpha. Kód ovladače se neměnil, pouze nasazení.
Na vhodném stroji (Linux, běžný uživatel může použít , viz podrobnosti) tyto příkazy zvednou cluster a nainstalují ovladač 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
Jakmile všechno proběhne, výstup bude obsahovat pokyny k použití:
Testovací cluster je připraven. Přihlaste se pomocí [...] /pmem-csi/_work/pmem-govm/ssh.0, spusťte
kubectl, jakmile se přihlásíte. Alternativně použijte kubectl přímo s následující proměnnou prostředí:
KUBECONFIG=[...] /pmem-csi/_work/pmem-govm/kube.config
secret/pmem-csi-registry-secrets byl vytvořen
secret/pmem-csi-node-secrets byl vytvořen
serviceaccount/pmem-csi-controller byl vytvořen
...
Chcete-li vyzkoušet dočasné svazky ovladače pmem-csi:
cat deploy/kubernetes-1.19/pmem-app-ephemeral.yaml |
[...] /pmem-csi/_work/pmem-govm/ssh.0 kubectl create -f -
Objekty CSIStorageCapacity nejsou určeny ke čtení lidmi, takže je potřeba nějaké zpracování. Pomocí filtrů šablony v Golangu budou zobrazeny třídy úložišť. V tomto příkladu budou zobrazeny název, topologie 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
Jeden objekt obsahuje následující 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:
Pojďme zkusit vytvořit demonstrační aplikaci s jedním dočasným svazkem pro obecné použití. Obsah souboru 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 vytvoření, jak bylo uvedeno v pokynech výše, máme další 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
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čekávané informace se aktualizovaly pro 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
Pokud jiná aplikace bude potřebovat více než 26620Mi, plánovač to nebude brát v úvahu pmem-csi-pmem-govm-worker1 v žádném případě.
Co dál?
Obě funkce jsou stále ve vývoji. Během alpha testování bylo otevřeno několik žádostí. Odkazy na návrhy na zlepšení dokumentují práci, kterou je třeba udělat, aby se přešlo do fáze beta, a jaké alternativy byly již zváženy a zamítnuty:
Zdroj: habr.com
