Kuhifadhi data katika kundi la Kubernetes

Kuna njia kadhaa za kusanidi uhifadhi wa data kwa programu zinazoendesha kwenye nguzo ya Kubernetes. Baadhi yao tayari wamepitwa na wakati, wengine walionekana hivi karibuni. Katika makala hii, tutaangalia dhana ya chaguo tatu za kuunganisha mifumo ya hifadhi, ikiwa ni pamoja na moja ya hivi karibuni - kuunganisha kupitia Kiolesura cha Uhifadhi wa Kontena.

Njia ya 1: Bainisha PV kwenye onyesho la ganda

Faili ya wazi ya kawaida inayoelezea ganda katika nguzo ya Kubernetes:

Sehemu za faili ya maelezo zinazoelezea ni sauti gani imeunganishwa na wapi imeangaziwa kwa rangi.

Katika sehemu kiasiMilima onyesha pointi za mlima (mountPath) - ambayo saraka ndani ya chombo kiasi cha kudumu kitawekwa, pamoja na jina la kiasi.

Katika sehemu x huorodhesha juzuu zote zinazotumika kwenye ganda. Taja jina la kila kiasi, pamoja na aina (kwa upande wetu: awsElasticBlockStore) na vigezo vya uunganisho. Ni vigezo gani vimeorodheshwa kwenye faili ya maelezo hutegemea aina ya sauti.

Kiasi sawa kinaweza kupachikwa wakati huo huo katika vyombo vingi vya pod. Kwa njia hii, michakato tofauti ya programu inaweza kufikia data sawa.

Njia hii ya uunganisho iligunduliwa mwanzoni kabisa, wakati Kubernetes ilikuwa katika utoto wake, na leo njia hiyo imepitwa na wakati.

Kuna shida kadhaa wakati wa kuitumia:

1. juzuu zote lazima ziundwe kwa mikono; Kubernetes haiwezi kuunda chochote kwa ajili yetu;
2. vigezo vya upatikanaji kwa kila kiasi ni cha pekee, na lazima zielezwe katika maonyesho ya pods zote zinazotumia kiasi;
3. ili kubadilisha mfumo wa hifadhi (kwa mfano, kuondoka kutoka AWS hadi Google Cloud), unahitaji kubadilisha mipangilio na aina ya kiasi kilichowekwa katika maonyesho yote.

Yote hii ni ngumu sana, kwa hivyo kwa kweli njia hii inatumika kuunganisha aina fulani tu za kiasi: configMap, siri, emptyDir, hostPath:

• configMap na siri ni viwango vya huduma vinavyokuruhusu kuunda kiasi na faili kutoka kwa maonyesho ya Kubernetes kwenye kontena.

• emptyDir ni kiasi cha muda, kilichoundwa tu kwa maisha ya pod. Rahisi kutumia kwa majaribio au kuhifadhi data ya muda. Wakati ganda limefutwa, sauti ya tupu yaDir pia inafutwa na data yote inapotea.

• hostPath - hukuruhusu kuweka saraka yoyote kwenye diski ya ndani ya seva ambayo programu inaendesha ndani ya chombo na programu, pamoja na /etc/kubernetes. Hiki ni kipengele kisicho salama, kwa hivyo sera za usalama kwa kawaida hukataza matumizi ya aina hii ya sauti. Vinginevyo, programu ya mshambulizi itaweza kupachika saraka ya HTC Kubernetes ndani ya kontena lake na kuiba vyeti vyote vya kundi. Kwa kawaida, juzuu za hostPath zinaruhusiwa tu kutumiwa na programu za mfumo zinazoendeshwa katika nafasi ya majina ya mfumo wa kube.

Mifumo ya hifadhi ambayo Kubernetes hufanya kazi nayo nje ya boksi hutolewa katika nyaraka.

Njia ya 2. Uunganisho kwa makao ya SC/PVC/PV

Njia mbadala ya uunganisho ni dhana ya darasa la Uhifadhi, PersistentVolumeClaim, PersistentVolume.

Darasa la uhifadhi huhifadhi vigezo vya uunganisho kwenye mfumo wa kuhifadhi data.

PersistentVolumeClaim inaelezea mahitaji ya ile ambayo programu inahitaji.
Kiwango cha Kudumu huhifadhi vigezo vya ufikiaji na hali ya kiasi.

Kiini cha wazo: katika ganda la maelezo zinaonyesha kiasi cha aina PersistentVolumeClaim na zinaonyesha jina la huluki hii katika kigezo cha claimName.

Faili ya maelezo ya PersistentVolumeClaim inaeleza mahitaji ya kiasi cha data ambayo programu inahitaji. Ikiwa ni pamoja na:

• saizi ya diski;
• njia ya kufikia: ReadWriteOnce au ReadWriteMany;
• kiungo kwa Darasa la Hifadhi - ambamo mfumo wa kuhifadhi data tunataka kuunda sauti.

Faili ya maelezo ya darasa la Hifadhi huhifadhi aina na vigezo vya muunganisho kwenye mfumo wa hifadhi. Cubelet inawahitaji ili kuweka kiasi kwenye nodi yake.

Onyesho la PersistentVolume linaonyesha darasa la Hifadhi na vigezo vya ufikiaji kwa kiasi maalum (kitambulisho cha sauti, njia, n.k.).

Wakati wa kuunda PVC, Kubernetes huangalia ni ukubwa gani na ni darasa gani la Hifadhi linahitajika, na kuchagua PersistentVolume isiyolipishwa.

Ikiwa PV kama hizo hazipatikani, Kubernetes inaweza kuzindua programu maalum - Mtoaji (jina lake limeonyeshwa kwenye darasa la Hifadhi). Mpango huu huunganishwa kwenye mfumo wa hifadhi, huunda kiasi cha ukubwa unaohitajika, hupokea kitambulisho na kuunda faili ya maelezo ya PersistentVolume katika nguzo ya Kubernetes, ambayo inahusishwa na PersistentVolumeClaim.

Seti hii yote ya vifupisho hukuruhusu kuondoa maelezo kuhusu mfumo gani wa hifadhi ambao programu inafanya kazi nao kutoka kwa kiwango cha faili ya maelezo ya programu hadi kiwango cha usimamizi.

Vigezo vyote vya kuunganisha kwenye mfumo wa kuhifadhi data ziko katika darasa la Hifadhi, ambalo wasimamizi wa nguzo wanajibika. Unachohitaji kufanya unapohama kutoka AWS hadi Google Cloud ni kubadilisha jina la darasa la Hifadhi hadi PVC katika maonyesho ya programu. Kiasi cha Kudumu cha kuhifadhi data kitaundwa katika kundi kiotomatiki kwa kutumia programu ya Mtoa Huduma.

Njia ya 3. Kiolesura cha Kuhifadhi Kontena

Msimbo wote unaoingiliana na mifumo mbalimbali ya hifadhi ni sehemu ya msingi wa Kubernetes. Utoaji wa marekebisho ya hitilafu au utendakazi mpya unahusishwa na matoleo mapya; lazima msimbo ubadilishwe kwa matoleo yote yanayotumika ya Kubernetes. Yote hii ni ngumu kudumisha na kuongeza utendaji mpya.

Ili kutatua tatizo hilo, watengenezaji kutoka Cloud Foundry, Kubernetes, Mesos na Docker waliunda Kiolesura cha Uhifadhi wa Kontena (CSI) - kiolesura rahisi kilichounganishwa kinachoelezea mwingiliano wa mfumo wa usimamizi wa kontena na kiendeshi maalum (CSI Driver) kinachofanya kazi na kifaa maalum. mfumo wa kuhifadhi. Msimbo wote wa mwingiliano na mifumo ya hifadhi ulihamishwa kutoka msingi wa Kubernetes hadi mfumo tofauti.

Nyaraka za Kiolesura cha Kuhifadhi Kontena.

Kwa kawaida, Dereva wa CSI huwa na vipengele viwili: Programu-jalizi ya Node na programu-jalizi ya Kidhibiti.

Programu-jalizi ya Node huendesha kila nodi na inawajibika kwa kuweka viwango na kufanya shughuli juu yao. Programu-jalizi ya Kidhibiti huingiliana na mfumo wa kuhifadhi: huunda au kufuta kiasi, hupeana haki za ufikiaji, nk.

Kwa sasa, madereva ya zamani yanabaki kwenye kernel ya Kubernetes, lakini haipendekezi tena kutumiwa na kila mtu anashauriwa kufunga Dereva ya CSI hasa kwa mfumo ambao watafanya kazi nao.

Ubunifu huo unaweza kuwatisha wale ambao tayari wamezoea kuweka uhifadhi wa data kupitia darasa la Uhifadhi, lakini kwa kweli hakuna kitu cha kutisha kilichotokea. Kwa waandaaji wa programu, hakuna kinachobadilika - wamefanya kazi tu na jina la Hifadhi ya darasa, na wataendelea kufanya hivyo. Kwa wasimamizi, usakinishaji wa chati ya usukani umeongezwa na muundo wa mipangilio umebadilika. Ikiwa hapo awali mipangilio iliingizwa moja kwa moja kwenye darasa la Uhifadhi, sasa lazima kwanza iwekwe kwenye chati ya usukani, na kisha kwenye darasa la Uhifadhi. Ukiiangalia, hakuna kitu kibaya kilichotokea.

Hebu tuchukue mfano ili tuangalie faida unazoweza kupata kwa kubadili kuunganisha mifumo ya hifadhi ya Ceph kwa kutumia kiendeshi cha CSI.

Wakati wa kufanya kazi na Ceph, programu-jalizi ya CSI hutoa chaguzi zaidi za kufanya kazi na mifumo ya uhifadhi kuliko viendeshi vilivyojengwa.

1. Uundaji wa diski yenye nguvu. Kwa kawaida diski za RBD hutumiwa tu katika hali ya RWO, lakini CSI ya Ceph inaziruhusu kutumika katika hali ya RWX. Maganda kadhaa kwenye nodi tofauti yanaweza kuweka diski sawa ya RDB kwenye nodi zao na kufanya kazi nayo sambamba. Ili kuwa sawa, sio kila kitu ni mkali - diski hii inaweza kuunganishwa tu kama kifaa cha kuzuia, ambayo inamaanisha itabidi ubadilishe programu kufanya kazi nayo katika hali nyingi za ufikiaji.
2. Kuunda snapshots. Katika kundi la Kubernetes, unaweza kuunda faili ya maelezo na hitaji la kuunda muhtasari. Programu-jalizi ya CSI itaiona na kuchukua taswira kutoka kwa diski. Kulingana nayo, unaweza kutengeneza nakala rudufu au nakala ya PersistentVolume.
3. Kuongeza ukubwa wa diski juu ya uhifadhi naVolume Persistent katika nguzo ya Kubernetes.
4. Nafasi. Viendeshi vya CephFS vilivyojengwa ndani ya Kubernetes hazitumii upendeleo, lakini programu-jalizi mpya za CSI zilizo na Ceph Nautilus ya hivi punde zinaweza kuwezesha upendeleo kwenye sehemu za CephFS.
5. Vipimo. Programu-jalizi ya CSI inaweza kumpa Prometheus aina mbalimbali za metriki kuhusu ni kiasi gani kimeunganishwa, ni mawasiliano gani yanayofanyika, n.k.
6. Topolojia kufahamu. Hukuruhusu kubainisha katika faili za maelezo jinsi nguzo hiyo inavyosambazwa kijiografia, na epuka kuunganisha mfumo wa hifadhi ulioko Amsterdam kwenye maganda yanayoendeshwa London.

Jinsi ya kuunganisha Ceph kwa nguzo ya Kubernetes kupitia CSI, ona katika sehemu ya vitendo ya hotuba ya shule ya jioni ya Slurm. Unaweza pia kujiandikisha kwa Kozi ya video ya Ceph, ambayo itazinduliwa tarehe 15 Oktoba.

Mwandishi wa makala: Sergey Bondarev, mbunifu anayefanya mazoezi huko Southbridge, Msimamizi Aliyethibitishwa wa Kubernetes, mmoja wa watengenezaji wa kubespray.

Andiko kidogo la Posta si la kutangaza, bali kwa manufaa...

PS Sergey Bondarev anaongoza kozi mbili za kina: zilizosasishwa Msingi wa Kubernetes Septemba 28-30 na ya juu Kubernetes Mega Oktoba 14-16.

Chanzo: mapenzi.com