Sinubukan ng kumpanya ng URUS ang Kubernetes sa iba't ibang anyo: independiyenteng pag-deploy sa bare metal, sa Google Cloud, at pagkatapos ay inilipat ang platform nito sa Mail.ru Cloud Solutions (MCS) cloud. Isinalaysay ni Igor Shishkin kung paano sila pumili ng bagong cloud provider at kung paano nila nagawang lumipat dito sa loob ng dalawang oras (), senior system administrator sa URUS.
Ano ang ginagawa ng URUS?
Mayroong maraming mga paraan upang mapabuti ang kalidad ng kapaligiran sa lunsod, at isa sa mga ito ay upang gawin itong environment friendly. Ito mismo ang ginagawa ng URUS - kumpanya ng Smart Digital Services. Dito sila nagpapatupad ng mga solusyon na tumutulong sa mga negosyo na subaybayan ang mahahalagang tagapagpahiwatig ng kapaligiran at bawasan ang kanilang negatibong epekto sa kapaligiran. Kinokolekta ng mga sensor ang data sa komposisyon ng hangin, antas ng ingay at iba pang mga parameter, at pagkatapos ay ipadala ang mga ito sa pinag-isang platform ng URUS-Ekomon para sa pagsusuri at paggawa ng mga rekomendasyon.
Paano gumagana ang URUS mula sa loob
Ang karaniwang kliyente ng URUS ay isang kumpanyang matatagpuan sa o malapit sa isang lugar ng tirahan. Ito ay maaaring isang pabrika, daungan, railway depot o anumang iba pang pasilidad. Kung ang aming kliyente ay nakatanggap na ng babala, pinagmulta para sa polusyon sa kapaligiran, o gustong gumawa ng mas kaunting ingay, bawasan ang dami ng mga nakakapinsalang emisyon, siya ay lumapit sa amin, at nag-aalok na kami sa kanya ng isang handa na solusyon para sa pagsubaybay sa kapaligiran.
Ang graph ng pagsubaybay sa konsentrasyon ng H2S ay nagpapakita ng mga regular na emisyon sa gabi mula sa isang kalapit na planta
Ang mga device na ginagamit namin sa URUS ay naglalaman ng ilang sensor na nangongolekta ng impormasyon tungkol sa nilalaman ng ilang partikular na gas, antas ng ingay at iba pang data upang masuri ang sitwasyon sa kapaligiran. Ang eksaktong bilang ng mga sensor ay palaging tinutukoy ng partikular na gawain.
Depende sa mga detalye ng mga sukat, ang mga device na may mga sensor ay maaaring matatagpuan sa mga dingding ng mga gusali, poste at iba pang mga arbitrary na lugar. Ang bawat naturang device ay nangongolekta ng impormasyon, pinagsasama-sama ito at ipinapadala ito sa gateway ng pagtanggap ng data. Doon ay sine-save namin ang data para sa pangmatagalang imbakan at paunang iproseso ito para sa kasunod na pagsusuri. Ang pinakasimpleng halimbawa ng kung ano ang nakukuha natin bilang resulta ng pagsusuri ay ang air quality index, na kilala rin bilang AQI.
Kasabay nito, maraming iba pang mga serbisyo ang gumagana sa aming platform, ngunit ang mga ito ay pangunahing katangian ng serbisyo. Halimbawa, ang serbisyo ng notification ay nagpapadala ng mga abiso sa mga kliyente kung ang alinman sa mga sinusubaybayang parameter (halimbawa, nilalaman ng CO2) ay lumampas sa pinahihintulutang halaga.
Paano kami nag-iimbak ng data. Ang kwento ng Kubernetes sa bare metal
Ang URUS environmental monitoring project ay may ilang data warehouse. Sa isa ay pinapanatili namin ang "raw" na data - kung ano ang natanggap namin nang direkta mula sa mga device mismo. Ang storage na ito ay isang "magnetic" tape, tulad ng sa mga lumang cassette tape, na may kasaysayan ng lahat ng indicator. Ang pangalawang uri ng storage ay ginagamit para sa preprocessed na data - data mula sa mga device, na pinayaman ng metadata tungkol sa mga koneksyon sa pagitan ng mga sensor at ang pagbabasa mismo ng mga device, kaugnayan sa mga organisasyon, lokasyon, atbp. Nagbibigay-daan sa iyo ang impormasyong ito na dynamic na masuri kung paano mayroon ang isang partikular na indicator. nagbago sa isang tiyak na yugto ng panahon. Ginagamit namin ang "raw" na imbakan ng data, bukod sa iba pang mga bagay, bilang isang backup at para sa pagpapanumbalik ng na-preprocess na data, kung may ganoong pangangailangan.
Noong naghahanap kami upang malutas ang aming problema sa imbakan ilang taon na ang nakalipas, mayroon kaming dalawang pagpipilian sa platform: Kubernetes at OpenStack. Ngunit dahil ang huli ay mukhang napakapangit (tingnan lamang ang arkitektura nito upang kumbinsihin ito), kami ay nanirahan sa Kubernetes. Ang isa pang argumento sa pabor nito ay ang relatibong simpleng kontrol ng software, ang kakayahang mas flexible na i-cut kahit na ang mga node ng hardware ayon sa mga mapagkukunan.
Kasabay ng pag-master ng Kubernetes mismo, pinag-aralan din namin ang mga paraan upang mag-imbak ng data, habang pinapanatili namin ang lahat ng aming storage sa Kubernetes sa aming sariling hardware, nakatanggap kami ng mahusay na kadalubhasaan. Lahat ng mayroon kami noon ay nabuhay sa Kubernetes: statefull storage, monitoring system, CI/CD. Ang Kubernetes ay naging isang all-in-one na platform para sa amin.
Ngunit gusto naming makipagtulungan sa Kubernetes bilang isang serbisyo, at hindi makisali sa suporta at pagpapaunlad nito. Dagdag pa, hindi namin nagustuhan kung magkano ang gastos namin sa pagpapanatili nito sa hubad na metal, at kailangan namin ng patuloy na pag-unlad! Halimbawa, ang isa sa mga unang gawain ay ang pagsamahin ang mga controller ng Kubernetes Ingress sa imprastraktura ng network ng aming organisasyon. Ito ay isang masalimuot na gawain, lalo na kung isasaalang-alang na sa oras na iyon ay walang handa para sa pamamahala ng mapagkukunang programmatic tulad ng mga tala ng DNS o ang paglalaan ng mga IP address. Nang maglaon, nagsimula kaming mag-eksperimento sa panlabas na imbakan ng data. Hindi namin kailanman nakuha ang pagpapatupad ng PVC controller, ngunit kahit na noon ay naging malinaw na ito ay isang malaking lugar ng trabaho na nangangailangan ng mga dedikadong espesyalista.
Ang paglipat sa Google Cloud Platform ay isang pansamantalang solusyon
Napagtanto namin na hindi ito maaaring magpatuloy, at inilipat ang aming data mula sa bare metal patungo sa Google Cloud Platform. Sa katunayan, sa oras na iyon ay walang maraming mga kagiliw-giliw na pagpipilian para sa isang kumpanyang Ruso: bukod sa Google Cloud Platform, ang Amazon lamang ang nag-aalok ng katulad na serbisyo, ngunit nakipag-ayos pa rin kami sa solusyon mula sa Google. Pagkatapos ay tila sa amin ay mas kumikita sa ekonomiya, mas malapit sa Upstream, hindi banggitin ang katotohanan na ang Google mismo ay isang uri ng PoC Kubernetes sa Produksyon.
Ang unang malaking problema ay lumitaw sa abot-tanaw habang ang aming customer base ay lumago. Noong kailangan naming mag-imbak ng personal na data, nahaharap kami sa isang pagpipilian: magtrabaho kami sa Google at lumabag sa mga batas ng Russia, o naghahanap kami ng alternatibo sa Russian Federation. Ang pagpili, sa kabuuan, ay predictable. π
Paano namin nakita ang perpektong serbisyo sa cloud
Sa simula ng paghahanap, alam na namin kung ano ang gusto naming makuha mula sa hinaharap na cloud provider. Anong serbisyo ang hinahanap namin:
- Mabilis at nababaluktot. Upang mabilis tayong magdagdag ng bagong node o mag-deploy ng isang bagay anumang oras.
- mura. Labis kaming nag-aalala tungkol sa isyu sa pananalapi, dahil limitado kami sa mga mapagkukunan. Alam na namin na gusto naming makipagtulungan sa Kubernetes, at ngayon ang gawain ay i-minimize ang gastos nito upang madagdagan o mapanatili ang kahusayan ng paggamit ng solusyon na ito.
- automated. Pinlano naming magtrabaho kasama ang serbisyo sa pamamagitan ng API, nang walang mga manager at tawag sa telepono o mga sitwasyon kung saan kailangan naming manu-manong itaas ang ilang dosenang node sa emergency mode. Dahil ang karamihan sa aming mga proseso ay awtomatiko, inaasahan namin ang parehong mula sa serbisyo ng cloud.
- Sa mga server sa Russian Federation. Siyempre, binalak naming sumunod sa batas ng Russia at sa parehong 152-FZ.
Noong panahong iyon, kakaunti ang mga provider ng Kubernetes aaS sa Russia, at kapag pumipili ng provider, mahalagang hindi namin ikompromiso ang aming mga priyoridad. Ang Mail.ru Cloud Solutions team, kung saan nagsimula kaming magtrabaho at nakikipagtulungan pa rin, ay nagbigay sa amin ng isang ganap na automated na serbisyo, na may suporta sa API at isang maginhawang control panel na kinabibilangan ng Horizon - kasama nito mabilis kaming makakataas ng arbitrary na bilang ng mga node.
Paano namin nagawang lumipat sa MCS sa loob ng dalawang oras
Sa ganitong mga paglipat, maraming mga kumpanya ang nahaharap sa mga paghihirap at pag-urong, ngunit sa aming kaso ay wala. Kami ay masuwerte: dahil nagtatrabaho na kami sa Kubernetes bago nagsimula ang paglipat, itinama lang namin ang tatlong file at inilunsad ang aming mga serbisyo sa bagong cloud platform, ang MCS. Hayaan mong ipaalala ko sa iyo na noong panahong iyon ay nakaalis na kami sa wakas at namuhay sa Google Cloud Platform. Samakatuwid, ang paglipat mismo ay tumagal ng hindi hihigit sa dalawang oras, kasama ang kaunting oras (mga isang oras) na ginugol sa pagkopya ng data mula sa aming mga device. Noon ay gumagamit na kami ng Spinnaker (isang multi-cloud na serbisyo ng CD para magbigay ng Continous Delivery). Mabilis din namin itong idinagdag sa bagong cluster at nagpatuloy na gumana gaya ng dati.
Salamat sa automation ng mga proseso ng pag-unlad at CI/CD, ang Kubernetes sa URUS ay pinangangasiwaan ng isang espesyalista (at ako iyon). Sa ilang yugto, ang isa pang tagapangasiwa ng system ay nakipagtulungan sa akin, ngunit pagkatapos ay naging awtomatiko na namin ang lahat ng pangunahing gawain at mayroong higit at higit pang mga gawain sa bahagi ng aming pangunahing produkto at makatuwiran na idirekta ang mga mapagkukunan dito.
Natanggap namin ang inaasahan namin mula sa cloud provider, dahil nagsimula kaming makipagtulungan nang walang ilusyon. Kung mayroong anumang mga insidente, ang mga ito ay halos teknikal at ang mga madaling maipaliwanag sa pamamagitan ng kamag-anak na pagiging bago ng serbisyo. Ang pangunahing bagay ay ang koponan ng MCS ay mabilis na nag-aalis ng mga pagkukulang at mabilis na tumugon sa mga tanong sa mga mensahero.
Kung ihahambing ko ang aking karanasan sa Google Cloud Platform, sa kanilang kaso ay hindi ko alam kung nasaan ang button ng feedback, dahil hindi naman ito kailangan. At kung may nangyaring mga problema, ang Google mismo ay nagpadala ng mga notification nang unilaterally. Ngunit sa kaso ng MCS, sa palagay ko ang malaking kalamangan ay ang mga ito ay mas malapit hangga't maaari sa mga kliyenteng Ruso - parehong heograpikal at mental.
Paano natin nakikita ang pagtatrabaho sa mga ulap sa hinaharap
Ngayon ang aming trabaho ay malapit na nauugnay sa Kubernetes, at ito ay ganap na nababagay sa amin mula sa punto ng view ng mga gawain sa imprastraktura. Samakatuwid, hindi namin pinaplano na lumipat mula dito kahit saan, bagama't patuloy kaming nagpapakilala ng mga bagong kasanayan at serbisyo upang pasimplehin ang mga nakagawiang gawain at i-automate ang mga bago, pataasin ang katatagan at pagiging maaasahan ng mga serbisyo... Inilulunsad namin ngayon ang serbisyo ng Chaos Monkey (partikular , gumagamit kami ng chaoskube, ngunit hindi nito binabago ang konsepto: ), na orihinal na nilikha ng Netflix. Isang simpleng bagay ang ginagawa ng Chaos Monkey: tinatanggal nito ang isang random na pod ng Kubernetes sa random na oras. Ito ay kinakailangan upang ang aming serbisyo ay mamuhay nang normal sa bilang ng mga pagkakataon nβ1, kaya sinasanay namin ang aming mga sarili na maging handa para sa anumang mga problema.
Ngayon ay nakikita ko na ang paggamit ng mga third-party na solusyon - ang parehong mga cloud platform - bilang ang tanging tamang bagay para sa mga batang kumpanya. Karaniwan, sa simula ng kanilang paglalakbay, sila ay limitado sa mga mapagkukunan, kapwa tao at pinansyal, at ang pagbuo at pagpapanatili ng kanilang sariling cloud o data center ay masyadong mahal at labor-intensive. Nagbibigay-daan sa iyo ang mga tagapagbigay ng cloud na bawasan ang mga gastos na ito; mabilis mong makukuha mula sa kanila ang mga mapagkukunang kinakailangan para sa pagpapatakbo ng mga serbisyo dito at ngayon, at bayaran ang mga mapagkukunang ito pagkatapos ng katotohanan. Para sa kumpanya ng URUS, mananatili kaming tapat sa Kubernetes sa cloud sa ngayon. Ngunit sino ang nakakaalam, maaaring kailanganin nating palawakin ang heograpiya, o ipatupad ang mga solusyon batay sa ilang partikular na kagamitan. O marahil ang dami ng mga mapagkukunang natupok ay magbibigay-katwiran sa sariling mga Kubernetes sa bare-metal, tulad ng noong unang panahon. π
Ang natutunan namin sa pagtatrabaho sa mga serbisyo ng cloud
Sinimulan naming gamitin ang Kubernetes sa bare metal, at kahit doon ay maganda ito sa sarili nitong paraan. Ngunit ang mga lakas nito ay eksaktong ipinahayag bilang isang bahagi ng aaS sa cloud. Kung magtatakda ka ng layunin at i-automate ang lahat hangga't maaari, maiiwasan mo ang pag-lock-in ng vendor at ang paglipat sa pagitan ng mga cloud provider ay tatagal ng ilang oras, at mananatili sa amin ang mga nerve cell. Maaari naming payuhan ang iba pang mga kumpanya: kung gusto mong maglunsad ng iyong sariling (cloud) na serbisyo, pagkakaroon ng limitadong mga mapagkukunan at maximum na bilis para sa pag-unlad, magsimula ngayon sa pamamagitan ng pagrenta ng mga mapagkukunan ng ulap, at bumuo ng iyong data center pagkatapos magsulat ng Forbes tungkol sa iyo.
Pinagmulan: www.habr.com