ProHoster > blog > Utawala > Kiasi cha Ephemeral na Ufuatiliaji wa Uwezo wa Hifadhi: EmptyDir kwenye Steroids
Kiasi cha Ephemeral na Ufuatiliaji wa Uwezo wa Hifadhi: EmptyDir kwenye Steroids
Programu zingine pia zinahitaji kuhifadhi data, lakini zinafaa kabisa na ukweli kwamba data haitahifadhiwa baada ya kuanza tena.
Kwa mfano, huduma za kuhifadhi zinadhibitiwa na RAM, lakini pia zinaweza kuhamisha data ambayo haitumiwi sana kuhifadhi ambayo ni ya polepole kuliko RAM, na athari ndogo kwa utendakazi wa jumla. Programu zingine zinahitaji kufahamu kuwa kunaweza kuwa na ingizo la kusoma tu katika faili, kama vile mipangilio au vitufe vya siri.
Kubernetes tayari ina aina kadhaa kiasi cha ephemeral, lakini utendakazi wao ni mdogo kwa kile kinachotekelezwa katika K8s.
Ephemeral Kiasi cha CSI iliruhusu Kubernetes kupanuliwa na viendeshaji vya CSI ili kutoa usaidizi kwa kiasi chepesi cha ndani. Kwa njia hii inawezekana kutumia miundo ya kiholela: mipangilio, siri, data ya kitambulisho, vigezo, na kadhalika. Viendeshi vya CSI lazima virekebishwe ili kuunga mkono kipengele hiki cha Kubernetes, kwani inadhaniwa kuwa viendeshi vya kawaida vya kawaida havitafanya kazi - lakini inachukuliwa kuwa kiasi kama hicho kinaweza kutumika kwenye nodi yoyote iliyochaguliwa kwa pod.
Hili linaweza kuwa tatizo kwa majuzuu ambayo yanatumia rasilimali kubwa za seva pangishi au kwa hifadhi ambayo inapatikana tu kwenye baadhi ya wapangishi. Ndiyo maana Kubernetes 1.19 inatanguliza vipengele viwili vipya vya upimaji wa alpha ambavyo kimawazo vinafanana na juzuu za EmptyDir:
madhumuni ya jumla ephemeral kiasi;
Ufuatiliaji wa uwezo wa kuhifadhi wa CSI.
Manufaa ya mbinu mpya:
hifadhi inaweza kuwa ya ndani au kushikamana kupitia mtandao;
juzuu zinaweza kuwa na saizi maalum ambayo haiwezi kuzidishwa na programu;
inafanya kazi na viendeshaji vyovyote vya CSI vinavyosaidia utoaji wa kiasi kinachoendelea na (kusaidia ufuatiliaji wa uwezo) kutekeleza wito GetCapacity;
kiasi kinaweza kuwa na data ya awali kulingana na dereva na mipangilio;
shughuli zote za kawaida na kiasi (kuunda snapshot, kurekebisha ukubwa, nk) zinasaidiwa;
juzuu zinaweza kutumika na kidhibiti chochote cha programu ambacho kinakubali moduli au vipimo vya sauti;
Kipanga ratiba cha Kubernetes huchagua nodi zinazofaa kivyake, kwa hivyo hakuna haja tena ya kutoa na kusanidi viendelezi vya kipanga ratiba au kurekebisha vijiti vya wavuti.
Chaguzi za maombi
Kwa hivyo, viwango vya jumla vya ephemeral vinafaa kwa kesi zifuatazo za utumiaji:
Kumbukumbu inayoendelea kama mbadala wa RAM kwa memcached
Matoleo ya hivi punde ya memcached aliongeza msaada kutumia kumbukumbu inayoendelea (Intel Optane, nk., takriban. mfasiri) badala ya RAM ya kawaida. Wakati wa kupeleka memcached kupitia kidhibiti cha programu, unaweza kutumia juzuu za madhumuni ya jumla za muda mfupi kuomba kwamba kiasi cha saizi fulani igawiwe kutoka kwa PMEM kwa kutumia kiendeshi cha CSI, kwa mfano. PMEM-CSI.
Hifadhi ya ndani ya LVM kama nafasi ya kazi
Programu zinazofanya kazi na data ambayo ni kubwa kuliko RAM zinaweza kuhitaji hifadhi ya ndani yenye ukubwa au vipimo vya utendakazi ambavyo juzuu za kawaida za Kubernetes EmptyDir haziwezi kutoa. Kwa mfano, kwa kusudi hili iliandikwa TopoLVM.
Ufikiaji wa kusoma pekee wa kiasi cha data
Ugawaji wa kiasi unaweza kusababisha kuundwa kwa kiasi kamili wakati:
Kiasi hiki kinaweza kupachikwa katika hali ya kusoma tu.
Jinsi gani kazi hii
Madhumuni ya Jumla Vitabu vya Ephemeral
Kipengele muhimu cha juzuu za ephemeral za madhumuni ya jumla ni chanzo kipya cha sauti, EphemeralVolumeSource, iliyo na nyanja zote za kuunda ombi la kiasi (kihistoria inaitwa ombi la sauti inayoendelea, PVC). Kidhibiti kipya ndani kube-controller-manager inaangalia maganda ambayo huunda chanzo cha kiasi kama hicho, na kisha huunda PVC kwa maganda hayo. Kwa dereva wa CSI, ombi hili linaonekana sawa na wengine, kwa hivyo hakuna msaada maalum unahitajika hapa.
Mradi PVC kama hizo zipo, zinaweza kutumika kama maombi mengine yoyote kwenye sauti. Hasa, zinaweza kurejelewa kama chanzo cha data wakati wa kunakili sauti au kuunda muhtasari kutoka kwa sauti. Kitu cha PVC pia kina hali ya sasa ya kiasi.
Majina ya PVC zilizoundwa kiotomatiki yamefafanuliwa awali: ni mchanganyiko wa jina la ganda na jina la sauti, ikitenganishwa na hyphen. Majina yaliyoainishwa hurahisisha kuingiliana na PVC kwa sababu sio lazima utafute ikiwa unajua jina la ganda na jina la sauti. Ubaya ni kwamba jina linaweza kuwa tayari linatumika, ambalo linagunduliwa na Kubernetes na kwa sababu hiyo ganda limezuiwa kuanza.
Ili kuhakikisha kwamba kiasi kinafutwa pamoja na pod, mtawala hufanya ombi kwa kiasi chini ya mmiliki. Wakati pod inafutwa, utaratibu wa kawaida wa kukusanya takataka hufanya kazi, ambayo hufuta ombi na kiasi.
Maombi yanalinganishwa na dereva wa uhifadhi kupitia utaratibu wa kawaida wa darasa la uhifadhi. Ingawa madarasa yenye kufungwa kwa haraka na kuchelewa (aka WaitForFirstConsumer) zinaungwa mkono, kwa juzuu za ephemeral inaeleweka kutumia WaitForFirstConsumer, basi kipanga ratiba kinaweza kuzingatia matumizi ya nodi zote mbili na upatikanaji wa hifadhi wakati wa kuchagua nodi. Kipengele kipya kinaonekana hapa.
Ufuatiliaji wa Uwezo wa Hifadhi
Kwa kawaida kipanga ratiba hajui ni wapi kiendeshi cha CSI kitaunda sauti. Pia hakuna njia kwa mpanga ratiba kuwasiliana na dereva moja kwa moja ili kuomba maelezo haya. Kwa hiyo, mratibu hupiga kura hadi apate moja ambayo kiasi kinaweza kupatikana (kuchelewa kwa kisheria) au kuacha uchaguzi wa eneo kabisa kwa dereva (kumfunga mara moja).
Mpya APICSIStorageCapacity, ambayo iko katika hatua ya alpha, huruhusu data muhimu kuhifadhiwa katika etcd ili ipatikane kwa kipanga ratiba. Tofauti na usaidizi wa kiasi cha ephemeral cha madhumuni ya jumla, unapopeleka kiendeshaji, lazima uwashe ufuatiliaji wa uwezo wa kuhifadhi: external-provisioner inapaswa kuchapisha habari ya uwezo iliyopokelewa kutoka kwa dereva kupitia kawaida GetCapacity.
Iwapo kipanga ratiba kinahitaji kuchagua nodi ya ganda la sauti isiyofungwa ambayo hutumia kufunga kwa kuchelewa, na dereva akawasha kipengele hiki wakati wa kupeleka kwa kuweka bendera. CSIDriver.storageCapacity, kisha nodi ambazo hazina uwezo wa kutosha wa kuhifadhi zitatupwa kiotomatiki. Hii inafanya kazi kwa madhumuni ya jumla ya juzuu za ephemeral na zinazoendelea, lakini si kwa juzuu za ephemeral za CSI kwa sababu vigezo vyake haviwezi kusomwa na Kubernetes.
Kama kawaida, kiasi kilichounganishwa mara moja huundwa kabla ya ganda kupangwa, na uwekaji wao huchaguliwa na dereva wa uhifadhi, kwa hivyo wakati wa kusanidi. external-provisioner Kwa chaguo-msingi, madarasa ya uhifadhi yenye kufungwa mara moja yanarukwa, kwa kuwa data hii haitatumika hata hivyo.
Kwa kuwa kipanga ratiba cha kubernetes kinalazimishwa kufanya kazi na taarifa zinazoweza kuwa za muda, hakuna hakikisho kwamba uwezo utapatikana katika kila hali wakati kiasi kinapoundwa, lakini nafasi ya kuunda bila majaribio tena huongezeka.
NB Unaweza kupata habari ya kina zaidi, na pia "fanya mazoezi kwa usalama kwenye msimamo wa paka", na katika hali isiyoeleweka kabisa, pata usaidizi wa kiufundi unaohitimu katika kozi kubwa - Msingi wa Kubernetes itafanyika Septemba 28-30, na kwa wataalamu wa hali ya juu zaidi Kubernetes Mega Oktoba 14-16.
usalama
Uwezo wa CSIStorage
Vitu vya CSIStorageCapacity hukaa katika nafasi za majina; wakati wa kusambaza kila kiendeshi cha CSI katika nafasi yake ya jina, inashauriwa kuzuia haki za RBAC kwa CIStorageCapacity katika nafasi hiyo kwani ni dhahiri data inatoka wapi. Kubernetes haangalii hii hata hivyo, na kawaida madereva huwekwa kwenye nafasi sawa ya majina, kwa hivyo mwishowe madereva wanatarajiwa kufanya kazi na sio kuchapisha data isiyo sahihi (na hapa ndipo kadi yangu ilishindwa, takriban. mfasiri kulingana na mzaha wa ndevu)
Madhumuni ya Jumla Vitabu vya Ephemeral
Ikiwa watumiaji wana haki ya kuunda pod (moja kwa moja au isiyo ya moja kwa moja), wataweza pia kuunda juzuu za ephemeral za madhumuni ya jumla hata kama hawana haki za kuunda ombi la sauti. Hii ni kwa sababu ukaguzi wa ruhusa wa RBAC unatumika kwa kidhibiti kinachounda PVC, si kwa mtumiaji. Hili ndilo badiliko kuu la kuongeza kwa akaunti yako, kabla ya kuwezesha kipengele hiki kwenye makundi ambapo watumiaji wasioaminika hawapaswi kuwa na haki za kuunda juzuu.
Mfano
Tenga tawi PMEM-CSI ina mabadiliko yote muhimu ili kuendesha kundi la Kubernetes 1.19 ndani ya mashine pepe za QEMU zenye vipengele vyote katika hatua ya alpha. Nambari ya dereva haijabadilika, uwekaji tu umebadilika.
Kwenye mashine inayofaa (Linux, mtumiaji wa kawaida anaweza kutumia Docker, tazama hapa maelezo) amri hizi zitaleta nguzo na kusakinisha kiendeshi cha 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
Baada ya kila kitu kufanya kazi, matokeo yatakuwa na maagizo ya matumizi:
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 -
CIStorageCapacity vitu si maana ya kusomwa na binadamu, hivyo baadhi ya usindikaji inahitajika. Vichungi vya violezo vya Golang vitaonyesha madarasa ya uhifadhi, mfano huu utaonyesha jina, topolojia na uwezo:
Wacha tujaribu kuunda ombi la onyesho lenye kusudi moja la jumla la sauti ya muda mfupi. Yaliyomo kwenye faili 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
Baada ya uundaji, kama inavyoonyeshwa katika maagizo hapo juu, sasa tunayo ganda la ziada na 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
Ikiwa programu nyingine inahitaji zaidi ya 26620Mi, kipanga ratiba hakitazingatia pmem-csi-pmem-govm-worker1 kwa vyovyote vile.
Nini hapo?
Vipengele vyote viwili bado vinatengenezwa. Programu nyingi zilifunguliwa wakati wa majaribio ya alpha. Pendekezo la uboreshaji huunganisha hati ya kazi inayohitaji kufanywa ili kuhamia hatua ya beta, na vile vile ni njia mbadala ambazo tayari zimezingatiwa na kukataliwa: