Ba'zi ilovalar ham ma'lumotlarni saqlashi kerak, ammo ular qayta ishga tushirilgandan keyin ma'lumotlar saqlanmasligi bilan juda qulaydir.
Misol uchun, keshlash xizmatlari operativ xotira bilan cheklangan, lekin ayni paytda RAMga qaraganda sekinroq saqlash uchun kamdan-kam qo'llaniladigan ma'lumotlarni ko'chirishi mumkin, bu umumiy ishlashga ozgina ta'sir qiladi. Boshqa ilovalar fayllarda sozlamalar yoki maxfiy kalitlar kabi faqat o'qish uchun kiritilgan ma'lumotlar bo'lishi mumkinligini bilishi kerak.
Kubernetes allaqachon bir nechta turlarga ega , lekin ularning funksionalligi K8-larda amalga oshiriladigan narsalar bilan cheklangan.
Efemer engil mahalliy hajmlarni qo'llab-quvvatlash uchun Kubernetes-ni CSI drayverlari bilan kengaytirishga imkon berdi. Shu tarzda foydalanish mumkin : sozlamalar, sirlar, identifikatsiya ma'lumotlari, o'zgaruvchilar va boshqalar. CSI drayverlari ushbu Kubernetes xususiyatini qo'llab-quvvatlash uchun o'zgartirilishi kerak, chunki oddiy standartlashtirilgan drayverlar ishlamaydi deb taxmin qilinadi - lekin bunday hajmlarni podkast uchun tanlangan har qanday tugunda ishlatish mumkin deb taxmin qilinadi.
Bu muhim xost resurslarini iste'mol qiladigan hajmlar yoki faqat ba'zi xostlarda mavjud bo'lgan saqlash uchun muammo bo'lishi mumkin. Shuning uchun Kubernetes 1.19 kontseptual jihatdan EmptyDir jildlariga o'xshash ikkita yangi alfa sinov hajmi xususiyatlarini taqdim etadi:
-
umumiy maqsadli efemer hajmlar;
-
CSI saqlash hajmini kuzatish.
Yangi yondashuvning afzalliklari:
-
saqlash mahalliy yoki tarmoq orqali ulanishi mumkin;
-
hajmlar ilova tomonidan oshirib bo'lmaydigan belgilangan hajmga ega bo'lishi mumkin;
-
doimiy hajmlarni ta'minlashni qo'llab-quvvatlaydigan va (imkoniyatlarni kuzatishni qo'llab-quvvatlash uchun) qo'ng'iroqni amalga oshiradigan har qanday CSI drayverlari bilan ishlaydi
GetCapacity; -
hajmlar drayver va sozlamalarga qarab ba'zi dastlabki ma'lumotlarga ega bo'lishi mumkin;
-
ovoz balandligi bilan barcha standart operatsiyalar (snapshot yaratish, o'lchamini o'zgartirish va h.k.) qo'llab-quvvatlanadi;
-
jildlar modul yoki hajm spetsifikatsiyasini qabul qiladigan har qanday dastur boshqaruvchisi bilan ishlatilishi mumkin;
-
Kubernetes rejalashtiruvchisi mos tugunlarni o'zi tanlaydi, shuning uchun endi rejalashtiruvchi kengaytmalarini ta'minlash va sozlash yoki veb-huklarni o'zgartirishga hojat qolmaydi.
Ilovalar
Shuning uchun umumiy maqsadli efemer hajmlar quyidagi foydalanish holatlariga mos keladi:
Memcached uchun RAM o'rniga doimiy xotira
Memcached-ning so'nggi versiyalari doimiy xotiradan foydalanish (Intel Optane va boshqalar, taxminan. tarjimon) oddiy RAM o'rniga. Memcached-ni dastur boshqaruvchisi orqali o'rnatishda siz umumiy maqsadli vaqtinchalik hajmlardan foydalanishingiz mumkin, masalan, CSI drayveri yordamida ma'lum hajmdagi hajmni PMEMdan ajratishni so'rashingiz mumkin. .
LVM mahalliy xotirasi ish joyi sifatida
Operativ xotiradan kattaroq maʼlumotlar bilan ishlaydigan ilovalar Kubernetes’dan oddiy EmptyDir hajmlari taqdim eta olmaydigan hajm yoki ishlash koʻrsatkichlari bilan mahalliy saqlashni talab qilishi mumkin. Masalan, shu maqsadda yozilgan .
Ma'lumotlar hajmlari uchun faqat o'qish uchun ruxsat
Jildni taqsimlash quyidagi hollarda to'liq hajmni yaratishga olib kelishi mumkin:
-
tiklanish ;
-
yaratish ;
-
работе .
Ushbu jildlar faqat o'qish rejimida o'rnatilishi mumkin.
U qanday ishlaydi
Umumiy maqsadli efemer hajmlar
Umumiy maqsadli efemer jildlarning asosiy xususiyati yangi hajm manbai, EphemeralVolumeSource, hajm so'rovini yaratish uchun barcha maydonlarni o'z ichiga oladi (tarixiy ravishda doimiy hajm so'rovi, PVX deb ataladi). Yangi kontroller kube-controller-manager bunday hajm manbasini yaratadigan podkalarga qaraydi va keyin bu podlar uchun PVX yaratadi. CSI drayveri uchun bu so'rov boshqalar bilan bir xil ko'rinadi, shuning uchun bu erda hech qanday maxsus yordam kerak emas.
Bunday PVXlar mavjud ekan, ular hajmdagi boshqa so'rovlar kabi ishlatilishi mumkin. Xususan, jilddan nusxa ko'chirish yoki jilddan suratni yaratishda ularga ma'lumot manbai sifatida murojaat qilish mumkin. PVX ob'ekti hajmining joriy holatini ham o'z ichiga oladi.
Avtomatik ravishda yaratilgan PVX nomlari oldindan belgilangan: ular pod nomi va jild nomining kombinatsiyasi bo'lib, chiziq bilan ajratilgan. Oldindan belgilangan nomlar PVX bilan ishlashni osonlashtiradi, chunki pod nomi va jild nomini bilsangiz, uni izlashingiz shart emas. Salbiy tomoni shundaki, bu nom allaqachon ishlatilayotgan bo'lishi mumkin, bu Kubernetes tomonidan aniqlanadi va natijada podkastning ishga tushishi bloklanadi.
Ovoz podshok bilan birga o'chirilishini ta'minlash uchun kontroller egasi ostidagi ovoz balandligiga so'rov yuboradi. Pod o'chirilganda, standart axlat yig'ish mexanizmi ishlaydi, bu so'rovni ham, ovoz balandligini ham o'chiradi.
So'rovlar saqlash drayveri tomonidan saqlash sinfining oddiy mexanizmi orqali mos keladi. Darhol va kech bog'langan sinflar (aka WaitForFirstConsumer) qo'llab-quvvatlanadi, vaqtinchalik hajmlar uchun undan foydalanish mantiqiy WaitForFirstConsumer, keyin rejalashtiruvchi tugunni tanlashda tugunlardan foydalanish va saqlash mavjudligini hisobga olishi mumkin. Bu yerda yangi xususiyat paydo bo'ladi.
Saqlash hajmini kuzatish
Odatda rejalashtiruvchi CSI drayveri tovushni qayerda yaratishi haqida hech qanday ma'lumotga ega emas. Shuningdek, rejalashtiruvchining ushbu ma'lumotni so'rash uchun haydovchi bilan bevosita bog'lanishining imkoni yo'q. Shuning uchun, rejalashtiruvchi jildlarga kirish mumkin bo'lgan birini topmaguncha (kechik bog'lanish) yoki joyni tanlashni to'liq haydovchiga qoldiradi (darhol bog'lash) tugunlarni so'raydi.
Yangi CSIStorageCapacity, alfa bosqichida bo'lgan, kerakli ma'lumotlarni etcd da saqlashga imkon beradi, shunda ular rejalashtiruvchiga mavjud bo'ladi. Umumiy maqsadli vaqtinchalik hajmlarni qo'llab-quvvatlashdan farqli o'laroq, drayverni o'rnatganingizda, saqlash hajmini kuzatishni yoqishingiz kerak: external-provisioner haydovchidan olingan sig'im to'g'risidagi ma'lumotni oddiy orqali nashr etishi kerak GetCapacity.
Agar rejalashtiruvchi kechiktirilgan bog'lanishdan foydalanadigan ajratilmagan hajmli pod uchun tugunni tanlashi kerak bo'lsa va haydovchi bayroqni o'rnatish orqali tarqatish paytida ushbu xususiyatni yoqgan bo'lsa CSIDriver.storageCapacity, keyin etarli saqlash hajmiga ega bo'lmagan tugunlar avtomatik ravishda o'chiriladi. Bu umumiy maqsadli vaqtinchalik va doimiy hajmlar uchun ishlaydi, lekin CSI efemer jildlari uchun emas, chunki ularning parametrlarini Kubernetes o'qiy olmaydi.
Odatdagidek, darhol bog'langan hajmlar podkastlar rejalashtirilishidan oldin yaratiladi va ularning joylashuvi saqlash drayveri tomonidan tanlanadi, shuning uchun sozlash paytida external-provisioner Odatiy bo'lib, darhol bog'langan saqlash sinflari o'tkazib yuboriladi, chunki bu ma'lumotlar baribir ishlatilmaydi.
Kubernetes rejalashtiruvchisi potentsial eskirgan ma'lumotlar bilan ishlashga majbur bo'lganligi sababli, hajm yaratilganda har bir holatda sig'im mavjud bo'lishiga kafolat yo'q, lekin uni qayta urinishlarsiz yaratish imkoniyati baribir ortadi.
NB Siz batafsilroq ma'lumot olishingiz, shuningdek, xavfsiz tarzda "mushuklar stendida mashq qilishingiz" mumkin va umuman tushunarsiz vaziyat yuzaga kelganda, intensiv kurslarda malakali texnik yordam olishingiz mumkin - 28-30 sentabr kunlari bo‘lib o‘tadi va ilg‘or mutaxassislar uchun 14–16 oktyabr.
Xavfsizlik
CSIStorageCapacity
CSIStorageCapacity ob'ektlari nomlar bo'shliqlarida joylashgan; har bir CSI drayverini o'z nomlar maydoniga chiqarayotganda, RBAC huquqlarini ushbu bo'shliqda CSIStorageCapacity uchun cheklash tavsiya etiladi, chunki ma'lumotlar qaerdan kelgani aniq. Kubernetes buni baribir tekshirmaydi va odatda drayverlar bir xil nomlar maydoniga joylashtiriladi, shuning uchun oxir-oqibat drayverlar ishlashi va noto'g'ri ma'lumotlarni nashr etmasligi kutiladi (va bu erda mening kartam muvaffaqiyatsiz tugadi, taxminan. soqolli hazilga asoslangan tarjimon)
Umumiy maqsadli efemer hajmlar
Agar foydalanuvchilar pod (to'g'ridan-to'g'ri yoki bilvosita) yaratish huquqiga ega bo'lsa, ular jildda so'rov yaratish huquqiga ega bo'lmasa ham, umumiy maqsadli efemer jildlarni yaratishi mumkin. Buning sababi, RBAC ruxsati tekshiruvlari foydalanuvchiga emas, balki PVXni yaratuvchi boshqaruvchiga qo'llaniladi. Bu qo'shilishi kerak bo'lgan asosiy o'zgarish , ishonchsiz foydalanuvchilar jild yaratish huquqiga ega bo'lmasligi kerak bo'lgan klasterlarda ushbu xususiyatni yoqishdan oldin.
misol
Alohida PMEM-CSI alfa bosqichidagi barcha xususiyatlarga ega QEMU virtual mashinalarida Kubernetes 1.19 klasterini ishga tushirish uchun barcha kerakli o'zgarishlarni o'z ichiga oladi. Haydovchi kodi o'zgarmadi, faqat tarqatish o'zgardi.
Tegishli mashinada (Linux, oddiy foydalanuvchi foydalanishi mumkin , qarang tafsilotlar) ushbu buyruqlar klasterni ochadi va PMEM-CSI drayverini o'rnatadi:
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
Har bir narsa ishlagandan so'ng, chiqishda foydalanish bo'yicha ko'rsatmalar mavjud:
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 ob'ektlari odamlar tomonidan o'qish uchun mo'ljallanmagan, shuning uchun ba'zi ishlov berish talab etiladi. Golang shablon filtrlari saqlash sinflarini ko'rsatadi, bu misol nom, topologiya va sig'imni ko'rsatadi:
$ 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
Bitta ob'ekt quyidagi tarkibga ega:
$ 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>
Keling, bitta umumiy maqsadli vaqtinchalik hajmli demo ilovani yaratishga harakat qilaylik. Fayl tarkibi 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
Yaratgandan so'ng, yuqoridagi ko'rsatmalarda ko'rsatilganidek, endi bizda qo'shimcha pod va PVX mavjud:
$ 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
PVX egasi - ostida:
$ 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
...
uchun kutilayotgan yangilangan ma'lumotlar 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
Agar boshqa dasturga 26620Mi dan ortiq kerak bo'lsa, rejalashtiruvchi hisobga olmaydi pmem-csi-pmem-govm-worker1 har qanday holatda ham.
Keyin nima?
Har ikkala xususiyat ham ishlab chiqilmoqda. Alfa testi davomida bir nechta ilovalar ochildi. Takomillashtirish bo'yicha taklif havolalari beta-bosqichga o'tish uchun bajarilishi kerak bo'lgan ishlarni hujjatlashtiradi, shuningdek, qaysi alternativlar allaqachon ko'rib chiqilgan va rad etilgan:
Manba: www.habr.com