Hoy Habr!
Ipinapaalala namin sa iyo na naglabas kami ng isa pang lubhang kawili-wili at kapaki-pakinabang tungkol sa mga pattern ng Kubernetes. Nagsimula ang lahat sa "" Brendan Burns, at, sa pamamagitan ng paraan, mayroon kaming trabaho sa segment na ito . Ngayon, iniimbitahan ka naming magbasa ng isang artikulo mula sa MiniIO blog na maikling binabalangkas ang mga uso at mga detalye ng mga pattern ng pag-iimbak ng data sa Kubernetes.
Sa panimula, binago ng Kubernetes ang tradisyonal na pag-develop ng application at mga pattern ng deployment. Ngayon ang isang team ay maaaring bumuo, sumubok, at mag-deploy ng isang application sa loob ng ilang araw—sa maraming kapaligiran, lahat ay nasa mga cluster ng Kubernetes. Ang ganitong gawain sa mga nakaraang henerasyon ng teknolohiya ay karaniwang tumatagal ng mga linggo, kung hindi buwan.
Ang acceleration na ito ay ginawang posible sa pamamagitan ng abstraction na ibinigay ng Kubernetes - iyon ay, dahil ang Kubernetes mismo ay nakikipag-ugnayan sa mababang antas ng mga detalye ng pisikal o virtual machine, na nagpapahintulot sa mga user na ideklara ang gustong processor, ang gustong dami ng memory, at ang bilang ng container. mga pagkakataon, bukod sa iba pang mga parameter. Sa malaking komunidad na sumusuporta sa Kubernetes at patuloy na lumalawak ang paggamit nito, ang Kubernetes ang nangunguna sa lahat ng container orchestration platform sa malawak na margin.
Habang lumalaki ang paggamit ng Kubernetes, lumalaki din ang kalituhan tungkol sa mga pattern ng storage nito..
Sa lahat ng nakikipagkumpitensya para sa isang piraso ng Kubernetes pie (ibig sabihin, imbakan ng data), pagdating sa pag-uusap tungkol sa pag-iimbak ng data, ang signal ay nalunod sa napakaraming ingay.
Ang Kubernetes ay naglalaman ng modernong modelo para sa pagbuo, pag-deploy, at pamamahala ng application. Ang modernong modelong ito ay nag-decouples ng data storage mula sa computation. Upang lubos na maunawaan ang detatsment sa konteksto ng Kubernetes, kailangan mo ring maunawaan kung ano ang stateful at stateless na mga application, at kung paano umaangkop ang data storage doon. Ito ay kung saan ang REST API na diskarte na ginagamit ng S3 ay may malinaw na mga pakinabang sa POSIX/CSI na diskarte ng iba pang mga solusyon.
Sa artikulong ito, pag-uusapan natin ang tungkol sa mga pattern ng pag-iimbak ng data sa Kubernetes at partikular na tatalakayin ang debate sa pagitan ng stateful at stateless na mga application upang mas maunawaan kung ano ang pagkakaiba sa pagitan ng mga ito at kung bakit ito mahalaga. Ang natitirang bahagi ng teksto ay titingnan ang mga application at ang kanilang mga pattern ng pag-iimbak ng data ayon sa pinakamahuhusay na kagawian para sa pagtatrabaho sa mga container at Kubernetes.
Mga Lalagyan na Walang Estado
Ang mga lalagyan ay likas na magaan at panandalian. Madali silang ihinto, alisin, o i-deploy sa ibang node - lahat sa loob ng ilang segundo. Sa isang malaking container orchestration system, ang mga naturang operasyon ay nangyayari sa lahat ng oras, at hindi napapansin ng mga user ang mga naturang pagbabago. Gayunpaman, ang mga paglipat ay posible lamang kung ang lalagyan ay walang anumang mga dependency sa node kung saan ito matatagpuan. Ang mga naturang lalagyan ay sinasabing gumagana walang estado.
Mga Stateful na Lalagyan
Kung ang isang container ay nag-iimbak ng data sa mga lokal na naka-attach na device (o sa isang block device), ang data store kung saan ito nakatira ay kailangang ilipat sa isang bagong node, kasama ang container mismo, kung sakaling mabigo. Mahalaga ito dahil kung hindi ay hindi gagana nang maayos ang application na tumatakbo sa container dahil kailangan nitong ma-access ang data na nakaimbak sa lokal na media. Ang mga naturang lalagyan ay sinasabing gumagana stateful.
Mula sa isang purong teknikal na pananaw, ang mga stateful na lalagyan ay maaari ding ilipat sa iba pang mga node. Karaniwan itong nakakamit gamit ang mga distributed file system o i-block ang network storage na naka-attach sa lahat ng node na tumatakbo sa mga container. Sa ganitong paraan, ina-access ng mga lalagyan ang mga volume para sa patuloy na pag-iimbak ng data, at ang impormasyon ay nakaimbak sa mga disk na matatagpuan sa buong network. Tatawagin ko ang pamamaraang ito "stateful container approach", at sa natitirang bahagi ng artikulo ay tatawagin ko ito para sa pagkakapareho.
Sa isang tipikal na stateful na diskarte sa container, ang lahat ng application pod ay naka-attach sa iisang distributed file system—isang uri ng shared storage kung saan naninirahan ang lahat ng data ng application. Bagama't posible ang ilang mga pagkakaiba-iba, ito ay isang mataas na antas na diskarte.
Ngayon tingnan natin kung bakit ang stateful container approach ay isang anti-pattern sa cloud-centric na mundo.
Cloud-native na disenyo ng application
Ayon sa kaugalian, ang mga application ay gumagamit ng mga database para sa structured storage ng impormasyon at mga lokal na disk o distributed file system kung saan ang lahat ng unstructured o kahit semi-structured na data ay itinapon. Habang dumarami ang dami ng hindi nakabalangkas na data, napagtanto ng mga developer na ang POSIX ay masyadong madaldal, may malaking overhead, at sa huli ay nakahadlang sa pagganap ng application kapag lumilipat sa tunay na malalaking sukat.
Ito ay pangunahing nag-ambag sa paglitaw ng isang bagong pamantayan para sa pag-iimbak ng data, iyon ay, cloud-based na imbakan, pangunahing gumagana batay sa REST API at pagpapalaya sa application mula sa mabigat na pagpapanatili ng isang lokal na imbakan ng data. Sa kasong ito, ang application ay epektibong napupunta sa stateless mode (dahil ang estado ay nasa malayong imbakan). Ang mga makabagong application ay binuo mula sa simula na nasa isip ang salik na ito. Bilang isang patakaran, ang anumang modernong application na nagpoproseso ng data ng isang uri o iba pa (mga log, metadata, blobs, atbp.) ay binuo ayon sa isang cloud-oriented na paradigm, kung saan ang estado ay inililipat sa isang software system na espesyal na nakatuon para sa imbakan nito.
Pinipilit ng stateful container approach ang buong paradigm na ito pabalik kung saan ito nagsimula!
Sa pamamagitan ng paggamit ng mga interface ng POSIX upang mag-imbak ng data, ang mga application ay nagpapatakbo na parang stateful, at dahil dito, umaalis sila sa pinakamahalagang prinsipyo ng cloud-centric na disenyo, iyon ay, ang kakayahang mag-iba-iba ang laki ng mga thread ng manggagawa sa aplikasyon depende sa papasok input.
Kung susuriing mabuti ang sitwasyong ito, nalaman namin na kapag pumipili ng data store, paulit-ulit tayong nahaharap sa dilemma ng POSIX vs. REST API, PERO sa karagdagang paglala ng mga problema sa POSIX dahil sa likas na katangian ng mga Kubernetes na kapaligiran. Sa partikular,
- Ang POSIX ay madaldal: Kinakailangan ng POSIX semantics na ang bawat operasyon ay maiugnay sa metadata at mga deskriptor ng file na makakatulong sa pagpapanatili ng estado ng operasyon. Nagreresulta ito sa mga makabuluhang gastos na walang tunay na halaga. Ang mga Object storage API, partikular ang S3 API, ay nag-aalis sa mga kinakailangang ito, na nagpapahintulot sa application na gumana at pagkatapos ay "kalimutan" ang tungkol sa tawag. Ang tugon mula sa sistema ng imbakan ay nagpapahiwatig kung ang aksyon ay matagumpay o hindi. Kung nabigo ito, maaaring subukang muli ng application.
- Mga paghihigpit sa network: Sa isang distributed system, ipinahihiwatig na maaaring maraming application ang sumusubok na magsulat ng data sa parehong naka-attach na media. Samakatuwid, hindi lamang makikipagkumpitensya ang mga application sa isa't isa para sa bandwidth ng paglilipat ng data (upang magpadala ng data sa media), ngunit ang storage system mismo ay makikipagkumpitensya para sa bandwidth na ito sa pamamagitan ng pagpapadala ng data sa mga pisikal na disk. Dahil sa pagiging madaldal ng POSIX, ang bilang ng mga tawag sa network ay tumataas nang maraming beses. Sa kabilang banda, ang S3 API ay nagbibigay ng malinaw na pagkakaiba sa pagitan ng mga tawag sa network sa pagitan ng mga nagmumula sa kliyente patungo sa server at sa mga nangyayari sa loob ng server.
- katiwasayan: Ang modelo ng seguridad ng POSIX ay idinisenyo para sa aktibong pakikilahok ng tao: ang mga administrator ay nagko-configure ng mga partikular na antas ng pag-access para sa bawat user o grupo. Ang paradigm na ito ay mahirap iangkop sa isang cloud-centric na mundo. Nakadepende ang mga modernong application sa mga modelo ng seguridad na nakabatay sa API, kung saan ang mga karapatan sa pag-access ay tinukoy bilang isang hanay ng mga patakaran, mga account ng serbisyo, pansamantalang kredensyal, atbp. ay inilalaan.
- Pamahalaan: Ang mga stateful na lalagyan ay may ilang overhead sa pamamahala. Pinag-uusapan natin ang tungkol sa pag-synchronize ng parallel na pag-access sa data, pagtiyak ng pagkakapare-pareho ng data, ang lahat ng ito ay nangangailangan ng maingat na pagsasaalang-alang kung aling mga pattern ng pag-access ng data ang gagamitin. Ang karagdagang software ay dapat na naka-install, sinusubaybayan, at na-configure, hindi pa banggitin ang karagdagang pagsisikap sa pag-unlad.
Interface ng Imbakan ng Data ng Container
Bagama't ang Container Storage Interface (CSI) ay naging malaking tulong sa paglaganap ng Kubernetes volume layer, na bahagyang nag-outsourcing nito sa mga third-party na nagtitinda ng storage, hindi rin ito sinasadyang nag-ambag sa paniniwala na ang stateful na diskarte sa container ay ang inirerekomendang paraan para sa pag-iimbak ng data sa Kubernetes.
Ang CSI ay binuo bilang isang pamantayan para sa pagbibigay ng arbitrary na block at mga file storage system sa mga legacy na application kapag tumatakbo sa Kubernetes. At, tulad ng ipinakita ng artikulong ito, ang tanging sitwasyon kung saan ang isang stateful na diskarte sa container (at ang CSI sa kasalukuyan nitong anyo) ay may katuturan ay kapag ang application mismo ay isang legacy system kung saan hindi posibleng magdagdag ng suporta para sa object storage API .
Mahalagang maunawaan na ang paggamit ng CSI sa kasalukuyang anyo nito, iyon ay, ang pag-mount ng mga volume kapag nagtatrabaho sa mga modernong application, makakatagpo kami ng humigit-kumulang sa parehong mga problema na lumitaw sa mga system kung saan ang pag-iimbak ng data ay nakaayos sa istilong POSIX.
Isang Mas Mabuting Diskarte
Sa kasong ito, mahalagang maunawaan na ang karamihan sa mga application ay hindi likas na idinisenyo para sa stateful o stateless na trabaho. Ang pag-uugali na ito ay nakasalalay sa pangkalahatang arkitektura ng system at ang mga partikular na pagpipilian sa disenyo na ginawa. Pag-usapan natin nang kaunti ang tungkol sa mga stateful application.
Sa prinsipyo, ang lahat ng data ng application ay maaaring nahahati sa maraming malawak na uri:
- Data ng log
- Data ng timestamp
- Data ng transaksyon
- Metadata
- Mga larawan ng lalagyan
- Blob (binary large object) data
Ang lahat ng mga uri ng data na ito ay napakahusay na sinusuportahan sa mga modernong platform ng imbakan, at mayroong ilang mga cloud-native na platform na iniakma upang maghatid ng data sa bawat isa sa mga partikular na format na ito. Halimbawa, ang data ng transaksyon at metadata ay maaaring manatili sa isang modernong cloud-native na database gaya ng CockroachDB, YugaByte, atbp. Ang mga imahe ng container o blob data ay maaaring maimbak sa isang docker registry batay sa MiniIO. Ang data ng timestamp ay maaaring maimbak sa isang database ng serye ng oras gaya ng InfluxDB, atbp. Hindi na kami magdedetalye tungkol sa bawat uri ng data at mga nauugnay na application dito, ngunit ang pangkalahatang ideya ay upang maiwasan ang patuloy na pag-iimbak ng data na umaasa sa lokal na pag-mount ng disk.
Bukod pa rito, kadalasan ay epektibong magbigay ng pansamantalang caching layer na nagsisilbing pansamantalang file store para sa mga application, ngunit hindi dapat umasa ang mga application sa layer na ito bilang pinagmulan ng katotohanan.
Stateful na imbakan ng application
Bagama't sa karamihan ng mga kaso, kapaki-pakinabang na panatilihing walang estado ang mga application, ang mga application na iyon na idinisenyo upang mag-imbak ng data - tulad ng mga database, object store, key-value store - ay dapat na stateful. Tingnan natin kung bakit naka-deploy ang mga application na ito sa Kubernetes. Kunin natin ang MiniIO bilang isang halimbawa, ngunit ang mga katulad na prinsipyo ay nalalapat sa anumang iba pang malaking cloud-native na sistema ng imbakan.
Ang mga cloud-native na application ay idinisenyo upang lubos na mapakinabangan ang flexibility na likas sa mga container. Nangangahulugan ito na hindi sila gumagawa ng mga pagpapalagay tungkol sa kapaligiran kung saan sila idi-deploy. Halimbawa, ang MiniIO ay gumagamit ng internal erasure coding na mekanismo para mabigyan ang system ng sapat na katatagan upang manatiling gumagana kahit na ang kalahati ng mga disk ay nabigo. Pinamamahalaan din ng MiniIO ang integridad at seguridad ng data gamit ang proprietary server-side hashing at encryption.
Para sa mga naturang cloud-centric na application, ang mga lokal na persistent volume (PV) ay pinaka-maginhawa bilang backup na storage. Ang lokal na PV ay nagbibigay ng kakayahang mag-imbak ng raw data, habang ang mga application na tumatakbo sa itaas ng mga PV na ito ay independiyenteng nangongolekta ng impormasyon upang sukatin ang data at pamahalaan ang lumalaking mga kinakailangan sa data.
Ang diskarte na ito ay mas simple at makabuluhang mas nasusukat kaysa sa mga CSI-based na PV, na nagpapakilala ng sarili nilang mga layer ng pamamahala ng data at redundancy sa system; ang punto ay ang mga layer na ito ay karaniwang sumasalungat sa mga application na idinisenyo upang maging stateful.
Isang malakas na paggalaw patungo sa pag-decoupling ng data mula sa mga kalkulasyon
Sa artikulong ito, napag-usapan namin kung paano muling ini-orient ang mga application upang gumana nang hindi nagse-save ng estado, o, sa madaling salita, ang pag-iimbak ng data ay nahiwalay mula sa pag-compute dito. Sa konklusyon, tingnan natin ang ilang tunay na halimbawa ng kalakaran na ito.
, isang kilalang data analytics platform, ay tradisyonal na naging stateful at na-deploy sa HDFS. Gayunpaman, habang ang Spark ay lumipat sa isang cloud-centric na mundo, ang platform ay lalong ginagamit nang walang estado gamit ang `s3a`. Gumagamit ang Spark ng s3a upang ilipat ang estado sa iba pang mga system, habang ang mga lalagyan ng Spark mismo ay gumagana nang ganap na walang estado. Iba pang mga pangunahing manlalaro ng negosyo sa larangan ng malaking data analytics, sa partikular, , , Gumagalaw din sila upang magtrabaho kasama ang paghihiwalay ng imbakan ng data at mga kalkulasyon sa kanila.
Ang mga katulad na pattern ay makikita rin sa iba pang malalaking analytical na platform, kabilang ang Presto, Tensorflow hanggang R, Jupyter. Sa pamamagitan ng pag-offload ng estado sa mga malayuang cloud storage system, nagiging mas madaling pamahalaan at sukatin ang iyong application. Bilang karagdagan, pinapadali nito ang portability ng application sa iba't ibang mga kapaligiran.
Pinagmulan: www.habr.com
