Kwa kutarajia Vitaly Khabarov waliohojiwa Dmitry Stolyarov (), mkurugenzi wa ufundi na mwanzilishi mwenza wa kampuni ya Flant. Vitaly alimuuliza Dmitry kuhusu kile Flant hufanya, kuhusu Kubernetes, maendeleo ya mfumo wa ikolojia, msaada. Tulijadili kwa nini Kubernetes inahitajika na ikiwa inahitajika kabisa. Na pia kuhusu huduma ndogo ndogo, Amazon AWS, mbinu ya "Nitakuwa na bahati" kwa DevOps, mustakabali wa Kubernetes yenyewe, kwa nini, lini na jinsi gani itachukua ulimwengu, matarajio ya DevOps na wahandisi wanapaswa kujiandaa kwa nini mkali na wa karibu wa siku zijazo kwa kurahisisha na mitandao ya neva.
sikiliza kama podikasti kwenye DevOps Deflop - podikasti ya lugha ya Kirusi kuhusu DevOps, na hapa chini kuna toleo la maandishi.
Hapa na chini anauliza maswali mhandisi kutoka Express42.
Kuhusu "Flant"
- Habari Dima. Wewe ni mkurugenzi wa kiufundi"" na pia mwanzilishi wake. Tafadhali tuambie kampuni inafanya nini na uko ndani yake?
Dmitry: Kutoka nje inaonekana kama sisi ndio watu ambao tunazunguka kusakinisha Kubernetes kwa kila mtu na kufanya jambo nayo. Lakini hiyo si kweli. Tulianza kama kampuni inayoshughulika na Linux, lakini kwa muda mrefu sana shughuli yetu kuu imekuwa ikitoa miradi ya uzalishaji na upakiaji wa juu. Kawaida tunaunda miundombinu yote kutoka mwanzo na kisha tunawajibika kwa muda mrefu, mrefu. Kwa hivyo, kazi kuu ambayo "Flant" hufanya, ambayo inapokea pesa, ni kuwajibika na kutekeleza uzalishaji wa turnkey.
Mimi, kama mkurugenzi wa ufundi na mmoja wa waanzilishi wa kampuni, natumia mchana na usiku kujaribu kufikiria jinsi ya kuongeza ufikiaji wa uzalishaji, kurahisisha uendeshaji wake, kufanya maisha ya wasimamizi kuwa rahisi, na maisha ya watengenezaji yawe ya kupendeza zaidi. .
Kuhusu Kubernetes
- Hivi majuzi nimekuwa nikiona ripoti nyingi kutoka kwa Flant na Kuhusu Kubernetes Umefikaje hapo?
Dmitry: Tayari nimelizungumza hili mara nyingi, lakini sijali kulirudia hata kidogo. Nadhani ni sawa kurudia mada hii kwa sababu kuna mkanganyiko kati ya sababu na athari.
Kweli tulihitaji chombo. Tulikabiliwa na matatizo mengi, tulijitahidi, tukashinda kwa magongo mbalimbali na tulihisi haja ya chombo. Tulipitia chaguzi nyingi tofauti, tukajenga baiskeli zetu wenyewe, na tukapata uzoefu. Hatua kwa hatua tulifikia hatua ambayo tulianza kutumia Docker mara tu ilipoonekana - karibu 2013. Wakati wa kuonekana kwake, tayari tulikuwa na uzoefu mwingi na vyombo, tayari tulikuwa tumeandika analog ya "Docker" - baadhi ya magongo yetu huko Python. Pamoja na ujio wa Docker, iliwezekana kutupa magongo na kutumia suluhisho la kuaminika na linaloungwa mkono na jamii.
Na Kubernetes hadithi ni sawa. Kufikia wakati ilipoanza kupata kasi - kwetu hili ni toleo la 1.2 - tayari tulikuwa na rundo la mikongojo kwenye Shell na Chef, ambayo kwa namna fulani tulijaribu kupanga na Docker. Tulikuwa tukiangalia kwa umakini Rancher na suluhisho zingine kadhaa, lakini Kubernetes ilionekana, ambayo kila kitu kinatekelezwa kama vile tungefanya au bora zaidi. Hakuna cha kulalamika.
Ndiyo, kuna aina fulani ya kutokamilika hapa, kuna aina fulani ya kutokamilika huko - kuna mengi ya kutokamilika, na 1.2 kwa ujumla ni ya kutisha, lakini ... Kubernetes ni kama jengo linalojengwa - unatazama mradi na kuelewa. kwamba itakuwa poa. Ikiwa jengo sasa lina msingi na sakafu mbili, basi unaelewa kuwa ni bora kutohamia bado, lakini hakuna matatizo hayo na programu - unaweza tayari kuitumia.
Hatukuwa na wakati ambapo tulifikiria kutumia Kubernetes au la. Tulikuwa tukingojea kwa muda mrefu kabla ya kuonekana, na tukajaribu kuunda analogues sisi wenyewe.
Kuhusu Kubernetes
Je, unahusika moja kwa moja katika maendeleo ya Kubernetes yenyewe?
Dmitry: Kati. Badala yake, tunashiriki katika maendeleo ya mfumo ikolojia. Tunatuma idadi fulani ya maombi ya kuvuta: kwa Prometheus, kwa waendeshaji mbalimbali, kwa Helm - kwa mfumo wa ikolojia. Kwa bahati mbaya, siwezi kufuatilia kila kitu tunachofanya na ninaweza kuwa na makosa, lakini hakuna bwawa moja kutoka kwetu hadi msingi.
- Wakati huo huo, unatengeneza zana zako nyingi karibu na Kubernetes?
Dmitry: Mkakati ni huu: tunaenda na kuvuta maombi kwa kila kitu ambacho tayari kipo. Ikiwa maombi ya kuvuta hayatakubaliwa hapo, tunayauza sisi wenyewe na kuishi hadi yatakapokubaliwa na ujenzi wetu. Kisha, inapofika juu ya mkondo, tunarudi kwenye toleo la juu la mto.
Kwa mfano, tuna mwendeshaji wa Prometheus, ambaye tulibadilisha na kurudi kwenye sehemu ya juu ya mkusanyiko wetu labda mara 5 tayari. Tunahitaji aina fulani ya kipengele, tumetuma ombi la kuvuta, tunahitaji kukisambaza kesho, lakini hatutaki kungoja kitolewe juu. Ipasavyo, tunakusanyika kwa ajili yetu wenyewe, toa mkusanyiko wetu na kipengele chetu, ambacho tunahitaji kwa sababu fulani, kwa makundi yetu yote. Kisha, kwa mfano, hutugeuza juu ya mto kwa maneno: "Guys, hebu tuifanye kwa kesi ya jumla zaidi," sisi, au mtu mwingine, tunaimaliza, na baada ya muda inaunganishwa tena.
Tunajaribu kuendeleza kila kitu kilichopo. Vipengele vingi ambavyo havipo, bado havijavumbuliwa, au vimevumbuliwa, lakini havijapata muda wa kutekeleza - tunafanya hivyo. Na sio kwa sababu tunapenda mchakato au ujenzi wa baiskeli kama tasnia, lakini kwa sababu tu tunahitaji zana hii. Swali mara nyingi huulizwa, kwa nini tulifanya hili au jambo lile? Jibu ni rahisi - ndiyo, kwa sababu tulipaswa kwenda zaidi, kutatua tatizo fulani la vitendo, na tulitatua na tula hii.
Njia ni kama hii kila wakati: tunatafuta kwa uangalifu sana na, ikiwa hatutapata suluhisho la jinsi ya kutengeneza trolleybus kutoka kwa mkate, basi tunatengeneza mkate wetu wenyewe na trolleybus yetu wenyewe.
Vyombo vya Flanta
- Ninajua kuwa Flant sasa ina waendeshaji addon, waendeshaji ganda, na zana za dapp/werf. Kama ninavyoielewa, hii ni chombo sawa katika mwili tofauti. Pia ninaelewa kuwa kuna zana nyingi tofauti ndani ya Flaunt. Hii ni kweli?
Dmitry: Tuna mengi zaidi kwenye GitHub. Kutokana na kile ninachokumbuka sasa, tunayo ramani ya hali - jopo la Grafana ambalo kila mtu amekutana nalo. Imetajwa katika karibu kila nakala ya pili kuhusu ufuatiliaji wa Kubernetes kwenye Medium. Haiwezekani kueleza kwa ufupi ramani ya hali ni nini - inahitaji makala tofauti, lakini ni jambo la manufaa sana kwa hali ya ufuatiliaji baada ya muda, kwani katika Kubernetes mara nyingi tunahitaji kuonyesha hali baada ya muda. Pia tunayo LogHouse - hili ni jambo kulingana na ClickHouse na uchawi nyeusi kwa kukusanya kumbukumbu katika Kubernetes.
Huduma nyingi! Na kutakuwa na zaidi, kwa sababu idadi ya ufumbuzi wa ndani itatolewa mwaka huu. Kati ya zile kubwa sana kulingana na opereta wa addon, kuna rundo la nyongeza za Kubernetes, ala jinsi ya kusanikisha vizuri meneja wa sert - zana ya kudhibiti cheti, jinsi ya kusanikisha kwa usahihi Prometheus na rundo la vifaa - hizi ni karibu ishirini tofauti. jozi zinazosafirisha data na kukusanya kitu, kwa Prometheus hii ina michoro na arifa za kushangaza zaidi. Yote hii ni rundo la addons kwa Kubernetes, ambayo imewekwa kwenye nguzo, na inageuka kutoka rahisi hadi baridi, ya kisasa, ya moja kwa moja, ambayo masuala mengi tayari yametatuliwa. Ndiyo, tunafanya mengi.
Maendeleo ya mfumo wa ikolojia
"Inaonekana kwangu kuwa huu ni mchango mkubwa sana katika maendeleo ya chombo hiki na njia zake za matumizi." Je, unaweza kukadiria takriban ni nani mwingine angetoa mchango sawa katika maendeleo ya mfumo ikolojia?
Dmitry: Katika Urusi, ya makampuni ambayo yanafanya kazi katika soko letu, hakuna mtu hata karibu. Kwa kweli, hii ni taarifa kubwa, kwa sababu kuna wachezaji wakuu kama Barua na Yandex - pia wanafanya kitu na Kubernetes, lakini hata hawakaribii mchango wa kampuni katika ulimwengu wote ambao hufanya zaidi kuliko sisi. Ni vigumu kulinganisha Flant, ambayo ina wafanyakazi wa watu 80, na Red Hat, ambayo ina wahandisi 300 kwa Kubernetes pekee, ikiwa sikosea. Ni vigumu kulinganisha. Tuna watu 6 katika idara ya RnD, ikiwa ni pamoja na mimi, ambao walikata zana zetu zote. Watu 6 dhidi ya wahandisi 300 wa Red Hat - ni vigumu kwa namna fulani kulinganisha.
- Hata hivyo, wakati hata watu hawa 6 wanaweza kufanya kitu muhimu sana na kuwatenganisha, wakati wanakabiliwa na tatizo la vitendo na kutoa suluhisho kwa jamii - kesi ya kuvutia. Ninaelewa kuwa katika kampuni kubwa za teknolojia, ambapo wana timu yao ya ukuzaji na usaidizi wa Kubernetes, kimsingi, zana sawa zinaweza kutengenezwa. Huu ni mfano kwao wa kile kinachoweza kuendelezwa na kutolewa kwa jamii, na kutoa msukumo kwa jamii nzima inayotumia Kubernetes.
Dmitry: Labda hii ni kipengele cha kiunganishi, upekee wake. Tuna miradi mingi na tunaona hali nyingi tofauti. Kwa sisi, njia kuu ya kuunda thamani iliyoongezwa ni kuchambua kesi hizi, kupata kawaida na kuwafanya kuwa nafuu iwezekanavyo kwetu. Tunalifanyia kazi hili kikamilifu. Ni ngumu kwangu kuzungumza juu ya Urusi na ulimwengu, lakini tuna wahandisi wapatao 40 wa DevOps katika kampuni wanaofanya kazi Kubernetes. Sidhani kama kuna kampuni nyingi nchini Urusi zilizo na idadi inayolingana ya wataalam wanaoelewa Kubernetes, ikiwa wapo kabisa.
Ninaelewa kila kitu kuhusu jina la mhandisi wa DevOps, kila mtu anaelewa kila kitu na amezoea kuwaita wahandisi wa DevOps wahandisi wa DevOps, hatutajadili hili. Wahandisi hawa wote 40 wa ajabu wa DevOps wanakabiliwa na kutatua matatizo kila siku, tunachanganua tu tukio hili na kujaribu kujumlisha. Tunaelewa kwamba ikiwa inabakia ndani yetu, basi katika mwaka mmoja au mbili chombo hakitakuwa na maana, kwa sababu mahali fulani katika jumuiya Tula iliyopangwa tayari itaonekana. Hakuna maana katika kukusanya uzoefu huu ndani - ni tu kuondoa nishati na wakati katika dev/null. Na hatuionei huruma hata kidogo. Tunachapisha kila kitu kwa furaha kubwa na kuelewa kwamba inahitaji kuchapishwa, kuendelezwa, kukuzwa, kukuzwa, ili watu waitumie na kuongeza uzoefu wao - basi kila kitu kinakua na maisha. Kisha baada ya miaka miwili chombo hakiingii kwenye takataka. Sio huruma kuendelea kumwaga kwa nguvu, kwa sababu ni wazi kwamba mtu anatumia chombo chako, na baada ya miaka miwili kila mtu anaitumia.
Hii ni sehemu ya mkakati wetu mkubwa na dapp/werf. Sikumbuki wakati tulianza kuifanya, inaonekana kama miaka 3 iliyopita. Hapo awali, ilikuwa kwa ujumla kwenye ganda. Ilikuwa ni uthibitisho bora wa dhana, tulitatua baadhi ya matatizo yetu - ilifanya kazi! Lakini kuna matatizo na shell, haiwezekani kupanua zaidi, programu kwenye shell ni kazi nyingine. Tulikuwa na tabia ya kuandika katika Ruby, ipasavyo, sisi remake kitu katika Ruby, maendeleo, maendeleo, maendeleo, na kukimbia katika ukweli kwamba jamii, umati kwamba haina kusema βtunataka au hatutaki, β anainua pua yake kwa Ruby, ni mcheshi gani huo? Tuligundua kwamba tunapaswa kuandika mambo haya yote katika Go ili tu kutimiza jambo la kwanza kwenye orodha hakiki: Zana ya DevOps inapaswa kuwa binary tuli. To be Go or not sio muhimu sana, lakini binary tuli iliyoandikwa katika Go ni bora zaidi.
Tulitumia nguvu zetu, tukaandika upya dapp katika Go na kuiita werf. Dapp haitumiki tena, haijatengenezwa, inatumika katika toleo jipya zaidi, lakini kuna njia ya kuboresha kabisa hadi juu, na unaweza kuifuata.
Kwa nini dapp iliundwa?
- Je, unaweza kutuambia kwa ufupi kwa nini dapp iliundwa, ni matatizo gani inasuluhisha?
Dmitry: Sababu ya kwanza iko kwenye kusanyiko. Hapo awali, tulikuwa na shida kubwa na ujenzi wakati Docker haikuwa na uwezo wa hatua nyingi, kwa hivyo tulifanya hatua nyingi peke yetu. Kisha tulikuwa na rundo la masuala zaidi na kusafisha picha. Kila mtu anayefanya CI / CD, mapema kuliko baadaye, anakabiliwa na tatizo kwamba kuna kundi la picha zilizokusanywa, unahitaji kwa namna fulani kusafisha kile kisichohitajika na kuacha kile kinachohitajika.
Sababu ya pili ni kupelekwa. Ndiyo, kuna Helm, lakini hutatua baadhi tu ya matatizo. Cha kufurahisha vya kutosha, imeandikwa kwamba "Helm ndiye Meneja wa Kifurushi cha Kubernetes." Hasa nini "the". Pia kuna maneno "Meneja wa Kifurushi" - ni matarajio gani ya kawaida kutoka kwa Meneja wa Kifurushi? Tunasema: "Kidhibiti cha Kifurushi - sasisha kifurushi!" na tunatarajia atuambie: βKifurushi kimeletwa.β
Inafurahisha kwamba tunasema: "Helm, sasisha kifurushi," na anapojibu kwamba aliiweka, zinageuka kuwa alianza usakinishaji - alionyesha Kubernetes: "Zindua jambo hili!", Na ikiwa ilianza au la. , iwe inafanya kazi au la, Helm haisuluhishi suala hili hata kidogo.
Inabadilika kuwa Helm ni kichakataji maandishi tu ambacho hupakia data kwenye Kubernetes.
Lakini kama sehemu ya utumaji wowote, tunataka kujua ikiwa ombi limetolewa kwa ajili ya uzalishaji au la? Imetolewa kwa utayarishaji inamaanisha kuwa programu imehamia hapo, toleo jipya limetumwa, na angalau halianguki hapo na kujibu ipasavyo. Helm haisuluhishi shida hii kwa njia yoyote. Ili kutatua, unahitaji kutumia juhudi nyingi, kwa sababu unahitaji kumpa Kubernetes amri ya kusambaza na kufuatilia kile kinachotokea huko - ikiwa imetumwa au imetolewa. Na pia kuna kazi nyingi zinazohusiana na kupelekwa, kusafisha, na kusanyiko.
Mipango
Mwaka huu tutaanza maendeleo ya ndani. Tunataka kufikia kile kilichokuwa katika Vagrant - tuliandika "vagrant up" na tukasambaza mashine pepe. Tunataka kufikia mahali ambapo kuna mradi katika Git, tunaandika "werf up" hapo, na inaleta nakala ya ndani ya mradi huu, iliyotumwa katika mini-Kub ya ndani, na saraka zote zinazofaa kwa maendeleo zimeunganishwa. . Kulingana na lugha ya maendeleo, hii inafanywa tofauti, lakini hata hivyo, ili maendeleo ya ndani yanaweza kufanywa kwa urahisi chini ya faili zilizowekwa.
Hatua inayofuata kwetu ni kuwekeza kwa urahisi kwa watengenezaji. Ili kupeleka mradi haraka ndani kwa kutumia zana moja, kuukuza, kuusukuma hadi kwenye Git, na pia utatolewa kwa hatua au majaribio, kulingana na mabomba, na kisha kutumia zana sawa kwenda kwa uzalishaji. Umoja huu, muunganisho, uzalishwaji wa miundombinu kutoka kwa mazingira ya ndani hadi mauzo ni jambo muhimu sana kwetu. Lakini hii bado haijawashwa - tunapanga kuifanya.
Lakini njia ya dapp/werf imekuwa sawa na Kubernetes hapo mwanzo. Tulikutana na shida, tukatatua kwa njia za kufanya kazi - tulikuja na suluhisho zetu wenyewe kwenye ganda, kwa chochote. Kisha walijaribu kwa namna fulani kunyoosha kazi hizi, kujumlisha na kuziunganisha katika jozi katika kesi hii, ambayo tunashiriki kwa urahisi.
Kuna njia nyingine ya kuangalia hadithi hii yote, na mlinganisho.
Kubernetes ni fremu ya gari yenye injini. Hakuna milango, glasi, redio, mti wa Krismasi - hakuna chochote. Sura na injini tu. Na kuna Helm - hii ni usukani. Baridi - kuna usukani, lakini pia unahitaji pini ya usukani, rack ya usukani, sanduku la gia na magurudumu, na huwezi kufanya bila yao.
Kwa upande wa werf, hii ni sehemu nyingine ya Kubernetes. Ni sasa tu katika toleo la alpha la werf, kwa mfano, Helm imeundwa ndani ya werf, kwa sababu tumechoka kuifanya sisi wenyewe. Kuna sababu nyingi za kufanya hivi, nitakuambia kwa undani juu ya kwanini tulikusanya usukani wote pamoja na mkulima ndani ya werf. .
Sasa werf ni sehemu iliyojumuishwa zaidi. Tunapata usukani uliomalizika, pini ya usukani - mimi si mzuri sana kwa magari, lakini hii ni kizuizi kikubwa ambacho tayari kinasuluhisha shida nyingi. Hatuna haja ya kupitia orodha wenyewe, chagua sehemu moja kwa nyingine, fikiria jinsi ya kuziunganisha pamoja. Tunapata mchanganyiko tayari ambao hutatua idadi kubwa ya matatizo mara moja. Lakini ndani yake imejengwa kutoka kwa vifaa sawa vya chanzo wazi, bado hutumia Docker kwa kusanyiko, Helm kwa utendaji fulani, na kuna maktaba zingine kadhaa. Hiki ni zana iliyojumuishwa ili kupata CI/CD baridi nje ya kisanduku haraka na kwa urahisi.
Je, Kubernetes ni vigumu kutunza?
- Unazungumza juu ya uzoefu ambao ulianza kutumia Kubernetes, hii ni fremu yako, injini, na kwamba unaweza kunyongwa vitu vingi tofauti juu yake: mwili, usukani, screw kwenye kanyagio, viti. Swali linatokea - msaada wa Kubernetes ni mgumu kwako? Una uzoefu mwingi, unatumia muda na rasilimali kiasi gani kusaidia Kubernetes kwa kujitenga na kila kitu kingine?
Dmitry: Hili ni swali gumu sana na kujibu, tunahitaji kuelewa msaada ni nini na tunataka nini kutoka kwa Kubernetes. Labda unaweza kufichua?
- Ninavyojua na ninavyoona, sasa timu nyingi zinataka kujaribu Kubernetes. Kila mtu hujishughulisha nayo, huiweka kwa magoti yake. Nina hisia kwamba watu hawaelewi kila wakati utata wa mfumo huu.
Dmitry: Ni hivyo.
- Je, ni vigumu kiasi gani kuchukua na kusakinisha Kubernetes kutoka mwanzo ili iwe tayari kwa uzalishaji?
Dmitry: Unafikiri ni vigumu kiasi gani kupandikiza moyo? Ninaelewa hili ni swali la maelewano. Kutumia scalpel na kutofanya makosa sio ngumu sana. Ikiwa wanakuambia wapi kukata na wapi kushona, basi utaratibu yenyewe sio ngumu. Ni vigumu kuhakikisha muda baada ya muda kwamba kila kitu kitafanya kazi.
Kufunga Kubernetes na kuifanya ifanye kazi ni rahisi: kifaranga! - imewekwa, kuna njia nyingi za ufungaji. Lakini nini kinatokea matatizo yanapotokea?
Maswali huibuka kila wakati - ni nini ambacho hatujazingatia bado? Bado hatujafanya nini? Ni vigezo gani vya Linux kernel vilibainishwa vibaya? Bwana, hata tuliwataja?! Je, ni vipengele vipi vya Kubernetes tumewasilisha na ambavyo hatujawasilisha? Maelfu ya maswali hutokea, na kujibu, unahitaji kutumia miaka 15-20 katika sekta hii.
Nina mfano wa hivi majuzi kuhusu mada hii ambao unaweza kufichua maana ya tatizo "Je, Kubernetes ni vigumu kudumisha?" Wakati fulani uliopita tulizingatia kwa dhati ikiwa tunapaswa kujaribu kutekeleza Cilium kama mtandao huko Kubernetes.
Hebu nielezee Kilio ni nini. Kubernetes ina utekelezaji mwingi tofauti wa mfumo mdogo wa mtandao, na mmoja wao ni mzuri sana - Cilium. Maana yake ni nini? Katika kernel, wakati fulani uliopita iliwezekana kuandika ndoano za kernel, ambazo kwa njia moja au nyingine huvamia mfumo mdogo wa mtandao na mifumo mingine mbalimbali, na kuruhusu kupitisha chunks kubwa kwenye kernel.
Kiini cha Linux kihistoria kina mfumo wa ip, kichujio cha kupita kiasi, madaraja na vifaa vingi tofauti vya zamani ambavyo vina umri wa miaka 15, 20, 30. Kwa ujumla, wanafanya kazi, kila kitu ni nzuri, lakini sasa wamekusanya vyombo, na inaonekana kama mnara wa matofali 15 juu ya kila mmoja, na unasimama juu yake kwa mguu mmoja - hisia ya ajabu. Mfumo huu umetengenezwa kihistoria na nuances nyingi, kama kiambatisho kwenye mwili. Katika baadhi ya hali kuna masuala ya utendaji, kwa mfano.
Kuna BPF ya ajabu na uwezo wa kuandika ndoano kwa kernel - wavulana waliandika ndoano zao kwa kernel. Kifurushi kinakuja kwenye kernel ya Linux, wanaichukua moja kwa moja kwenye pembejeo, wanaichakata wenyewe kama inavyopaswa bila madaraja, bila TCP, bila rundo la IP - kwa kifupi, kupita kila kitu kilichoandikwa kwenye kernel ya Linux, na kisha kutema mate. nje ndani ya chombo.
Nini kimetokea? Utendaji mzuri sana, sifa nzuri - nzuri tu! Lakini tunaangalia hii na kuona kwamba kwenye kila mashine kuna programu inayounganishwa na Kubernetes API na, kulingana na data inayopokea kutoka kwa API hii, hutoa msimbo wa C na unajumuisha jozi ambazo hupakia kwenye kernel ili ndoano hizi zifanye kazi. kwenye nafasi ya kernel.
Nini kitatokea ikiwa kitu kitaenda vibaya? Hatujui. Ili kuelewa hili, unahitaji kusoma kanuni hii yote, kuelewa mantiki yote, na ni ajabu jinsi ilivyo vigumu. Lakini, kwa upande mwingine, kuna madaraja haya, vichungi vya wavu, njia ya ip - sijasoma msimbo wao wa chanzo, na wala sina wahandisi 40 wanaofanya kazi katika kampuni yetu. Labda ni wachache tu wanaoelewa baadhi ya sehemu.
Na ni tofauti gani? Inabadilika kuwa kuna ip rout, kernel ya Linux, na kuna zana mpya - inafanya tofauti gani, hatuelewi moja au nyingine. Lakini tunaogopa kutumia kitu kipya - kwa nini? Kwa sababu ikiwa chombo kina umri wa miaka 30, basi katika miaka 30 mende zote zimepatikana, makosa yote yamepitishwa na hauitaji kujua juu ya kila kitu - inafanya kazi kama sanduku nyeusi na inafanya kazi kila wakati. Kila mtu anajua bisibisi kipi cha kushikilia mahali, ni tcpdump ipi iendeshe saa ngapi. Kila mtu anajua huduma za uchunguzi vizuri na anaelewa jinsi seti hii ya vipengele inavyofanya kazi kwenye kernel ya Linux - sio jinsi inavyofanya kazi, lakini jinsi ya kuitumia.
Na Cilium ya kushangaza sio umri wa miaka 30, bado haijazeeka. Kubernetes ana shida sawa, nakala. Hiyo Cilium imewekwa kikamilifu, kwamba Kubernetes imewekwa kikamilifu, lakini wakati kitu kinakwenda vibaya katika uzalishaji, unaweza kuelewa haraka katika hali mbaya nini kilikwenda vibaya?
Tunaposema ni ngumu kudumisha Kubernetes - hapana, ni rahisi sana, na ndio, ni ngumu sana. Kubernetes inafanya kazi nzuri peke yake, lakini na nuances bilioni.
Kuhusu mbinu "nitakuwa na bahati".
- Je, kuna makampuni ambapo nuances hizi ni karibu kuhakikishiwa kuonekana? Tuseme Yandex ghafla huhamisha huduma zote kwa Kubernetes, kutakuwa na mzigo mkubwa huko.
Dmitry: Hapana, hii sio mazungumzo kuhusu mzigo, lakini kuhusu mambo rahisi zaidi. Kwa mfano, tuna Kubernetes, tulituma programu hapo. Unajuaje kuwa inafanya kazi? Hakuna zana iliyotengenezwa tayari kuelewa kuwa programu haivunjiki. Hakuna mfumo uliotengenezwa tayari ambao hutuma arifa; unahitaji kusanidi arifa hizi na kila ratiba. Na tunasasisha Kubernetes.
Nina Ubuntu 16.04. Unaweza kusema kwamba hili ni toleo la zamani, lakini bado tuko nalo kwa sababu ni LTS. Kuna systemd, nuance ambayo ni kwamba haina kusafisha C-vikundi. Kubernetes huzindua maganda, huunda vikundi vya C, kisha hufuta maganda, na kwa njia fulani ikawa - sikumbuki maelezo, samahani - kwamba vipande vya mfumo hubaki. Hii inaongoza kwa ukweli kwamba baada ya muda, gari lolote huanza kupungua kwa nguvu. Hili sio swali hata juu ya upakiaji. Ikiwa maganda ya kudumu yanazinduliwa, kwa mfano, ikiwa kuna Kazi ya Cron inayozalisha mara kwa mara maganda, basi mashine yenye Ubuntu 16.04 itaanza kupungua baada ya wiki. Kutakuwa na wastani wa mzigo wa juu kila wakati kutokana na ukweli kwamba kundi la vikundi vya C vimeundwa. Hili ndio shida ambayo mtu yeyote ambaye anasakinisha tu Ubuntu 16 na Kubernetes juu atakabiliana nayo.
Wacha tuseme anasasisha kwa njia fulani mfumo au kitu kingine, lakini kwenye kernel ya Linux hadi 4.16 inafurahisha zaidi - unapofuta vikundi vya C, huvuja kwenye kernel na hazijafutwa. Kwa hiyo, baada ya mwezi wa kufanya kazi kwenye mashine hii, haitawezekana kuangalia takwimu za kumbukumbu kwa makao. Tunachukua faili, kuipindua kwenye programu, na faili moja inazunguka kwa sekunde 15, kwa sababu kernel inachukua muda mrefu sana kuhesabu vikundi vya C milioni ndani yake, ambavyo vinaonekana kufutwa, lakini hapana - vinavuja. .
Bado kuna mambo mengi madogo kama haya hapa na pale. Hili sio suala ambalo makampuni makubwa yanaweza wakati mwingine kukabiliana na mizigo mizito sana - hapana, ni suala la mambo ya kila siku. Watu wanaweza kuishi kama hii kwa miezi - walisakinisha Kubernetes, kusambaza programu - inaonekana kufanya kazi. Kwa watu wengi hii ni kawaida. Hawatajua hata kwamba programu hii itaanguka kwa sababu fulani, hawatapokea tahadhari, lakini kwao hii ndiyo kawaida. Hapo awali, tuliishi kwenye mashine za kawaida bila ufuatiliaji, sasa tulihamia Kubernetes, pia bila ufuatiliaji - ni tofauti gani?
Swali ni kwamba tunapotembea kwenye barafu, hatujui unene wake isipokuwa tunaipima mapema. Watu wengi hutembea na hawana wasiwasi, kwa sababu wametembea hapo awali.
Kwa mtazamo wangu, nuance na utata wa uendeshaji wa mfumo wowote ni kuhakikisha kwamba unene wa barafu ni wa kutosha kutatua matatizo yetu. Hiki ndicho tunachozungumzia.
Katika IT, inaonekana kwangu, kuna njia nyingi sana "nitakuwa na bahati". Watu wengi husakinisha programu na kutumia maktaba ya programu kwa matumaini kwamba watapata bahati. Kwa ujumla, watu wengi wana bahati. Labda ndiyo sababu inafanya kazi.
- Kutoka kwa tathmini yangu ya kukata tamaa, inaonekana kama hii: wakati hatari ni kubwa, na maombi lazima ifanye kazi, basi msaada unahitajika kutoka kwa Flaunt, labda kutoka kwa Red Hat, au unahitaji timu yako ya ndani iliyojitolea mahsusi kwa Kubernetes, ambayo iko tayari. kuivuta.
Dmitry: Kwa kusudi, hii ni hivyo. Kuingia kwenye hadithi ya Kubernetes kwa timu ndogo peke yako kunahusisha hatari kadhaa.
Je, tunahitaji vyombo?
Unaweza kutuambia jinsi Kubernetes imeenea nchini Urusi?
Dmitry: Sina data hii, na sina uhakika mtu mwingine yeyote anayo. Tunasema: "Kubernetes, Kubernetes," lakini kuna njia nyingine ya kuangalia suala hili. Pia sijui jinsi kontena zimeenea, lakini najua takwimu kutoka kwa ripoti kwenye Mtandao kwamba 70% ya kontena hupangwa na Kubernetes. Ilikuwa chanzo cha kuaminika kwa sampuli kubwa ulimwenguni kote.
Kisha swali lingine - tunahitaji vyombo? Hisia yangu ya kibinafsi na msimamo wa jumla wa kampuni ya Flant ni kwamba Kubernetes ni kiwango cha ukweli.
Hakutakuwa na chochote isipokuwa Kubernetes.
Hiki ni kibadilishaji mchezo kabisa katika uwanja wa usimamizi wa miundombinu. Kabisa kabisa - ndivyo hivyo, hakuna tena Ansible, Chef, mashine za kawaida, Terraform. Sizungumzi juu ya mbinu za zamani za kilimo cha pamoja. Kubernetes ni kibadilishaji kabisa, na sasa itakuwa hivi tu.
Ni wazi kwamba kwa wengine inachukua miaka kadhaa, na kwa wengine miongo kadhaa, kutambua hili. Sina shaka kuwa hakutakuwa na chochote isipokuwa Kubernetes na sura hii mpya: hatuharibu tena mfumo wa uendeshaji, lakini tumia. miundombinu kama kanuni, sio tu na nambari, lakini na yml - miundombinu iliyoelezewa wazi. Nina hisia kuwa itakuwa hivi kila wakati.
- Hiyo ni, kampuni hizo ambazo bado hazijabadilisha Kubernetes hakika zitaibadilisha au kubaki kusahaulika. Nimekuelewa kwa usahihi?
Dmitry: Hii pia si kweli kabisa. Kwa mfano, ikiwa tuna kazi ya kuendesha seva ya DNS, basi inaweza kuendeshwa kwenye FreeBSD 4.10 na inaweza kufanya kazi kikamilifu kwa miaka 20. Kazi tu na ndivyo hivyo. Labda katika miaka 20 kitu kitahitaji kusasishwa mara moja. Ikiwa tunazungumzia kuhusu programu katika muundo ambao tulizindua na kwa kweli inafanya kazi kwa miaka mingi bila sasisho yoyote, bila kufanya mabadiliko, basi, bila shaka, hakutakuwa na Kubernetes. Hahitajiki hapo.
Kila kitu kinachohusiana na CI/CD - popote Utoaji Unaoendelea unahitajika, ambapo unahitaji kusasisha matoleo, kufanya mabadiliko yanayotumika, popote unahitaji kujenga uvumilivu wa makosa - Kubernetes pekee.
Kuhusu huduma ndogo ndogo
- Hapa nina dissonance kidogo. Kufanya kazi na Kubernetes, unahitaji msaada wa nje au wa ndani - hii ndiyo hatua ya kwanza. Pili, tunapoanza maendeleo, sisi ni mwanzo mdogo, hatuna chochote bado, maendeleo ya Kubernetes au usanifu wa huduma ndogo kwa ujumla inaweza kuwa ngumu na sio haki ya kiuchumi kila wakati. Ninavutiwa na maoni yako - je wanaoanza wanahitaji kuanza mara moja kuandika kwa Kubernetes kutoka mwanzo, au bado wanaweza kuandika monolith, na kisha kuja Kubernetes tu?
Dmitry: Swali zuri. Nina mazungumzo juu ya huduma ndogo Mara nyingi nimekutana na watu wakijaribu kugonga misumari kwa darubini. Mbinu yenyewe ni sahihi; sisi wenyewe huunda programu yetu ya ndani kwa njia hii. Lakini unapofanya hivi, unahitaji kuelewa wazi unachofanya. Neno ninalochukia zaidi kuhusu huduma ndogo ni "ndogo." Kihistoria, neno hili lilianzia hapo, na kwa sababu fulani watu wanafikiri kwamba micro ni ndogo sana, chini ya milimita, kama micrometer. Hii si sahihi.
Kwa mfano, kuna monolith iliyoandikwa na watu 300, na kila mtu aliyeshiriki katika maendeleo anaelewa kuwa kuna matatizo huko, na inapaswa kuvunjwa katika vipande vidogo - vipande 10, ambayo kila moja imeandikwa na watu 30. katika toleo la chini. Hii ni muhimu, muhimu na baridi. Lakini mwanzo unapokuja kwetu, ambapo watu 3 wazuri sana na wenye talanta waliandika huduma ndogo 60 kwenye magoti yao, kila wakati ninapotafuta Corvalol.
Inaonekana kwangu kwamba hii tayari imezungumzwa juu ya maelfu ya nyakati - tulipata monolith iliyosambazwa kwa namna moja au nyingine. Hii sio haki ya kiuchumi, ni vigumu sana kwa ujumla katika kila kitu. Nimeona hili mara nyingi sana ambalo linaniumiza sana, kwa hivyo ninaendelea kulizungumza.
Kwa swali la awali, kuna mgongano kati ya ukweli kwamba, kwa upande mmoja, Kubernetes inatisha kutumia, kwa sababu haijulikani ni nini kinachoweza kuvunja huko au kutofanya kazi, kwa upande mwingine, ni wazi kwamba kila kitu kinakwenda huko. na hakuna chochote isipokuwa Kubernetes kitakachokuwepo . Jibu - pima kiasi cha faida inayokuja, kiasi cha kazi ambazo unaweza kutatua. Hii ni upande mmoja wa mizani. Kwa upande mwingine, kuna hatari zinazohusiana na kupungua au kupungua kwa muda wa majibu, kiwango cha upatikanaji - na kupungua kwa viashiria vya utendaji.
Hii hapa - ama tunasonga haraka, na Kubernetes huturuhusu kufanya mambo mengi kwa haraka na bora zaidi, au tunatumia masuluhisho ya kuaminika, yaliyojaribiwa kwa wakati, lakini tunasonga polepole zaidi. Hili ni chaguo ambalo kila kampuni inapaswa kufanya. Unaweza kuifikiria kama njia msituni - unapotembea kwa mara ya kwanza, unaweza kukutana na nyoka, tiger au mbwa wazimu, na wakati umetembea mara 10, umekanyaga njia, umeondolewa. matawi na kutembea rahisi. Kila wakati njia inakuwa pana. Kisha ni barabara ya lami, na baadaye boulevard nzuri.
Kubernetes haijasimama. Swali tena: Kubernetes, kwa upande mmoja, ni jozi 4-5, kwa upande mwingine, ni mfumo mzima wa ikolojia. Huu ndio mfumo wa uendeshaji ambao tunao kwenye mashine zetu. Hii ni nini? Ubuntu au Curios? Hii ni kernel ya Linux, rundo la vipengele vya ziada. Mambo haya yote hapa, nyoka mmoja mwenye sumu alitupwa nje ya barabara, uzio ukawekwa pale. Kubernetes inakua kwa haraka sana na kwa nguvu, na kiasi cha hatari, kiasi cha haijulikani kinapungua kila mwezi na, ipasavyo, mizani hii inasawazisha tena.
Kujibu swali la nini kinachoanza kinapaswa kufanya, ningesema - kuja kwa Flaunt, kulipa rubles elfu 150 na kupata huduma rahisi ya DevOps ya turnkey. Ikiwa wewe ni mwanzo mdogo na watengenezaji wachache, hii inafanya kazi. Badala ya kuajiri DevOps yako mwenyewe, ambaye atahitaji kujifunza jinsi ya kutatua matatizo yako na kulipa mshahara kwa wakati huu, utapata suluhisho la turnkey kwa masuala yote. Ndiyo, kuna baadhi ya hasara. Sisi, kama mtoaji, hatuwezi kuhusika sana na kujibu mabadiliko haraka. Lakini tuna utaalamu mwingi na mazoea yaliyotengenezwa tayari. Tunahakikisha kwamba katika hali yoyote hakika tutaibaini haraka na kuinua Kubernetes yoyote kutoka kwa wafu.
Ninapendekeza sana uhamishaji wa biashara kwa wanaoanzisha na kuanzisha biashara hadi ukubwa ambapo unaweza kujitolea kwa timu ya watu 10 kwa shughuli, kwa sababu vinginevyo hakuna maana. Kwa hakika inaeleweka kusambaza hii.
Kuhusu Amazon na Google
- Je, mwenyeji kutoka kwa suluhisho kutoka Amazon au Google anaweza kuchukuliwa kama chanzo cha nje?
Dmitry: Ndiyo, bila shaka, hii hutatua masuala kadhaa. Lakini tena kuna nuances. Bado unahitaji kuelewa jinsi ya kuitumia. Kwa mfano, kuna mambo elfu kidogo katika kazi ya Amazon AWS: Mizani ya Mzigo inahitaji kuwashwa moto au ombi lazima liandikwe mapema kwamba "jamani, tutapokea trafiki, weka Kisawazisho cha Mzigo kwa ajili yetu!" Unahitaji kujua nuances hizi.
Unapogeukia watu waliobobea katika hili, unapata karibu mambo yote ya kawaida kufungwa. Sasa tuna wahandisi 40, hadi mwisho wa mwaka kutakuwa na 60 - hakika tumekutana na mambo haya yote. Hata kama tutakutana na tatizo hili tena kwenye mradi fulani, tunaulizana haraka na kujua jinsi ya kulitatua.
Pengine jibu ni - bila shaka, hadithi mwenyeji hurahisisha sehemu fulani. Swali ni kama uko tayari kuwaamini wahudumu hawa na kama watasuluhisha matatizo yako. Amazon na Google wamefanya vizuri. Kwa kesi zetu zote - haswa. Hatuna uzoefu mzuri zaidi. Mawingu mengine yote ambayo tulijaribu kufanya kazi nayo yanaleta matatizo mengi - Ager, na kila kitu kilicho nchini Urusi, na kila aina ya OpenStack katika utekelezaji tofauti: Headster, Overage - chochote unachotaka. Yote yanaleta matatizo ambayo hutaki kuyatatua.
Kwa hivyo, jibu ni ndio, lakini, kwa kweli, hakuna suluhisho nyingi za mwenyeji.
Nani anahitaji Kubernetes?
- Na bado, ni nani anayehitaji Kubernetes? Nani anapaswa tayari kubadili Kubernetes, ambaye ni mteja wa kawaida wa Flaunt ambaye anakuja mahususi kwa Kubernetes?
Dmitry: Hili ni swali la kufurahisha, kwa sababu hivi sasa, baada ya Kubernetes, watu wengi wanakuja kwetu: "Guys, tunajua kuwa unafanya Kubernetes, tufanyie sisi!" Tunawajibu: "Mabwana, hatufanyi Kubernetes, tunafanya kazi na kila kitu kinachohusiana nayo." Kwa sababu kwa sasa haiwezekani kutengeneza bidhaa bila kufanya CI/CD zote na hadithi hii yote. Kila mtu ametoka katika mgawanyiko kwamba tuna maendeleo kwa maendeleo, na kisha unyonyaji kwa unyonyaji.
Wateja wetu wanatarajia mambo tofauti, lakini kila mtu anasubiri muujiza fulani mzuri kwamba wana matatizo fulani, na sasa - hop! - Kubernetes itazitatua. Watu wanaamini miujiza. Katika akili zao wanaelewa kuwa hakutakuwa na muujiza, lakini katika nafsi zao wanatumaini - ni nini ikiwa Kubernetes hii sasa itatatua kila kitu kwa ajili yetu, wanazungumza sana juu yake! Ghafla yeye sasa - kupiga chafya! - na risasi ya fedha, chafya! - na tuna muda wa nyongeza wa 100%, wasanidi programu wote wanaweza kutoa chochote kitakachoingia katika toleo la umma mara 50, na hakitaacha kufanya kazi. Kwa ujumla, muujiza!
Watu kama hao wanapokuja kwetu, tunasema: "Samahani, lakini hakuna kitu kama muujiza." Ili kuwa na afya, unahitaji kula vizuri na kufanya mazoezi. Ili kuwa na bidhaa ya kuaminika, inahitaji kufanywa kwa uhakika. Ili kuwa na CI/CD inayofaa, unahitaji kuifanya iwe hivi. Hiyo ni kazi kubwa inayohitaji kufanywa.
Kujibu swali la nani anayehitaji Kubernetes - hakuna mtu anayehitaji Kubernetes.
Watu wengine wana maoni potofu kwamba wanahitaji Kubernetes. Watu wanahitaji, wana hitaji kubwa la kuacha kufikiria, kusoma, na kupendezwa na shida zote za miundombinu na shida za kuendesha maombi yao. Wanataka maombi yafanye kazi tu na kupeleka tu. Kwao, Kubernetes ni matumaini kwamba wataacha kusikia hadithi kwamba "tulikuwa tumelala pale," au "hatuwezi kusambaza," au kitu kingine.
Mkurugenzi wa kiufundi kawaida huja kwetu. Wanamuuliza mambo mawili: kwa upande mmoja, tupe sifa, kwa upande mwingine, utulivu. Tunapendekeza ujichukulie na uifanye. risasi ya fedha, au tuseme fedha-plated, ni kwamba wewe kuacha kufikiri juu ya matatizo haya na kupoteza muda. Utakuwa na watu maalum ambao watafunga suala hili.
Maneno ambayo sisi au mtu mwingine yeyote anahitaji Kubernetes sio sahihi.
Wasimamizi wanahitaji sana Kubernetes, kwa sababu ni toy ya kuvutia sana ambayo unaweza kucheza nayo na kucheza nayo. Wacha tuwe waaminifu - kila mtu anapenda vinyago. Sisi sote ni watoto mahali fulani, na tunapoona mpya, tunataka kuicheza. Kwa wengine, hii imekatishwa tamaa, kwa mfano, katika utawala, kwa sababu tayari wamecheza vya kutosha na tayari wamechoka hadi hawataki tu. Lakini hii haijapotea kabisa kwa mtu yeyote. Kwa mfano, ikiwa nimekuwa nimechoka na toys katika uwanja wa utawala wa mfumo na DevOps kwa muda mrefu, basi bado ninapenda toys, bado ninunua mpya. Watu wote, kwa njia moja au nyingine, bado wanataka aina fulani ya toys.
Hakuna haja ya kucheza na uzalishaji. Chochote ninachopendekeza kabisa kutofanya na kile ninachokiona sasa kwa jumla: "Loo, toy mpya!" β walikimbia kwenda kuinunua, wakainunua na: βHebu tuipeleke shuleni sasa na tuionyeshe kwa marafiki zetu wote.β Usifanye hivi. Ninaomba msamaha, watoto wangu wanakua tu, mimi huona kitu kila wakati kwa watoto, naona ndani yangu, na kisha kukijumlisha kwa wengine.
Jibu la mwisho ni: hauitaji Kubernetes. Unahitaji kutatua matatizo yako.
Unachoweza kufikia ni:
- prod haina kuanguka;
- hata akijaribu kuanguka, tunajua kuhusu hilo mapema, na tunaweza kuweka kitu ndani yake;
- tunaweza kuibadilisha kwa kasi ambayo biashara yetu inaihitaji, na tunaweza kuifanya kwa urahisi; haituletei matatizo yoyote.
Kuna mahitaji mawili ya kweli: kutegemewa na mabadiliko/unyumbufu wa uchapishaji. Kila mtu ambaye kwa sasa anafanya aina fulani ya miradi ya IT, bila kujali ni aina gani ya biashara - laini kwa ajili ya kurahisisha dunia, na ambaye anaelewa hili, anahitaji kutatua mahitaji haya. Kubernetes na mbinu sahihi, na uelewa sahihi na uzoefu wa kutosha utapata kutatua yao.
Kuhusu isiyo na seva
- Ikiwa unatazama kidogo zaidi katika siku zijazo, kisha kujaribu kutatua tatizo la kutokuwepo kwa maumivu ya kichwa na miundombinu, kwa kasi ya utoaji na kasi ya mabadiliko ya maombi, ufumbuzi mpya huonekana, kwa mfano, bila seva. Je, unahisi uwezekano wowote katika mwelekeo huu na, hebu tuseme, hatari kwa Kubernetes na ufumbuzi sawa?
Dmitry: Hapa tunahitaji kutoa maoni tena kwamba mimi si mwonaji ambaye anatazama mbele na kusema - itakuwa hivi! Ingawa nilifanya vivyo hivyo. Ninaangalia miguu yangu na kuona rundo la matatizo huko, kwa mfano, jinsi transistors hufanya kazi kwenye kompyuta. Ni funny, sawa? Tunakumbana na hitilafu kadhaa kwenye CPU.
Fanya kutokuwa na seva ya kuaminika kabisa, nafuu, bora na rahisi, kutatua masuala yote ya mfumo ikolojia. Hapa nakubaliana na Elon Musk kwamba sayari ya pili inahitajika ili kuunda uvumilivu wa makosa kwa wanadamu. Ingawa sijui anachosema, ninaelewa kuwa siko tayari kuruka Mars mwenyewe na haitatokea kesho.
Kwa kutokuwa na seva ni wazi kuwa hili ni jambo sahihi kiitikadi, kama uvumilivu wa makosa kwa wanadamu - kuwa na sayari mbili ni bora kuliko moja. Lakini jinsi ya kufanya hivyo sasa? Kutuma safari moja ya kujifunza si tatizo ikiwa utaelekeza nguvu zako katika hilo. Kutuma safari kadhaa na kusuluhisha maelfu ya watu huko, nadhani, pia ni kweli. Lakini kuifanya iwe ya kuvumilia makosa kabisa ili nusu ya ubinadamu huishi huko, inaonekana kwangu sasa haiwezekani, bila kuzingatiwa.
Na bila seva moja kwa moja: jambo ni nzuri, lakini ni mbali na shida za 2019. Karibu na 2030 - wacha tuishi ili kuiona. Sina shaka kwamba tutaishi, hakika tutaishi (kurudia kabla ya kwenda kulala), lakini sasa tunahitaji kutatua matatizo mengine. Ni kama kuamini katika hadithi ya upinde wa mvua. Ndiyo, asilimia kadhaa ya kesi zinatatuliwa, na zinatatuliwa kikamilifu, lakini kwa kujitegemea, bila seva ni upinde wa mvua ... Kwangu, mada hii ni mbali sana na isiyoeleweka sana. Siko tayari kuzungumza. Mnamo 2019, huwezi kuandika programu moja bila seva.
Jinsi Kubernetes itabadilika
- Tunapoelekea katika siku zijazo za mbali zinazoweza kuwa nzuri, unafikiri Kubernetes na mfumo ikolojia unaoizunguka utastawi vipi?
Dmitry: Nimefikiria sana hili na nina jibu wazi. Ya kwanza ni ya serikali - baada ya yote, bila utaifa ni rahisi kufanya. Kubernetes hapo awali aliwekeza zaidi katika hii, yote ilianza nayo. Stateless inafanya kazi kikamilifu katika Kubernetes, hakuna chochote cha kulalamika. Bado kuna matatizo mengi, au tuseme, nuances. Kila kitu hapo tayari kinafanya kazi nzuri kwa ajili yetu, lakini ni sisi. Itachukua angalau miaka michache zaidi kwa hili kufanya kazi kwa kila mtu. Hii sio kiashiria kilichohesabiwa, lakini hisia zangu kutoka kwa kichwa changu.
Kwa kifupi, hali kamili inapaswa - na itaendelea kwa nguvu sana, kwa sababu programu zetu zote huhifadhi hali; hakuna programu zisizo na uraia. Huu ni udanganyifu; kila wakati unahitaji aina fulani ya hifadhidata na kitu kingine. Statefull ni juu ya kunyoosha kila kitu kinachowezekana, kurekebisha mende zote, kuboresha shida zote ambazo zinakabiliwa sasa - wacha tuite kupitishwa.
Kiwango cha haijulikani, kiwango cha matatizo yasiyotatuliwa, kiwango cha uwezekano wa kukutana na kitu kitashuka kwa kiasi kikubwa. Hii ni hadithi muhimu. Na waendeshaji - kila kitu kinachohusiana na uratibu wa mantiki ya usimamizi, mantiki ya kudhibiti ili kupata huduma rahisi: Huduma rahisi ya MySQL, huduma rahisi ya RabbitMQ, huduma rahisi ya Memcache - kwa ujumla, vipengele hivi vyote ambavyo tunahitaji kuhakikishiwa kufanya kazi. sanduku. Hii inasuluhisha tu maumivu kwamba tunataka hifadhidata, lakini hatutaki kuisimamia, au tunataka Kubernetes, lakini hatutaki kuisimamia.
Hadithi hii ya maendeleo ya waendeshaji kwa namna moja au nyingine itakuwa muhimu katika miaka michache ijayo.
Nadhani urahisi wa matumizi unapaswa kuongezeka sana - sanduku litakuwa nyeusi zaidi, zaidi na la kuaminika zaidi, na vifungo zaidi na rahisi zaidi.
Niliwahi kusikiliza mahojiano ya zamani na Isaac Asimov kutoka miaka ya 80 kwenye YouTube kwenye kipindi cha Saturday Night Live - programu kama Haraka, ya kuvutia tu. Walimuuliza kuhusu mustakabali wa kompyuta. Alisema kuwa siku zijazo ni rahisi, kama redio. Mpokeaji wa redio hapo awali alikuwa jambo ngumu. Ili kukamata wimbi, ilibidi ugeuze vifungo kwa dakika 15, ugeuze skewers na kwa ujumla ujue jinsi kila kitu kinavyofanya kazi, kuelewa fizikia ya maambukizi ya wimbi la redio. Kama matokeo, kulikuwa na kisu kimoja tu kwenye redio.
Sasa 2019 redio gani? Katika gari, mpokeaji wa redio hupata mawimbi yote na majina ya vituo. Fizikia ya mchakato haijabadilika kwa miaka 100, lakini urahisi wa matumizi umebadilika. Sasa, na sio sasa tu, tayari mnamo 1980, wakati kulikuwa na mahojiano na Azimov, kila mtu alitumia redio na hakuna mtu aliyefikiria jinsi inavyofanya kazi. Ilifanya kazi kila wakati - hiyo ni iliyotolewa.
Azimov kisha akasema kwamba itakuwa sawa na kompyuta - urahisi wa matumizi utaongezeka. Ingawa mnamo 1980 ilibidi ufunzwe kubonyeza vitufe kwenye kompyuta, haitakuwa hivyo katika siku zijazo.
Nina hisia kwamba kwa Kubernetes na kwa miundombinu pia kutakuwa na ongezeko kubwa la urahisi wa matumizi. Hii, kwa maoni yangu, ni dhahiri - iko juu ya uso.
Nini cha kufanya na wahandisi?
- Nini kitatokea kwa wahandisi na wasimamizi wa mfumo wanaounga mkono Kubernetes?
Dmitry: Nini kilitokea kwa mhasibu baada ya ujio wa 1C? Kuhusu sawa. Kabla ya hili, walihesabu kwenye karatasi - sasa katika programu. Uzalishaji wa kazi umeongezeka kwa amri za ukubwa, lakini kazi yenyewe haijatoweka. Ikiwa hapo awali ilichukua wahandisi 10 kufunga balbu nyepesi, sasa moja itatosha.
Kiasi cha programu na idadi ya kazi, inaonekana kwangu, sasa inakua kwa kasi zaidi kuliko DevOps mpya inavyoonekana na ufanisi unaongezeka. Kuna uhaba maalum katika soko hivi sasa na itaendelea muda mrefu. Baadaye, kila kitu kitarudi kwa aina fulani ya hali ya kawaida, ambayo ufanisi wa kazi utaongezeka, kutakuwa na zaidi na zaidi bila seva, neuron itaunganishwa na Kubernetes, ambayo itachagua rasilimali zote kama inahitajika, na kwa ujumla itakuwa. kufanya kila kitu yenyewe, kama ni lazima - mtu tu hatua mbali na si kuingilia kati.
Lakini mtu bado atahitaji kufanya maamuzi. Ni wazi kwamba kiwango cha sifa na utaalamu wa mtu huyu ni cha juu. Siku hizi, katika idara ya uhasibu, hauitaji wafanyikazi 10 wanaotunza vitabu ili mikono yao isichoke. Sio lazima tu. Nyaraka nyingi huchanganuliwa kiatomati na kutambuliwa na mfumo wa usimamizi wa hati za kielektroniki. Mhasibu mkuu mmoja mahiri anatosha, tayari ana ujuzi mkubwa zaidi, na uelewa mzuri.
Kwa ujumla, hii ndiyo njia ya kwenda katika sekta zote. Ni sawa na magari: hapo awali, gari lilikuja na fundi na madereva watatu. Siku hizi, kuendesha gari ni mchakato rahisi ambao sisi sote tunashiriki kila siku. Hakuna mtu anayefikiria kuwa gari ni kitu ngumu.
DevOps au uhandisi wa mifumo haitaondoka - kazi ya hali ya juu na ufanisi utaongezeka.
- Nilisikia pia wazo la kupendeza kwamba kazi itaongezeka.
Dmitry: Bila shaka, asilimia mia moja! Kwa sababu kiasi cha programu tunachoandika kinaongezeka mara kwa mara. Idadi ya masuala ambayo tunasuluhisha na programu inazidi kuongezeka. Kiasi cha kazi kinaongezeka. Sasa soko la DevOps limejaa joto sana. Hii inaweza kuonekana katika matarajio ya mshahara. Kwa njia nzuri, bila kuingia katika maelezo, kunapaswa kuwa na vijana wanaotaka X, watu wa kati wanaotaka 1,5X, na wazee wanaotaka 2X. Na sasa, ikiwa unatazama soko la mshahara la DevOps la Moscow, mdogo anataka kutoka X hadi 3X na mkuu anataka kutoka X hadi 3X.
Hakuna anayejua ni kiasi gani cha gharama. Kiwango cha mshahara kinapimwa na ujasiri wako - nyumba ya wazimu kamili, kuwa waaminifu, soko la joto sana.
Kwa kweli, hali hii itabadilika hivi karibuni - kueneza fulani kunapaswa kutokea. Hii sivyo ilivyo kwa maendeleo ya programu - licha ya ukweli kwamba kila mtu anahitaji watengenezaji, na kila mtu anahitaji watengenezaji wazuri, soko linaelewa ni nani anayestahili nini - sekta hiyo imetulia. Sivyo ilivyo kwa DevOps siku hizi.
- Kutoka kwa kile nilichosikia, nilihitimisha kuwa msimamizi wa mfumo wa sasa haipaswi kuwa na wasiwasi sana, lakini ni wakati wa kuboresha ujuzi wake na kujiandaa kwa ukweli kwamba kesho kutakuwa na kazi zaidi, lakini itakuwa na sifa zaidi.
Dmitry: Asilimia mia moja. Kwa ujumla, tunaishi 2019 na kanuni ya maisha ni hii: kujifunza maisha yote - tunajifunza katika maisha yetu yote. Inaonekana kwangu kuwa sasa kila mtu tayari anajua na anahisi hii, lakini haitoshi kujua - lazima uifanye. Kila siku lazima tubadilike. Ikiwa hatutafanya hivi, basi mapema au baadaye tutaachwa kwenye kando ya taaluma.
Kuwa tayari kwa zamu kali za digrii 180. Sikatai hali ambapo kitu kinabadilika sana, kitu kipya kinavumbuliwa - kinatokea. Hop! - na sasa tunatenda tofauti. Ni muhimu kuwa tayari kwa hili na usijali. Inaweza kutokea kwamba kesho kila kitu ninachofanya kitageuka kuwa sio lazima - hakuna kitu, nimesoma maisha yangu yote na niko tayari kujifunza kitu kingine. Sio shida. Hakuna haja ya kuogopa usalama wa kazi, lakini unahitaji kuwa tayari kujifunza kila wakati kitu kipya.
Matakwa na dakika ya matangazo
- Je! una hamu yoyote?
Dmitry: Ndiyo, nina matakwa kadhaa.
Kwanza na mercantile - kujiunga na . Wasomaji wapendwa, nenda kwa YouTube na ujiandikishe kwa chaneli yetu. Katika takriban mwezi mmoja tutaanza upanuzi wa kina wa huduma ya video. Tutakuwa na maudhui mengi ya kielimu kuhusu Kubernetes, yaliyo wazi na tofauti: kutoka kwa mambo ya vitendo, hadi maabara, hadi mambo ya kina ya kinadharia na jinsi ya kutumia Kubernetes kwenye kiwango cha kanuni na mifumo.
Tamaa ya pili ya mfanyabiashara - nenda kwa na kuweka nyota kwa sababu tunakula juu yao. Usipotupa nyota, hatutakuwa na chakula. Ni kama mana katika mchezo wa kompyuta. Tunafanya kitu, tunafanya, tunajaribu, mtu anasema kuwa hizi ni baiskeli za kutisha, mtu ambaye kila kitu kibaya kabisa, lakini tunaendelea na kutenda kwa uaminifu kabisa. Tunaona tatizo, kulitatua na kushiriki uzoefu wetu. Kwa hivyo, tupe nyota, haitaondoka kwako, lakini itakuja kwetu, kwa sababu tunawalisha.
Tatu, muhimu, na sio hamu tena ya kibiashara - acha kuamini hadithi za hadithi. Ninyi ni wataalamu. DevOps ni taaluma nzito na inayowajibika. Acha kucheza mahali pa kazi. Hebu ibofye kwa ajili yako na utaielewa. Fikiria kwamba unakuja hospitalini, na hapo daktari anakufanyia majaribio. Ninaelewa kuwa hii inaweza kuwa mbaya kwa mtu, lakini, uwezekano mkubwa, hii sio juu yako, lakini juu ya mtu mwingine. Waambie wengine waache pia. Hii inaharibu maisha yetu sote - wengi huanza kushughulikia shughuli, wasimamizi na DevOps kama marafiki ambao wamevunja kitu tena. Hii "ilivunjwa" mara nyingi kwa sababu ya ukweli kwamba tulienda kucheza, na hatukuangalia kwa ufahamu baridi kwa nini kilikuwa hapa na kilichokuwa hapa.
Hii haimaanishi kuwa haupaswi kufanya majaribio. Tunahitaji kufanya majaribio, tunafanya wenyewe. Kuwa waaminifu, sisi wenyewe wakati mwingine hucheza michezo - hii, bila shaka, ni mbaya sana, lakini hakuna mwanadamu ni mgeni kwetu. Hebu tutangaze mwaka wa 2019 kuwa mwaka wa majaribio mazito, yaliyofikiriwa vyema, na si michezo ya uzalishaji. Pengine hivyo.
- Asante sana!
Dmitry: Asante, Vitaly, kwa wakati na kwa mahojiano. Wasomaji wapendwa, asante sana ikiwa umefikia hatua hii ghafla. Natumai tumekuletea angalau mawazo kadhaa.
Katika mahojiano, Dmitry aligusa suala la werf. Sasa hii ni kisu cha Uswisi cha ulimwengu wote ambacho hutatua karibu shida zote. Lakini haikuwa hivyo kila wakati. Washa kwenye tamasha hilo Dmitry Stolyarov atakuambia kuhusu chombo hiki kwa undani. katika ripoti hiyo kutakuwa na kila kitu: shida na nuances zilizofichwa za Kubernetes, chaguzi za kutatua shida hizi na utekelezaji wa sasa wa werf kwa undani. Jiunge nasi tarehe 27 na 28 Mei, tutaunda zana bora kabisa.
Chanzo: mapenzi.com