Mwisho wa Mei ilifanya mkutano mtandaoni juu ya mada hiyo . Tulizungumza juu ya vyombo, Kubernetes na orchestration kimsingi, vigezo vya kuchagua miundombinu na mengi zaidi. Washiriki walishiriki kesi kutoka kwa mazoezi yao wenyewe.
Washiriki:
- Evgeniy Potapov, Mkurugenzi Mtendaji wa ITSumma. Zaidi ya nusu ya wateja wake tayari wanahama au wanataka kuhamia Kubernetes.
- Dmitry Stolyarov, CTO "Flant". Ana uzoefu wa miaka 10+ kufanya kazi na mifumo ya kontena.
- Denis Remchukov (aka Eric Oldmann), COO argotech.io, aliyekuwa RAO UES. Aliahidi kuzungumza juu ya kesi katika biashara ya "umwagaji damu".
- Andrey Fedorovsky, CTO "News360.com"Baada ya kununua kampuni na mchezaji mwingine, anawajibika kwa idadi ya miradi na miundombinu ya ML na AI.
- Ivan Kruglov, mhandisi wa mifumo, ex-Booking.com.Mtu yule yule ambaye alifanya mengi na Kubernetes kwa mikono yake mwenyewe.
Mada:
- Maarifa ya washiriki kuhusu vyombo na okestration (Docker, Kubernetes, n.k.); kile kilichojaribiwa kwa vitendo au kuchambuliwa.
- Uchunguzi: Kampuni inaunda mpango wa maendeleo ya miundombinu kwa miaka. Je, uamuzi unafanywaje kama kujenga (au kuhamisha miundombinu ya sasa) kwenye kontena na Kuber au la?
- Shida katika ulimwengu wa asili ya wingu, ni nini kinakosekana, wacha tufikirie nini kitatokea kesho.
Majadiliano ya kuvutia yalifuata, maoni ya washiriki yalikuwa tofauti sana na yalisababisha maoni mengi ambayo nataka kushiriki nawe. Kula , na hapa chini ni muhtasari wa majadiliano.
Je, Kubernetes tayari ni soko la kawaida au kubwa?
"Tuliifikia (Kubernetes. - Mh.) wakati hakuna mtu aliyejua kuihusu bado. Tulikuja kwake hata wakati hayupo. Tuliitaka hapo awali "- Dmitry Stolyarov
Picha kutoka Reddit.com
Miaka 5-10 iliyopita kulikuwa na idadi kubwa ya zana, na hapakuwa na kiwango kimoja. Kila baada ya miezi sita bidhaa mpya ilionekana, au hata zaidi ya moja. Kwanza Vagrant, halafu Chumvi, Chef, Puppet,... βna unajenga upya miundombinu yako kila baada ya miezi sita. Una wasimamizi watano ambao wanashughulika kila mara kuandika upya mipangilio,β anakumbuka Andrey Fedorovsky. Anaamini kwamba Docker na Kubernetes "wamejazana" wengine. Docker imekuwa kiwango katika miaka mitano iliyopita, Kubernetes katika miaka miwili iliyopita. Na ni nzuri kwa tasnia.
Dmitry Stolyarov na timu yake wanapenda Kuber. Walitaka chombo kama hicho kabla ya kuonekana, na wakaja nacho wakati hakuna mtu aliyejua juu yake. Hivi sasa, kwa sababu za urahisi, hawachukui mteja ikiwa wanaelewa kuwa hawatatekeleza Kubernetes pamoja naye. Wakati huo huo, kulingana na Dmitry, kampuni hiyo ina "hadithi nyingi za mafanikio kuhusu kurejesha urithi mbaya."
Kubernetes sio tu upangaji wa kontena, ni mfumo wa usimamizi wa usanidi na API iliyotengenezwa, sehemu ya mtandao, kusawazisha L3 na vidhibiti vya Ingress, ambayo inafanya iwe rahisi kudhibiti rasilimali, kiwango na muhtasari kutoka kwa tabaka za chini za miundombinu.
Kwa bahati mbaya, katika maisha yetu lazima tulipe kila kitu. Na ushuru huu ni mkubwa, haswa ikiwa tunazungumza juu ya mpito kwa Kubernetes ya kampuni iliyo na miundombinu iliyoendelea, kama Ivan Kruglov anavyoamini. Angeweza kufanya kazi kwa uhuru katika kampuni iliyo na miundombinu ya kitamaduni na Kuber. Jambo kuu ni kuelewa sifa za kampuni na soko. Lakini, kwa mfano, kwa Evgeny Potapov, ambaye angefanya jumla ya Kubernetes kwa chombo chochote cha orchestration ya chombo, swali kama hilo halitokei.
Evgeniy alichora mlinganisho na hali katika miaka ya 1990, wakati programu iliyoelekezwa kwa kitu ilionekana kama njia ya kupanga programu ngumu. Wakati huo, mjadala uliendelea na zana mpya zilionekana kusaidia OOP. Kisha microservices iliibuka kama njia ya kuondokana na dhana ya monolithic. Hii, ilisababisha kuibuka kwa makontena na zana za usimamizi wa makontena. "Nadhani hivi karibuni tutakuja wakati ambapo hakutakuwa na swali kuhusu ikiwa inafaa kuandika programu ndogo ya huduma ndogo, itaandikwa kama huduma ndogo kwa chaguo-msingi," anaamini. Vivyo hivyo, Docker na Kubernetes hatimaye watakuwa suluhisho la kawaida bila hitaji la chaguo.
Tatizo la hifadhidata zisizo na utaifa
Picha na
Siku hizi, kuna mapishi mengi ya kuendesha hifadhidata katika Kubernetes. Hata jinsi ya kutenganisha sehemu inayofanya kazi na diski ya I/O kutoka, kwa masharti, sehemu ya maombi ya hifadhidata. Inawezekana kwamba katika siku zijazo hifadhidata itabadilika sana hivi kwamba itawasilishwa kwenye sanduku, ambapo sehemu moja itapangwa kupitia Docker na Kubernetes, na katika sehemu nyingine ya miundombinu, kupitia programu tofauti, sehemu ya uhifadhi itatolewa. ? Besi zitabadilika kama bidhaa?
Maelezo haya ni sawa na usimamizi wa foleni, lakini mahitaji ya kuaminika na maingiliano ya habari katika hifadhidata za jadi ni ya juu zaidi, Andrey anaamini. Uwiano wa hit ya akiba katika hifadhidata za kawaida unabaki kuwa 99%. Ikiwa mfanyakazi huenda chini, mpya huzinduliwa, na cache "hu joto" kutoka mwanzo. Hadi kache itakapo joto, mfanyakazi hufanya kazi polepole, ambayo inamaanisha kuwa haiwezi kupakiwa na mzigo wa mtumiaji. Ingawa hakuna mzigo wa mtumiaji, kashe haitoi joto. Ni duara mbaya.
Dmitry kimsingi hakubaliani - akidi na kugawanyika hutatua tatizo. Lakini Andrey anasisitiza kuwa suluhisho haifai kwa kila mtu. Katika hali zingine, akidi inafaa, lakini inaweka mzigo wa ziada kwenye mtandao. Hifadhidata ya NoSQL haifai katika visa vyote.
Washiriki wa mkutano waligawanywa katika kambi mbili.
Denis na Andrey wanasema kuwa kila kitu kilichoandikwa kwa diski - hifadhidata na kadhalika - haiwezekani kufanya katika mfumo wa ikolojia wa Kuber. Haiwezekani kudumisha uadilifu na uthabiti wa data ya uzalishaji katika Kubernetes. Hiki ni kipengele cha msingi. Suluhisho: miundombinu ya mseto.
Hata hifadhidata asili za kisasa za wingu kama MongoDB na Cassandra, au foleni za ujumbe kama vile Kafka au RabbitMQ, zinahitaji hifadhi za data zinazoendelea nje ya Kubernetes.
Vitu vya Evgeniy: "Misingi huko Kubera ni jeraha la karibu la Urusi, au karibu na biashara, ambalo linahusishwa na ukweli kwamba hakuna Kupitishwa kwa Wingu nchini Urusi." Kampuni ndogo au za kati huko Magharibi ni Cloud. Hifadhidata za Amazon RDS ni rahisi kutumia kuliko kuchezea Kubernetes mwenyewe. Huko Urusi hutumia Kuber "juu ya msingi" na kuhamisha besi kwake wakati wanajaribu kuondoa zoo.
Dmitry pia hakukubaliana na taarifa kwamba hakuna hifadhidata inayoweza kuwekwa katika Kubernetes: "Msingi ni tofauti na msingi. Na ikiwa unasukuma hifadhidata kubwa ya uhusiano, basi kwa hali yoyote. Ikiwa unasukuma kitu kidogo na asili ya wingu, ambacho kimeandaliwa kiakili kwa maisha ya nusu-ephemeral, kila kitu kitakuwa sawa. Dmitry pia alisema kuwa zana za usimamizi wa hifadhidata haziko tayari kwa Docker au Kuber, kwa hivyo shida kubwa huibuka.
Ivan, kwa upande wake, ana hakika kwamba hata ikiwa tutatoka kwa dhana ya serikali na isiyo na serikali, mfumo wa ikolojia wa suluhisho la biashara huko Kubernetes bado haujawa tayari. Kwa Kuber, ni vigumu kudumisha mahitaji ya kisheria na udhibiti. Kwa mfano, haiwezekani kutoa suluhisho la utoaji wa utambulisho ambapo dhamana kali za utambulisho wa seva inahitajika, hadi kwenye maunzi ambayo yameingizwa kwenye seva. Eneo hili linaendelea, lakini hakuna suluhisho bado.
Washiriki hawakuweza kukubaliana, kwa hivyo hakuna hitimisho litakalotolewa katika sehemu hii. Wacha tutoe mifano michache ya vitendo.
Uchunguzi wa 1. Usalama wa mtandao wa "kidhibiti kikubwa" kilicho na besi nje ya Kubera
Katika kesi ya mfumo wa usalama wa mtandao ulioendelezwa, matumizi ya vyombo na orchestration hufanya iwezekanavyo kupigana na mashambulizi na kuingilia. Kwa mfano, katika kidhibiti kimoja cha mega, Denis na timu yake walitekeleza mchanganyiko wa orchestrator na huduma ya SIEM iliyofunzwa ambayo inachambua kumbukumbu kwa wakati halisi na kuamua mchakato wa mashambulizi, udukuzi au kushindwa. Katika tukio la shambulio, jaribio la kuweka kitu, au katika tukio la uvamizi wa virusi vya ransomware, ni, kwa njia ya orchestrator, huchukua vyombo na maombi kwa kasi zaidi kuliko kuambukizwa, au kwa kasi zaidi kuliko mashambulizi ya mshambuliaji.
Uchunguzi wa 2. Uhamishaji mdogo wa hifadhidata za Booking.com hadi Kubernetes
Katika Booking.com, hifadhidata kuu ni MySQL iliyo na urudiaji wa asynchronous - kuna bwana na safu nzima ya watumwa. Kufikia wakati Ivan aliondoka kwenye kampuni, mradi ulizinduliwa wa kuhamisha watumwa ambao wanaweza "kupigwa risasi" na uharibifu fulani.
Mbali na msingi kuu, kuna usakinishaji wa Cassandra na orchestration iliyoandikwa kibinafsi, ambayo iliandikwa hata kabla Kuber hajaingia kwenye mkondo. Hakuna matatizo katika suala hili, lakini inaendelea kwenye SSD za ndani. Hifadhi ya mbali, hata ndani ya kituo hicho cha data, haitumiwi kutokana na tatizo la latency ya juu.
Darasa la tatu la hifadhidata ni huduma ya utaftaji ya Booking.com, ambapo kila nodi ya huduma ni hifadhidata. Majaribio ya kuhamisha huduma ya utafutaji kwa Kuber imeshindwa, kwa sababu kila node ni 60-80 GB ya hifadhi ya ndani, ambayo ni vigumu "kuinua" na "joto".
Kama matokeo, injini ya utaftaji haikuhamishiwa Kubernetes, na Ivan hafikirii kuwa kutakuwa na majaribio mapya katika siku za usoni. Hifadhidata ya MySQL ilihamishwa kwa nusu: Watumwa tu, ambao hawaogopi "kupigwa risasi". Cassandra ametulia kikamilifu.
Uchaguzi wa miundombinu kama kazi bila suluhu ya jumla
Picha na
Wacha tuseme tuna kampuni mpya, au kampuni ambayo sehemu ya miundombinu imejengwa kwa njia ya zamani. Inaunda mpango wa maendeleo ya miundombinu kwa miaka. Je, uamuzi unafanywaje kama kujenga miundombinu kwenye makontena na Kuber au la?
Kampuni zinazopigania nanoseconds hazijumuishwi kwenye mjadala. Uhifadhi wa afya hulipa kwa suala la kuegemea, lakini bado kuna makampuni ambayo yanapaswa kuzingatia mbinu mpya.
Ivan: "Ningeanzisha kampuni kwenye wingu sasa, kwa sababu ni haraka," ingawa sio bei rahisi. Pamoja na maendeleo ya ubepari wa ubia, wanaoanza hawana shida kubwa na pesa, na kazi kuu ni kushinda soko.
Ivan ana maoni kwamba maendeleo ya miundombinu ya sasa ni kigezo cha uteuzi. Ikiwa kulikuwa na uwekezaji mkubwa katika siku za nyuma, na inafanya kazi, basi hakuna maana ya kuifanya tena. Ikiwa miundombinu haijatengenezwa, na kuna matatizo na zana, usalama na ufuatiliaji, basi ni mantiki kuangalia miundombinu iliyosambazwa.
Kodi italazimika kulipwa kwa hali yoyote, na Ivan angelipa ile iliyomruhusu kulipa kidogo katika siku zijazo. "Kwa sababu tu kwa sababu ninapanda treni ambayo wengine wanasonga, nitasafiri mbali zaidi kuliko nikikaa kwenye gari-moshi lingine, ambalo ni lazima nijitie mafuta."anasema Ivan. Wakati kampuni ni mpya, na mahitaji ya latency ni makumi ya milliseconds, basi Ivan angeangalia kwa "waendeshaji" ambao hifadhidata za classical "zimefungwa" leo. Wanainua mnyororo wa kuiga, ambao hujibadilisha yenyewe ikiwa itashindwa, nk ...
Kwa kampuni ndogo iliyo na seva kadhaa, Kubera haina maana,β anasema Andrey. Lakini ikiwa inapanga kukua hadi mamia ya seva au zaidi, basi inahitaji otomatiki na mfumo wa usimamizi wa rasilimali. 90% ya kesi zinafaa gharama. Aidha, bila kujali kiwango cha mzigo na rasilimali. Inaleta maana kwa kila mtu, kuanzia kampuni zinazoanza hadi kampuni kubwa zilizo na hadhira ya mamilioni, kutazama hatua kwa hatua bidhaa za uandaaji wa makontena. "Ndio, hii ni siku zijazo," Andrey ana uhakika.
Denis alitaja vigezo kuu viwili - scalability na utulivu wa operesheni. Atachagua zana ambazo zinafaa zaidi kwa kazi hiyo. "Inaweza kuwa noname iliyokusanywa kwenye magoti yako, na ina Toleo la Jumuiya ya Nutanix juu yake. Hii inaweza kuwa safu ya pili katika mfumo wa maombi kwenye Kuber iliyo na hifadhidata kwenye sehemu ya nyuma, ambayo inakiliwa na imebainisha vigezo vya RTO na RPO" (malengo ya muda/ahamu - takriban.).
Evgeniy aligundua shida inayowezekana na wafanyikazi. Kwa sasa, hakuna wataalam wengi waliohitimu sana kwenye soko ambao wanaelewa "utumbo." Hakika, ikiwa teknolojia iliyochaguliwa ni ya zamani, basi ni vigumu kuajiri mtu yeyote isipokuwa watu wa umri wa kati ambao ni kuchoka na uchovu wa maisha. Ingawa washiriki wengine wanaamini kuwa hili ni suala la mafunzo ya wafanyikazi.
Ikiwa tutaweka swali la chaguo: kuzindua kampuni ndogo katika Wingu la Umma na hifadhidata katika Amazon RDS au "kwenye msingi" na hifadhidata huko Kubernetes, basi licha ya mapungufu kadhaa, Amazon RDS ikawa chaguo la washiriki.
Kwa kuwa wengi wa wasikilizaji wa mkutano huo sio kutoka kwa biashara ya "umwagaji damu", basi suluhu zilizosambazwa ndizo tunapaswa kujitahidi. Mifumo ya kuhifadhi data lazima isambazwe, itegemewe, na iunde muda wa kusubiri kupimwa katika vitengo vya milisekunde, makumi zaidi.", Andrey alisema kwa muhtasari.
Kutathmini Matumizi ya Kubernetes
Msikilizaji Anton Zhbankov aliuliza swali la mtego kwa waombaji msamaha wa Kubernetes: ulichaguaje na kufanya upembuzi yakinifu? Kwa nini Kubernetes, kwa nini si mashine pepe, kwa mfano?
Picha na
Dmitry na Ivan walijibu. Katika visa vyote viwili, kupitia majaribio na makosa, mlolongo wa maamuzi ulifanywa, kama matokeo ambayo washiriki wote walifika Kubernetes. Sasa biashara zinaanza kutengeneza programu kwa kujitegemea ambayo inaleta maana kuhamishia kwa Kuber. Hatuzungumzii juu ya mifumo ya kawaida ya wahusika wengine, kama vile 1C. Kubernetes husaidia wakati wasanidi wanahitaji kutoa matoleo kwa haraka, na Uboreshaji Unaoendelea bila kukoma.
Timu ya Andrey ilijaribu kuunda nguzo inayoweza kuenea kulingana na mashine pepe. Nodi zilianguka kama domino, ambayo wakati mwingine ilisababisha kuanguka kwa nguzo. "Kinadharia, unaweza kuimaliza na kuiunga mkono kwa mikono yako, lakini inachosha. Na ikiwa kuna suluhisho kwenye soko ambalo hukuruhusu kufanya kazi nje ya boksi, basi tunafurahi kuishughulikia. Na tukabadilika kama matokeo, "anasema Andrey.
Kuna viwango vya uchambuzi na hesabu kama hizo, lakini hakuna mtu anayeweza kusema jinsi zilivyo sahihi kwenye vifaa halisi vinavyofanya kazi. Kwa mahesabu, ni muhimu pia kuelewa kila chombo na mazingira, lakini hii haiwezekani.
Nini kinatungoja
Picha na
Kadiri teknolojia inavyoendelea, vipande vingi zaidi na zaidi vinavyotofautiana vinaonekana, na kisha mabadiliko ya awamu hutokea, muuzaji anaonekana ambaye ameua unga wa kutosha ili kila kitu kiwe pamoja katika chombo kimoja.
Unafikiri kutakuja wakati ambapo kutakuwa na chombo kama Ubuntu kwa ulimwengu wa Linux? Labda chombo kimoja cha chombo na ochestration kitajumuisha Kuber. Itafanya iwe rahisi kujenga mawingu kwenye msingi.
Jibu lilitolewa na Ivan: "Google sasa inaunda Anthos - hii ni toleo lao lililowekwa kifurushi ambalo linatumia wingu na linajumuisha Kuber, Service Mesh, ufuatiliaji - vifaa vyote vinavyohitajika kwa huduma ndogo za nje." Tuko karibu katika siku zijazo."
Denis pia alitaja Nutanix na VMWare na bidhaa ya vRealize Suite, ambayo inaweza kukabiliana na kazi kama hiyo bila uwekaji wa vyombo.
Dmitry alishiriki maoni yake kwamba kupunguza "maumivu" na kupunguza kodi ni maeneo mawili ambayo tunaweza kutarajia maboresho.
Kwa muhtasari wa majadiliano, tunaangazia shida zifuatazo za miundombinu ya kisasa:
- Washiriki watatu mara moja waligundua shida na hali.
- Maswala anuwai ya usaidizi wa usalama, pamoja na uwezekano kwamba Docker itaishia na matoleo mengi ya Python, seva za programu, na vifaa.
Overspending, ambayo ni bora kujadiliwa katika mkutano tofauti.
Changamoto ya kujifunza kama okestration ni mfumo tata wa ikolojia.
Tatizo la kawaida katika tasnia ni matumizi mabaya ya zana.Hitimisho zingine ni juu yako. Bado kuna hisia kwamba si rahisi kwa mchanganyiko wa Docker+Kubernetes kuwa sehemu ya "kati" ya mfumo. Kwa mfano, mifumo ya uendeshaji imewekwa kwenye vifaa vya kwanza, ambayo haiwezi kusema juu ya vyombo na orchestration. Labda katika siku zijazo, mifumo ya uendeshaji na vyombo vitaunganishwa na programu ya usimamizi wa wingu.
Picha naNapenda kuchukua nafasi hii kumsalimia mama yangu na kukukumbusha kuwa tuna kundi la Facebook , kituo na machapisho ya kuvutia kutoka kwa blogi mbalimbali za teknolojia. Na chaneli yangu , ambapo ninazungumza juu ya kusimamia maendeleo katika kampuni za bidhaa.
Chanzo: mapenzi.com