Ang ilang mga application ay kailangan ding mag-imbak ng data, ngunit medyo komportable sila sa katotohanan na ang data ay hindi mase-save pagkatapos ng pag-restart.
Halimbawa, ang mga serbisyo sa pag-cache ay nililimitahan ng RAM, ngunit maaari ring ilipat ang data na bihirang ginagamit sa storage na mas mabagal kaysa sa RAM, na may maliit na epekto sa pangkalahatang pagganap. Kailangang malaman ng ibang mga application na maaaring mayroong ilang read-only na input sa mga file, tulad ng mga setting o mga lihim na key.
Ang Kubernetes ay mayroon nang ilang uri , ngunit ang kanilang functionality ay limitado sa kung ano ang ipinatupad sa K8s.
Pansamantala pinahintulutan ang Kubernetes na ma-extend sa mga driver ng CSI upang magbigay ng suporta para sa magaan na lokal na volume. Sa ganitong paraan posible itong gamitin : mga setting, mga lihim, data ng pagkakakilanlan, mga variable, at iba pa. Ang mga driver ng CSI ay dapat mabago upang suportahan ang tampok na Kubernetes na ito, dahil ipinapalagay na ang mga regular na standardized na driver ay hindi gagana - ngunit ipinapalagay na ang mga naturang volume ay maaaring gamitin sa anumang node na pinili para sa pod.
Maaaring ito ay isang problema para sa mga volume na kumokonsumo ng makabuluhang mga mapagkukunan ng host o para sa imbakan na magagamit lamang sa ilang mga host. Iyon ang dahilan kung bakit ipinakilala ng Kubernetes 1.19 ang dalawang bagong feature ng dami ng pagsubok sa alpha na kapareho ng konsepto sa mga volume ng EmptyDir:
-
pangkalahatang layunin ephemeral volume;
-
Pagsubaybay sa kapasidad ng imbakan ng CSI.
Mga kalamangan ng bagong diskarte:
-
imbakan ay maaaring lokal o konektado sa pamamagitan ng isang network;
-
ang mga volume ay maaaring magkaroon ng isang tinukoy na laki na hindi maaaring lampasan ng application;
-
gumagana sa anumang mga driver ng CSI na sumusuporta sa pagbibigay ng patuloy na dami at (upang suportahan ang pagsubaybay sa kapasidad) na nagpapatupad ng tawag
GetCapacity; -
ang mga volume ay maaaring may ilang paunang data depende sa driver at mga setting;
-
lahat ng karaniwang operasyon na may volume (paglikha ng snapshot, pagbabago ng laki, atbp.) ay suportado;
-
maaaring gamitin ang mga volume sa anumang application controller na tumatanggap ng module o volume specification;
-
Ang scheduler ng Kubernetes ay pipili ng mga angkop na node nang mag-isa, kaya hindi na kailangang maglaan at mag-configure ng mga extension ng scheduler o magbago ng mga webhook.
Mga pagpipilian sa application
Samakatuwid, ang mga pangkalahatang layunin na ephemeral volume ay angkop para sa mga sumusunod na kaso ng paggamit:
Ang patuloy na memorya bilang kapalit ng RAM para sa memcached
Pinakabagong release ng memcached gamit ang patuloy na memorya (Intel Optane, atbp., tinatayang tagasalin) sa halip na regular na RAM. Kapag nagde-deploy ng memcached sa pamamagitan ng isang application controller, maaari mong gamitin ang pangkalahatang layunin na ephemeral volume upang humiling na ang isang volume ng isang partikular na laki ay ilaan mula sa PMEM gamit ang CSI driver, halimbawa. .
LVM lokal na imbakan bilang isang workspace
Ang mga application na gumagana sa data na mas malaki kaysa sa RAM ay maaaring mangailangan ng lokal na storage na may sukat o mga sukatan ng pagganap na hindi maibibigay ng mga regular na volume ng EmptyDir mula sa Kubernetes. Halimbawa, para sa layuning ito ito ay isinulat .
Read-only na access para sa dami ng data
Ang paglalaan ng isang volume ay maaaring magresulta sa paglikha ng isang buong volume kapag:
-
pagpapanumbalik ;
-
lumilikha ;
-
trabaho .
Ang mga volume na ito ay maaaring i-mount sa read-only na mode.
ΠΠ°ΠΊ ΡΡΠΎ ΡΠ°Π±ΠΎΡΠ°Π΅Ρ
Pangkalahatang Layunin Ephemeral Volume
Ang pangunahing tampok ng pangkalahatang layunin na ephemeral volume ay ang bagong pinagmumulan ng volume, EphemeralVolumeSource, na naglalaman ng lahat ng mga patlang upang lumikha ng isang kahilingan sa dami (sa kasaysayan ay tinatawag na isang patuloy na kahilingan sa dami, PVC). Bagong controller sa kube-controller-manager tinitingnan ang mga pod na lumilikha ng ganoong source ng volume, at pagkatapos ay gumagawa ng PVC para sa mga pod na iyon. Para sa driver ng CSI, ang kahilingang ito ay kamukha ng iba, kaya walang espesyal na suporta ang kailangan dito.
Hangga't umiiral ang mga naturang PVC, maaari silang magamit tulad ng anumang iba pang mga kahilingan sa volume. Sa partikular, maaari silang i-reference bilang data source kapag kumukopya ng volume o gumagawa ng snapshot mula sa volume. Ang bagay na PVC ay naglalaman din ng kasalukuyang estado ng volume.
Ang mga pangalan ng mga awtomatikong ginawang PVC ay paunang natukoy: ang mga ito ay isang kumbinasyon ng pangalan ng pod at ang pangalan ng volume, na pinaghihiwalay ng isang gitling. Pinapadali ng mga paunang natukoy na pangalan ang pakikipag-ugnayan sa PVC dahil hindi mo na kailangang hanapin ito kung alam mo ang pangalan ng pod at pangalan ng volume. Ang downside ay ang pangalan ay maaaring ginagamit na, na na-detect ng Kubernetes at bilang resulta ay naharang ang pod mula sa pagsisimula.
Upang matiyak na ang volume ay tatanggalin kasama ng pod, ang controller ay humihiling sa volume sa ilalim ng may-ari. Kapag na-delete ang pod, gumagana ang karaniwang mekanismo ng pangongolekta ng basura, na nagtatanggal sa parehong kahilingan at volume.
Ang mga kahilingan ay itinutugma ng driver ng storage sa pamamagitan ng normal na mekanismo ng klase ng storage. Bagaman ang mga klase na may agaran at huli na pagbubuklod (aka WaitForFirstConsumer) ay sinusuportahan, para sa mga ephemeral na volume ay makatuwirang gamitin WaitForFirstConsumer, pagkatapos ay maaaring isaalang-alang ng scheduler ang parehong paggamit ng node at availability ng storage kapag pumipili ng node. May lalabas na bagong feature dito.
Pagsubaybay sa Kapasidad ng Imbakan
Karaniwan ang scheduler ay walang kaalaman kung saan ang CSI driver ay gagawa ng volume. Wala ring paraan para direktang makipag-ugnayan ang scheduler sa driver para hilingin ang impormasyong ito. Samakatuwid, ang scheduler poll nodes hanggang sa mahanap nito ang isa kung saan maaaring ma-access ang mga volume (late binding) o ipaubaya sa driver ang pagpili ng lokasyon (immediate binding).
Bago CSIStorageCapacity, na nasa yugto ng alpha, ay nagbibigay-daan sa kinakailangang data na maimbak sa etcd upang ito ay magagamit sa scheduler. Hindi tulad ng suporta para sa pangkalahatang layunin na ephemeral volume, kapag na-deploy mo ang driver, dapat mong paganahin ang pagsubaybay sa kapasidad ng storage: external-provisioner dapat i-publish ang impormasyon ng kapasidad na natanggap mula sa driver sa pamamagitan ng normal GetCapacity.
Kung kailangan ng scheduler na pumili ng node para sa isang pod na may unbound volume na gumagamit ng late binding, at pinagana ng driver ang feature na ito sa panahon ng deployment sa pamamagitan ng pagtatakda ng flag CSIDriver.storageCapacity, pagkatapos ay ang mga node na walang sapat na kapasidad ng imbakan ay awtomatikong itatapon. Gumagana ito para sa pangkalahatang layunin na ephemeral at persistent volume, ngunit hindi para sa CSI ephemeral volume dahil hindi mababasa ng Kubernetes ang mga parameter ng mga ito.
Gaya ng dati, ang mga agad na naka-link na volume ay nilikha bago ang mga pod ay naka-iskedyul, at ang kanilang pagkakalagay ay pinili ng driver ng imbakan, kaya kapag nagko-configure external-provisioner Bilang default, nilaktawan ang mga klase ng storage na may agarang pagbubuklod, dahil hindi pa rin magagamit ang data na ito.
Dahil ang scheduler ng kubernetes ay napipilitang magtrabaho kasama ang potensyal na hindi napapanahon na impormasyon, walang garantiya na ang kapasidad ay magagamit sa bawat kaso kapag ang volume ay ginawa, ngunit ang mga pagkakataon na ito ay malilikha nang walang muling pagsubok ay tumataas pa rin.
NB Maaari kang makakuha ng mas detalyadong impormasyon, pati na rin ang ligtas na "pagsasanay sa cats stand", at sa kaso ng isang ganap na hindi maintindihan na sitwasyon, makatanggap ng kwalipikadong tulong sa teknikal na suporta sa masinsinang mga kurso - ay gaganapin sa Setyembre 28-30, at para sa mas advanced na mga espesyalista Oktubre 14β16.
katiwasayan
CSIStorageCapacity
Ang mga object ng CSIStorageCapacity ay nasa mga namespace; kapag inilulunsad ang bawat CSI driver sa sarili nitong namespace, inirerekomendang paghigpitan ang mga karapatan ng RBAC sa CSIStorageCapacity sa espasyong iyon dahil malinaw kung saan nanggagaling ang data. Hindi pa rin ito sinusuri ng Kubernetes, at kadalasan ang mga driver ay inilalagay sa parehong namespace, kaya sa huli ang mga driver ay inaasahang gagana at hindi mag-publish ng maling data (at dito nabigo ang aking card, tinatayang tagasalin batay sa isang may balbas na biro)
Pangkalahatang Layunin Ephemeral Volume
Kung may mga karapatan ang mga user na gumawa ng pod (direkta o hindi direkta), makakagawa din sila ng mga pangkalahatang layunin na ephemeral volume kahit na wala silang karapatang gumawa ng kahilingan sa volume. Ito ay dahil ang mga pagsusuri sa pahintulot ng RBAC ay inilalapat sa controller na lumilikha ng PVC, hindi sa gumagamit. Ito ang pangunahing pagbabago na idaragdag , bago i-enable ang feature na ito sa mga cluster kung saan hindi dapat magkaroon ng mga karapatan ang mga hindi pinagkakatiwalaang user na gumawa ng mga volume.
Halimbawa
Hiwalay Ang PMEM-CSI ay naglalaman ng lahat ng kinakailangang pagbabago para magpatakbo ng Kubernetes 1.19 cluster sa loob ng mga virtual machine ng QEMU kasama ang lahat ng feature sa alpha stage. Hindi nagbago ang driver code, ang deployment lang ang nagbago.
Sa isang angkop na makina (Linux, maaaring gamitin ng isang normal na user , tingnan mo mga detalye) ilalabas ng mga utos na ito ang cluster at i-install ang driver ng 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
Matapos gumana ang lahat, ang output ay maglalaman ng mga tagubilin para sa paggamit:
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 -
Ang mga bagay na CSIStorageCapacity ay hindi nilalayong basahin ng mga tao, kaya nangangailangan ng ilang pagproseso. Ipapakita ng mga filter ng template ng Golang ang mga klase ng imbakan, ipapakita ng halimbawang ito ang pangalan, topology at kapasidad:
$ 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
Ang isang bagay ay may sumusunod na nilalaman:
$ 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>
Subukan nating lumikha ng demo application na may iisang pangkalahatang layunin na ephemeral volume. Mga nilalaman ng file 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
Pagkatapos gumawa, tulad ng ipinapakita sa mga tagubilin sa itaas, mayroon na kaming karagdagang pod at 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
May-ari ng PVC - sa ilalim ng:
$ 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
...
Inaasahang na-update na impormasyon para sa 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
Kung ang isa pang application ay nangangailangan ng higit sa 26620Mi, hindi isasaalang-alang ng scheduler pmem-csi-pmem-govm-worker1 sa anumang kaso.
Ano ang susunod?
Ang parehong mga tampok ay nasa pag-unlad pa rin. Maraming mga application ang binuksan sa panahon ng pagsubok sa alpha. Ang mga link sa panukala sa pagpapabuti ay nagdodokumento ng gawaing kailangang gawin upang lumipat sa beta stage, pati na rin kung aling mga alternatibo ang naisip at tinanggihan na:
Pinagmulan: www.habr.com