Néhány alkalmazásnak is szüksége van adatok tárolására, de viszonylag nyugodtan viselik, hogy az adatok nem maradnak meg újraindítás után.
Például a gyorsítótárazási szolgáltatások korlátozottak a RAM-ra, de áthelyezhetik a ritkán használt adatokat egy lassabb tárolóra, amely kisebb hatással van az általános teljesítményre. Más alkalmazásoknak tudniuk kell, hogy a fájlokban lehetnek olyan írásvédett bemeneti adatok, mint például a beállítások vagy titkos kulcsok.
A Kubernetes már rendelkezik néhány típussal , de a funkcionalitásuk korlátozott a K8s-ben implementáltakra.
Átmeneti lehetővé tették a Kubernetes kiterjesztését CSI driverekkel, amelyek támogatják a könnyű helyi köteteket. Ezen a módon lehetséges alkalmazni : beállítások, titkok, azonosító adatok, változók és így tovább. A CSI drivereket még ki kell egészíteni a Kubernetes ezen funkciója támogatásához, mivel a hagyományos szabványosított driverek várhatóan nem fognak működni — de feltételezhető, hogy az ilyen kötetek bármelyik kiválasztott csomóponton használhatók a pod számára.
Ez problémát jelenthet a számottevő erőforrást fogyasztó kötetek esetén, vagy olyan tárolók esetén, amelyek csak bizonyos csomópontokon elérhetők. Ezért a Kubernetes 1.19-ben két új kötet funkciót vezettek be alfa tesztelésre, amelyek konceptuálisan hasonlítanak az EmptyDir kötetekhez:
általános célú átmeneti kötetek;
CSI tárhely-követés.
Az új megközelítés előnyei:
a tárolás lehet helyi vagy hálózaton keresztül csatlakoztatott;
a köteteknek megadott mérete lehet, amelyet az alkalmazás nem léphet túl;
működik bármely CSI driverrel, amely támogatja az állandó kötetek biztosítását, és (a tárhely-követés támogatása érdekében) implementálja a hívást
GetCapacity;a köteteknek lehetnek bizonyos kezdőadataik, amelyek a drivertől és a paraméterektől függenek;
minden típusú kötetműveletet (állapotképek létrehozása, méretezés stb.) támogatnak;
a kötetek bármely alkalmazásvezérlővel használhatók, amely elfogadja a modul vagy kötet specifikációt;
A Kubernetes scheduler automatically selects suitable nodes, so there's no longer a need to provide and configure scheduler extensions and modify webhooks.
Application Scenarios
Thus, ephemeral general-purpose volumes are suitable for the following application scenarios:
Persistent memory as a replacement for RAM for memcached
Latest releases of memcached for using persistent memory (Intel Optane, etc.) jegyzet: fordító) instead of regular RAM. When deploying memcached through the application controller, you can request a volume of a specified size from PMEM using ephemeral general-purpose volumes via the CSI driver, for instance, .
Local LVM storage as a workspace
Applications dealing with data sizes exceeding RAM can request local storage with dimensions or performance metrics that normal EmptyDir volumes from Kubernetes cannot provide. For this purpose, .
Read-only access for data volumes
Volume allocation can lead to the creation of a filled volume when:
restoring ;
creating ;
munkában .
These volumes can be mounted in read-only mode.
Hogyan működik ez
Ephemeral General-Purpose Volumes
A key feature of ephemeral general-purpose volumes is the new volume source, EphemeralVolumeSource, which contains all the fields for creating a volume request (historically called a persistent volume request, PVC). A new controller in kube-controller-manager watches for pods that create such a volume source and then creates a PVC for those pods. For the CSI driver, this request looks the same as others, so no special support is needed here.
As long as such PVCs exist — they can be used just like any other volume requests. In particular, they can serve as a data source reference when copying a volume or creating a snapshot from a volume. The PVC object also contains the current state of the volume.
Automatikusan létrehozott PVC-k nevei előre meghatározottak: a pod és a kötet neve közötti kötőjelmelléket használva van kombinálva. A nevek előre meghatározott volta megkönnyíti a PVC-kkel való interakciót, mivel nem szükséges keresni, ha tudjuk a pod és a kötet nevét. A hátránya, hogy a név már használatban lehet, amit a Kubernetes észlel, amely miatt a pod indítása blokkolva van.
Annak érdekében, hogy biztosak legyünk abban, hogy a kötet el lesz távolítva a pod-dal együtt, a vezérlő a pod-t a kötet kérésének tulajdonosává teszi. Amikor a pod törlésre kerül, a szokásos selejtezési mechanizmus aktiválódik, amely eltávolítja a kérést és a kötetet.
A kérések a tárolókezelőhöz vannak társítva a tárolóosztály szokásos mechanizmusán keresztül. Noha a közvetlen és későbbi kapcsolatok (ezek is WaitForFirstConsumer) támogatottak, érdemes efemer kötetek számára használni WaitForFirstConsumer, így a ütemező figyelembe tudja venni a csomópont használatát és a tároló elérhetőségét a csomópont kiválasztásakor. Ezen a ponton új funkció lép életbe.
A tároló kapacitás nyomon követése
Általában az ütemező nem rendelkezik olyan adatokkal, hogy a CSI tárolókezelő hol hozza létre a kötetet. Az ütemezőnek nincs lehetősége közvetlenül kapcsolatba lépni a kezelővel az információ kérésére. Ezért az ütemező folyamatosan lekérdezi a csomópontokat, amíg nem talál olyat, ahol a kötetek elérhetőek (későbbi kapcsolat), vagy teljesen a kezelőre bízza a hely kiválasztását (immediate binding).
Új CSIStorageCapacity, amely alpha fázisban van, lehetővé teszi a szükséges adatok tárolását az etcd-ben, így azok elérhetőek az ütemező számára. Az efemer, általános célú kötetek támogatásánál figyelembe kell venni a tárolókapacitás nyomon követését a kezelő telepítésekor: external-provisioner meg kell osztania a kezelőtől kapott kapacitásinformációt a szokásos GetCapacity.
Ha az ütemezőnek ki kell választania egy csomópontot a nem hozzárendelt kötetet használó pod számára, amely későbbi kapcsolást használ, és a kezelő a telepítéskor aktiválta ezt a funkciót a CSIDriver.storageCapacityjelző beállításával, akkor automatikusan elvetjük azokat a csomópontokat, ahol nincs elegendő tárolókapacitás. Ez működik az efemer általános célú és állandó kötetekre is, de nem az efemer CSI kötetekre, mivel azok beállításai nem olvashatóak a Kubernetes által.
A megszokott módon a közvetlen összekapcsolású kötetek a podok ütemezése előtt készülnek el, és a tárolóvezérlő választja ki a helyüket, ezért a beállítás során external-provisioner alapértelmezés szerint kihagyják a közvetlen összekapcsolású tárolási osztályokat, mivel ezeket az adatokat egyébként sem használják.
Mivel a Kubernetes ütemező kénytelen elavult információkkal dolgozni, nincs garancia arra, hogy a kapacitás bármikor elérhető lesz, amikor a kötetet létrehozzák, de a próbálkozások nélküli létrehozás esélyei mindenképpen nőnek.
Figyelem. További információkat kaphat, és biztonságosan 'próbálgathatja' a rendszert, valamint, ha igazán zavaró helyzet állna elő, szakszerű támogatást kaphat az intenzív kurzusok során — szeptember 28-30. között, a haladóbb szakemberek számára október 14-16.
Biztonság
CSIStorageCapacity
A CSIStorageCapacity objektumok névtérben találhatók, minden CSI vezérlő telepítésekor ajánlott az RBAC jogosultságokat korlátozni ebben a névtérben, mivel nyilvánvaló, honnan származnak az adatok. Mindenesetre a Kubernetes ezt nem ellenőrzi, és a vezérlőket jellemzően egy névtérben telepítik, így végső soron elvárható, hogy a vezérlők működjenek és ne publikáljanak hamis adatokat (itt pedig átjött a kártyám, fordító megjegyzése, egy régi vicc nyomán)
Ephemeral General-Purpose Volumes
Ha a felhasználóknak jogosultságuk van pod létrehozására (közvetlenül vagy közvetve) — akkor képesek lesznek létrehozni efemer általános célú köteteket is, még akkor is, ha nincs jogosultságuk kötet igénylésére. Mindez azért van, mert a RBAC jogosultság-ellenőrzések arra a vezérlőre vonatkoznak, amelyik létrehozza a PVC-t, nem pedig a felhasználóra. Ez a fő változtatás, amit hozzá kell adni , mielőtt ezt a funkciót aktiválják a klaszterekben, ha megbízhatatlan felhasználóknak nem szabad köteteket létrehozniuk.
támadásra
Egy különálló a PMEM-CSI-ban tartalmazza az összes szükséges módosítást a Kubernetes 1.19 klaszter virtuális gépeken történő futtatásához, amelyek minden alpha fázisban lévő funkciót tartalmaznak. A vezérlő kódja nem változott, csak a telepítés.
Egy megfelelő gépen (Linux, a normál felhasználó használhatja , lásd a részleteket) ezek a parancsok elindítják a klasztert és telepítik a PMEM-CSI vezérlőt:
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
Miután minden működni kezd, a kimenet tartalmazni fogja a használati utasításokat:
A tesztklaszter készen áll. Jelentkezzen be a [...] /pmem-csi/_work/pmem-govm/ssh.0, futtassa
kubectl bejelentkezés után. Alternatív megoldásként közvetlenül a kubectl-t használja a következő környezeti változóval:
KUBECONFIG=[...] /pmem-csi/_work/pmem-govm/kube.config
secret/pmem-csi-registry-secrets létrehozva
secret/pmem-csi-node-secrets létrehozva
serviceaccount/pmem-csi-controller létrehozva
...
Próbálja ki a pmem-csi illesztőprogram ideiglenes köteteket:
cat deploy/kubernetes-1.19/pmem-app-ephemeral.yaml |
[...] /pmem-csi/_work/pmem-govm/ssh.0 kubectl create -f -
A CSIStorageCapacity objektumok nem emberi olvasásra létrejöttek, ezért valamilyen feldolgozásra van szükség. A Golang sablonfiltrái segítségével megmutatják a tároló osztályokat, ebben a példában a név, a topológia és a kapacitás lesz látható:
$ 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
Egy külön objektumnak ilyen tartalma van:
$ kubectl describe csistoragecapacities/csisc-6cw8j
Név: csisc-sqdnt
Namespace: default
Címkék:
Annotációk:
API verzió: storage.k8s.io/v1alpha1
Kapacitás: 30716Mi
Típus: CSIStorageCapacity
Metaadatok:
Létrehozás időbélyeg: 2020-08-11T15:41:03Z
Generálási név: csisc-
Kezelt mezők:
...
Tulajdonosi hivatkozások:
API verzió: apps/v1
Vezérlő: true
Típus: StatefulSet
Név: pmem-csi-controller
UID: 590237f9-1eb4-4208-b37b-5f7eab4597d1
Erőforrás verzió: 2994
Önlink: /apis/storage.k8s.io/v1alpha1/namespaces/default/csistoragecapacities/csisc-sqdnt
UID: da36215b-3b9d-404a-a4c7-3f1c3502ab13
Node Topológia:
Megfelelő címkék:
pmem-csi.intel.com/node: pmem-csi-pmem-govm-worker1
Tároló osztály neve: pmem-csi-sc-late-binding
Események:
Próbáljunk létrehozni egy bemutató alkalmazást egy általános célú ideiglenes kötet használatával. A fájl tartalma 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
A fenti utasítások szerint, miután létrehoztuk, egy további pod és PVC-nk jelent meg:
$ kubectl get pods/my-csi-app-inline-volume -o wide
NÉV KÉSZ ÁLLAPOT ÚJRAINDÍTÁSOK ÉLETKOR IP NODE NÉPSZERŰSÍTETT NODE KÉSZÜLTSÉGI KAPUK
my-csi-app-inline-volume 1/1 Futtatás 0 6m58s 10.36.0.2 pmem-csi-pmem-govm-worker1
$ kubectl get pvc/my-csi-app-inline-volume-my-csi-volume
NÉV ÁLLAPOT KÖTET KAPACITÁS HOZZÁFÉRÉSI MÓDOK TÁROLÓOSZTÁLY ÉLETKOR
my-csi-app-inline-volume-my-csi-volume Hozzárendelve pvc-c11eb7ab-a4fa-46fe-b515-b366be908823 4Gi RWO pmem-csi-sc-late-binding 9m21s
A PVC tulajdonosa a 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
...
A várt információ frissült 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
Ha egy másik alkalmazásnak több mint 26620Mi szükséges, a scheduler nem veszi figyelembe pmem-csi-pmem-govm-worker1 minden körülmények között.
Mi következik?
Mindkét funkció még fejlesztés alatt áll. Számos bejelentés történt az alpha tesztelés során. A javaslatokkal kapcsolatos linkeken dokumentáljuk a szükséges munkálatokat, hogy átlépjünk a beta szakaszba, valamint hogy milyen alternatívák kerültek már megvizsgálásra és elutasításra:
Forrás: habr.com
