Në prag të Vitalij Khabarov ka intervistuar Dmitri Stolyarov (), drejtori teknik dhe bashkëthemelues i kompanisë "Flant". Vitalij e pyeti Dmitrin për atë çfarë bën "Flant", për Kubernetes, zhvillimin e ekosistemit, mbështetje. Diskutuan përse është e nevojshme Kubernetes dhe a është me të vërtetë e nevojshme. Gjithashtu folën për mikroshërbimet, Amazon AWS, qasjen "Do të kem fat" në DevOps, të ardhmen e Kubernetes, pse, kur dhe si do të pushtojë botën, perspektivat e DevOps dhe për çfarë duhet të përgatiten inxhinierët në të ardhmen e ndritshme dhe të afërt me thjeshtimin dhe rrjetet neuromore.
në formën e një podkasti mund ta dëgjoni në DevOps Deflope - podkastin në gjuhën ruse për DevOps, ndërsa më poshtë - versioni tekstual.
Këtu dhe më tej pyetjet i bën inxhinieri nga Express42.
Për "Flant"
- Dima, përshëndetje. Ti je drejtori teknik i "" dhe gjithashtu themeluesi i saj. Të lutem, tregoi pak për atë çfarë bën kompania dhe ti në të?
Dmitri: Nga jashtë duket si të ishim disa djem që shëtisin dhe vendosin Kubernetes dhe bëjnë diçka me të. Por nuk është kështu. Ne kemi filluar si një kompani që merret me Linux, por prej shumë kohësh aktiviteti ynë kryesor është përkujdesja për projekte me prodhim dhe highload nga fillimi në fund. Zakonisht ndërtojmë të gjithë infrastrukturën nga e para dhe pastaj mbajmë përgjegjësi për të për një kohë të gjatë. Prandaj, puna kryesore që kryen "Flant", për të cilën merr pagesë, është marrja e përgjegjësisë dhe realizimi i prodhimit nga fillimi në fund..
Unë, si drejtori teknik dhe një nga themeluesit e kompanisë, merrem gjatë gjithë ditës me atë se si të rris disponueshmërinë e prodhimit, ta thjeshtoj përdorimin e tij, t'i lehtësoj jetën administratorëve dhe t'u bëj jetën zhvilluesve më të këndshme.
Për Kubernetes
- Kohët e fundit nga "Flant" shoh shumë ligjërata dhe për Kubernetes. Si e arritët atë?
Dmitri: Unë kam treguar për këtë shumë herë, por fare nuk më vjen keq ta përsëris. Mendoj se është e duhur të përsëris këtë temë, sepse ndodhin konfuzionet mes shkakut dhe pasojës.
Na duhej na duhej na duhej na duhej na duhej nevojë për një instrument. Kishim përballur me një mori problemesh, luftuam dhe i kaluam ato me metoda të ndryshme dhe ndjenim nevojën për një instrument. Provonim shumë mundësi të ndryshme, krijonim biçikletat tona dhe grumbulloheshim përvojë. Gradualisht arritëm në pikën ku filluam të përdornim Docker gati menjëherë sapo u shfaq — rreth vitit 2013. Në momentin e shfaqjes së tij, ne tashmë kishim përvojë të madhe me kontejnerët, kishim shkruar një analog të "Docker" — disa nga metodat tona të ndryshme në Python. Me shfaqjen e Docker ishte e mundur të heqnim metodat e zakonshme dhe të përdornim një zgjidhje të sigurt dhe të mbështetur nga komuniteti.
Historia me Kubernetes është e ngjashme. Në momentin kur ai filloi të merrte pikë, — për ne kjo ishte versioni 1.2, — ne kishim tashmë një mori metodash të ndryshme në Shell dhe në Chef, të cilat tentonim t'i orkestronim me Docker. Ne shikonim seriozisht në drejtim të Rancher dhe zgjidhjeve të tjera të ndryshme, por këtu u shfaq Kubernetes, në të cilin është realizuar gjithçka ashtu si do ta bënim ne ose edhe më mirë. Nuk ka asgjë për ta kritikuar.
Po, ka disa gjëra që nuk janë përfunduar, atje ka disa probleme — shumë probleme, dhe 1.2 është vërtet e frikshme, por... Kubernetes është si një ndërtesë në ndërtim — e sheh projektin dhe e kupton se do të jetë e mrekullueshme. Nëse ndërtesa tani ka një themel dhe dy kate, atëherë e kupton se është më mirë të mos hysh brenda ende, por me softin nuk ka probleme të tilla — mund të përdoret tashmë.
Nuk patëm ndonjë moment ku mendonim nëse do të përdorim Kubernetes apo jo. E pritëm atë shumë përpara se të shfaqej dhe provonim të krijonim vetë analoge.
Rreth Kubernetes
— A merrni pjesë drejtpërdrejt në zhvillimin e Kubernetes vetë?
Dmitri: Pjesërisht. Më tepër jemi të angazhuar në zhvillimin e ekosistemës. Dërgojmë një numër të caktuar kërkesash pull: në Prometheus, në operatorë të ndryshëm, në Helm — në ekosistemë. Fatkeqësisht, nuk mund të ndjek çdo gjë që bëjmë dhe mund të gaboj, por nuk kemi asnjë pull për bërthamën.
— Ndërkohë ju po zhvilloni dhe shumë instrumente të tjerë përreth Kubernetes?
Dmitri: Strategjia është e tillë: ne shkojmë dhe kërkojmë pull në gjithçka që ekziston. Nëse atje nuk pranohen kërkesat pull, ne thjesht e forkojmë për veten tonë dhe jetojmë deri sa ato të pranohen me ndërtimet tona. Pastaj, kur kjo arrin në upstream, kthehemi në versionin upstream.
Për shembull, ne kemi një operator Prometheus, me të cilin kemi kaluar përtej upstream-it të ndërtimit tonë tashmë rreth 5 herë, ndoshta. Na nevojitet ndonjë funksionalitet, dërguam një pull request, na duhet ta lëshojmë atë nesër, dhe nuk dëshirojmë të presim derisa ta publikojnë në upstream. Prandaj, ne e përgatisim ndërtimin tonë me funksionalitetin tonë që na nevojitet, në të gjitha klasteret tona. Më pas, kjo ri-dërgohet në upstream me fjalët: «Djem, le të bëjmë për një rast më të përgjithshëm», ne, ose dikush tjetër, e përfundon atë, dhe me kalimin e kohës, përsëri bashkohet.
Çdo gjë që ekziston, ne përpiqemi ta zhvillojmë.. Shumë elemente, të cilat ende nuk ekzistojnë, nuk janë shpikur ende ose janë shpikur, por nuk janë realizuar ende — ne i bëjmë. Dhe jo sepse na pëlqen procesi vetë ose ndërtimi i biçikletave si një industri, por thjesht sepse na nevojitet ky mjet. Shpesh bëhet pyetja, pse kemi bërë atë ose këtë gjë? Përgjigjja është e thjeshtë — sepse duhej të shkonim përpara, të zgjidhnim ndonjë problem praktik, dhe ne e zgjidhëm atë me këtë mjet.
Rruga gjithmonë është kështu: ne kërkojmë me shumë kujdes dhe, nëse nuk gjejmë ndonjë zgjidhje, si të bëjmë një bukë të thekur një trolebuz, atëherë bëjmë bukën tonë dhe trolebuzin tonë.
Mjetet e «Flant»
— Më është njoftuar se tani «Flant» ka addon-operatorë, operatorë shell, mjete dapp/werf. Siç kuptoj, kjo është e njëjta mjet në inkarnime të ndryshme. Gjithashtu kuptoj që brenda «Flant» ekzistojnë shumë mjete të tjera të ndryshme. A është kështu?
Dmitri: Ne kemi shumë gjëra të tjera në GitHub. nga ato që unë mund të kujtoj tani, kemi statusmap — një panel për Grafana, i cili ka qenë i njohur për të gjithë. E përmend pak a shumë në çdo artikull të dytë mbi monitorimin e Kubernetes në Medium. Është e pamundur të flasësh shkurtimisht për atë që është statusmap — kërkohet një artikull të veçantë, por është një gjë shumë e dobishme për monitorimin e statusit në kohë, sepse në Kubernetes na nevojitet shpesh të tregojmë statusin në kohë. Gjithashtu, ne kemi LogHouse — një gjë e bazuar në ClickHouse dhe magji të zezë për mbledhjen e logeve në Kubernetes.
Mënyra shumë utilitarëve! Dhe do të ketë më shumë, sepse një sasi e caktuar e zgjidhjeve të brendshme do të lëshohen këtë vit. Nga utilitarët e mëdhenj bazuar në operatorin addon, ka një sërë addons për Kubernetes siç është mënyra e duhur për të vendosur sert manager — një mjet për menaxhimin e certifikatave, si dhe mënyra e duhur për të vendosur Prometheus me shumë shtesa — këto janë rreth njëzet binarë të ndryshëm që eksportojnë të dhëna dhe bëjnë diçka, për këtë Prometheus ofron grafikë të shkëlqyer dhe alarme. Të gjitha këto janë thjesht një sërë addons për Kubernetes, të cilat instalohen në klaster dhe ai kthehet nga një i thjeshtë në një të avancuar, automatik, në të cilin shumë pyetje tashmë janë zgjidhur. Po, bëjmë shumë.
Zhvillimi i ekosistemit
— Më duket se është një kontribut shumë i madh në zhvillimin e këtij mjeti dhe metodave të përdorimit të tij. A mund të bësh një vlerësim se kush tjetër do të kontribuonte në zhvillimin e ekosistemit?
Dmitri: Në Rusi, nga ato kompani që veprojnë në tregun tonë — askush, as edhe në afërsi. Sigurisht, kjo është një deklaratë e fuqishme, sepse ka lojtarë të mëdhenj si Mail dhe Yandex — ata gjithashtu po bëjnë diçka me Kubernetes, por edhe ata nuk i janë afruar kontributit të kompanive në tërësi në mbarë botën, të cilat bëjnë shumë më tepër se ne. Është e vështirë të krahasosh "Flant" me një staf prej 80 njerëzish dhe Red Hat, ku vetëm për një Kubernetes ka 300 inxhinierë, nëse nuk gaboj. E vështirë të krahasosh. Ne kemi në departamentin tonë të RnD 6 njerëz, duke përfshirë veten, që punojnë në të gjitha mjetet tona. 6 njerëz përballë 300 inxhinierëve të Red Hat — është pak e vështirë për t'u krahasuar.
— Megjithatë, kur edhe këta 6 njerëz mund të bëjnë diçka me vlerë të vërtetë dhe të transferueshme, kur ata përballen me një problem praktik dhe japin zgjidhjen në komunitet — është një rast interesant. E kuptoj se në kompanitë e mëdha teknologjike, ku ka zhvillim dhe një ekip mbështetje për Kubernetes, mund të zhvillohen gjithashtu mjete të tilla. Ky është një shembull për ta se çfarë mund të zhvillohet dhe të jepet në komunitet, të japë një nxitje për të gjithë komunitetin që përdor Kubernetes.
Dmitri: Ndoshta është kjo një veçori e integratorit. Ne kemi shumë projekte dhe shohim shumë situata të ndryshme. Për ne, mënyra kryesore për të krijuar vlerë të shtuar është të analizojmë këto raste, të gjejmë të përbashkëtat dhe t'i ulim sa më shumë kostot për ne. Këto janë aktivitete me të cilat merremi aktivisht. Më është vështirë të flas për Rusinë dhe botën, por kemi rreth 40 inxhinierë DevOps në kompani që merren me Kubernetes. Nuk mendoj se në Rusi ka shumë kompani me një numër të ngjashëm specialistësh që kuptojnë Kubernetes, nëse ndonjëherë ka.
E kuptoj gjithçka për titullin e punës DevOps-inxhinier, të gjithë e dinë dhe janë mësuar ta quajnë DevOps-inxhinierët si të tillë, nuk do ta diskutojmë këtë. Të gjithë këta 40 DevOps-inxhinierë të mrekullueshëm përballen çdo ditë me probleme dhe i zgjidhin ato, ne thjesht analizojmë këtë përvojë dhe përpiqemi ta përmbledhim. E dimë se nëse kjo përvojë mbetet brenda nesh, pas një viti ose dy, mjeti nuk do të ketë vlerë, sepse diku në komunitet do të shfaqet një mjet i gatshëm. Nuk ka kuptim të akumulojmë këtë përvojë brenda — është thjesht një humbje kohe dhe energjie. Por ne jemi plotësisht të gatshëm ta ndajmë. Ne me kënaqësi e publikojmë gjithçka dhe kuptohet se duhet ta publikohet, zhvillohet, promovuar, që njerëzit ta përdorin dhe t'i shtojnë përvojat e tyre — atëherë gjithçka rritet dhe jeton. Pas dy vitesh, mjeti nuk do të përfundonte në plehra. Nuk na vjen keq të vazhdojmë të investojmë energji, sepse është e qartë se dikush po e përdor mjetin tonë, dhe pas dy vitesh, tashmë të gjithë po e përdorin atë.
Kjo është një pjesë e strategjisë sonë të madhe me dapp/werf. Nuk e mbaj mend se kur filluam ta bëjmë, duket se ishim rreth 3 vjet më parë. Fillimisht ishte plotësisht në shell. Ishte një provë e shkëlqyer e konceptit, ne zgjidhëm disa nga problemet tona private — rezultoi! Por me shell ka probleme, nuk është e mundur të vazhdohet më tej, programimi në shell është një aktivitet i vështirë. Kemi pasur zakonin të shkruajmë në Ruby, kështu që, përkatësisht, bëjmë disa riorganizime në Ruby dhe vazhduam, vazhduam dhe ndeshëm në faktin që komuniteti, turma, që nuk thotë 'ne duam apo nuk duam', mbron hundët nga Ruby, saqë është qesharake. E kuptuam se duhet të shkruajmë gjithçka në Go, për të përmbushur pikën e parë në listën e kontrollit: Mjeti DevOps duhet të jetë një binar statik.Në Go ose jo në Go nuk ka shumë rëndësi, por më mirë një binar statik i shkruar në Go.
Kemi shpenzuar forca, rishkruam dapp-in në Go dhe e quajtëm werf. Dapp-i nuk mbështetet më, nuk zhvillohet, punon në një version të fundit, por ka një rrugë absolute për upgrade dhe mund të ndiqet.
Pse u krijua dapp
— A mund të tregosh shkurtimisht se përse u krijua dapp, cilat probleme zgjidh?
Dmitri: Arsyeja e parë është ndërtimi. Fillimisht ishim përballë problemeve të mëdha me ndërtimin, kur Docker nuk dinte për multi-stage, dhe ne e bëmë multi-stage me forcat tona. Pastaj kishim një mori pyetjesh të tjera lidhur me pastrimin e images. Të gjithë ata që bëjnë CI/CD, më shpejt se më vonë, përballen me problemin se ka një mori images të ndërtuara, dhe duhet të pastroni atë që nuk është e nevojshme dhe të lini atë që është e nevojshme.
Arsyeja e dytë është deploy-i. Po, ka Helm, por ai zgjidh vetëm një pjesë të problemeve. Çuditërisht, është shkruar se "Helm - menaxheri i paketave për Kubernetes". Saktësisht, "ai". Ka edhe fjalët "menaxheri i paketave" - çfarë pritet zakonisht nga një menaxher paketash? Ne themi: "Menaxher pakete - vendos paketën!" dhe presim që ai të na thotë: "Paketë e vendosur".
Është interesante se ne themi: "Helm, vendos paketën", dhe kur ai përgjigjet që e ka vendosur, zbulojmë se ai vetëm ka nisur instalimin - i tha Kubernetes: "Këtë gjë nise!", dhe nëse ajo ka filluar apo jo, nëse punon apo jo, Helm nuk e trajton këtë çështje fare.
Kështu që rezulton se Helm është thjesht një preprocessori tekstual që ngarkohet me të dhëna në Kubernetes.
Por ne në kuadër të çdo deploy-i duam të dimë - a u nxorr aplikacioni në prodhim apo jo? U nxorr në prodhim do të thotë që aplikacioni atje doli, një version i ri u vendos dhe ai aty së paku nuk bie dhe përgjigjet saktë. Helm nuk e zgjidh këtë detyrë. Për ta zgjidhur, duhet të shpenzojmë shumë forca, sepse duhet t'i japim Kubernetes komandën të nxjerrë dhe të ndjekim se çfarë po ndodh atje - a u vendos, a doli. Dhe ka një mori detyrash lidhur me deploy-in, pastrimin, ndërtimin.
Planet
Edhe këtë vit ne do të fillojmë zhvillimin lokal. Duam të arrijmë në atë që ishte më parë në Vagrant - thjesht të shkruajmë «vagrant up» dhe të kemi virtualet tona të ngritura. Dëshirojmë të arrijmë një gjendje ku ka një projekt në Git, ne shkruajmë «werf up», dhe ai ngre një kopje lokale të këtij projekti, e cila funksionon në një mini-Kub lokal, me të gjitha drejtoritë e lidhura që janë të përshtatshme për zhvillim. Varësisht nga gjuha e zhvillimit, kjo ekzekutohet në mënyra të ndryshme, por megjithatë, duhet të jetë e mundur të bëhet zhvillimi lokal lehtësisht me skedarë të instaluar.
Hapi tjetër për ne është të investojmë thellë në komfortin e zhvilluesve.. Që me një mjet të vetëm të ngremë shpejt një projekt lokal, të zhvillojmë, të shtypim në Git, dhe ai gjithashtu do të përfundojë në stage ose në teste, varësisht nga pipeline-t, dhe pastaj me të njëjtin mjet të shkojmë në prodhim. Ky unitet, unifikimi, përmbushshmëria e infrastrukturës nga mjedisi lokal në prodhim është një pikë shumë e rëndësishme për ne. Por për momentin, kjo nuk ekziston në werf - vetëm e planifikojmë.
Por rruga për dapp/werf ka qenë gjithmonë e ngjashme me atë të Kubernetes në fillim. Ne u përballëm me probleme, i zgjidhëm ato me mënyra të drejta - shpikëm disa zgjidhje për vete mbi shell, mbi çfarëdo që të ishte. Më pas, përpiqeshim t'i shkurtojmë, t'i përmbledhim dhe t'i konsolidonim ato në binarë në këtë rast, të cilat thjesht i ndajmë.
Ka gjithashtu një këndvështrim tjetër në tërë këtë histori, me analogji.
Kubernetes është si korniza e një makine me motor. S'ka dyer, xhama, radio, aromatizues - nuk ka asgjë. Vetëm kornizë dhe motor. Dhe ka Helm - ky është timoni. Super, ka timon, por na nevojiten edhe buksi i timonit, sistemi i timonit, kutia e shpejtësisë dhe rrotat, pa to nuk shkon.
Në rastin e werf - është një komponent tjetër për Kubernetes. Por tani ne kemi një version alfa të werf, për shembull, Helm kompiluar brenda werf, sepse na ka bezdisur ta bëjmë atë vetë. Shumë arsye për ta bërë këtë, detajisht për arsyet pse e kemi kompiluar helm tërësisht me tiller brenda werf, do ta tregoj në .
Tani tani werf është një komponent më i integruar. Ne po marrim një timon të gatshëm, një pin timoni - nuk e kam shumë idenë për makinat, por kjo është një bllok i madh që zgjidh një gamë të madhe të detyrave. Nuk është e nevojshme të shfletojmë katalogun vetë, të kemi një pjesë te tjera, të mendojmë si t'i bashkojmë ato. Ne po marrim një kombajna të gatshëm që zgjidh një grup të madh detyrash menjëherë. Por brenda, gjithçka është ndërtuar nga ato komponentë open source, gjithashtu përdor Docker për ndërtim, Helm për pjesën e funksionalitetit, dhe ka disa bibliotekat të tjera. Ky është një instrument i integruar për të marrë shpejt dhe lehtësisht CI/CD të shkëlqyese nga kutia.
A është e vështirë të mbash Kubernetes?
— Ti po flet për përvojën, se si keni filluar të përdorni Kubernetes, kjo është për ju një kornizë, një motor, dhe se mund të jetë shumë gjëra të ndryshme: një trup, një timon, të lidhësh pedalet, ulëset. Shfaqet pyetja - sa e vështirë është për ju mbështetje Kubernetes? Keni një përvojë të pasur, sa kohë dhe burime ju duhen për mbështetje Kubernetes në ndarje nga të gjitha të tjerat?
Dmitri: Kjo është një pyetje shumë e ndërlikuar dhe për të përgjigjur, duhen kuptuar çfarë do të thotë mbështetje dhe çfarë duam nga Kubernetes. Ndoshta ti do ta sqarohet?
— Sa di unë dhe siç shoh, tani shumë ekipe dëshirojnë të provojë Kubernetes. Të gjithë po e provojnë, e instalojnë në mënyrë ad hoc. Kam ndjesinë se njerëzit nuk e kuptojnë gjithmonë kompleksitetin e këtij sistemi.
Dmitri: E vërtetë.
— Sa e vështirë është të marrësh dhe të instalosh Kubernetes nga zero, në mënyrë që të jetë gati për prodhim?
Dmitri: Si mendon, sa e vështirë është të transplantosh një zemër? E kuptoj, pyetje e ndjeshme. Të përdorësh një thikë kirurgjikale dhe të mos gabosh — nuk është aq e vështirë. Nëse të japin udhëzime se ku të prerë dhe ku të qepësh, atëherë procedura vetë nuk është e komplikuar. E vështirë është të garantosh që gjithçka do të shkojë siç duhet nga një herë në tjetrën.
Të instalosh Kubernetes dhe ta bësh ta punojë lehtë: cick! — u instalua, ka shumë mënyra për ta instaluar. Por çfarë do të ndodhë kur të shfaqen problemet?
Gjithmonë shfaqen pyetje - çfarë nuk kemi marrë parasysh? Çfarë nuk kemi bërë? Cilat parametra të kernelit Linux kemi specifikuar gabimisht? Zoti, a i kemi specifikuar ne gjithsesi?! Cilët komponentë Kubernetes kemi instaluar, dhe cilët jo? Shfaqen mijëra pyetje, dhe për t'u përgjigjur në to, nevojitet 15-20 vjet përvojë në këtë industri.
Kam kam një shembull të freskët mbi këtë temë, i cili mund të zbulojë kuptimin e problemit "A është e vështirë të mbash Kubernetes?" Një kohë më parë ne e shqyrtuam me seriozitet mundësinë e implementimit të Cilium si rrjet në Kubernetes.
Le të shpjegoj se çfarë është Cilium. Në Kubernetes ka shumë realizime të ndryshme të sistemit të rrjetit, dhe një nga ato është shumë e shkëlqyer - kjo është Cilium. Çfarë e bën atë të veçantë? Në bërthamën e sistemit, një kohë më parë u shfaq mundësia për të shkruar kapakë për bërthamën, të cilat në një mënyrë ose në një tjetër ndërhyjnë në sistemin e rrjetit dhe në shumë sisteme të tjera, duke lejuar kalimin e pjesëve të mëdha në bërthamë.
Në bërthamën e Linux-it historikisht ka ip rout, filtra, bridge dhe shumë komponente të tjera të vjetra, të cilat kanë 15, 20, ose madje 30 vjet. Në tërësi ato funksionojnë, gjithçka është super, por tani kemi shtuar një shumëllojshmëri containerësh, dhe kjo duket si një kulla prej 15 kockash një mbi tjetrën, ndërsa ti qëndron mbi të me një këmbë - një ndjenjë e çuditshme. Ky sistem ka evoluar historikisht me shumë nuanca, si një apendiks në trup. Në disa situata ka probleme me performancën, për shembull.
Ka një BPF fantastik dhe mundësinë për të shkruar kapakë për bërthamën - djemtë kanë shkruar kapakët e tyre për bërthamën. Pakoja arrin në bërthamën Linux, ata e nxjerrin atë direkt në hyrje, e trajtojnë vetë siç duhet pa bridge, pa TCP, pa IP-steck - për ta thënë shkurt, në mënyrë që të kalojnë gjithçka që është shkruar në bërthamën Linux, dhe menjëherë e nxjerrin në container.
Çfarë doli? Performancë shumë e shkëlqyer, veçori të shkëlqyera - thjesht e shkëlqyer! Por ne e shikojmë këtë dhe shohim se në çdo makinë ka një program që lidhet me API-në e Kubernetes dhe mbi të dhënat që merr nga ky API, gjeneron kod C dhe kompilon binarët që i ngarkon në bërthamë, në mënyrë që këto kapakë të funksionojnë në hapësirën e bërthamës.
Çfarë do të ndodhë nëse diçka shkon keq? Ne nuk e dimë. Për ta kuptuar këtë, duhet të lexojmë të gjithë këtë kod, të kuptojmë gjithë logjikën, dhe kjo është shumë e komplikuar. Por, nga ana tjetër, ka këto bridge, filtra rrjeti, ip rout - unë nuk kam lexuar burimin e tyre, as 40 inxhinierët që punojnë në kompaninë tonë. Ndoshta disa fragmente i kuptojnë vetëm disa.
Dhe çfarë ndryshimi ka? Kështu që kemi ip rout, bërthamën Linux, dhe kemi një mjet të ri - çfarë ndryshimi, nuk kuptojmë asnjë, as tjetrin. Por kemi frikë të përdorim të rejat - pse? Sepse nëse mjeti ka 30 vjet, gjatë këtyre 30 vjetëve janë gjetur të gjitha gabimet, kanë trokitur mbi të gjitha pengesat dhe nuk është e nevojshme të dish për gjithçka - funksionon, si një kuti e zezë, dhe funksionon gjithmonë. Të gjithë e dinë se ku të fusin një drejtkëndësh diagnostikues, cili tcpdump të aktivizohet në momentin e duhur. Të gjithë i njohin mirë mjetet diagnostikuese dhe kuptojnë si funksionon ky grup komponentësh në bërthamën Linux - jo si është ndërtuar, por si të përdoret ai.
Por Cilium i mrekullueshëm nuk është 30 vjeç, ai nuk është akoma përfunduar. Problemi është i njëjtë me Kubernetes, është një kopje. Si Cilium instalohet shkëlqyeshëm, ashtu edhe Kubernetes instalohet shkëlqyeshëm, por kur diçka nuk shkon në prodhim, jeni të aftë ta kuptoni shpejt çfarë shkoi keq në një situatë kritike?
Kur flasim për sa e vështirë është të mbash Kubernetes - jo, është shumë e thjeshtë, dhe po, është jashtëzakonisht e vështirë. Kubernetes funksionon shkëlqyer vetvetiu, por me një miliard nuanca.
Për qasjen "Më pëlqen fatin"
- A ka kompani ku këto nuanca do të shfaqen pothuajse garantuar? Le të supozojmë se Yandex papritmas kalon të gjitha shërbimet në Kubernetes, atje do të ketë një ngarkesë të madhe.
Dmitri: Jo, kjo nuk është bisedë për ngarkesën, por për gjërat më të thjeshta. Për shembull, kemi Kubernetes, e kemi vendosur një aplikacion atje. Si ta kuptojmë nëse po funksionon? Nuk ka një mjet të gatshëm për të kuptuar që aplikacioni nuk bie, thjesht nuk ekziston. Nuk ka një sistem të gatshëm që të dërgojë alarmin - duhet të konfiguroni këto alarme dhe çdo grafik. Dhe ne po përditësojmë Kubernetes.
Ka Ubuntu 16.04. Mund të thuhet se kjo është një version i vjetër, por ne ende jemi mbi të, sepse ka LTS. Atje ka systemd, dhe nuanca e tij është se ai nuk pastron grupet C. Kubernetes nis pod-et, krijon grupe C, pastaj i heq pod-et, dhe ndodhin disa gjëra – nuk e mbaj mend në detaje, më falni – që mbeten slices të systemd. Kjo çon në faktin se me kalimin e kohës çdo makinë fillon të ngadalësohet shumë. Kjo nuk është as një çështje mbi highload. Nëse nisen pod-et e vazhdueshme, për shembull, nëse ka një Cron Job që vazhdimisht gjeneron pod-e, atëherë makina me Ubuntu 16.04 pas një jave do të fillojë të ngadalësohet. Do të ketë vazhdimisht një load average të lartë për shkak të krijimit të shumë grupeve C. Kjo është një problem me të cilin përballet secili që thjesht instalon Ubuntu 16 dhe vendos Kubernetes mbi të.
Lë të themi se ai ndonjëherë do ta përditësojë systemd ose diçka tjetër, por në bërthamën Linux deri në versionin 4.16 është akoma më qesharake – kur hiqen grupet C, ato rrjedhin në bërthamë dhe faktikisht nuk largohen. Pra, pas një muaji pune në këtë makinë do të jetë e pamundur të shikosh statistikat e memories për pod-et. Ne nxjerrim një skedar, e rrotullojmë në program, dhe një skedar rrotullohet për 15 sekonda, sepse bërthama llogarit për një kohë të gjatë brenda një milioni grupeve C, që duket se janë hequr, por jo – ato vazhdojnë të rrjedhin.
Ka shumë detaje të tilla ende këtu dhe atje. Kjo nuk është një çështje që kompanitë gjigante mund të përballen herë pas here në ngarkesa shumë të mëdha – jo, kjo është një çështje e përditshme. Njerëzit mund të jetojnë kështu për muaj me radhë – vendosën Kubernetes, vendosën aplikacionin – duket se punon. Më shumë se shumë është në rregull. Për faktin se ndonjëherë ky aplikacion ndonjëherë do të bjerë, ata as nuk do ta dinë, alerthi nuk do të vijë, por për ta kjo është normale. Më parë jetonin në virtuale pa monitorim, tani u transferuan në Kubernetes gjithashtu pa monitorim – çfarë rëndësie ka?
Çështja është se kur ecim mbi akull, kurrë nuk e dimë trashësinë e tij, nëse nuk e kemi matur paraprakisht. Shumë ecin dhe nuk shqetësohen, sepse edhe më parë kanë ecur.
Nga pikëpamja ime, nuanca dhe kompleksiteti i eksploitimit të çdo sistemi është se për të garantuar që trashësia e akullit është mjaft e mjaftueshme për të zgjidhur detyrat tona. Bëhet fjalë për këtë.
Në IT, më duket se ka shumë qasje të stilit "Më ka rënë fatit". Shumë vendosin software, përdorin biblioteka programore në shpresë se do t'u ndodhi ndonjë fat. Në përgjithësi, fatin e ka shumë njerëz. Ndoshta për këtë arsye funksionon.
— Nga vlerësimi im pesimist, kjo duket kështu: kur rreziqet janë të mëdha dhe aplikacioni duhet të funksionojë, atëherë nevojitet mbështetje nga "Flant", ndoshta nga Red Hat, ose kërkohet një ekip i brendshëm i dedikuar posaçërisht për Kubernetes, i gatshëm ta mbajë atë.
Dmitri: Objekivisht, kjo është e vërtetë. Të futesh vetë në histori me Kubernetes nga një ekip i vogël - është një sasi e caktuar rreziqesh.
A na duhen konteinerë?
— A mund të tregosh, sa i përhapur është Kubernetes në Rusi?
Dmitri: Nuk kam këto të dhëna, dhe nuk jam i sigurt se dikush i ka ato. Ne flasim: "Kubernetes, Kubernetes", por ka një këndvështrim tjetër për këtë çështje. Sa të përhapura janë konteinerët, as këtë nuk e di, por e di një shifër nga raportet në internet, që 70% e konteinerëve orkestrohen nga Kubernetes. Ky ishte një burim i besueshëm me një mostrë të mjaftueshme nga bota.
Pastaj, një pyetje tjetër - a na duhen konteinerë? Kam një ndjesi personale dhe në përgjithësi pozita e kompanisë "Flant" është se Kubernetes është standardi de facto.
Nuk do të ketë asgjë tjetër përveç Kubernetes.
Ky është një ndryshues i lojës absolute në fushën e menaxhimit të infrastrukturës. Thjesht absolut - asgjë më shumë nga Ansible, Chef, makinat virtuale, Terraform. Nuk po flas për metodat e vjetra kolhoze. Kubernetes është një ndryshues absolut i lojës, dhe tani do të jetë vetëm kështu.
është e qartë se disa njerëz u duhet disa vite, ndonjëherë disa dhjetëra, që ta kuptojnë këtë. Nuk kam dyshime se nuk do të ketë asgjë tjetër përveç Kubernetes dhe këtij këndvështrimi të ri: nuk e lëndojmë më operativin, por e përdorim infrastructure as code, por jo me kod, por me yml - infrastrukturë të përshkruar në mënyrë deklarative. Kam ndjesinë se kështu do të jetë gjithmonë.
— Pra, ato kompani që ende nuk kanë kaluar në Kubernetes, do të kalojnë patjetër në të ose do të mbeten në harresë. E kam kuptuar saktë?
Dmitri: Kjo gjithashtu nuk është krejtësisht e saktë. Për shembull, nëse kemi si detyrë të nisim një server dns, atëherë mund ta nisim atë në FreeBSD 4.10 dhe ai mund të funksionojë shkëlqyeshëm për 20 vjet. Thjesht të funksionojë dhe kaq. Ka mundësi që pas 20 vjetësh të jetë e nevojshme ta përmirësojmë një herë. Nëse flasim për softuer në formatin se ne e nisim dhe ai vërtet funksionon shumë vite pa ndonjë përmirësim, pa bërë ndryshime, atëherë natyrisht nuk do të ketë Kubernetes. Ai atje nuk është i nevojshëm.
Gjithçka që ka të bëjë me CI/CD — kudo ku nevojitet Continuous Delivery, ku kërkohet të përditësohen versionet, të bëhen ndryshime aktive, kudo ku është e nevojshme të krijohet qëndrueshmëri — vetëm Kubernetes.
Për mikroshedhjet
— Këtu më lind një disonancë të vogël. Për të punuar me Kubernetes, nevojitet mbështetje e jashtme ose të brendshme — ky është momenti i parë. I dyti — kur ne sapo fillojmë zhvillimin, jemi një startup të vogël, nuk kemi asgjë, zhvillimi nën Kubernetes ose nën një arkitekturë mikroshedhjesh mund të jetë i komplikuar, dhe nuk gjithmonë është i justifikuar ekonomikisht. Më intereson mendimi yt — duhet që startupet që nisin nga zero të fillojnë menjëherë të shkruajnë nën Kubernetes apo mund të shkruajnë fillimisht një monolit dhe më pas të kalojnë në Kubernetes?
Dmitri: Pyetje emocionuese. Kam një referat për mikroshedhjet Shumë herë jam përballur me faktin se njerëzit përpiqen të godasin petka me një mikroskop. Vetë qasja është e saktë, ne projektuam brendshëm softin tonë pikërisht në këtë mënyrë. Por kur e bën këtë, është e nevojshme të kuptosh qartë se çfarë po bën. Më shumë se gjithçka në mikroshedhje, urrej fjalën «mikro». Historikisht është krijuar kjo fjalë, dhe ndonjë mënyrë njerëzit mendojnë se mikro do të thotë shumë i vogël, më i vogël se një milimetër, si mikrometri. Nuk është kështu.
Për shembull, ekziston një monolit, që shkruhet nga 300 njerëz, dhe të gjithë ata që morën pjesë në zhvillim e dinë se në atë ka probleme, dhe duhet që të ndahet në copa mikro — rreth 10, çdo një prej të cilave shkruhen nga 30 njerëz në variantin minimal. Kjo është e rëndësishme, e nevojshme dhe e shkëlqyer. Por kur vjen një startup te ne, ku 3 djem shumë të zotë dhe të talentuar kanë shkruar mbi gjak në 60 mikroshedhje, çdo herë unë kërkoj Corvalol.
Më duket se për këtë janë folur mijëra herë — kemi marrë një monolit të shpërndarë në formën e tij të ndryshme. Kjo është ekonomikisht e paarsyeshme, shumë e komplikuar në përgjithësi. Thjesht kam parë kaq shumë herë këtë, sa që më bën dhimbje, prandaj vazhdoj ta diskutoj.
Në lidhje me pyetjen fillestare, ekziston një konflikt mes faktit që, nga njëra anë, Kubernetes është shumë i frikshëm për t'u përdorur, sepse nuk e di se çfarë mund të prishë ose të mos funksionojë, dhe nga ana tjetër, është e qartë se të gjithë po shkojnë drejt këtij sistemi dhe nuk do të ketë asgjë tjetër përveç Kubernetes. Përgjigjia është — të peshohet sasia e përfitimit që vjen, volumet e detyrave që mund të zgjidhni. Kjo është nga njëra anë e peshës. Nga ana tjetër — rreziqet që lidhen me ndalimin e punës ose me uljen e kohës së reagimit, nivelit të disponueshmërisë — me uljen e treguesve të performancës.
Këtu është kështu — ose ne lëvizim shpejt, dhe Kubernetes lejon të realizohen shumë gjëra më shpejt dhe më mirë, ose përdorim zgjidhje të besueshme, të provuara me kalimin e kohës, por lëvizim shumë më ngadalë. Kjo zgjedhje duhet ta bëjë secila kompani. Mund ta shqyrtoni këtë si një shtigje në xhungla — kur e kaloni herën e parë, mund të takoni një gjarpër, një tigër ose një lloj matoshi të çmendur, dhe kur e kaloni 10 herë — keni hapur një shtigje, hequr degët dhe e bëni më të lehtë kalimin. Me çdo herë, shtigji bëhet më i gjerë. Më pas është një rrugë e asfaltuar, e më vonë një bulevard i bukur.
Kubernetes nuk qëndron në vend. Përsëri pyetje: Kubernetes, nga njëra anë, është 4-5 binarë, nga ana tjetër — është e gjithë ekosistemi. Kjo është një sistem operativ që kemi në makinat tona. Çfarë është? Ubuntu apo Curios? Kjo është bërthama Linux, një many komponentësh shtesë. Të gjitha këto gjëra këtu kanë hequr një gjarpër helmues nga rruga, atje kanë vënë një gardh. Kubernetes zhvillohet shumë shpejt dhe dinamikisht, dhe sasia e rreziqeve, sasia e të panjohurave me çdo muaj po ulet dhe, për pasojë, këto peshore përsëri balancohen.
Duke përgjigje pyetjes, çfarë të bëjë një startup, do të thosha - ejani te "Flant", paguani 150 mijë rubla dhe merrni shërbimin DevOps të lehtë me çelës në dorë. Nëse jeni një startup i vogël me disa zhvillues, kjo funksionon. Në vend që të angazhoni një DevOps të vetin, i cili duhet të mësojë për të zgjidhur problemet tuaja dhe të paguani gjatë këtij kohë rrogën, do të merrni zgjidhjen e të gjitha çështjeve me çelës në dorë. Po, ka disa disavantazhe. Ne, si outsourcer, nuk mund të jemi kaq të angazhuar dhe të reagojmë shpejt ndaj ndryshimeve. Por kemi shumë ekspertizë, praktika të gatshme. Garantojmë që në çdo situatë do ta zgjidhim me siguri dhe shpejt dhe do ta nxjerrim çfarëdo Kubernetes nga këtë botë.
Unë kategorikisht rekomandoj outsourcing për startup-et dhe bizneset e pjekura deri në madhësinë kur mund të dedikoni një ekip prej 10 personash për operacionin, sepse ndryshe nuk ka kuptim. Ka kuptim tërësisht që të bëni outsourcing.
Për Amazon dhe Google
— A mund të konsiderohet si outsourcing hostingu nga zgjidhja nga Amazon ose Google?
Dmitri: Po, sigurisht, kjo zgjidh disa çështje. Por përsëri ka nuanca. Sërish duhet të kuptoni se si ta përdorni. Për shembull, ka mijëra detaje në funksionimin e Amazon AWS: Load Balancer duhet të ngrohet ose paraprakisht të shkruani një kërkesë, që "djem, do të na vijë trafik, ngrohni Load Balancer-in tonë!" Këto nuanca duhet t’i dini.
Kur iu drejtoheni njerëzve që specializohen në këtë fushë, merrni pothuajse të gjitha çështjet tipike të mbyllura. Aktualisht kemi 40 inxhinierë, deri në fund të vitit ndoshta do të jenë 60 - ne me siguri kemi hasur në të gjitha këto çështje. Edhe nëse në ndonjë projekt hasim sërish në këtë problem, ne tashmë e pyesim shpejt njëri-tjetrin dhe dimë se si ta zgjidhim.
Ndoshta, përgjigjja është kjo - sigurisht, historia e hostimit lehtëson një pjesë. Pyetja është, a jeni të gatshëm të besoni këtyre hostuesve, dhe a do ta zgjidhin ata problemin tuaj. Amazon dhe Google e kanë provuar veten mirë. Për të gjitha rastet tona - me siguri. Ne nuk kemi ndonjë experiencë pozitive të tjera. Të gjithë cloud-et e tjera me të cilat kemi provuar të punojmë krijojnë shumë probleme - dhe Ager, dhe gjithçka që ka në Rusi, dhe të gjitha llojet e OpenStack në realizime të ndryshme: Headster, Overage - gjithçka që dëshironi. Të gjitha krijojnë probleme që nuk dëshirojmë t’i zgjidhim.
Prandaj, përgjigjja është - po, por, për fakt, zgjidhjet e mature të hostimit nuk janë shumë.
Kush do të ketë nevojë për Kubernetes?
— E megjithatë kush do të ketë nevojë për Kubernetes? Kush duhet të kalojë tashmë në Kubernetes, kush është klienti tipik i "Flanta", i cili vjen për Kubernetes?
Dmitri: Pyetje interesante, sepse tani pikërisht nëpërmjet Kubernetes shumë njerëz po vijnë te ne: "Djem, e dimë se ju bëni Kubernetes, na bëni një!". Ne iu përgjigjemi: "Zotërinj, ne nuk bëjmë Kubernetes, ne bëjmë prodhim dhe gjithçka që lidhet me të". Sepse të bësh një prodhim, pa bërë të gjithë CI/CD-në dhe të gjithë këtë histori, në ditët e sotme është thjesht e pamundur. Të gjithë kanë hequr dorë nga ndarja që ne kemi zhvillimin si zhvillim dhe më pas shfrytëzimin si shfrytëzim.
Klientët tanë presin gjëra të ndryshme, por të gjithë presin njëfarë mrekullie, se ata kanë problemet e tyre dhe tani - hop! - Kubernetes do t'i zgjidhë ato. Njerëzit besojnë në mrekulli. Në mënyrë të arsyeshme kuptojnë se nuk do të ketë ndonjë mrekulli, por me shpirt shpresojnë - ndoshta ky Kubernetes tani do ta zgjidhë çështjen e gjitha, flitet aq shumë për të! Mund të ndodhë që ai tani - chih! - dhe një plumb argjendi, chih! - dhe ne kemi 100% uptime, të gjithë zhvilluesit mund të publikojnë çfarëdo në prodhim 50 herë dhe ai nuk bie. Në përgjithësi, një mrekulli!
Kur njerëz të tillë vijnë te ne, ne themi: "Na falni, por nuk ka mrekulli". Për të qenë të shëndetshëm, duhet të ushqehesh mirë dhe të ushtrosh sport. Për të pasur një prodhim të besueshëm, duhet të bësh atë në mënyrë të besueshme. Për të pasur një CI/CD funksionale, duhet ta bësh atë të tillë. Kjo është shumë punë që duhet të bëhet.
Duke iu përgjigjur pyetjes se kush do të ketë nevojë për Kubernetes - Kubernetes nuk i nevojitet askujt.
Disa njerëz kanë një ndjenjë të gabuar se u nevojitet Kubernetes. Njerëzve u nevojitet, kanë një nevojë të thellë për të pushuar nga mendimet, angazhimet, dhe shqetësimet rreth problemeve të infrastrukturës dhe problemeve të lançimit të aplikacioneve të tyre. Ata duan që aplikacionet të funksionojnë thjesht dhe të deplojnë me lehtësi. Për ta, Kubernetes është shpresa se do të pushonin së dëgjuari histori si "ne ishim atje", ose "nuk mund të zhvillohemi", ose diçka tjetër.
Zakonisht te ne vjen një drejtor teknik. Nga ai kërkohen dy gjëra: nga njëra anë, na jepni funksionalitete, nga ana tjetër - stabilitet. Ne propozojmë ta marrim këtë mbi ne dhe ta realizojmë. Plumbi i argjendtë, më saktësisht, i argjendosur, është se do të ndaloni së menduari për këto probleme dhe do të kurseni kohë. Do të keni njerëz të veçantë që do të zgjidhin këtë çështje.
Formulimi që na nevojitet Kubernetes ose dikujt tjetër është i gabuar.
Kubernetes është shumë i nevojshëm për administratorët, sepse është një lojë shumë interesante, me të cilën mund të luash, të gërmosh. Le të jemi të sinqertë – të gjithë i duam lojërat. Të gjithë ndonjëherë jemi fëmijë, dhe kur shohim një të re – duam ta provojmë. Disa e kanë humbur këtë, për shembull në administrimin e sistemit, sepse kanë luajtur mjaftueshëm dhe u kanë ardhur në majë të hundës, saqë thjesht nuk dëshirojnë më. Sidoqoftë, kjo nuk është krejtësisht e humbur për askënd. Për shembull, nëse për mua lojërat në fushën e administratës së sistemeve dhe DevOps janë bërë të mërzitshme, akoma i pëlqej lojërat dhe gjithmonë blej disa të reja. Të gjithë njerëzit, në një mënyrë ose në një tjetër, gjithmonë duan disa lojëra.
Mos luani me prodhimin. Çfarëdo që unë të rekomandoj kategorikisht që të mos bëni dhe çfarë shoh tani masivisht: "Ah, një lojë e re!" – u nxituam ta blejmë, e blejmë dhe: "Le të marrim tani në shkollë, të tregojmë të gjithëve miqtë". Mos bëni kështu. Më falni, fëmijët e mi po rriten dhe unë gjithmonë shoh diçka në fëmijë, e vë re te vetja, dhe pastaj e përgjithësoj për të tjerët.
Përgjigjja përfundimtare: nuk ju nevojitet Kubernetes. Duhet të zgjidhni problemet tuaja.
Mund të arrihet që:
- prodhimi të mos bjerë;
- edhe nëse përpiqet të bjerë, ne e dimë për këtë paraprakisht dhe mund të veprojmë;
- mund ta ndryshojmë me atë shpejtësi që na nevojitet për biznesin dhe ta bëjmë këtë në një mënyrë të удобshme, pa krijuar probleme për ne.
Nevojat reale janë dy: qëndrueshmëria dhe dinamizmi/ fleksibiliteti i lëshimit. Çdo kush që po bën projekte IT tani, nuk ka rëndësi në çfarë biznesi - soft për lehtësimin e botës, dhe kush e kupton këtë, duhet të zgjidhë këto nevoja. Kubernetes, me qasje të duhur, me kuptim të duhur dhe me mjaft përvojë, mund t'i zgjidhë ato.
Për serverless
- Nëse shikoni pak më tej në të ardhmen, përpiqen të zgjidhin problemin e mungesës së dhimbjes së kokës me infrastrukturën, me shpejtësinë e lëshimit dhe shpejtësinë e ndryshimit të aplikacioneve, po shfaqen zgjidhje të reja, për shembull, serverless. A ndien ndonjë potencial në këtë drejtim dhe, le të themi, rrezik për Kubernetes dhe zgjidhje të ngjashme?
Dmitri: Këtu duhet të bëjmë një vërejtje tjetër, që unë nuk jam një parashikues që shikon përpara dhe thotë - do të jetë kështu! Megjithatë, sapo kam bërë të njëjtën gjë. Unë shikoj poshtë dhe shoh një mori problemesh, për shembull, si funksionojnë tranzistorët në kompjuter. Qesharake, apo jo? Ne përballemi me disa bllokime në CPU.
Të bësh serverless mjaft të besueshëm, të lirë, efektiv dhe të përshtatshëm, duke zgjidhur të gjitha çështjet e ekosistemit. Këtu pajtohem me Elon Musk se na nevojitet një planet tjetër për të siguruar qëndrueshmërinë për njerëzimin. Megjithatë, nuk e di se çfarë thotë ai, por kuptoj që nuk jam gati të fluturoj vetë në Mars dhe kjo nuk do të ndodhë nesër.
Me serverless është qartë se është një gjë ideologjikisht e drejtë, si qëndrueshmëria për njerëzimin - të kesh dy planete është më mirë se të kesh një. Por si ta bëjmë këtë tani? Të dërgojmë një ekspeditë - nuk është problem, nëse përqendrohemi në këtë përpjekje. Të dërgojmë disa ekspedita dhe të vendosim atje disa mijëra njerëz, mendoj se gjithashtu është realiste. Por të realizohet qëndrueshmëria e plotë, që gjysma e njerëzimit të jetonte atje, më duket tani e pamundur, e pa shqyrtuar.
Me serverless është njësoj: është një gjë e shkëlqyer, por është larg në lidhje me problemet e vitit 2019. Afërsisht deri në vitin 2030 - le të arrijmë deri aty. Nuk kam dyshime se do të arrijmë, ne patjetër do të arrijmë (përgjakni para gjumit), por tani duhet të zgjidhim probleme të tjera. Është si të besosh në një kalë magjik Rainbow. Po, disa përqindje e rasteve zgjidhen, dhe zgjidhen shkëlqyeshëm, por subjektivisht serverless - është një ylber... Për mua kjo temë është shumë e largët dhe shumë e paqartë. Nuk jam gati të flas. Në vitin 2019 me serverless nuk mund të shkruash asnjë aplikacion.
Si do të zhvillohet Kubernetes
— Ndërsa ne shkojmë drejt këtij të ardhmeje potencialisht të mrekullueshme, si mendon, si do të zhvillohet Kubernetes dhe ekosistemi përreth tij?
DmitriKam shumë mendova për këtë dhe kam një përgjigje të qartë. E para - stateful - është më e lehtë të bëhet stateless. Kubernetes nga fillimi ka investuar më shumë në këtë, gjithçka filloi me të. Stateless funksionon praktikisht në mënyrë perfekte në Kubernetes, nuk ka asgjë për t'u ankuar. Për stateful ka ende shumë probleme, më saktësisht nuanca. Ne kemi gjithçka duke punuar shkëlqyer atje, por kjo është ne. Për të funksionuar për të gjithë, nevojiten edhe disa vite maksimale. Kjo nuk është një tregues i llogaritur, por ndjenja ime nga mendja.
Në përmbledhje, stateful duhet të zhvillohet shumë - dhe do të zhvillohet - sepse të gjitha aplikacionet tona ruajnë statusin, nuk ka aplikacione stateless. Kjo është një iluzion, gjithmonë nevojitet një databazë dhe diçka tjetër. Stateful është rrafshimi i gjithçkaje që është e mundur, rregullimi i të gjithë defekteve, përmirësimi i të gjithë problemeve me të cilat përballemi tani - le ta quajmë këtë adoption.
Niveli i të panjohurës, niveli i problemeve të pazgjidhura, niveli i mundësisë për të përballur me diçka, do të bjerë shumë. Kjo është një histori e rëndësishme. Dhe operatorët - gjithçka që ka të bëjë me kodifikimin e logjistikës së administratës, logjikën e menaxhimit, për të marrë shërbimin e lehtë: shërbimi i lehtë MySQL, shërbimi i lehtë RabbitMQ, shërbimi i lehtë Memcache, - të gjitha këto komponente që na nevojiten për të marrë diçka të funksionojë nga kutia garantuar. Kjo shëron pikërisht ato dhimbje, që ne duam një databazë, por nuk duam ta administrojmë, apo duam Kubernetes, por nuk duam ta administrojmë.
Kjo histori e zhvillimit të operatorëve në një mënyrë ose në një tjetër do të jetë e rëndësishme në vitet e ardhshme.
Mendoj se do të rritet shumë thjeshtësia e shfrytëzimit - kuti do të bëhet gjithnjë e më e zezë, gjithnjë e më e besueshme, me rregullime gjithnjë e më të thjeshta.
Njëherë dëgjoja një intervistë të vjetër me Isaac Asimov nga vitet '80 në YouTube në shfaqjen Saturday Night Live - një emision si Urgant, vetëm më interesant. Aty e pyetën për të ardhmen e kompjuterëve. Ai tha se e ardhmja është në thjeshtësi, siç ishte me receptorin e radios. Receptori i radios në fillim ishte një send i komplikuar. Për të kapur një valë, duhej të rrotulloje rrotat për 15 minuta, të rrotulloje ndihmësit dhe të dija si funksiononte gjithçka, të kuptoje fizikën e transmetimit të valëve radio. Në fund, në radio mbeti vetëm një rrotë.
Cila është radioja në vitin 2019? Në makinë, radio pranuesi gjen të gjitha valët dhe emrat e stacioneve. Fizika e procesit nuk ka ndryshuar për 100 vjet, por ka ndryshuar thjeshtësia e përdorimit. Tani, dhe jo vetëm tani, që nga viti 1980, kur u bë një intervistë me Asimov, të gjithë përdornin radio dhe askush nuk mendonte se si është ndërtuar. Ajo gjithmonë ka funksionuar - është një të vërtetë.
Asimov atëherë tha se do të jetë e ngjashme me kompjuterët - thjeshtësia e përdorimit do të rritet. Nëse në vitin 1980 ishte e nevojshme të kishe një arsim të veçantë për të shtypur butonat në një kompjuter, në të ardhmen nuk do të jetë kështu.
Kam ndjesinë se me Kubernetes dhe me infrastrukturën thjeshtësia e përdorimit do të rritet shumë. Kjo është, sipas meje, e qartë - qëndron në sipërfaqe.
Çfarë do të ndodhë me inxhinierët?
- Çfarë do të ndodhë me inxhinierët, administratorët sistemorë, që mbështesin Kubernetes?
Dmitri: Çfarë ndodhi me kontabilistin pas shfaqjes së 1C? Afërsisht e njëjta gjë. Para kësaj, llogaritnin në letër - tani në program. Produktiviteti i punës është rritur disa herë, por puna nuk është zhdukur. Nëse më parë duhej 10 inxhinierë për të vendosur një llampë, tani do të mjaftonte vetëm një.
Më duket se numri i softuerëve dhe numri i detyrave tani po rritet me një shpejtësi më të madhe se sa po shfaqen DevOps të rinj dhe po rritet efikasiteti. Tani, në treg ka një mungesë të menjëhershme dhe do të zgjasë për një kohë të gjatë. Më vonë, gjithçka do të kalojë në një normë të caktuar, ku efikasiteti i punës do të rritet, do të ketë gjithnjë e më shumë serverless, dhe Kubernetes do të lidhet me një rrjet nervor, i cili do të përzgjedhë të gjitha burimet pikërisht siç duhet, dhe gjithçka do të bëjë vetë, siç duhet - njeriu largohet dhe nuk pengon.
Por vendimet ende do të duhet t'i marrë dikush. E qartë është se niveli i kualifikimeve dhe specializimi i atij personi është më i lartë. Tani, në departamentin e kontabilitetit, nuk nevojiten 10 punonjës që të mbajnë librat e kontabilitetit, që duar të tyre të mos lodhen. Kjo thjesht nuk është e nevojshme. Shumë dokumente skanohet automatikisht, njihet nga sistemi i menaxhimit të dokumenteve elektronike. Mjafton një kryekontabël i zgjuar, tashmë me aftësi të shumëfishuara dhe një kuptim të mirë.
Në përgjithësi, kjo është rruga në të gjitha industrinë. Me automjetet ashtu siç është: dikur një mekanik dhe tre shoferë i përkisnin një automobili. Tani, drejtimi i një automobili është një proces shumë i thjeshtë, në të cilin të gjithë ne marrim pjesë çdo ditë. Askush nuk mendon se automobili është diçka e komplikuar.
DevOps ose inxhinieria sistemike nuk do të zhduken – niveli i lartë dhe efikasiteti i punës do të rriten.
– Kam dëgjuar një ide interesante, që në të vërtetë puna do të rritet.
Dmitri: Sigurisht, njëqind përqind! Sepse sasia e softuerit që shkruajmë, vazhdimisht po rritet. Numri i pyetjeve që ne zgjidhim me softuerin, vazhdimisht po rritet. Sasia e punës po rritet. Tani tregu DevOps është sot ekstremisht i mbingarkuar. Kjo vihet re nga pritjet për pagat. Në përgjithësi, pa u thelluar në detaje, duhet të ketë të rinj që duan X, mesatarë që duan 1.5X, dhe të lartë që duan 2X. Dhe tani, nëse shikojmë tregun e pagave për DevOps në Moskë, një i ri dëshiron nga X deri në 3X dhe një i lartë dëshiron nga X deri në 3X.
Askush nuk e di, sa kushton. Niveli i pagës matet me sigurinë tuaj – është një kaos i plotë, nëse të them të drejtën, tregu është ekstremisht i mbingarkuar.
Sigurisht, ky situatë do të ndryshojë shumë shpejt – duhet të ndodhë një saturim i caktuar. Me zhvillimin e softuerit nuk është kështu – pavarësisht se zhvilluesit janë të nevojshëm, dhe të gjithë kanë nevojë për zhvillues të mirë, tregu kupton se kush sa kushton – industria është stabilizuar. Me DevOps tani nuk është kështu.
– Nga ato që kam dëgjuar, kam arritur në përfundimin se nuk ka nevojë të shqetësohet shumë administratori i sistemit aktual, por duhet të fillojë të përmirësojë aftësitë dhe të përgatitet për faktin se nesër do të ketë më shumë punë, por ajo do të jetë më e kualifikuar.
Dmitri: Njëqind përqind. Në përgjithësi, ne jetojmë në vitin 2019 dhe rregulli i jetës është ky: mësimi gjatë gjithë jetës – ne mësojmë gjatë gjithë jetës. Më duket se tani e dinë të gjithë dhe e ndjejnë këtë, por nuk është mjaft të dish – duhet të veprosh. Çdo ditë ne duhet të ndryshojmë. Nëse nuk e bëjmë këtë, për më vonë ose më herët do të na hedhin në anën e profesionit.
Jini të gatshëm për kthesa të papritura prej 180 gradësh. Nuk përjashtoj situatat kur diçka do të ndryshojë ndjeshëm, do të shpikim diçka të re — ndodhin këto. Hup! — dhe tani veprojmë ndryshe. Është e rëndësishme të jeni të gatshëm për këtë dhe të mos shqetësoheni. Mund të ndodhë që nesër gjithçka që po bëj të bëhet e panevojshme — nuk ka gjë, kam mësuar gjatë gjithë jetës dhe jam i gatshëm të mësoj diçka tjetër. Kjo nuk është një problem. Nuk është e nevojshme të keni frikë nga siguria e punës, por duhet të jeni të gatshëm të mësoni vazhdimisht diçka të re.
Dëshira dhe një moment reklame
— A do të kesh ndonjë dëshira?
Dmitri: Po, kam disa dëshira.
E para dhe materialiste — regjistrohuni në . Të nderuar lexues, shkoni në YouTube dhe regjistrohuni në kanalin tonë. Diku pas një muaji do të fillojmë një ekspansion aktiv në platformën e videove, do të kemi shumë përmbajtje edukative rreth Kubernetes-it, të hapur dhe të ndryshëm: nga gjëra praktike, deri në laboratore, te thellësitë teorike dhe si të aplikoni Kubernetes në nivelin e parimeve dhe modeleve.
Dëshira e dytë materialiste — shkoni në dhe na jepni yje, sepse ne ushqehemi me to. Nëse nuk na jepni yje, ne do të jemi pa bukë. Kjo është si mana në një lojë kompjuterike. Ne bëjmë diçka, përpiqemi, dikush thotë se këto janë biçikleta të tmerrshme, dikush tjetër thotë se gjithçka është e gabuar, dhe ne vazhdojmë dhe veprojmë krejtësisht ndershëm. Ne shohim problemin, e zgjidhim atë dhe ndajmë përvojën. Prandaj, na jepni një yll, për ju nuk do të jetë asgjë, ndërsa për ne do të jetë shumë, sepse ne ushqehemi me to.
E treta, e rëndësishme, dhe tashmë jo materiale — ndaloni së besuari në përralla. Ju jeni profesionistë. DevOps është një profesion shumë serioz dhe përgjegjës. Ndaloni së luajtur në vendin e punës. Le të ju godasë dhe të kuptoni këtë. Imagjinoni se shkoni në spital dhe atje një doktori eksperimenton me ju. E kuptoj se për disa mund të jetë ofenduese, por, me sa duket, nuk është për ju, por për dikë tjetër. Tregoni të tjerëve që të ndalojnë gjithashtu. Kjo vërtet i prish jetën të gjithëve ne — shumë fillojnë ta shohin mbarëvajtjen, administratorët dhe DevOps si djem që përsëri kanë thyer diçka. Ky "thyer" ndodh më shpesh për shkak se ne kemi shkuar të luajmë, dhe jo me një mendje të qartë ta shikojmë se këtu është kështu e këtu është ashtu.
Kjo nuk do të thotë se nuk duhet të eksperimentojmë. Duhet të eksperimentojmë, ne po e bëjmë këtë. Të jemi të sinqertë, ne ndonjëherë also luajmë — është, natyrisht, shumë keq, por asgjë që është njerëzore nuk na është e huaj. Le të shpallim vitin 2019 si vitin e eksperimenteve serioze dhe të menduara, dhe jo si vitin e lojërave në prodhim. Ndoshta, kështu.
— Faleminderit shumë!
Dmitri: Faleminderit ty, Vitali, për kohën dhe për intervistën. Të dashur lexues, faleminderit ju, nëse ndoshta arritët deri në këtë moment. Shpresoj se së paku disa mendime ju sollëm.
Në intervistë, Dmitri preku çështjen e werf. Tani është një thikë universale zvicerane, e cila zgjidh gati të gjitha problemet. Por, nuk ka qenë gjithmonë kështu. në festivalin Dmitri Stolyarov do të flasë në detaje për këtë mjet. Në raportin do të ketë gjithçka: problemet dhe nuancat e fshehura të Kubernetes, mundësitë e zgjidhjes së këtyre vështirësive dhe realizimi aktual i werf në detaje. Bashkohuni më 27 dhe 28 maj, do të krijojmë mjete të përsosura.
Burimi: habr.com
