Sakupin ng Kubernetes ang mundo. Kailan at paano?

Sa paghihintay DevOpsConf Vitaly Khabarov nakapanayam Dmitry Stolyarov (distol), teknikal na direktor at co-founder ng kumpanya ng Flant. Tinanong ni Vitaly si Dmitry tungkol sa kung ano ang ginagawa ng Flant, tungkol sa Kubernetes, pag-unlad ng ecosystem, suporta. Tinalakay namin kung bakit kailangan ang Kubernetes at kung kailangan ba talaga ito. At tungkol din sa mga microservice, Amazon AWS, ang "Magiging maswerte ako" na diskarte sa DevOps, ang kinabukasan mismo ng Kubernetes, bakit, kailan at paano nito sakupin ang mundo, ang mga prospect ng DevOps at kung ano ang dapat paghandaan ng mga inhinyero sa maliwanag at malapit na hinaharap na may pagpapagaan at mga neural network.

Orihinal na panayam makinig bilang podcast sa DevOps Deflop - isang podcast sa wikang Russian tungkol sa DevOps, at sa ibaba ay ang bersyon ng teksto.

Dito at sa ibaba ay nagtatanong siya Vitaly Khabarov engineer mula sa Express42.

Tungkol sa "Flant"

- Hello Dima. Ikaw ang technical director"Flant"at ang nagtatag din nito. Mangyaring sabihin sa amin kung ano ang ginagawa ng kumpanya at kung ano ka sa loob nito?

Dmitry: Mula sa labas, tila kami ang mga taong umiikot sa pag-install ng Kubernetes para sa lahat at may ginagawa dito. Ngunit hindi iyon totoo. Nagsimula kami bilang isang kumpanya na nakikitungo sa Linux, ngunit sa napakatagal na panahon ang aming pangunahing aktibidad ay ang pagseserbisyo sa produksyon at mga proyektong turnkey na may mataas na karga. Karaniwan naming itinatayo ang buong imprastraktura mula sa simula at pagkatapos ay responsable para dito sa mahabang panahon. Samakatuwid, ang pangunahing gawain na ginagawa ng "Flant", kung saan tumatanggap ito ng pera, ay pagkuha ng responsibilidad at pagpapatupad ng turnkey production.




Ako, bilang teknikal na direktor at isa sa mga tagapagtatag ng kumpanya, ay gumugugol ng buong araw at gabi sa pagsisikap na malaman kung paano dagdagan ang pagiging naa-access ng produksyon, gawing simple ang operasyon nito, gawing mas madali ang buhay ng mga administrator, at ang buhay ng mga developer ay mas kaaya-aya. .

Tungkol sa Kubernetes

— Kamakailan lamang ay marami akong nakikitang ulat mula sa Flant at Artikulo tungkol sa Kubernetes. Paano ka napunta dito?

Dmitry: Napag-usapan ko na ito ng maraming beses, ngunit wala akong balak na ulitin ito. Sa tingin ko, tama na ulitin ang paksang ito dahil may kalituhan sa pagitan ng sanhi at bunga.

Kailangan talaga namin ng tool. Marami kaming hinarap na problema, nakipaglaban, nalampasan ang mga ito gamit ang iba't ibang saklay at naramdaman ang pangangailangan para sa isang kasangkapan. Dumaan kami sa maraming iba't ibang opsyon, gumawa ng sarili naming mga bisikleta, at nagkaroon ng karanasan. Unti-unti ay dumating kami sa punto kung saan nagsimula kaming gumamit ng Docker halos sa sandaling lumitaw ito - noong 2013. Sa oras ng paglitaw nito, marami na kaming karanasan sa mga lalagyan, nagsulat na kami ng analogue ng "Docker" - ilan sa aming sariling mga saklay sa Python. Sa pagdating ng Docker, naging posible na itapon ang mga saklay at gumamit ng maaasahan at suportado ng komunidad na solusyon.

Sa Kubernetes ang kuwento ay katulad. Sa oras na nagsimula itong makakuha ng momentum - para sa amin ito ay bersyon 1.2 - mayroon na kaming isang grupo ng mga saklay sa parehong Shell at Chef, na kahit papaano ay sinubukan naming i-orchestrate sa Docker. Seryoso kaming tumitingin sa Rancher at iba't ibang mga solusyon, ngunit pagkatapos ay lumitaw ang Kubernetes, kung saan ang lahat ay ipinatupad nang eksakto tulad ng gagawin namin o mas mabuti pa. Walang dapat ireklamo.

Oo, mayroong ilang uri ng di-kasakdalan dito, mayroong ilang uri ng di-kasakdalan doon - maraming di-kasakdalan, at 1.2 sa pangkalahatan ay kakila-kilabot, ngunit... Ang Kubernetes ay parang isang gusaling itinatayo - tinitingnan mo ang proyekto at naiintindihan na ito ay magiging cool. Kung ang gusali ay mayroon na ngayong isang pundasyon at dalawang palapag, pagkatapos ay nauunawaan mo na mas mahusay na hindi pa lumipat, ngunit walang ganoong mga problema sa software - maaari mo na itong gamitin.

Wala kaming sandali kung saan naisipan naming gamitin ang Kubernetes o hindi. Matagal na namin itong hinihintay bago ito lumitaw, at sinubukan naming lumikha ng mga analogue sa aming sarili.

Tungkol sa Kubernetes

— Direktang kasangkot ka ba sa pagbuo ng Kubernetes mismo?

Dmitry: Katamtaman. Sa halip, nakikilahok tayo sa pagpapaunlad ng ecosystem. Nagpapadala kami ng tiyak na bilang ng mga kahilingan sa paghila: sa Prometheus, sa iba't ibang operator, sa Helm - sa ecosystem. Sa kasamaang palad, hindi ko masusubaybayan ang lahat ng ginagawa namin at maaaring mali ako, ngunit walang kahit isang pool mula sa amin papunta sa core.

— Kasabay nito, ginagawa mo ba ang marami sa iyong mga tool sa paligid ng Kubernetes?

Dmitry: Ang diskarte ay ito: pumunta kami at kumukuha ng mga kahilingan sa lahat ng mayroon na. Kung hindi tinatanggap ang mga pull request doon, kami na lang mismo ang nagtitinda sa kanila at nabubuhay hanggang sa matanggap sila kasama ng aming mga build. Pagkatapos, kapag umabot na ito sa upstream, babalik tayo sa upstream na bersyon.

Halimbawa, mayroon kaming operator ng Prometheus, kung saan kami ay lumipat pabalik-balik sa upstream ng aming pagpupulong marahil 5 beses na. Kailangan namin ng ilang uri ng feature, nagpadala kami ng pull request, kailangan namin itong ilunsad bukas, ngunit ayaw naming maghintay na mailabas ito sa itaas. Alinsunod dito, nagtitipon kami para sa aming sarili, ilunsad ang aming pagpupulong kasama ang aming tampok, na kailangan namin para sa ilang kadahilanan, sa lahat ng aming mga kumpol. Pagkatapos, halimbawa, ibinabalik nila ito sa amin sa upstream na may mga salitang: "Guys, let's do it for a more general case," tapusin natin, o ng ibang tao, at sa paglipas ng panahon, muli itong nagsasama.

Sinusubukan naming paunlarin ang lahat ng umiiral. Maraming elemento na wala pa, hindi pa naiimbento, o naimbento na, ngunit wala pang panahon para ipatupad - ginagawa na natin. At hindi dahil gusto namin ang proseso o paggawa ng bisikleta bilang isang industriya, ngunit dahil lang kailangan namin ang tool na ito. Madalas itanong, bakit natin ginawa ito o ang bagay na iyon? Ang sagot ay simple - oo, dahil kailangan naming pumunta pa, lutasin ang ilang praktikal na problema, at nalutas namin ito sa tula na ito.

Ang landas ay palaging ganito: maingat tayong naghahanap at, kung wala tayong mahanap na solusyon kung paano gumawa ng trolleybus mula sa isang tinapay, pagkatapos ay gumawa tayo ng sarili nating tinapay at sarili nating trolleybus.

Mga tool sa Flanta

— Alam kong mayroon na ngayong mga addon operator, shell operator, at dapp/werf tool ang Flant. Sa pagkakaintindi ko, ito ang parehong instrumento sa iba't ibang pagkakatawang-tao. Naiintindihan ko rin na marami pang iba't ibang tool sa loob ng Flaunt. Ito ay totoo?

Dmitry: Marami pa kami sa GitHub. Mula sa naaalala ko ngayon, mayroon kaming statusmap - isang panel para sa Grafana na nakita ng lahat. Nabanggit ito sa halos bawat pangalawang artikulo tungkol sa pagsubaybay ng Kubernetes sa Medium. Imposibleng maipaliwanag nang maikli kung ano ang isang statusmap - kailangan nito ng isang hiwalay na artikulo, ngunit ito ay isang napaka-kapaki-pakinabang na bagay para sa pagsubaybay sa katayuan sa paglipas ng panahon, dahil sa Kubernetes ay madalas na kailangan nating magpakita ng katayuan sa paglipas ng panahon. Mayroon din kaming LogHouse - ito ay isang bagay na batay sa ClickHouse at black magic para sa pagkolekta ng mga log sa Kubernetes.

Ang daming utility! At magkakaroon ng higit pa, dahil maraming mga panloob na solusyon ang ilalabas sa taong ito. Sa napakalaking mga batay sa addon operator, mayroong isang bungkos ng mga addon para sa Kubernetes, ala kung paano maayos na i-install ang sert manager - isang tool para sa pamamahala ng mga sertipiko, kung paano i-install nang tama ang Prometheus na may isang bungkos ng mga accessories - ito ay halos dalawampung iba't ibang mga binary na nag-e-export ng data at nangongolekta ng isang bagay, sa Prometheus na ito ay may pinakakahanga-hangang mga graphics at alerto. Ang lahat ng ito ay isang grupo lamang ng mga addon sa Kubernetes, na naka-install sa isang cluster, at ito ay lumiliko mula sa simple hanggang sa cool, sopistikado, awtomatiko, kung saan maraming mga isyu ang nalutas na. Oo, marami kaming ginagawa.

Pag-unlad ng Ecosystem

"Sa tingin ko ito ay isang napakalaking kontribusyon sa pagbuo ng instrumento na ito at ang mga pamamaraan ng paggamit nito." Maaari mo bang tantiyahin kung sino pa ang gagawa ng parehong kontribusyon sa pag-unlad ng ecosystem?

Dmitry: Sa Russia, sa mga kumpanyang nagpapatakbo sa aming merkado, walang sinuman ang malapit. Siyempre, ito ay isang malakas na pahayag, dahil may mga pangunahing manlalaro tulad ng Mail at Yandex - mayroon din silang ginagawa sa Kubernetes, ngunit kahit na hindi sila lumalapit sa kontribusyon ng mga kumpanya sa buong mundo na higit na gumagawa kaysa sa amin. Mahirap ikumpara ang Flant, na may kawani na 80 katao, at ang Red Hat, na mayroong 300 inhinyero sa bawat Kubernetes lamang, kung hindi ako nagkakamali. Mahirap ikumpara. Mayroon kaming 6 na tao sa departamento ng RnD, kasama ako, na pinutol ang lahat ng aming mga gamit. 6 na tao kumpara sa 300 inhinyero ng Red Hat - mahirap itong ikumpara.

- Gayunpaman, kapag kahit na ang 6 na tao na ito ay maaaring gumawa ng isang bagay na talagang kapaki-pakinabang at alienating, kapag sila ay nahaharap sa isang praktikal na problema at nagbibigay ng solusyon sa komunidad - isang kawili-wiling kaso. Naiintindihan ko na sa malalaking kumpanya ng teknolohiya, kung saan mayroon silang sariling Kubernetes development at support team, sa prinsipyo, ang parehong mga tool ay maaaring mabuo. Ito ay isang halimbawa para sa kanila kung ano ang maaaring paunlarin at ibigay sa komunidad, na nagbibigay ng lakas sa buong komunidad na gumagamit ng Kubernetes.

Dmitry: Ito ay marahil isang tampok ng integrator, ang kakaiba nito. Marami kaming mga proyekto at nakikita namin ang maraming iba't ibang mga sitwasyon. Para sa amin, ang pangunahing paraan upang lumikha ng karagdagang halaga ay pag-aralan ang mga kasong ito, hanapin ang pagkakatulad at gawing mura ang mga ito hangga't maaari para sa amin. Kami ay aktibong nagtatrabaho dito. Mahirap para sa akin na pag-usapan ang tungkol sa Russia at sa mundo, ngunit mayroon kaming humigit-kumulang 40 DevOps engineer sa kumpanyang nagtatrabaho sa Kubernetes. Sa palagay ko ay hindi maraming kumpanya sa Russia na may maihahambing na bilang ng mga espesyalista na nakakaunawa sa Kubernetes, kung mayroon man.

Naiintindihan ko ang lahat tungkol sa job title na DevOps engineer, naiintindihan ng lahat ang lahat at nakasanayan na nilang tawagan ang mga DevOps engineer na DevOps engineer, hindi natin ito tatalakayin. Lahat ng 40 kahanga-hangang DevOps engineer na ito ay nahaharap at nilulutas ang mga problema araw-araw, sinusuri lang namin ang karanasang ito at sinusubukang i-generalize. Naiintindihan namin na kung mananatili ito sa loob natin, pagkatapos ay sa isang taon o dalawa ang tool ay magiging walang silbi, dahil sa isang lugar sa komunidad ay lilitaw ang isang handa na Tula. Walang saysay ang pag-iipon ng karanasang ito sa loob - ito ay nag-uubos lamang ng enerhiya at oras sa dev/null. At hindi kami naawa para dito. Ini-publish namin ang lahat nang may labis na kasiyahan at nauunawaan na kailangan itong i-publish, i-develop, i-promote, i-promote, upang gamitin ito ng mga tao at idagdag ang kanilang karanasan - pagkatapos ang lahat ay lumalaki at nabubuhay. Pagkatapos ng dalawang taon ang instrumento ay hindi napupunta sa basurahan. Hindi nakakalungkot na magpatuloy sa pagbuhos ng lakas, dahil malinaw na may gumagamit ng iyong tool, at pagkatapos ng dalawang taon lahat ay gumagamit nito.

Ito ay bahagi ng aming malaking diskarte sa dapp/werf. I don’t remember when we started making it, parang 3 years ago. Sa una, ito ay karaniwang nasa shell. Ito ay isang sobrang patunay ng konsepto, nalutas namin ang ilan sa aming mga partikular na problema - gumana ito! Ngunit may mga problema sa shell, imposibleng palawakin pa ito, ang programming sa shell ay isa pang gawain. Nakagawian namin ang pagsusulat sa Ruby, ayon dito, gumawa kami ng isang bagay sa Ruby, binuo, binuo, binuo, at tumakbo sa katotohanan na ang komunidad, ang karamihan ng tao na hindi nagsasabi na "gusto namin o ayaw namin, ” tumaas ang ilong nito kay Ruby, nakakatawa ba iyon? Napagtanto namin na dapat naming isulat ang lahat ng bagay na ito sa Go para lang matugunan ang unang punto sa checklist: Ang tool ng DevOps ay dapat na isang static na binary. Ang maging Go o hindi ay hindi napakahalaga, ngunit ang isang static na binary na nakasulat sa Go ay mas mahusay.

Ginugol namin ang aming lakas, muling isinulat ang dapp sa Go at tinawag itong werf. Ang Dapp ay hindi na suportado, hindi binuo, tumatakbo sa ilang pinakabagong bersyon, ngunit mayroong ganap na landas sa pag-upgrade sa itaas, at maaari mo itong sundin.

Bakit nilikha ang dapp?

— Maaari mo bang sabihin sa amin nang maikli kung bakit nilikha ang dapp, anong mga problema ang nalulutas nito?

Dmitry: Ang unang dahilan ay sa kapulungan. Sa una, nagkaroon kami ng mga seryosong problema sa build noong walang multi-stage na kakayahan ang Docker, kaya gumawa kami ng multi-stage nang mag-isa. Pagkatapos ay nagkaroon kami ng marami pang isyu sa paglilinis ng larawan. Ang bawat isa na gumagawa ng CI/CD, mas maaga kaysa sa huli, ay nahaharap sa problema na mayroong isang grupo ng mga nakolektang larawan, kailangan mong kahit papaano ay linisin ang hindi kailangan at iwanan ang kailangan.

Ang pangalawang dahilan ay deployment. Oo, mayroong Helm, ngunit nalulutas lamang nito ang ilan sa mga problema. Nakakatuwa, nakasulat na "Helm is the Package Manager for Kubernetes." Eksakto kung ano ang "ang". Mayroon ding mga salitang "Package Manager" - ano ang karaniwang inaasahan mula sa isang Package Manager? Sinasabi namin: "Package Manager - i-install ang package!" at inaasahan naming sasabihin niya sa amin: "Naihatid na ang pakete."

Ito ay kagiliw-giliw na sinasabi namin: "Helm, i-install ang package," at kapag sumagot siya na na-install niya ito, lumalabas na nagsimula lang siya sa pag-install - ipinahiwatig niya ang Kubernetes: "Ilunsad ang bagay na ito!", at kung nagsimula ito o hindi. , gumagana man ito o hindi , hindi nireresolba ng Helm ang isyung ito.

Lumalabas na ang Helm ay isang text preprocessor lang na naglo-load ng data sa Kubernetes.

Ngunit bilang bahagi ng anumang deployment, gusto naming malaman kung ang application ay inilabas para sa produksyon o hindi? Ang ibig sabihin ng rolled out to prod ay lumipat na ang application doon, na-deploy na ang bagong bersyon, at least hindi ito nag-crash doon at tumutugon nang tama. Hindi malulutas ng timon ang problemang ito sa anumang paraan. Upang malutas ito, kailangan mong gumastos ng maraming pagsisikap, dahil kailangan mong bigyan ang Kubernetes ng utos na ilunsad at subaybayan kung ano ang nangyayari doon - kung ito ay na-deploy o inilunsad. At mayroon ding maraming mga gawain na nauugnay sa pag-deploy, paglilinis, at pagpupulong.

Mga Plano

Sa taong ito ay sisimulan natin ang lokal na pag-unlad. Gusto naming makamit ang dati sa Vagrant - nag-type kami ng "vagrant up" at nag-deploy kami ng mga virtual machine. Nais naming makarating sa punto kung saan mayroong isang proyekto sa Git, nagsusulat kami ng "werf up" doon, at naglalabas ito ng isang lokal na kopya ng proyektong ito, na na-deploy sa isang lokal na mini-Kub, kasama ang lahat ng mga direktoryo na maginhawa para sa pag-unlad na konektado. . Depende sa wika ng pag-unlad, ito ay ginagawa sa ibang paraan, ngunit gayunpaman, upang ang lokal na pag-unlad ay maginhawang maisagawa sa ilalim ng mga naka-mount na file.

Ang susunod na hakbang para sa amin ay mamuhunan sa kaginhawahan para sa mga developer. Upang mabilis na mag-deploy ng isang proyekto nang lokal gamit ang isang tool, i-develop ito, itulak ito sa Git, at lalabas din ito sa entablado o mga pagsubok, depende sa mga pipeline, at pagkatapos ay gamitin ang parehong tool upang pumunta sa produksyon. Ang pagkakaisa, pag-iisa, muling paggawa ng imprastraktura mula sa lokal na kapaligiran hanggang sa pagbebenta ay isang napakahalagang punto para sa amin. Ngunit wala pa ito sa werf - pinaplano lang namin itong gawin.

Ngunit ang landas patungo sa dapp/werf ay palaging pareho sa Kubernetes sa simula. Nakatagpo kami ng mga problema, nalutas ang mga ito gamit ang mga workaround - nakagawa kami ng ilang mga solusyon para sa aming sarili sa shell, sa anumang bagay. Pagkatapos ay sinubukan nilang ituwid ang mga workaround na ito, gawing pangkalahatan at pagsama-samahin ang mga ito sa mga binary sa kasong ito, na ibinabahagi lang namin.

May isa pang paraan upang tingnan ang buong kuwentong ito, na may mga pagkakatulad.

Ang Kubernetes ay isang car frame na may makina. Walang mga pinto, salamin, radyo, Christmas tree - wala talaga. Ang frame at makina lang. At mayroong Helm - ito ang manibela. Cool - mayroong manibela, ngunit kailangan mo rin ng steering pin, steering rack, gearbox at mga gulong, at hindi mo magagawa nang wala ang mga ito.

Sa kaso ng werf, ito ay isa pang bahagi sa Kubernetes. Ngayon lang sa alpha version ng werf, halimbawa, ang Helm ay pinagsama-sama sa loob ng werf, dahil pagod na kaming gawin ito sa aming sarili. Maraming dahilan para gawin ito, sasabihin ko sa iyo nang detalyado kung bakit namin pinagsama-sama ang buong timon kasama ng tiller inside werf sa isang ulat sa RIT++.

Ngayon ang werf ay isang mas pinagsamang bahagi. Nakakuha kami ng tapos na manibela, isang steering pin - Hindi ako masyadong magaling sa mga kotse, ngunit ito ay isang malaking bloke na nalulutas na ang isang medyo malawak na hanay ng mga problema. Hindi namin kailangang dumaan sa catalog sa aming sarili, pumili ng isang bahagi para sa isa pa, isipin kung paano i-screw ang mga ito. Makakakuha kami ng isang handa na pagsasama na malulutas ang isang malaking bilang ng mga problema nang sabay-sabay. Ngunit sa loob nito ay binuo mula sa parehong open source na mga bahagi, ginagamit pa rin nito ang Docker para sa pagpupulong, Helm para sa ilan sa mga pag-andar, at may ilang iba pang mga aklatan. Ito ay isang pinagsamang tool upang mabilis at maginhawang mailabas sa kahon ang cool na CI/CD.

Mahirap bang i-maintain ang Kubernetes?

— Pinag-uusapan mo ang karanasan na nagsimula kang gumamit ng Kubernetes, ito ay isang frame para sa iyo, isang makina, at maaari mong isabit ang maraming iba't ibang bagay dito: isang katawan, isang manibela, mga turnilyo sa mga pedal, mga upuan. Ang tanong ay lumitaw - gaano kahirap ang suporta ng Kubernetes para sa iyo? Marami kang karanasan, gaano karaming oras at mapagkukunan ang ginugugol mo sa pagsuporta sa Kubernetes nang hiwalay sa lahat ng iba pa?

Dmitry: Ito ay isang napakahirap na tanong at upang sagutin, kailangan nating maunawaan kung ano ang suporta at kung ano ang gusto natin mula sa Kubernetes. Baka pwede mong ibunyag?

— Sa pagkakaalam ko at sa nakikita ko, ngayon maraming team ang gustong subukan ang Kubernetes. Ang bawat tao'y harnesses kanilang sarili sa ito, ilagay ito sa kanilang mga tuhod. May pakiramdam ako na hindi palaging naiintindihan ng mga tao ang pagiging kumplikado ng sistemang ito.

Dmitry: Parang ganun.

— Gaano kahirap kunin at i-install ang Kubernetes mula sa simula upang ito ay handa na sa produksyon?

Dmitry: Gaano kahirap sa tingin mo ang mag-transplant ng puso? Naiintindihan ko na ito ay isang kompromiso na tanong. Ang paggamit ng scalpel at hindi nagkakamali ay hindi ganoon kahirap. Kung sasabihin nila sa iyo kung saan i-cut at kung saan magtahi, kung gayon ang pamamaraan mismo ay hindi kumplikado. Mahirap tiyakin sa bawat oras na magiging maayos ang lahat.

Ang pag-install ng Kubernetes at pagpapagana nito ay madali: sisiw! — naka-install, mayroong maraming mga paraan ng pag-install. Ngunit ano ang mangyayari kapag lumitaw ang mga problema?

Palaging lumitaw ang mga tanong - ano ang hindi pa natin isinasaalang-alang? Ano ang hindi pa natin nagagawa? Aling mga parameter ng Linux kernel ang natukoy nang hindi tama? Lord, nabanggit ba natin sila?! Aling mga bahagi ng Kubernetes ang naihatid namin at alin ang hindi pa namin? Libu-libong mga katanungan ang lumitaw, at upang masagot ang mga ito, kailangan mong gumastos ng 15-20 taon sa industriyang ito.

Mayroon akong kamakailang halimbawa sa paksang ito na maaaring magbunyag ng kahulugan ng problemang "Mahirap bang panatilihin ang Kubernetes?" Noong nakaraan, seryoso naming pinag-isipan kung dapat naming subukang ipatupad ang Cilium bilang isang network sa Kubernetes.

Hayaan akong ipaliwanag kung ano ang Cilium. Ang Kubernetes ay may maraming iba't ibang mga pagpapatupad ng networking subsystem, at isa sa mga ito ay napaka-cool - Cilium. Ano ang kahulugan nito? Sa kernel, ilang oras na ang nakalipas naging posible na magsulat ng mga kawit para sa kernel, na sa isang paraan o iba pa ay sumalakay sa network subsystem at iba't ibang mga subsystem, at pinapayagan kang i-bypass ang malalaking tipak sa kernel.

Ang Linux kernel sa kasaysayan ay may ip rout, isang overfilter, mga tulay at maraming iba't ibang lumang bahagi na 15, 20, 30 taong gulang. Sa pangkalahatan, gumagana ang mga ito, lahat ay mahusay, ngunit ngayon ay nakasalansan nila ang mga lalagyan, at mukhang isang tore ng 15 na mga brick sa ibabaw ng bawat isa, at nakatayo ka sa isang binti - isang kakaibang pakiramdam. Ang sistemang ito ay nabuo sa kasaysayan na may maraming mga nuances, tulad ng apendiks sa katawan. Sa ilang sitwasyon, may mga isyu sa pagganap, halimbawa.

Mayroong isang kahanga-hangang BPF at ang kakayahang magsulat ng mga kawit para sa kernel - ang mga lalaki ay nagsulat ng kanilang sariling mga kawit para sa kernel. Ang package ay pumapasok sa Linux kernel, inilabas nila ito sa mismong input, pinoproseso ito sa kanilang sarili nang walang mga tulay, walang TCP, walang IP stack - sa madaling salita, nilalampasan ang lahat ng nakasulat sa Linux kernel, at pagkatapos ay dumura ilabas ito sa lalagyan.

Anong nangyari? Napaka-cool na performance, cool na feature - cool lang! Ngunit tinitingnan namin ito at nakikita na sa bawat makina ay mayroong isang programa na kumokonekta sa Kubernetes API at, batay sa data na natatanggap nito mula sa API na ito, bumubuo ng C code at nag-compile ng mga binary na nilo-load nito sa kernel upang gumana ang mga hook na ito. sa kernel space.

Ano ang mangyayari kung may mali? Hindi namin alam. Upang maunawaan ito, kailangan mong basahin ang lahat ng code na ito, maunawaan ang lahat ng lohika, at kamangha-mangha kung gaano ito kahirap. Ngunit, sa kabilang banda, may mga tulay na ito, net filter, ip rout - Hindi ko pa nabasa ang source code nila, at wala rin ang 40 engineer na nagtatrabaho sa aming kumpanya. Siguro iilan lang ang nakakaintindi ng ilang bahagi.

At ano ang pagkakaiba? Lumalabas na mayroong ip rout, ang Linux kernel, at mayroong isang bagong tool - kung ano ang pagkakaiba nito, hindi namin naiintindihan ang isa o ang isa pa. Ngunit natatakot kaming gumamit ng bago - bakit? Dahil kung ang tool ay 30 taong gulang, pagkatapos ay sa 30 taon ang lahat ng mga bug ay natagpuan, ang lahat ng mga pagkakamali ay natapakan at hindi mo kailangang malaman ang tungkol sa lahat - ito ay gumagana tulad ng isang itim na kahon at palaging gumagana. Alam ng lahat kung aling diagnostic screwdriver ang idikit sa kung aling lugar, kung aling tcpdump ang tatakbo sa anong oras. Alam ng lahat ang mga diagnostic utilities at nauunawaan kung paano gumagana ang hanay ng mga bahagi na ito sa kernel ng Linux - hindi kung paano ito gumagana, ngunit kung paano ito gamitin.

At ang awesomely cool na Cilium ay wala pang 30 taong gulang, hindi pa ito matanda. Ang Kubernetes ay may parehong problema, kopyahin. Na ang Cilium ay ganap na naka-install, na ang Kubernetes ay ganap na naka-install, ngunit kapag may nangyaring mali sa produksyon, mabilis mo bang naiintindihan sa isang kritikal na sitwasyon kung ano ang nangyari?

Kapag sinabi nating mahirap i-maintain ang Kubernetes - hindi, napakadali nito, at oo, napakahirap. Mahusay na gumagana ang Kubernetes sa sarili nitong, ngunit may isang bilyong nuances.

Tungkol sa "I'll be lucky" approach

— Mayroon bang mga kumpanya kung saan halos garantisadong lalabas ang mga nuances na ito? Ipagpalagay na biglang inilipat ng Yandex ang lahat ng mga serbisyo sa Kubernetes, magkakaroon ng malaking load doon.

Dmitry: Hindi, ito ay hindi isang pag-uusap tungkol sa pagkarga, ngunit tungkol sa mga pinakasimpleng bagay. Halimbawa, mayroon kaming Kubernetes, na-deploy namin ang application doon. Paano mo malalaman na ito ay gumagana? Walang simpleng tool para maunawaan na hindi nag-crash ang application. Walang handa na sistema na nagpapadala ng mga alerto; kailangan mong i-configure ang mga alertong ito at ang bawat iskedyul. At ina-update namin ang Kubernetes.

Mayroon akong Ubuntu 16.04. Maaari mong sabihin na ito ay isang lumang bersyon, ngunit kami ay pa rin dito dahil ito ay LTS. Mayroong systemd, ang nuance nito ay hindi nito nililinis ang mga C-group. Ang Kubernetes ay naglulunsad ng mga pod, gumagawa ng mga C-group, pagkatapos ay nagde-delete ng mga pod, at kahit papaano ay lumalabas ito - Hindi ko maalala ang mga detalye, paumanhin - na nananatili ang mga systemd slice. Ito ay humahantong sa katotohanan na sa paglipas ng panahon, ang anumang sasakyan ay nagsisimulang bumagal nang malakas. Ito ay hindi kahit isang tanong tungkol sa highload. Kung ang mga permanenteng pod ay inilunsad, halimbawa, kung mayroong isang Cron Job na patuloy na bumubuo ng mga pod, ang makina na may Ubuntu 16.04 ay magsisimulang bumagal pagkatapos ng isang linggo. Magkakaroon ng patuloy na mataas na average ng load dahil sa katotohanan na isang grupo ng mga C-group ang nagawa. Ito ang problemang haharapin ng sinumang tao na simpleng nag-i-install ng Ubuntu 16 at Kubernetes sa itaas.

Sabihin natin na kahit papaano ay nag-a-update siya ng systemd o iba pa, ngunit sa Linux kernel hanggang 4.16 ito ay mas nakakatawa - kapag tinanggal mo ang mga C-group, tumagas ang mga ito sa kernel at hindi talaga natanggal. Samakatuwid, pagkatapos ng isang buwan ng pagtatrabaho sa makinang ito, imposibleng tingnan ang mga istatistika ng memorya para sa mga apuyan. Kumuha kami ng isang file, i-roll ito sa programa, at ang isang file ay gumulong sa loob ng 15 segundo, dahil ang kernel ay tumatagal ng napakatagal na oras upang mabilang ang isang milyong C-group sa loob mismo, na tila natanggal, ngunit hindi - sila ay tumutulo .

Marami pa ring ganoong maliliit na bagay dito at doon. Ito ay hindi isang isyu na kung minsan ay maaaring harapin ng mga higanteng kumpanya sa ilalim ng napakabigat na kargada - hindi, ito ay isang bagay ng pang-araw-araw na bagay. Maaaring mamuhay ng ganito ang mga tao sa loob ng ilang buwan - nag-install sila ng Kubernetes, nag-deploy ng application - mukhang gumagana ito. Para sa maraming tao ito ay normal. Hindi nila malalaman na ang application na ito ay mag-crash sa ilang kadahilanan, hindi sila makakatanggap ng isang alerto, ngunit para sa kanila ito ang pamantayan. Dati, nakatira kami sa mga virtual machine nang walang pagsubaybay, ngayon lumipat kami sa Kubernetes, wala ring pagsubaybay - ano ang pagkakaiba?

Ang tanong ay kapag naglalakad tayo sa yelo, hindi natin malalaman ang kapal nito maliban kung sinusukat natin ito nang maaga. Maraming tao ang naglalakad at huwag mag-alala, dahil nakalakad na sila noon.

Mula sa aking pananaw, ang nuance at pagiging kumplikado ng pagpapatakbo ng anumang system ay upang matiyak na ang kapal ng yelo ay eksaktong sapat upang malutas ang aming mga problema. Ito ang pinag-uusapan natin.

Sa IT, parang sa akin, napakaraming "I'll be lucky" approaches. Maraming tao ang nag-i-install ng software at gumagamit ng mga software library sa pag-asa na sila ay mapalad. Sa pangkalahatan, maraming tao ang masuwerte. Iyon ay marahil kung bakit ito gumagana.

— Mula sa aking pessimistic na pagtatasa, ganito ang hitsura: kapag mataas ang mga panganib, at dapat gumana ang aplikasyon, kailangan ang suporta mula sa Flaunt, marahil mula sa Red Hat, o kailangan mo ng iyong sariling panloob na koponan na partikular na nakatuon sa Kubernetes, na handa na para hilahin ito.

Dmitry: Sa layunin, ito ay gayon. Ang pagpasok sa kuwento ng Kubernetes para sa isang maliit na koponan sa iyong sarili ay nagsasangkot ng ilang mga panganib.

Kailangan ba natin ng mga lalagyan?

— Maaari mo bang sabihin sa amin kung gaano kalawak ang Kubernetes sa Russia?

Dmitry: Wala akong data na ito, at hindi ako sigurado na mayroon nito ang iba. Sinasabi namin: "Kubernetes, Kubernetes," ngunit may isa pang paraan ng pagtingin sa isyung ito. Hindi ko rin alam kung gaano kalawak ang mga container, ngunit may alam akong figure mula sa mga ulat sa Internet na 70% ng mga container ay inayos ng Kubernetes. Ito ay isang maaasahang mapagkukunan para sa isang medyo malaking sample sa buong mundo.

Pagkatapos ng isa pang tanong - kailangan ba natin ng mga lalagyan? Ang aking personal na pakiramdam at ang pangkalahatang posisyon ng kumpanya ng Flant ay ang Kubernetes ay isang de facto na pamantayan.

Walang iba kundi Kubernetes.

Ito ay isang ganap na game-changer sa larangan ng pamamahala ng imprastraktura. Basta absolute - iyon lang, wala nang Ansible, Chef, virtual machine, Terraform. Hindi ko pinag-uusapan ang mga lumang pamamaraan ng kolektibong sakahan. Ang Kubernetes ay isang ganap na nagbabago, at ngayon ay magiging ganito na lamang.

Malinaw na para sa ilan ay tumatagal ng ilang taon, at para sa iba ng ilang dekada, upang mapagtanto ito. Wala akong duda na walang iba kundi ang Kubernetes at ang bagong hitsura na ito: hindi na namin sinisira ang operating system, ngunit ginagamit imprastraktura bilang code, hindi lamang gamit ang code, ngunit may yml - isang deklaratibong inilarawan na imprastraktura. Feeling ko magiging ganito palagi.

— Ibig sabihin, iyong mga kumpanyang hindi pa lumilipat sa Kubernetes ay tiyak na lilipat dito o mananatili sa limot. Naintindihan kita ng tama?

Dmitry: Ito ay hindi rin ganap na totoo. Halimbawa, kung mayroon tayong gawain na magpatakbo ng DNS server, maaari itong patakbuhin sa FreeBSD 4.10 at maaari itong gumana nang perpekto sa loob ng 20 taon. Trabaho lang at iyon na. Marahil sa loob ng 20 taon ay may kailangang i-update nang isang beses. Kung pinag-uusapan natin ang software sa format na inilunsad namin at talagang gumagana ito nang maraming taon nang walang anumang mga update, nang hindi gumagawa ng mga pagbabago, kung gayon, siyempre, walang Kubernetes. Hindi siya kailangan doon.

Lahat ng nauugnay sa CI/CD - saanman kailangan ang Tuloy-tuloy na Paghahatid, kung saan kailangan mong mag-update ng mga bersyon, gumawa ng mga aktibong pagbabago, saanman kailangan mong bumuo ng fault tolerance - Kubernetes lang.

Tungkol sa mga microservice

- Narito mayroon akong bahagyang dissonance. Upang gumana sa Kubernetes, kailangan mo ng panlabas o panloob na suporta - ito ang unang punto. Pangalawa, kapag nagsisimula pa lang tayo sa pag-unlad, tayo ay isang maliit na startup, wala pa tayong kahit ano, ang pag-unlad para sa Kubernetes o microservice architecture sa pangkalahatan ay maaaring maging kumplikado at hindi palaging makatwiran sa ekonomiya. Interesado ako sa iyong opinyon - kailangan ba ng mga startup na agad na magsimulang magsulat para sa Kubernetes mula sa simula, o maaari pa rin silang magsulat ng isang monolith, at pagkatapos ay pupunta lamang sa Kubernetes?

Dmitry: Cool na tanong. May usapan ako tungkol sa microservices "Mga Microservice: Mahalaga ang Sukat." Maraming beses akong nakatagpo ng mga taong sinusubukang magmartilyo ng mga kuko gamit ang isang mikroskopyo. Ang diskarte mismo ay tama; kami mismo ang nagdidisenyo ng aming panloob na software sa ganitong paraan. Ngunit kapag ginawa mo ito, kailangan mong malinaw na maunawaan kung ano ang iyong ginagawa. Ang salitang pinakaayaw ko tungkol sa mga microservice ay "micro." Sa kasaysayan, ang salitang ito ay nagmula doon, at sa ilang kadahilanan ay iniisip ng mga tao na ang micro ay napakaliit, mas mababa sa isang milimetro, tulad ng isang micrometer. Mali ito.

Halimbawa, mayroong isang monolith na isinulat ng 300 katao, at naiintindihan ng lahat na lumahok sa pag-unlad na mayroong mga problema doon, at dapat itong hatiin sa mga micro-piraso - mga 10 piraso, bawat isa ay isinulat ng 30 katao. sa pinakamababang bersyon. Ito ay mahalaga, kailangan at cool. Ngunit kapag ang isang startup ay dumating sa amin, kung saan 3 napaka-cool at mahuhusay na lalaki ay sumulat ng 60 microservice sa kanilang mga tuhod, sa tuwing hahanapin ko ang Corvalol.

Tila sa akin na ito ay napag-usapan na tungkol sa libu-libong beses - nakakuha kami ng isang ibinahagi na monolith sa isang anyo o iba pa. Hindi ito makatwiran sa ekonomiya, napakahirap sa pangkalahatan sa lahat. I’ve just seen this so many times that it really hurts me, so I continue to talk about it.

Sa paunang tanong, mayroong isang salungatan sa pagitan ng katotohanan na, sa isang banda, ang Kubernetes ay nakakatakot gamitin, dahil hindi malinaw kung ano ang maaaring masira doon o hindi gumana, sa kabilang banda, malinaw na ang lahat ay napupunta doon at walang iiral kundi Kubernetes . Sagot - timbangin ang halaga ng benepisyong darating, ang dami ng mga gawain na maaari mong lutasin. Ito ay nasa isang bahagi ng sukat. Sa kabilang banda, may mga panganib na nauugnay sa downtime o sa pagbaba sa oras ng pagtugon, antas ng kakayahang magamit - na may pagbaba sa mga tagapagpahiwatig ng pagganap.

Narito ito - maaaring mabilis kaming kumilos, at pinapayagan kami ng Kubernetes na gawin ang maraming bagay nang mas mabilis at mas mahusay, o gumagamit kami ng maaasahan, nasubok sa oras na mga solusyon, ngunit kumilos nang mas mabagal. Ito ay isang pagpipilian na dapat gawin ng bawat kumpanya. Maaari mong isipin ito bilang isang landas sa gubat - kapag lumakad ka sa unang pagkakataon, maaari kang makatagpo ng isang ahas, isang tigre o isang baliw na badger, at kapag nakalakad ka ng 10 beses, tinahak mo ang landas, tinanggal. ang mga sanga at mas madaling maglakad. Sa bawat oras na ang landas ay nagiging mas malawak. Pagkatapos ito ay isang aspalto na kalsada, at kalaunan ay isang magandang boulevard.

Hindi tumitigil ang Kubernetes. Tanong muli: Ang Kubernetes, sa isang banda, ay 4-5 binary, sa kabilang banda, ito ay ang buong ecosystem. Ito ang operating system na mayroon kami sa aming mga makina. Ano ito? Ubuntu o Curios? Ito ang Linux kernel, isang grupo ng mga karagdagang bahagi. Ang lahat ng mga bagay na ito dito, isang makamandag na ahas ang itinapon sa kalsada, isang bakod ang itinayo doon. Ang Kubernetes ay umuunlad nang napakabilis at dynamic, at ang dami ng mga panganib, ang dami ng hindi alam ay bumababa bawat buwan at, nang naaayon, ang mga kaliskis na ito ay muling nagbabalanse.

Pagsagot sa tanong kung ano ang dapat gawin ng isang startup, sasabihin ko - pumunta sa Flaunt, magbayad ng 150 libong rubles at makakuha ng isang turnkey DevOps madaling serbisyo. Kung ikaw ay isang maliit na startup na may ilang mga developer, ito ay gumagana. Sa halip na kumuha ng sarili mong mga DevOps, na kakailanganing matutunan kung paano lutasin ang iyong mga problema at magbayad ng suweldo sa oras na ito, makakakuha ka ng isang turnkey na solusyon sa lahat ng mga isyu. Oo, may ilang mga disadvantages. Kami, bilang isang outsourcer, ay hindi maaaring makasali at mabilis na tumugon sa mga pagbabago. Ngunit marami kaming kadalubhasaan at mga nakahanda nang kasanayan. Ginagarantiya namin na sa anumang sitwasyon ay tiyak na mabilis naming malalaman ito at ibabangon ang sinumang Kubernete mula sa mga patay.

Lubos kong inirerekumenda ang pag-outsourcing sa mga startup at itinatag na mga negosyo hanggang sa isang sukat kung saan maaari mong italaga ang isang pangkat ng 10 tao sa mga operasyon, dahil kung hindi, walang saysay. Tiyak na makatuwiran na i-outsource ito.

Tungkol sa Amazon at Google

— Maaari bang ituring ang isang host mula sa isang solusyon mula sa Amazon o Google bilang isang outsource?

Dmitry: Oo, siyempre, malulutas nito ang ilang isyu. Ngunit muli may mga nuances. Kailangan mo pa ring maunawaan kung paano ito gamitin. Halimbawa, mayroong isang libong maliliit na bagay sa trabaho ng Amazon AWS: ang Load Balancer ay kailangang painitin o kailangang isulat nang maaga ang isang kahilingan na "guys, makakatanggap kami ng trapiko, painitin ang Load Balancer para sa amin!" Kailangan mong malaman ang mga nuances na ito.

Kapag bumaling ka sa mga taong dalubhasa dito, maisasara mo ang halos lahat ng karaniwang bagay. Mayroon na tayong 40 na mga inhinyero, sa pagtatapos ng taon ay malamang na magkakaroon ng 60 - tiyak na nakatagpo natin ang lahat ng mga bagay na ito. Kahit na makaharap muli ang problemang ito sa ilang proyekto, mabilis kaming nagtatanong sa isa't isa at alam namin kung paano ito lutasin.

Marahil ang sagot ay - siyempre, ang isang naka-host na kuwento ay nagpapadali sa ilang bahagi. Ang tanong ay kung handa ka bang magtiwala sa mga hoster na ito at kung malulutas ba nila ang iyong mga problema. Mahusay ang ginawa ng Amazon at Google. Para sa lahat ng aming mga kaso - eksakto. Wala na kaming mga positibong karanasan. Ang lahat ng iba pang ulap na sinubukan naming magtrabaho ay lumikha ng maraming problema - Ager, at lahat ng nasa Russia, at lahat ng uri ng OpenStack sa iba't ibang pagpapatupad: Headster, Overage - kahit anong gusto mo. Lahat sila ay gumagawa ng mga problema na hindi mo gustong lutasin.

Samakatuwid, ang sagot ay oo, ngunit, sa katunayan, walang masyadong mature na naka-host na mga solusyon.

Sino ang nangangailangan ng Kubernetes?

— At gayon pa man, sino ang nangangailangan ng Kubernetes? Sino ang dapat na lumipat sa Kubernetes, sino ang tipikal na kliyente ng Flaunt na partikular na dumarating para sa Kubernetes?

Dmitry: Ito ay isang kawili-wiling tanong, dahil sa ngayon, pagkatapos ng Kubernetes, maraming tao ang pumupunta sa amin: "Guys, alam namin na ginagawa mo ang Kubernetes, gawin mo ito para sa amin!" Sinasagot namin sila: "Mga ginoo, hindi kami gumagawa ng mga Kubernetes, ginagawa namin ang pag-uudyok at lahat ng nauugnay dito." Dahil sa kasalukuyan ay imposible lamang na gumawa ng isang produkto nang hindi ginagawa ang lahat ng CI/CD at ang buong kuwentong ito. Ang bawat isa ay lumayo sa dibisyon na mayroon tayong pag-unlad sa pamamagitan ng pag-unlad, at pagkatapos ay pagsasamantala sa pamamagitan ng pagsasamantala.

Inaasahan ng aming mga kliyente ang iba't ibang mga bagay, ngunit ang lahat ay naghihintay para sa ilang magandang himala na mayroon silang ilang mga problema, at ngayon - hop! — Lulutas sila ng mga Kubernetes. Naniniwala ang mga tao sa mga himala. Sa kanilang isipan ay naiintindihan nila na walang mangyayaring milagro, ngunit sa kanilang mga kaluluwa ay umaasa sila - paano kung itong mga Kubernete na ito ang lutasin ang lahat para sa atin, ang dami nilang pinag-uusapan! Biglang siya ngayon - bumahing! - at isang pilak na bala, bumahing! — at mayroon kaming 100% uptime, lahat ng mga developer ay maaaring maglabas ng anuman sa produksyon ng 50 beses, at hindi ito nag-crash. Sa pangkalahatan, isang himala!

Kapag lumapit sa atin ang gayong mga tao, sasabihin natin: “Paumanhin, ngunit walang himala.” Upang maging malusog, kailangan mong kumain ng maayos at mag-ehersisyo. Upang magkaroon ng maaasahang produkto, kailangan itong gawin nang mapagkakatiwalaan. Upang magkaroon ng maginhawang CI/CD, kailangan mong gawin itong ganito. Iyan ay maraming trabaho na kailangang gawin.

Pagsagot sa tanong kung sino ang nangangailangan ng Kubernetes - walang nangangailangan ng Kubernetes.

May maling akala ang ilang tao na kailangan nila ng Kubernetes. Kailangan ng mga tao, mayroon silang malalim na pangangailangan na huminto sa pag-iisip, pag-aaral, at pagiging interesado sa lahat ng mga problema ng imprastraktura at mga problema sa pagpapatakbo ng kanilang mga aplikasyon. Gusto nilang gumana lang ang mga application at i-deploy lang. Para sa kanila, ang Kubernetes ay ang pag-asa na itigil na nila ang pagdinig sa kuwento na "nakahiga kami doon," o "hindi kami makakalabas," o iba pa.

Karaniwang pumupunta sa amin ang technical director. Tinanong nila siya ng dalawang bagay: sa isang banda, bigyan kami ng mga tampok, sa kabilang banda, katatagan. Iminumungkahi namin na tanggapin mo ito sa iyong sarili at gawin ito. Ang pilak na bala, o sa halip ay pinilak-pilak, ay titigil ka sa pag-iisip tungkol sa mga problemang ito at pag-aaksaya ng oras. Magkakaroon ka ng mga espesyal na tao na magsasara ng isyung ito.

Ang mga salita na kailangan natin o ng sinuman sa Kubernetes ay hindi tama.

Kailangan talaga ng mga admin ang Kubernetes, dahil ito ay isang napaka-interesante na laruan na maaari mong paglaruan at paglalaruan. Maging tapat tayo - lahat ay mahilig sa mga laruan. Lahat tayo ay mga bata sa isang lugar, at kapag nakakita tayo ng bago, gusto nating laruin ito. Para sa ilan, ito ay pinanghinaan ng loob, halimbawa, sa administrasyon, dahil naglaro na sila ng sapat at pagod na sa punto na ayaw na nila. Ngunit hindi ito ganap na nawala sa sinuman. Halimbawa, kung pagod na ako sa mga laruan sa larangan ng pangangasiwa ng system at DevOps sa mahabang panahon, mahal ko pa rin ang mga laruan, bumibili pa rin ako ng mga bago. Lahat ng tao, sa isang paraan o iba pa, ay gusto pa rin ng ilang uri ng mga laruan.

Hindi na kailangang makipaglaro sa produksyon. Anuman ang inirerekumenda kong hindi gawin at kung ano ang nakikita ko ngayon nang maramihan: "Oh, isang bagong laruan!" — tumakbo sila para bilhin ito, binili ito at: "Dalhin natin ito sa paaralan ngayon at ipakita ito sa lahat ng ating mga kaibigan." Huwag gawin ito. Humihingi ako ng paumanhin, lumalaki pa lamang ang aking mga anak, palagi akong may nakikita sa mga bata, napapansin ko ito sa aking sarili, at pagkatapos ay i-generalize ito sa iba.

Ang huling sagot ay: hindi mo kailangan ng Kubernetes. Kailangan mong lutasin ang iyong mga problema.

Ang maaari mong makamit ay:

• hindi nahuhulog ang prod;
• kahit na sinubukan niyang mahulog, alam natin ang tungkol dito nang maaga, at maaari tayong maglagay ng isang bagay dito;
• maaari naming baguhin ito sa bilis kung saan kinakailangan ito ng aming negosyo, at magagawa namin ito nang maginhawa; hindi ito nagdudulot sa amin ng anumang mga problema.

Mayroong dalawang tunay na pangangailangan: pagiging maaasahan at dynamic/flexibility ng rollout. Ang bawat isa na kasalukuyang gumagawa ng ilang uri ng mga proyekto sa IT, anuman ang uri ng negosyo - malambot para sa pagpapagaan ng mundo, at nauunawaan ito, ay kailangang malutas ang mga pangangailangang ito. Ang mga Kubernetes na may tamang diskarte, may tamang pag-unawa at may sapat na karanasan ay nagbibigay-daan sa iyo na lutasin ang mga ito.

Tungkol sa walang server

— Kung titingnan mo nang kaunti pa ang hinaharap, pagkatapos ay sinusubukang lutasin ang problema ng kawalan ng pananakit ng ulo sa imprastraktura, sa bilis ng paglulunsad at bilis ng mga pagbabago sa aplikasyon, lilitaw ang mga bagong solusyon, halimbawa, walang server. May nararamdaman ka bang potensyal sa direksyong ito at, sabihin nating, isang panganib para sa Kubernetes at mga katulad na solusyon?

Dmitry: Narito kailangan nating muling magpahayag na hindi ako isang tagakita na tumitingin sa unahan at nagsasabing - magiging ganito! Kahit na ginawa ko lang ang parehong bagay. Tinitingnan ko ang aking mga paa at nakikita ang isang grupo ng mga problema doon, halimbawa, kung paano gumagana ang mga transistor sa isang computer. Nakakatuwa naman diba? Nakatagpo kami ng ilang mga bug sa CPU.

Gawing lubos na maaasahan, mura, mahusay at maginhawa ang serverless, nilulutas ang lahat ng isyu sa ecosystem. Dito sumasang-ayon ako kay Elon Musk na kailangan ang pangalawang planeta upang lumikha ng fault tolerance para sa sangkatauhan. Bagama't hindi ko alam kung ano ang sinasabi niya, naiintindihan ko na hindi pa ako handang lumipad sa Mars mismo at hindi ito mangyayari bukas.

Sa walang server, malinaw na malinaw na ito ay isang bagay na tama sa ideolohiya, tulad ng fault tolerance para sa sangkatauhan - ang pagkakaroon ng dalawang planeta ay mas mahusay kaysa sa isa. Ngunit paano ito gagawin ngayon? Ang pagpapadala ng isang ekspedisyon ay hindi isang problema kung itutuon mo ang iyong mga pagsisikap dito. Ang pagpapadala ng ilang mga ekspedisyon at pag-aayos ng ilang libong tao doon, sa tingin ko, ay makatotohanan din. Ngunit upang gawin itong ganap na fault-tolerant upang ang kalahati ng sangkatauhan ay nakatira doon, tila sa akin ngayon ay imposible, hindi isinasaalang-alang.

Sa serverless one on one: ang bagay ay cool, ngunit ito ay malayo sa mga problema ng 2019. Mas malapit sa 2030 - mabuhay tayo para makita ito. Wala akong duda na mabubuhay tayo, tiyak na mabubuhay tayo (ulitin bago matulog), ngunit ngayon kailangan nating lutasin ang iba pang mga problema. Ito ay tulad ng paniniwala sa fairy tale pony Rainbow. Oo, ilang porsyento ng mga kaso ang nalutas, at ang mga ito ay nalutas nang perpekto, ngunit sa subjective, ang serverless ay isang bahaghari... Para sa akin, ang paksang ito ay masyadong malayo at masyadong hindi maintindihan. Hindi ako handang makipag-usap. Sa 2019, hindi ka makakasulat ng isang application na walang server.

Paano mag-evolve ang Kubernetes

— Habang sumusulong tayo sa potensyal na napakagandang malayong hinaharap na ito, paano sa palagay mo uunlad ang Kubernetes at ang ecosystem sa paligid nito?

Dmitry: Marami akong pinag-isipan tungkol dito at mayroon akong malinaw na sagot. Ang una ay statefull - kung tutuusin, mas madaling gawin ang stateless. Ang Kubernetes sa una ay namuhunan nang higit pa dito, nagsimula ang lahat dito. Halos perpektong gumagana ang stateless sa Kubernetes, wala lang dapat ireklamo. Mayroon pa ring maraming mga problema, o sa halip, mga nuances. Lahat ng bagay doon ay gumagana nang mahusay para sa amin, ngunit iyon ay sa amin. Aabutin ng hindi bababa sa ilang taon bago ito gumana para sa lahat. Ito ay hindi isang kalkuladong tagapagpahiwatig, ngunit ang aking pakiramdam mula sa aking ulo.

Sa madaling sabi, ang statefull ay dapat - at gugustuhing - bumuo ng napakalakas, dahil ang lahat ng aming mga application ay nag-iimbak ng katayuan; walang mga stateless na application. Ito ay isang ilusyon; palagi kang nangangailangan ng ilang uri ng database at iba pa. Ang Statefull ay tungkol sa pag-aayos ng lahat ng posible, pag-aayos ng lahat ng mga bug, pagpapabuti ng lahat ng mga problema na kasalukuyang kinakaharap - tawagin natin itong adoption.

Ang antas ng hindi alam, ang antas ng hindi nalutas na mga problema, ang antas ng posibilidad na makatagpo ng isang bagay ay bababa nang malaki. Ito ay isang mahalagang kuwento. At mga operator - lahat ng bagay na may kaugnayan sa codification ng administration logic, control logic upang makakuha ng madaling serbisyo: MySQL madaling serbisyo, RabbitMQ madaling serbisyo, Memcache madaling serbisyo - sa pangkalahatan, lahat ng mga sangkap na ito na kailangan naming garantisadong magagawa ang kahon. Malulutas lang nito ang sakit na gusto namin ng isang database, ngunit hindi namin nais na pangasiwaan ito, o gusto namin ang mga Kubernetes, ngunit hindi namin nais na pangasiwaan ito.

Ang kuwentong ito ng pagpapaunlad ng operator sa isang anyo o iba pa ay magiging mahalaga sa susunod na dalawang taon.

Sa palagay ko ang kadalian ng paggamit ay dapat tumaas nang malaki - ang kahon ay magiging mas at mas itim, mas at mas maaasahan, na may higit at mas simpleng mga knobs.

Minsan ay nakinig ako sa isang lumang panayam kay Isaac Asimov mula sa 80s sa YouTube sa Saturday Night Live - isang programa tulad ng Urgant, kawili-wili lamang. Tinanong nila siya tungkol sa kinabukasan ng mga kompyuter. Sinabi niya na ang hinaharap ay nasa pagiging simple, tulad ng radyo. Ang radio receiver ay orihinal na isang kumplikadong bagay. Upang mahuli ang isang alon, kailangan mong i-on ang mga knobs sa loob ng 15 minuto, i-on ang mga skewer at sa pangkalahatan ay alam kung paano gumagana ang lahat, maunawaan ang physics ng radio wave transmission. Dahil dito, isang knob na lang ang natitira sa radyo.

Ngayon sa 2019 anong radyo? Sa kotse, hinahanap ng radio receiver ang lahat ng mga alon at ang mga pangalan ng mga istasyon. Ang pisika ng proseso ay hindi nagbago sa loob ng 100 taon, ngunit ang kadalian ng paggamit ay nagbago. Ngayon, at hindi lamang ngayon, na noong 1980, nang magkaroon ng isang pakikipanayam kay Azimov, lahat ay gumagamit ng radyo at walang nag-iisip tungkol sa kung paano ito gumagana. Palagi itong gumana - iyon ay ibinigay.

Pagkatapos ay sinabi ni Azimov na ito ay magiging pareho sa mga computer - ang kadalian ng paggamit ay tataas. Habang noong 1980 kailangan mong sanayin upang pindutin ang mga pindutan sa isang computer, hindi iyon ang mangyayari sa hinaharap.

May pakiramdam ako na sa Kubernetes at sa imprastraktura magkakaroon din ng malaking pagtaas sa kadalian ng paggamit. Ito, sa aking opinyon, ay halata - ito ay nasa ibabaw.

Ano ang gagawin sa mga inhinyero?

— Ano ang mangyayari sa mga inhinyero at system administrator na sumusuporta sa Kubernetes?

Dmitry: Ano ang nangyari sa accountant pagkatapos ng pagdating ng 1C? Halos pareho. Bago ito, nagbilang sila sa papel - ngayon sa programa. Ang produktibidad ng paggawa ay tumaas ng mga order ng magnitude, ngunit ang paggawa mismo ay hindi nawala. Kung dati ay tumagal ng 10 inhinyero upang i-tornilyo ang isang bumbilya, ngayon ay sapat na ang isa.

Ang dami ng software at ang bilang ng mga gawain, sa tingin ko, ay lumalaki na ngayon sa mas mabilis na rate kaysa sa mga bagong DevOps na lumilitaw at ang kahusayan ay tumataas. Mayroong tiyak na kakulangan sa merkado sa ngayon at magtatagal ito ng mahabang panahon. Sa paglaon, ang lahat ay babalik sa ilang uri ng normalidad, kung saan tataas ang kahusayan ng trabaho, magkakaroon ng higit pa at higit pang mga serverless, isang neuron ay makakabit sa Kubernetes, na pipili ng lahat ng mga mapagkukunan nang eksakto kung kinakailangan, at sa pangkalahatan ay gawin ang lahat sa sarili, gaya ng nararapat - lumayo lang ang tao at huwag makialam.

Ngunit kailangan pa rin ng isang tao na gumawa ng mga desisyon. Malinaw na mas mataas ang antas ng mga kwalipikasyon at espesyalisasyon ng taong ito. Sa panahon ngayon, sa accounting department, hindi mo na kailangan ng 10 empleyadong nag-iingat ng libro para hindi mapagod ang mga kamay. Hindi lang kailangan. Maraming mga dokumento ang awtomatikong na-scan at kinikilala ng electronic document management system. Ang isang matalinong punong accountant ay sapat na, mayroon nang higit na higit na mga kasanayan, na may mahusay na pag-unawa.

Sa pangkalahatan, ito ang paraan upang pumunta sa lahat ng mga industriya. Ito ay pareho sa mga kotse: dati, isang kotse ang dumating kasama ang isang mekaniko at tatlong driver. Sa ngayon, ang pagmamaneho ng kotse ay isang simpleng proseso kung saan lahat tayo ay nakikilahok araw-araw. Walang sinuman ang nag-iisip na ang isang kotse ay isang bagay na kumplikado.

Hindi mawawala ang DevOps o systems engineering - tataas ang mataas na antas ng trabaho at kahusayan.

— Narinig ko rin ang isang kawili-wiling ideya na talagang tataas ang gawain.

Dmitry: Siyempre, isang daang porsyento! Dahil ang dami ng software na sinusulat namin ay patuloy na lumalaki. Ang bilang ng mga isyu na nalutas namin sa software ay patuloy na lumalaki. Ang dami ng trabaho ay lumalaki. Ngayon ang merkado ng DevOps ay labis na uminit. Ito ay makikita sa mga inaasahan sa suweldo. Sa magandang paraan, nang hindi nagdedetalye, dapat may mga junior na gustong X, middles na gustong 1,5X, at senior na gustong 2X. At ngayon, kung titingnan mo ang merkado ng suweldo ng Moscow DevOps, gusto ng isang junior mula X hanggang 3X at gusto ng isang senior mula X hanggang 3X.

Walang nakakaalam kung magkano ang halaga nito. Ang antas ng suweldo ay nasusukat sa pamamagitan ng iyong kumpiyansa - isang kumpletong kabaliwan, sa totoo lang, isang napaka-overheated na merkado.

Siyempre, magbabago ang sitwasyong ito sa lalong madaling panahon - dapat mangyari ang ilang saturation. Hindi ito ang kaso sa pagbuo ng software - sa kabila ng katotohanan na ang lahat ay nangangailangan ng mga developer, at ang lahat ay nangangailangan ng mahusay na mga developer, naiintindihan ng merkado kung sino ang katumbas ng halaga - ang industriya ay nanirahan. Hindi iyon ang kaso sa DevOps sa mga araw na ito.

— Mula sa aking narinig, napagpasyahan ko na ang kasalukuyang tagapangasiwa ng system ay hindi dapat mag-alala ng labis, ngunit oras na upang i-upgrade ang kanyang mga kasanayan at maghanda para sa katotohanan na bukas ay magkakaroon ng mas maraming trabaho, ngunit ito ay magiging mas mataas na kwalipikado.

Dmitry: Isang daang porsyento. Sa pangkalahatan, nabubuhay tayo sa 2019 at ang panuntunan ng buhay ay ito: panghabambuhay na pag-aaral - natututo tayo sa buong buhay natin. Tila sa akin ngayon ay alam na ng lahat at nararamdaman ito, ngunit hindi sapat na malaman - kailangan mong gawin ito. Araw-araw dapat tayong magbago. Kung hindi natin ito gagawin, maya-maya ay mahuhulog tayo sa gilid ng propesyon.

Maging handa para sa matalim na 180-degree na pagliko. Hindi ko ibinubukod ang isang sitwasyon kung saan ang isang bagay ay radikal na nagbabago, isang bagay na bago ay naimbento - ito ay nangyayari. Hop! - at iba na ang kilos natin ngayon. Mahalagang maging handa para dito at huwag mag-alala. Maaaring mangyari na bukas ang lahat ng gagawin ko ay magiging hindi kailangan - wala, pinag-aralan ko ang buong buhay ko at handa akong matuto ng iba pa. Hindi ito problema. Hindi kailangang matakot sa seguridad sa trabaho, ngunit kailangan mong maging handa upang patuloy na matuto ng bago.

Mga kagustuhan at isang minuto ng advertising

- May hiling ka ba?

Dmitry: Oo, marami akong hiling.

Una at mercantile - mag-subscribe sa YouTube. Mga minamahal na mambabasa, pumunta sa YouTube at mag-subscribe sa aming channel. Sa humigit-kumulang isang buwan sisimulan namin ang aktibong pagpapalawak sa serbisyo ng video. Magkakaroon kami ng maraming pang-edukasyon na nilalaman tungkol sa mga Kubernetes, bukas at iba-iba: mula sa mga praktikal na bagay, hanggang sa mga laboratoryo, hanggang sa malalim na pangunahing teoretikal na mga bagay at kung paano gamitin ang Kubernetes sa antas ng mga prinsipyo at pattern.

Ang pangalawang mercantile wish - pumunta sa GitHub at naglalagay ng mga bituin dahil pinapakain natin sila. Kung hindi mo kami bibigyan ng mga bituin, wala kaming makakain. Parang mana sa isang computer game. Gumagawa kami ng isang bagay, ginagawa namin, sinusubukan namin, may nagsasabi na ang mga ito ay kakila-kilabot na mga bisikleta, isang tao na ang lahat ay ganap na mali, ngunit nagpapatuloy kami at kumikilos nang tapat. Nakikita namin ang isang problema, lutasin ito at ibinabahagi ang aming karanasan. Samakatuwid, bigyan kami ng isang bituin, hindi ito mawawala sa iyo, ngunit ito ay darating sa amin, dahil pinapakain namin sila.

Pangatlo, mahalaga, at hindi na mercantile na hangarin - huwag na kayong maniwala sa mga fairy tale. Kayo ay mga propesyonal. Ang DevOps ay isang napakaseryoso at responsableng propesyon. Itigil ang paglalaro sa lugar ng trabaho. Hayaan itong mag-click para sa iyo at mauunawaan mo ito. Isipin na ikaw ay pumunta sa ospital, at doon ang doktor ay nag-eeksperimento sa iyo. Naiintindihan ko na maaaring nakakasakit ito sa isang tao, ngunit, malamang, hindi ito tungkol sa iyo, ngunit tungkol sa ibang tao. Sabihin sa iba na tumigil din. Talagang sinisira nito ang buhay para sa ating lahat - marami ang nagsimulang ituring ang mga operasyon, mga admin at DevOps bilang mga dude na muling sinira ang isang bagay. Ito ay madalas na "nasira" dahil sa ang katunayan na kami ay nagpunta upang maglaro, at hindi tumingin nang may malamig na kamalayan na ganito ito, at ganyan ito.

Hindi ito nangangahulugan na hindi ka dapat mag-eksperimento. Kailangan nating mag-eksperimento, tayo mismo ang gumagawa nito. Sa totoo lang, tayo mismo ay minsan naglalaro - ito, siyempre, ay napakasama, ngunit walang tao ang alien sa atin. Ideklara natin ang 2019 na isang taon ng seryoso, pinag-isipang mabuti na mga eksperimento, at hindi mga laro sa produksyon. Malamang kaya.

- Maraming salamat!

Dmitry: Salamat, Vitaly, kapwa sa oras at sa pakikipanayam. Dear readers, maraming salamat kung bigla kayong umabot sa puntong ito. Umaasa ako na dinala namin sa iyo ang hindi bababa sa ilang mga saloobin.

Sa panayam, hinawakan ni Dmitry ang isyu ng werf. Ngayon ito ay isang unibersal na Swiss kutsilyo na malulutas ang halos lahat ng mga problema. Ngunit hindi ito palaging ganoon. Naka-on DevOpsConf  sa pagdiriwang RIT++ Sasabihin sa iyo ni Dmitry Stolyarov ang tungkol sa tool na ito nang detalyado. sa ulat "Werf ay ang aming tool para sa CI/CD sa Kubernetes" magkakaroon ng lahat: mga problema at mga nakatagong nuances ng Kubernetes, mga pagpipilian para sa paglutas ng mga paghihirap na ito at ang kasalukuyang pagpapatupad ng werf nang detalyado. Samahan kami sa Mayo 27 at 28, gagawa kami ng mga perpektong tool.

Pinagmulan: www.habr.com