🥇Efemer kötetek tárolási kapacitás követéssel: EmptyDir a szteroidokon

Egyes alkalmazásoknak adattárolásra is szükségük van, de eléggé megnyugszanak abban, hogy újraindítás után az adatok nem mentődnek el.

Például a gyorsítótárazási szolgáltatásokat korlátozza a RAM, de a ritkán használt adatokat is áthelyezhetik a RAM-nál lassabb tárolásra, ami csekély hatással van az általános teljesítményre. Más alkalmazásoknak tisztában kell lenniük azzal, hogy a fájlok csak olvasható bevitelt tartalmazhatnak, például beállításokat vagy titkos kulcsokat.

A Kubernetesnek már több típusa van efemer kötetek, de funkcionalitásuk a K8s-ban megvalósítottra korlátozódik.

Tiszavirág életű CSI kötetek lehetővé tette a Kubernetes CSI-illesztőprogramokkal való bővítését, hogy támogatást nyújtson a könnyű helyi kötetekhez. Ily módon lehetséges használni tetszőleges szerkezetek: beállítások, titkok, azonosító adatok, változók stb. A CSI-illesztőprogramokat módosítani kell, hogy támogassák ezt a Kubernetes-funkciót, mivel feltételezhető, hogy a szokásos szabványos illesztőprogramok nem működnek – de feltételezzük, hogy az ilyen kötetek a podhoz kiválasztott bármely csomóponton használhatók.

Ez problémát jelenthet olyan köteteknél, amelyek jelentős gazdagép-erőforrásokat fogyasztanak, vagy olyan tárhely esetében, amely csak néhány gazdagépen érhető el. Ezért a Kubernetes 1.19 két új alfatesztelési kötet-szolgáltatást vezet be, amelyek elvileg hasonlóak az EmptyDir kötetekhez:

általános célú efemer kötetek;
CSI tárolókapacitás nyomon követése.

Az új megközelítés előnyei:

a tárolás lehet helyi vagy hálózaton keresztül csatlakoztatva;
a kötetek meghatározott méretűek lehetnek, amelyeket az alkalmazás nem léphet túl;
működik minden olyan CSI-illesztőprogrammal, amely támogatja az állandó kötetek kiépítését, és (a kapacitáskövetés támogatása érdekében) megvalósítja a hívást GetCapacity;
a kötetek tartalmazhatnak néhány kezdeti adatot az illesztőprogramtól és a beállításoktól függően;
minden szabványos kötettel végzett művelet (pillanatkép készítése, átméretezés stb.) támogatott;
kötetek bármely olyan alkalmazásvezérlővel használhatók, amely elfogad egy modult vagy kötetspecifikációt;
A Kubernetes ütemező önállóan választja ki a megfelelő csomópontokat, így többé nincs szükség ütemezőbővítmények létrehozására és konfigurálására vagy webhookok módosítására.

Alkalmazási lehetőségek

Ezért az általános célú efemer kötetek a következő felhasználási esetekre alkalmasak:

Állandó memória a RAM helyettesítőjeként a gyorsítótárban

A memcached legújabb kiadásai hozzáadott támogatás állandó memória használata (Intel Optane stb., kb. fordító) normál RAM helyett. A memcached alkalmazásvezérlőn keresztül történő üzembe helyezésekor általános célú efemer kötetekkel kérheti, hogy adott méretű kötetet rendeljenek ki a PMEM-ből a CSI illesztőprogram segítségével, például PMEM-CSI.

LVM helyi tárhely munkaterületként

A RAM-nál nagyobb adatokkal dolgozó alkalmazások olyan méretű vagy teljesítménymutatókkal rendelkező helyi tárhelyet igényelhetnek, amelyet a Kubernetes szokásos EmptyDir-kötetei nem tudnak biztosítani. Például erre a célra azt írták TopoLVM.

Csak olvasási hozzáférés az adatmennyiségekhez

Egy kötet kiosztása teljes kötet létrehozását eredményezheti, ha:

Ezek a kötetek csak olvasható módban csatlakoztathatók.

Ez hogy működik

Általános célú, efemer kötetek

Az általános célú efemer kötetek kulcsfontosságú jellemzője az új kötetforrás, EphemeralVolumeSource, amely tartalmazza a kötetkérelem létrehozásához szükséges összes mezőt (korábbi nevén tartós kötetkérés, PVC). Új vezérlő bekerült kube-controller-manager megvizsgálja azokat a hüvelyeket, amelyek ilyen hangerőforrást hoznak létre, majd létrehoz egy PVC-t ezekhez a hüvelyekhez. A CSI meghajtó esetében ez a kérés ugyanúgy néz ki, mint a többi, ezért itt nincs szükség speciális támogatásra.

Amíg léteznek ilyen PVC-k, ugyanúgy használhatók, mint bármely más kérés a köteten. Különösen adatforrásként hivatkozhatnak rájuk egy kötet másolásakor vagy pillanatfelvétel készítésekor a kötetről. A PVC objektum a kötet aktuális állapotát is tartalmazza.

Az automatikusan létrehozott PVC-k nevei előre meghatározottak: a podnév és a kötetnév kombinációja, kötőjellel elválasztva. Az előre meghatározott nevek megkönnyítik a PVC-vel való interakciót, mert nem kell keresnie, ha ismeri a pod nevét és a kötet nevét. Hátránya, hogy a név már használatban lehet, amit a Kubernetes észlel, és ennek eredményeként a pod nem indul el.

Annak biztosítására, hogy a kötet a podlal együtt törlésre kerüljön, a vezérlő kérést küld a tulajdonos alá tartozó kötethez. A pod törlésekor a szabványos szemétgyűjtő mechanizmus működik, amely törli a kérést és a kötetet is.

A kéréseket a tároló-illesztőprogram egyezteti a tárolási osztály normál mechanizmusán keresztül. Bár az osztályok azonnali és késői kötéssel (aka WaitForFirstConsumer) támogatottak, efemer köteteknél érdemes használni WaitForFirstConsumer, akkor az ütemező a csomóponthasználatot és a tárhely elérhetőségét is figyelembe veheti a csomópont kiválasztásakor. Itt egy új funkció jelenik meg.

Tárolási kapacitás követése

Az ütemező általában nem tudja, hogy a CSI-illesztőprogram hol hozza létre a kötetet. Arra sincs mód, hogy az ütemező közvetlenül felvegye a kapcsolatot a sofőrrel, hogy ezt az információt kérje. Ezért az ütemező addig lekérdezi a csomópontokat, amíg meg nem találja azt, amelyen a kötetek elérhetők (késői kötés), vagy a hely megválasztását teljesen az illesztőprogramra bízza (azonnali kötés).

Új API CSIStorageCapacity, amely alfa szakaszban van, lehetővé teszi a szükséges adatok etcd-ben történő tárolását, hogy azok elérhetőek legyenek az ütemező számára. Az általános célú efemer kötetek támogatásával ellentétben az illesztőprogram telepítésekor engedélyeznie kell a tárolókapacitás nyomon követését: external-provisioner közzé kell tennie az illesztőprogramtól normál módon kapott kapacitásinformációkat GetCapacity.

Ha az ütemezőnek ki kell választania egy csomópontot egy kötetlen kötettel rendelkező podhoz, amely késői összerendelést használ, és az illesztőprogram engedélyezte ezt a funkciót a telepítés során a jelző beállításával CSIDriver.storageCapacity, akkor a nem elegendő tárolókapacitással rendelkező csomópontok automatikusan el lesznek dobva. Ez mind az általános célú efemer, mind az állandó köteteknél működik, de nem a CSI efemer köteteknél, mivel ezek paramétereit a Kubernetes nem tudja beolvasni.

Szokás szerint az azonnal összekapcsolt kötetek a pod-ok ütemezése előtt jönnek létre, és elhelyezésüket a tároló-illesztőprogram választja ki, így a konfiguráláskor external-provisioner Alapértelmezés szerint az azonnali kötéssel rendelkező tárolási osztályok kimaradnak, mivel ezek az adatok egyébként sem kerülnek felhasználásra.

Mivel a kubernetes ütemező kénytelen potenciálisan elavult információkkal dolgozni, nincs garancia arra, hogy a kötet létrehozásakor minden esetben rendelkezésre áll a kapacitás, de ennek ellenére megnő annak esélye, hogy újrapróbálkozás nélkül létrejön.

NB Részletesebb információkat kaphat, valamint biztonságosan „gyakorolhat a macskaállványon”, és teljesen érthetetlen helyzet esetén szakképzett technikai támogatást kaphat intenzív tanfolyamokon - Kubernetes bázis szeptember 28-30-án kerül megrendezésre, és a haladóbb szakemberek számára Kubernetes Mega október 14-16.

biztonság

CSIStorageCapacity

A CSIStorageCapacity objektumok névterekben találhatók; amikor minden CSI-illesztőprogramot a saját névterében teszünk közzé, ajánlatos korlátozni az RBAC-jogokat a CSIStorageCapacityre ezen a területen, mivel nyilvánvaló, honnan származnak az adatok. A Kubernetes egyébként nem ellenőrzi ezt, és az illesztőprogramok általában ugyanabba a névtérbe kerülnek, így végső soron az illesztőprogramoktól elvárható, hogy működjenek, és ne tegyenek közzé hibás adatokat (és itt hibásodott meg a kártyám, kb. szakállas vicc alapján fordító)

Általános célú, efemer kötetek

Ha a felhasználók jogosultak egy pod létrehozására (közvetlenül vagy közvetve), akkor is képesek lesznek általános célú, efemer köteteket létrehozni, még akkor is, ha nincs jogosultságuk kérés létrehozására a köteten. Ennek az az oka, hogy az RBAC engedélyek ellenőrzése a PVC-t létrehozó vezérlőre vonatkozik, nem a felhasználóra. Ez a fő módosítás fiókjába, mielőtt engedélyezné ezt a funkciót azokon a fürtökön, ahol a nem megbízható felhasználóknak nem kellene kötetek létrehozására joga.

Példa

Különálló ág A PMEM-CSI tartalmazza az összes szükséges változtatást a Kubernetes 1.19-es fürt QEMU virtuális gépeken belüli futtatásához, az alfa szakasz összes funkciójával. Az illesztőprogram kódja nem változott, csak a telepítés változott.

Egy megfelelő gépen (Linux, normál felhasználó használhatja Dokkmunkás, néz itt részletek) ezek a parancsok előhívják a fürtöt, és telepítik a PMEM-CSI illesztőprogramot:

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 &amp;&amp; echo &amp;&amp; test/setup-deployment.sh

Miután minden működik, a kimenet használati utasításokat tartalmaz:

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 -

A CSIStorageCapacity objektumokat nem arra szánták, hogy emberek olvassák, ezért némi feldolgozásra van szükség. A Golang sablonszűrők megmutatják a tárolási osztályokat, ez a példa a nevet, a topológiát és a kapacitást:

$ 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 objektum a következő tartalommal rendelkezik:

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

Próbáljunk meg létrehozni egy demóalkalmazást egyetlen általános célú, efemer kötettel. 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

Létrehozása után, amint az a fenti utasításokban látható, most van egy további tok és 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

PVC tulajdonos - alatt:

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

Várhatóan frissített információk a következőhöz: 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 26620Mi-nél többre van szüksége, az ütemező nem veszi figyelembe pmem-csi-pmem-govm-worker1 mindenesetre.

Mi a következő lépés?

Mindkét funkció még fejlesztés alatt áll. Az alfateszt során több alkalmazás is megnyílt. A fejlesztési javaslat hivatkozásai dokumentálják a béta szakaszba lépéshez szükséges munkát, valamint azt, hogy mely alternatívákat vették már figyelembe és utasították el:

Forrás: will.com

Efemer kötetek tárolási kapacitás követéssel: EmptyDir a szteroidokon

Alkalmazási lehetőségek

Állandó memória a RAM helyettesítőjeként a gyorsítótárban

LVM helyi tárhely munkaterületként

Csak olvasási hozzáférés az adatmennyiségekhez

Ez hogy működik

Általános célú, efemer kötetek

Tárolási kapacitás követése

biztonság

CSIStorageCapacity

Általános célú, efemer kötetek

Példa

Mi a következő lépés?

Hozzászólás Megszünteti a választ