ProHoster > Blog > Bestjoer > Opslachkapasiteit folge efemere voluminten: EmptyDir op steroïden

Opslachkapasiteit folge efemere voluminten: EmptyDir op steroïden

Opslachkapasiteit folge efemere voluminten: EmptyDir op steroïden

Guon applikaasjes moatte ek gegevens opslaan, mar se binne frij noflik mei it feit dat de gegevens net wurde bewarre nei in trochstart.

Bygelyks, caching tsjinsten wurde beheind yn RAM, mar kin ek ferpleatse gegevens dy't komselden brûkt wurdt om opslach dat is stadiger as RAM, mei in bytsje ynfloed op de totale prestaasjes. Oare applikaasjes moatte bewust wêze dat de bestannen wat allinich-lês-ynput kinne befetsje, lykas ynstellings of geheime kaaien.

Kubernetes hat al ferskate soarten efemere bondels, mar harren funksjonaliteit is beheind ta wat wurdt útfierd yn K8s.

Efemere It hannelvolumint fan 'CSI koe Kubernetes útwreide wurde mei CSI-bestjoerders om stipe te leverjen foar lichtgewicht lokale folumes. Op dizze manier is it mooglik om oan te freegjen willekeurige struktueren: ynstellings, geheimen, identifikaasjegegevens, fariabelen, ensfh. CSI-bestjoerders moatte wurde oanpast om dizze Kubernetes-funksje te stypjen, om't it wurdt ferwachte dat reguliere standerdisearre sjauffeurs net sille wurkje - mar der wurdt fan útgien dat sokke folumes kinne wurde brûkt op elke knooppunt keazen foar in pod.

Dit kin in probleem wêze foar folumes mei in signifikant konsumpsje fan nodeboarnen, of foar opslach dy't allinich beskikber is op guon knopen. Dêrom yntrodusearret Kubernetes 1.19 twa nije funksjes foar alfa-testvoluminten dy't konseptueel fergelykber binne mei EmptyDir-voluminten:

  • algemiene doel efemere voluminten;

  • CSI opslach kapasiteit monitoring.

Foardielen fan de nije oanpak:

  • opslach kin lokaal of netwurk ferbûn wêze;

  • folumes kinne in spesifisearre grutte hawwe dy't net troch de applikaasje kin wurde oerskreaun;

  • wurket mei elke CSI-bestjoerder dy't it leverjen fan persistente folumes stipet en (om kapasiteitsfolging te stypjen) dy't de oprop ymplementearret GetCapacity;

  • folumes kinne hawwe wat initial gegevens ôfhinklik fan de bestjoerder en parameters;

  • alle typyske folume operaasjes (meitsje in momintopname, feroarje grutte, ensfh) wurde stipe;

  • folumes kinne brûkt wurde mei eltse applikaasje controller dy't akseptearret in module of folume spesifikaasje;

  • De Kubernetes-planner kiest sels de passende knooppunten, dus jo hoege net langer planner-útwreidings te leverjen en te konfigurearjen en webhooks te feroarjen.

Opsjes foar tapassing

Dêrom binne efemere voluminten foar algemiene doel geskikt foar de folgjende gebrûksgefallen:

Persistent ûnthâld as ferfanging foar RAM foar memcached

Lêste releases fan memcached tafoege stipe gebrûk fan persistent ûnthâld (Intel Optane, ensfh., ca. oersetter) ynstee fan gewoane RAM. By it ynsetten fan memcached fia de applikaasjekontrôler, kinne jo tydlike voluminten foar algemiene doelen brûke om de tawizing fan in folume fan in opjûne grutte oan te freegjen fan PMEM mei it CSI-bestjoerder, bygelyks PMEM-CSI.

Lokale LVM opslach as wurkromte

Applikaasjes dy't wurkje mei gegevens grutter dan RAM kinne lokale opslach oanfreegje mei in grutte of prestaasjesmetriken dy't reguliere Kubernetes EmptyDir-volumes net kinne leverje. Bygelyks, foar dit doel waard skreaun TopoLVM.

Allinnich-lêzen tagong foar gegevensvoluminten

It tawizen fan in folume kin resultearje yn it meitsjen fan in folslein folume as:

Dizze folumes kinne wurde monteard yn allinich-lêsmodus.

Hoe docht dit wurk

Algemien Doel Efemere Volumes

In wichtich skaaimerk fan efemere voluminten foar algemien doel is de nije folumeboarne, EphemeralVolumeSourceA dat befettet alle fjilden foar it meitsjen fan in folume fersyk (histoarysk neamd in fersyk foar in oanhâldende folume, PVC). Nije controller yn kube-controller-manager Sjocht de Pods op dy't dy folumeboarne meitsje en makket dan in PVC foar dy Pods. Foar de CSI-bestjoerder sjocht dizze query itselde as de oaren, dus gjin spesjale stipe is hjir nedich.

Salang't sokke PVCs besteane, kinne se brûkt wurde lykas alle oare oanfragen foar in folume. Benammen kinne se ferwiisd wurde as in gegevensboarne by it kopiearjen fan in folume of it meitsjen fan in momintopname fan in folume. It PVC-objekt befettet ek de hjoeddeistige steat fan it folume.

De nammen fan 'e automatysk oanmakke PVC's binne foarôf definieare: se binne in kombinaasje fan in podnamme en in folumenamme, skieden troch in koppelteken. Foarôf definieare nammen meitsje it makliker om te ynteraksje mei de PVC, om't it net hoecht te wurde opsocht as de podnamme en folumenamme bekend binne. It neidiel is dat de namme al yn gebrûk is, wat wurdt ûntdutsen troch Kubernetes en as gefolch dat de Pod blokkearre wurdt om te begjinnen.

Om derfoar te soargjen dat it folume wurdt wiske tegearre mei de pod, de controller makket in query op it folume ûnder de eigner. As in pod wurdt wiske, fiert it de reguliere garbage collection meganisme, dy't wisket sawol it fersyk en it folume.

Fersiken wurde yn kaart brocht oan in opslach stjoerprogramma fia de normale opslach klasse meganisme. Hoewol klassen mei direkte en lette bining (se binne WaitForFirstConsumer) wurde stipe, foar efemere voluminten is it sin te brûken WaitForFirstConsumer, dan kin de planner sawol knooppuntgebrûk as beskikberens fan opslach beskôgje by it kiezen fan in knooppunt. Hjir komt in nije funksje.

Opslach kapasiteit tracking

De planner hat normaal gjin idee wêr't de CSI-bestjoerder it folume sil meitsje. D'r is ek gjin manier foar de planner om direkt kontakt te meitsjen mei de bestjoerder om dizze ynformaasje te freegjen. Dêrom ûndersiket de planner knooppunten oant it ien fynt wêrop folumes beskikber wêze kinne (lette bining), of lit de kar fan lokaasje folslein oan 'e bestjoerder (direkte bining).

Nij API CSIStorageCapacity, dy't yn 'e alfa-poadium is, lit de nedige gegevens wurde opslein yn etcd, sadat it beskikber is foar de planner. Oars as stipe foar tydlike voluminten foar algemiene doelen, moatte jo kontrôle opslachkapasiteit ynskeakelje as jo de bestjoerder ynsette: external-provisioner moatte publisearje de kapasiteit ynformaasje ûntfongen fan de bestjoerder fia de normale GetCapacity.

As de planner in knooppunt moat selektearje foar in pod mei in ûnbûn folume dat lette bining brûkt, en de ynsetbestjoerder dizze funksje ynskeakele hat troch de flagge yn te stellen CSIDriver.storageCapacity, knopen dy't net genôch opslachkapasiteit hawwe sille automatysk falle. Dit wurket foar sawol efemere algemiene doelen as persistente folumes, mar net foar efemere CSI-voluminten, om't har ynstellingen net kinne wurde lêzen troch Kubernetes.

Lykas gewoanlik wurde folumes direkt oanmakke foar podplanning, en har pleatsing wurdt keazen troch de opslachbestjoerder, dus by it konfigurearjen external-provisioner standert wurde fuortendaliks ferbûne opslachklassen oerslein, om't dizze gegevens yn elts gefal net brûkt wurde.

Sûnt de kubernetes planner wurdt twongen om te wurkjen mei potinsjeel muffe ynformaasje, der is gjin garânsje dat kapasiteit sil beskikber wêze elts momint in folume wurdt oanmakke, mar der is noch in hegere kâns dat it wurdt makke sûnder opnij besykjen.

NB Jo kinne mear detaillearre ynformaasje krije, lykas ek feilich "traine op in kattestand", en yn gefal fan in folslein ûnbegryplike situaasje, kwalifisearre help krije fan technyske stipe op yntinsives - Kubernetes Base wurdt holden op 28-30 septimber, en foar mear avansearre spesjalisten Kubernetes Mega 14-16 oktober.

Feiligens

CSIStorageCapacity

CSIStorageCapacity-objekten binne yn nammeromten, by it útroljen fan elke CSI-bestjoerder yn syn eigen nammeromte, wurdt it oanrikkemandearre om de RBAC-rjochten foar CSIStorageCapacity yn dizze romte te beheinen, om't it dúdlik is wêr't de gegevens weikomme. Yn alle gefallen kontrolearret Kubernetes dit net, en meastentiids wurde de bestjoerders yn deselde nammeromte pleatst, dus op it lêst wurdt ferwachte dat de bestjoerders sille wurkje en gjin ferkearde gegevens publisearje (en hjir hat de kaart my oerstreamd, ca. oersetter basearre op in burd grap)

Algemien Doel Efemere Volumes

As brûkers rjochten hawwe om in pod te meitsjen (direkt of yndirekt) - dan kinne se ek tydlike voluminten foar algemiene doelen meitsje, sels as se gjin rjochten hawwe om in fersyk foar in folume te meitsjen. Dit komt om't RBAC-rjochtenkontrôles wurde tapast op 'e kontrôler dy't de PVC makket, net foar de brûker. Dit is de wichtichste feroaring om ta te foegjen te rekkenjenfoardat jo dizze funksje ynskeakelje op klusters as net-fertroude brûkers net tastien wurde om folumes te meitsjen.

Foarbyld:

Skiede branch PMEM-CSI befettet alle nedige wizigingen om in Kubernetes 1.19-kluster út te fieren binnen QEMU firtuele masines mei alle funksjes yn 'e alfa-poadium. De bestjoerderkoade is net feroare, allinich de ynset is feroare.

Op in geskikte masine (Linux, in normale brûker kin brûke Havenarbeider,sjo hjir details) dizze kommando's sille it kluster ophelje en de PMEM-CSI-bestjoerder ynstallearje:

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

Nei't alles wurke hat, sil de útfier ynstruksjes foar gebrûk befetsje:

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 -

CSIStorageCapacity-objekten binne net bedoeld om te lêzen troch minsken, dus wat ferwurking is nedich. It brûken fan sjabloanfilters yn Golang sil de opslachklassen sjen litte, yn dit foarbyld wurde de namme, topology en kapasiteit toand:

$ 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

In inkeld objekt hat de folgjende ynhâld:

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

Litte wy besykje in demo-applikaasje te meitsjen mei in ienfâldich folume foar algemien doel. Triem ynhâld 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

Nei it meitsjen, lykas werjûn yn 'e ynstruksjes hjirboppe, hawwe wy in ekstra pod en 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 eigner - ûnder:

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

Ferwacht bywurke ynformaasje foar 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

As in oare applikaasje mear nedich is as 26620Mi, sil de planner gjin rekken hâlde pmem-csi-pmem-govm-worker1 yn elke regeling.

Wat is folgjende?

Beide funksjes binne noch yn ûntwikkeling. Ferskate kaartsjes waarden iepene tidens alpha-testen. De keppelings foar ferbetteringssuggestjes dokumintearje it wurk dat dien wurde moat om nei it beta-stadium te gean, lykas hokker alternativen al binne beskôge en ôfwiisd:

Boarne: www.habr.com

Add a comment