ProHoster > Блог > Administrado > Efemeraj Volumoj kun Stoka Kapacito-Spurado: EmptyDir sur Steroidoj

Efemeraj Volumoj kun Stoka Kapacito-Spurado: EmptyDir sur Steroidoj

Efemeraj Volumoj kun Stoka Kapacito-Spurado: EmptyDir sur Steroidoj

Iuj aplikoj ankaŭ bezonas konservi datumojn, sed ili estas sufiĉe komfortaj kun la fakto, ke la datumoj ne estos konservitaj post rekomenco.

Ekzemple, kaŝmemorservoj estas limigitaj de RAM, sed ankaŭ povas movi datumojn, kiuj malofte estas uzataj al stokado, kiu estas pli malrapida ol RAM, kun nur malmulte da efiko al totala efikeco. Aliaj aplikaĵoj devas konscii, ke eble ekzistas nurlegebla enigo en la dosieroj, kiel agordoj aŭ sekretaj ŝlosiloj.

Kubernetes jam havas plurajn tipojn efemeraj volumoj, sed ilia funkcieco estas limigita al kio estas efektivigita en la K8s.

Efemera CSI-volumoj permesis al Kubernetes esti etendita per CSI-ŝoforoj por disponigi subtenon por malpezaj lokaj volumoj. Tiamaniere eblas uzi arbitraj strukturoj: agordoj, sekretoj, identigaj datumoj, variabloj ktp. CSI-ŝoforoj devas esti modifitaj por subteni ĉi tiun funkcion de Kubernetes, ĉar oni supozas, ke regulaj normigitaj ŝoforoj ne funkcios - sed oni supozas, ke tiaj volumoj povas esti uzataj sur iu ajn nodo elektita por la pod.

Ĉi tio povas esti problemo por volumoj, kiuj konsumas signifajn gastigajn rimedojn aŭ por stokado, kiu estas nur disponebla ĉe iuj gastigantoj. Tial Kubernetes 1.19 enkondukas du novajn alfa-testajn volumajn funkciojn, kiuj koncipe similas al EmptyDir-volumoj:

  • ĝeneraluzeblaj efemeraj volumoj;

  • CSI-stoka kapacito spurado.

Avantaĝoj de la nova aliro:

  • stokado povas esti loka aŭ konektita per reto;

  • volumoj povas havi specifan grandecon, kiu ne povas esti superita de la aplikaĵo;

  • funkcias kun iuj CSI-ŝoforoj kiuj subtenas provizon de konstantaj volumoj kaj (por subteni kapacitspuradon) efektivigas la vokon GetCapacity;

  • volumoj povas havi iujn komencajn datumojn depende de la ŝoforo kaj agordoj;

  • ĉiuj normaj operacioj kun volumo (kreado de momentfoto, regrandigo, ktp.) estas subtenataj;

  • volumoj povas esti uzataj kun iu ajn aplika regilo, kiu akceptas modulon aŭ volumenospecifon;

  • La planilo de Kubernetes elektas taŭgajn nodojn memstare, do ne plu necesas provizi kaj agordi etendaĵojn pri horaro aŭ modifi rethokojn.

Aplikoj

Tial ĝeneraluzeblaj efemeraj volumoj taŭgas por la sekvaj uzkazoj:

Konstanta memoro kiel anstataŭaĵo por RAM por memcached

Plej novaj eldonoj de memcached aldonis subtenon uzante konstantan memoron (Intel Optane, ktp., ĉ. tradukisto) anstataŭ regula RAM. Dum deplojado de memcached per aplika regilo, vi povas uzi ĝeneralajn celajn efemerajn volumojn por peti, ke volumeno de difinita grandeco estu asignita de PMEM uzante la CSI-ŝoforon, ekzemple. PMEM-CSI.

LVM loka stokado kiel laborspaco

Aplikoj, kiuj funkcias kun datumoj pli grandaj ol RAM, povas postuli lokan stokadon kun grandeco aŭ rendimento metriko, kiujn regulaj EmptyDir-volumoj de Kubernetes ne povas provizi. Ekzemple, tiucele ĝi estis skribita TopoLVM.

Nurlegebla aliro por datumvolumoj

Asigno de volumeno povas rezultigi la kreadon de plena volumeno kiam:

Ĉi tiuj volumoj povas esti muntitaj en nurlegebla reĝimo.

Kiel tio funkcias

Ĝenerala Celo Efemeraj Volumoj

Ĉefa trajto de ĝeneraluzeblaj efemeraj volumoj estas la nova volumenfonto, EphemeralVolumeSource, enhavante ĉiujn kampojn por krei volumenan peton (historie nomatan persistan volumpeton, PVC). Nova regilo en kube-controller-manager rigardas la podojn kiuj kreas tian volumenfonton, kaj poste kreas PVC por tiuj balgoj. Por la CSI-ŝoforo, ĉi tiu peto aspektas same kiel la aliaj, do ne necesas speciala subteno ĉi tie.

Dum tiaj PVC-oj ekzistas, ili povas esti uzataj kiel iuj aliaj petoj sur la volumo. Aparte, ili povas esti referencitaj kiel datumfonto dum kopiado de volumeno aŭ kreado de momentfoto de volumeno. La PVC-objekto ankaŭ enhavas la nunan staton de la volumeno.

La nomoj de aŭtomate kreitaj PVC-oj estas antaŭdifinitaj: ili estas kombinaĵo de la podnomo kaj la volumnomo, apartigitaj per streketo. Antaŭdifinitaj nomoj faciligas interagi kun la PVC ĉar vi ne devas serĉi ĝin se vi konas la podnomon kaj volumnomon. La malavantaĝo estas, ke la nomo eble jam estas uzata, kiu estas detektita de Kubernetes kaj kiel rezulto la pod estas blokita de komenci.

Por certigi, ke la volumo estas forigita kune kun la pod, la regilo faras peton al la volumo sub la posedanto. Kiam la pod estas forigita, la norma rubokolekta mekanismo estas efektivigita, kiu forigas kaj la peton kaj la volumon.

Petoj estas egalitaj fare de la stokadŝoforo per la normala mekanismo de la stokadklaso. Kvankam klasoj kun tuja kaj malfrua ligado (alinome WaitForFirstConsumer) estas subtenataj, por efemeraj volumoj estas senco uzi WaitForFirstConsumer, tiam la planisto povas konsideri kaj nodan uzadon kaj stokan haveblecon dum elektado de nodo. Nova funkcio aperas ĉi tie.

Spurado de Kapacito de Stokado

Tipe la planisto havas neniun scion pri kie la CSI-ŝoforo kreos la volumenon. Ankaŭ ne ekzistas maniero por la planisto kontakti la ŝoforon rekte por peti ĉi tiun informon. Tial, la planisto sondas nodojn ĝis ĝi trovas unu sur kiu volumoj povas esti aliritaj (malfrua ligado) aŭ lasas la elekton de loko tute al la ŝoforo (tuja ligado).

Nova API CSIStorageCapacity, kiu estas en la alfa stadio, permesas la necesajn datumojn esti stokitaj en etcd tiel ke ĝi estas havebla al la planisto. Male al subteno por ĝeneraluzeblaj efemeraj volumoj, kiam vi deplojas la ŝoforon, vi devas ebligi spuradon de konserva kapacito: external-provisioner devus publikigi la kapacitinformojn ricevitajn de la ŝoforo per normala GetCapacity.

Se la planisto bezonas elekti nodon por pod kun nebindita volumeno kiu uzas malfruan ligadon, kaj la ŝoforo ebligis ĉi tiun funkcion dum deplojo agordante la flagon CSIDriver.storageCapacity, tiam nodoj kiuj ne havas sufiĉan stokan kapaciton estos aŭtomate forĵetitaj. Ĉi tio funkcias por ĝeneraluzeblaj efemeraj kaj persistaj volumoj, sed ne por CSI-efemeraj volumoj ĉar iliaj parametroj ne povas esti legitaj de Kubernetes.

Kiel kutime, tuj ligitaj volumoj estas kreitaj antaŭ ol podoj estas planitaj, kaj ilia lokigo estas elektita de la stoka ŝoforo, do dum agordado. external-provisioner Defaŭlte, stokadklasoj kun tuja ligado estas preterlasitaj, ĉar ĉi tiuj datumoj ĉiuokaze ne estos uzataj.

Ĉar la kubernetes-planilo estas devigita labori kun eble malmodernaj informoj, ne estas garantio, ke kapablo estos disponebla en ĉiu kazo kiam la volumeno estas kreita, sed la ŝancoj ke ĝi estos kreita sen reprovoj estas tamen pliigitaj.

NB Vi povas ricevi pli detalajn informojn, kaj ankaŭ sekure "praktiki sur la kata stando", kaj en kazo de tute nekomprenebla situacio, ricevi kvalifikitan teknikan subtenan helpon ĉe intensaj kursoj - Kubernetes Bazo okazos la 28-30-an de septembro, kaj por pli progresintaj specialistoj Kubernetes Mega 14–16 oktobro.

Sekureco

CSISstorageCapacity

CSIStorageCapacity-objektoj loĝas en nomspacoj; dum lanĉado de ĉiu CSI-ŝoforo en sia propra nomspaco, estas rekomendite limigi RBAC-rajtojn al la CSIStorageCapacity en tiu spaco ĉar estas evidente de kie venas la datenoj. Kubernetes ne kontrolas ĉi tion ĉiuokaze, kaj kutime ŝoforoj estas metitaj en la saman nomspacon, do finfine la ŝoforoj estas atenditaj funkcii kaj ne publikigi malĝustajn datumojn (kaj ĉi tie mia karto malsukcesis, ĉ. tradukisto bazita sur barba ŝerco)

Ĝenerala Celo Efemeraj Volumoj

Se uzantoj havas rajtojn krei pod (rekte aŭ nerekte), ili ankaŭ povos krei ĝeneraluzeblajn efemerajn volumojn eĉ se ili ne havas rajtojn krei peton sur la volumo. Ĉi tio estas ĉar RBAC-permesokontroloj estas aplikitaj al la regilo kiu kreas la PVC, ne al la uzanto. Ĉi tio estas la ĉefa ŝanĝo por aldoni al via konto, antaŭ ebligi ĉi tiun funkcion sur aretoj kie nefidindaj uzantoj ne devus havi rajtojn krei volumojn.

Ekzemplo:

Apartigi branĉo PMEM-CSI enhavas ĉiujn necesajn ŝanĝojn por ruli Kubernetes 1.19-areton ene de virtualaj maŝinoj QEMU kun ĉiuj funkcioj en la alfa stadio. La ŝoforkodo ne ŝanĝiĝis, nur la deplojo ŝanĝiĝis.

Sur taŭga maŝino (Linukso, normala uzanto povas uzi Docker, rigardu tie detaloj) ĉi tiuj komandoj aperigos la areton kaj instalos la PMEM-CSI-ŝoforon:

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

Post kiam ĉio funkcios, la eligo enhavos instrukciojn por uzo:

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-objektoj ne estas intencitaj por esti legitaj de homoj, do iu pretigo estas postulata. Golang-ŝablonaj filtriloj montros la stokadklasojn, ĉi tiu ekzemplo montros la nomon, topologion kaj kapaciton:

$ 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

Ununura objekto havas la jenan enhavon:

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

Ni provu krei demo-aplikaĵon kun ununura ĝenerala celo efemera volumeno. Dosiera enhavo 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

Post kreado, kiel montrite en la supraj instrukcioj, ni nun havas plian pod kaj 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-posedanto - sub:

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

Atendite ĝisdatigitaj informoj por 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

Se alia aplikaĵo bezonas pli ol 26620Mi, la planilo ne konsideros pmem-csi-pmem-govm-worker1 ĉiukaze.

Kio sekvas?

Ambaŭ funkcioj estas ankoraŭ evoluantaj. Pluraj aplikoj estis malfermitaj dum alfa-testado. La plibonigproponaj ligiloj dokumentas la laboron, kiu devas esti farita por moviĝi al la beta-fazo, same kiel kiuj alternativoj jam estis pripensitaj kaj malakceptitaj:

fonto: www.habr.com

Aldoni komenton