Në prag të Vitali Habrov ka intervistuar Dmitrin Stolyarov (), drejtorin teknik dhe bashkëthemeluesin e kompanisë "Flant". Vitali e pyeti Dmitrin mbi atë që bën "Flant", mbi Kubernetes, zhvillimin e ekosistemit, dhe mbështetje. Diskutuan pse është e nevojshme Kubernetes dhe nëse vërtet është e nevojshme. Gjithashtu folën për mikroshërbimet, Amazon AWS, qasjen "Më pëlqen 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 afërt me thjeshtësimin dhe rrjetet nervore.
në formë podkasti mund ta dëgjoni në DevOps Dëflop — podkast në gjuhën ruse mbi DevOps, ndërsa më poshtë gjeni versionin tekstual.
Këtu dhe më poshtë pyetjet i bën inxhinieri nga Express42.
Rreth "Flant"
— Dima, përshëndetje. Ti je drejtor teknik i "" dhe gjithashtu themeluesi i tij. Të lutem, trego pak për atë çfarë bën kompania dhe rolin tënd aty.
Dmitri: Në pamje të parë duket se ne jemi ata që vendosin Kubernetes dhe bëjnë diçka me të. Por nuk është e vërtetë. Ne filluam si një kompani që merret me Linux, por prej një kohe të gjatë aktiviteti ynë kryesor është ofrimi i shërbimeve për projekte prodhimi dhe highload. Zakonisht ndërtuam çdo infrastrukturë nga fillimi dhe pastaj për shumë kohë e mbajmë nën përgjegjësi. Prandaj, puna kryesore që bën «Flant» dhe për të cilën paguhet është marrja e përgjegjësisë dhe realizimi i projekteve prodhimi.
Unë, si drejtor teknik dhe një nga themeluesit e kompanisë, merrem me atë që të mendoj vazhdimisht se si të rris aksesin e prodhimit, të lehtësoj operimin e tij, të lehtësoj jetën e administratorëve dhe të bëj jetën e zhvilluesve më të këndshme.
Për Kubernetes
— Kohët e fundit nga «Flant» kam parë shumë prezantime dhe për Kubernetes. Si e arritët këtë?
Dmitri: Unë kam folur për këtë shumë herë, por nuk e kam aspak problem të përsëris. Mendoj se është e rëndësishme të përsëris këtë temë, sepse ka konfuzion midis arsyeve dhe pasojave.
Na na duhej nevojshim një mjet. Kemi përjetuar shumë probleme, kemi luftuar, i kemi tejkaluar ato me mënyra të ndryshme dhe kemi ndjerë nevojën për një mjet. Kemi shqyrtuar shumë mundësi të ndryshme, kemi ndërtuar biçikletat tona dhe kemi grumbulluar përvojë. Gradualisht arritëm deri në atë pikë sa filluam të përdorim Docker pothuajse menjëherë pas shfaqjes së tij — rreth vitit 2013. Në momentin e shfaqjes së tij, ne kishim tashmë shumë përvojë me kontejnerët, ne kishim shkruar një analog të "Docker" — disa nga mjetet tona në Python. Me shfaqjen e Docker-it, u shfaq mundësia për të hequr ato të çuditshme dhe për të përdorur një zgjidhje të besueshme dhe të mbështetur nga komuniteti.
Historia me Kubernetes është e ngjashme. Në momentin kur filloi të fitojë terren — për ne kjo ishte versioni 1.2 — ne kishim tashmë një numër të madh mjetesh dhe në Shell, dhe në Chef, të cilat ndonjëherë përpiqeshim t'i orkestronim Docker. Ne shikuam seriozisht në drejtim të Rancher dhe zgjidhjeve të tjera të ndryshme, por këtu doli Kubernetes, ku gjithçka ishte realizuar pikërisht ashtu siç do ta kishim bërë ne ose madje më mirë. Nuk kishte asnjë gjë për të kritikuar.
Po, këtu ka disa gjëra të pa përfunduara, ka disa gjëra të pa përfunduara - shumë, dhe 1.2 është vërtet e frikshme, por... Kubernetes është si një ndërtesë në ndërtim - e shikon projektin dhe kupton që do të jetë diçka e mrekullueshme. Nëse ndërtesa tani ka themelin dhe dy kate, kupton që nuk duhet të banojë akoma atje, por me softuerin nuk ka këso problemesh - mund ta përdorësh tashmë.
Nuk kemi pasur asnjë moment që të mendojmë nëse do ta përdorim Kubernetes apo jo. Ne e prisnim atë shumë përpara se të vinte, dhe përpiqeshim të krijonim alternativa vetë.
Rreth Kubernetes
— A merrni pjesë drejtpërdrejt në zhvillimin e vetë Kubernetes?
Dmitri: Në mënyrë të tërthortë. Për më tepër, ne marrim pjesë në zhvillimin e ekosistemit. Ne dërgojmë disa kërkesa pull: në Prometheus, në operatorë të ndryshëm, në Helm - në ekosistem. Fatkeqësisht, nuk jam në gjendje të ndjek gjithçka që bëjmë dhe mund të gaboj, por nga ne nuk ka asnjë pull në thelb.
— Ndërkohë, a zhvilloni shumë prej mjeteve tuaja rreth Kubernetes?
Dmitri: Strategjia është e tillë: ne shkojmë dhe bëjmë pull request për gjithçka që tashmë ekziston. Nëse nuk pranohet pull requests atje, ne thjesht e forkojmë për vete dhe jetojmë derisa ato të pranohet me ndërtimet tona. Pastaj, kur kjo arrin në upstream, kthehemi në versionin upstream.
Për shembull, kemi një operatore Prometheus, me të cilin kemi kaluar në upstream të ndërtimit tonë rreth 5 herë, ndoshta. Na nevojitet një veçori, dërgojmë një pull request, na duhet ta lëshojmë nesër, dhe nuk duam të presim derisa të lëshohet në upstream. Prandaj, ne e grumbullojmë për vete, lëshojmë ndërtimin tonë me veçorinë tonë, e cila na nevojitet për diçka. Më pas, kjo, për shembull, na kthehet në upstream me fjalët: “Djem, le të bëjmë për një rast më të përgjithshëm”, ne, ose dikush tjetër, përfundojmë këtë, dhe me kalimin e kohës përsëri bllokohet.
Çfarëdo që ekziston, ne përpiqemi ta zhvillojmë.. Shumë elemente, që ende nuk ekzistojnë, nuk janë menduar ende ose janë menduar, por nuk janë realizuar — ne i krijojmë ato. Dhe, jo sepse na pëlqen vetë procesi ose ndërtimi i biçikletave si industri, por thjesht sepse na nevojitet ky mjet. Shpesh shtrohet pyetja, përse e bëmë këtë ose atë gjë? Përgjigjja është e thjeshtë — po, sepse na duhej të shkonim përpara, të zgjidhnim një problem praktik, dhe ne e zgjidhëm atë me këtë mjet.
Rruga gjithmonë është kështu: ne kërkojmë shumë me kujdes dhe, nëse nuk gjejmë asnjë zgjidhje, si të bëjmë një trolebuz nga një bukë, atëherë ne e bëjmë bukën tonë dhe trolebuzin tonë.
Veglat 'Flanta'
— Më është bërë e njohur se tani ‘Flanta’ ka operatorë addon, operatorë shell, vegla dapp/werf. Siç e kuptoj, ky është e njëjta vegël në inkarnacione të ndryshme. Po ashtu, e kuptoj që brenda ‘Flanta’ ka edhe shumë vegla të tjera të ndryshme. Kështu është?
Dmitri: Në GitHub-in tonë kemi shumë gjëra të tjera. Nga ato që më vijnë në mendje tani, kemi statusmap - një panel për Grafana, që e donin të gjithë. Përmendet pothuajse në çdo artikull të dytë që flet për monitorimin e Kubernetes në Medium. Është e pamundur të flasësh shkurt për statusmap - kërkohet një artikull i veçantë, por është një gjë shumë e dobishme për monitorimin e statusit në kohë, pasi në Kubernetes shpesh duhet të tregojmë statusin në një periudhë të caktuar. Po ashtu kemi LogHouse - një instrument mbi bazën e ClickHouse dhe magjisë së zezë për grumbullimin e logeve në Kubernetes.
Shumë mjete! Dhe do të ketë edhe më shumë, sepse një sasi e caktuar zgjidhjesh të brendshme do të lëshohet këtë vit. Nga gjërat shumë të mëdha mbi operatorin addon, ka një mori addons për Kubernetes si për shembull si të instalosh saktësisht menaxherin e sertifikatave - një mjet për menaxhimin e sertifikatave, si të vendosësh Prometheus me shumë përbërës - janë rreth njëzet binarë të ndryshëm që eksportojnë të dhëna dhe mbledhin diçka, për këtë Prometheus ka grafikë të shkëlqyeshme dhe alarme. Të gjitha këto janë thjesht një mori addons për Kubernetes që vendosen në klaster dhe ai kthehet nga një i thjeshtë në një të avancuar, automatizuar, në të cilin shumë çështje janë zgjidhur tashmë. Po, bëjmë shumë gjëra.
Zhvillimi i ekosistemit
— Më duket se është një kontribut shumë i madh në zhvillimin e këtij instrumenti dhe metodave të tij të përdorimit. A mund të bësh një përllogaritje se kush tjetër mund të japë një kontribut të tillë në zhvillimin e ekosistemit?
Dmitri: Në Rusi, nga kompanitë që veprojnë në tregun tonë - askush as afërsisht. Sigurisht, kjo është një deklaratë e fortë, sepse ka lojtarë të mëdhenj si Mail me Yandex-in — ata po bëjnë diçka me Kubernetes, por madje edhe ata nuk i afrohen kontributit të kompanive në tërësi në botë, të cilat bëjnë shumë më tepër se ne. Është e vështirë të krahasosh "Flant" me një ekip prej 80 njerëzish dhe Red Hat, në të cilin ka vetëm për Kubernetes 300 inxhinierë, nëse nuk gaboj. Është e vështirë të krahasosh. Ne kemi në departamentin RnD 6 njerëz, përfshirë edhe mua, që zhvillojnë të gjithë mjete tona. 6 njerëz kundrejt 300 inxhinierëve të Red Hat — është disi e vështirë të krahasosh.
— Megjithatë, kur edhe këta 6 njerëz mund të bëjnë diçka vërtet të dobishme dhe të transferueshme, kur ata përballen me një detyrë praktike dhe i japin zgjidhje komunitetit — është një rast interesant. E kuptoj që në kompanitë e mëdha teknologjike, ku ka zhvillim të brendshëm dhe një ekip mbështetjeje për Kubernetes, në parim mund të zhvillohen mjete të ngjashme. Ky është një shembull për ata se çfarë mund të zhvillohet dhe t’i jepet komunitetit, për të dhënë një impuls të gjithë komunitetit që përdor Kubernetes.
Dmitri: Ndoshta kjo është një veçori e integratorëve, një karakteristikë e tyre. Ne kemi shumë projekte dhe shohim shumë situata të ndryshme. Për ne, mënyra kryesore e krijimit të vlerës së shtuar është të analizojmë këto raste, të gjejmë përbashkësitë dhe t'i reduktojmë ato sa më shumë që të jetë e mundur për ne. Ne merremi aktivisht me këtë. Më është e vështirë të flas për Rusinë dhe botën, por ne kemi rreth 40 inxhinierë DevOps në kompaninë tonë që merrem me Kubernetes. Nuk mendoj se ka shumë kompani në Rusi me një numër të krahasueshëm specialistësh që kuptojnë Kubernetes, nëse ato në të vërtetë ekzistojnë.
Unë e kuptoj gjithçka në lidhje me titullin DevOps Engineer; të gjithë e kuptojnë dhe janë mësuar ta quajnë DevOps inxhinierë. 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, ky mjet do të jetë i padobishëm, sepse diku në komunitet do të shfaqet një mjet i gatshëm. Nuk ka kuptim të grumbullojmë këtë përvojë brenda — është vetëm një humbje forca dhe kohe në dev/null. Ne nuk jemi aspak të shqetësuar. Me shumë kënaqësi, gjithçka e publikojmë dhe e kuptojmë se duhet ta publikojmë, ta zhvillojmë, ta promovojmë, ta shpërndajmë, në mënyrë që njerëzit ta përdorin dhe të shtojnë përvojën e tyre — atëherë gjithçka rritet dhe është e gjallë. Kështu, pas dy vitesh, mjeti nuk shkon në plehra. Nuk është problem të vazhdojmë të investojmë forca, sepse është e qartë se dikush po e përdor mjetin tuaj dhe pas dy vitesh, të gjithë e përdorin atë.
Kjo është pjesë e strategjisë sonë të madhe me dapp/werf.. Nuk e mbaj mend se kur e filluam, duket si para tre vjetësh. Në fillim ishte krejtësisht në shell. Ishte një provë fantastike, zgjidhëm disa nga problemet tona private – doli! Por me shell ka probleme, nuk është e mundur të vazhdojmë me të, programimi në shell është një gjë e komplikuar. Kishim zakon të shkruanim në Ruby, kështu që, përkatësisht, e përpunuam, e zhvilluam, e zhvilluam, dhe u përballëm me faktin se komuniteti, turma, që nuk thotë 'ne duam ose nuk duam', e kthen fytyrën nga Ruby, sa për të qeshur. Kuptuam se duhej ta shkruanim këtë në Go, për të përmbushur pikën e parë në listën kontrolluese: Mjeti DevOps duhet të jetë një binar statik. Në Go ose jo në Go nuk ka rëndësi aq shumë, por është më mirë një binar statik i shkruar në Go.
Harxhuam forcë, e ripërpunuam dapp në Go dhe e quajtëm werf. Dapp nuk mbështetet më, nuk zhvillohet, funksionon në ndonjë version të fundit, por ekziston një rrugë absolute për përmirësim, dhe mund të ndiqet.
Pse u krijua dapp
— A mund të tregosh shkurtimisht përse u krijua dapp, çfarë probleme zgjidh?
Dmitri: Arsyeja e parë është në ndërtim. Fillimisht, kishim probleme të mëdha me ndërtimin, kur Docker nuk dinte të bëjë multi-stage, dhe ne e bëmë multi-stage me fuqitë tona. Më pas patëm një mori pyetjesh lidhur me pastrimin e images. Të gjithë ata që bëjnë CI/CD, më shpejt se vonë, përballen me problemin se ka shumë images të ndërtuara, dhe duhet të pastrojnë ato që nuk duhen dhe të lënë ato që duhen.
Arsyeja e dytë është në depol. Po, ka Helm, por ai zgjidh vetëm një pjesë të detyrave. Siç është e çuditshme, është shkruar se 'Helm është Menaxheri i Paketave për Kubernetes'. Në të vërtetë, 'Menaxheri i Paketave' — çfarë pritet zakonisht nga Menaxheri i Paketave? Ne themi: 'Menaxheri i Paketave, vendos paketën!' dhe presim që ai të na thotë: 'Paketa u vendos'.
Është interesante se ne themi: 'Helm, vendos paketën', dhe kur ai përgjigjet se e ka vendosur, zbulojmë se ai vetëm ka filluar instalimin — i tha Kubernetes: 'Starto këtë gjë!', por nëse ajo u startua apo jo, nëse punon apo jo, Helm nuk e zgjidh këtë pyetje fare.
Prandaj, Helm është thjesht një preprocessori tekstual që ngarkon të dhëna në Kubernetes.
Por, ne do të duam ta dimë — a e realizuam aplikacionin në prodhim apo jo? Të ketë kaluar në prodhim do të thotë që aplikacioni u publikua, një version i ri u aktivizua, dhe ai të paktën nuk bie dhe përgjigjet saktë. Helm nuk e zgjidh këtë problem. Për ta zgjidhur atë, duhen investuar shumë përpjekje, sepse është e nevojshme të jepni komandën Kubernetes për të publikuar dhe të monitoroni se çfarë po ndodh atje — a është aktivizuar, a është rregulluar. Dhe ka gjithashtu shumë detyra të lidhura me publikimin, pastrimin, dhe ndërtimin.
Planet
Edhe këtë vit ne do të fillojmë zhvillimin lokal. Ne duam të arrijmë atë që dikur kishte në Vagrant — të shkruajmë 'vagrant up' dhe të na aktivizoheshin makinash virtuale. Ne duam të arrijmë në një gjendje ku ka një projekt në Git, ne aty shkruajmë 'werf up', dhe ai ngre një kopje lokale të këtij projekti, e cila është e instaluar në një mini-Kub lokal, me të gjitha dosjet e lidhura, të përshtatshme për zhvillim. Në varësi të gjuhës së zhvillimit, kjo kryhet ndryshe, megjithatë, që të mund të zhvillohet lehtësisht me skedarë të montuar.
Hapi ynë i ardhshëm është të forcojmë investimi në komoditet për zhvilluesit. Për të vendosur shpejt një projekt lokalisht me një mjet, për ta zhvilluar, për ta dërguar në Git, dhe ai të del po ashtu në skenë ose në teste, në varësi të pipeline-ve, dhe pastaj me të njëjtin mjet të shkojmë në prodhim. Ky unitet, unifikimi, riprodhueshmëria e infrastrukturës nga mjedisi lokal deri në prodhim është një moment shumë i rëndësishëm për ne. Por kjo ende nuk është në werf - vetëm po e planifikojmë.
Por rruga drejt dapp/werf gjithmonë ka qenë e njëjtë si me Kubernetes në fillim. Ne kemi përballur me probleme, i zgjidhim ato në mënyra alternative - shpikim disa zgjidhje me shell, me çfarëdo përmbajtjeje. Pastaj, këto rrugë alternative përpiqemi t'i shesim, t'i përgjithsojmë dhe t'i konsolidojmë në binarë, me të cilat vetëm ndajmë.
Ka një tjetër këndvështrim për gjithë këtë histori, me analogji.
Kubernetes është një strukturë automobili me motor. Nuk ka dyer, xhama, radio, aromatizues - për atë, nuk ka asgjë. Vetëm kornizë dhe motor. Dhe ka Helm - ky është timoni. Është super - kemi timonin, por na nevojiten gjithashtu stafetë e timonit, sistemi i drejtimit, kutia e ngjitjes dhe rrotat, sepse pa to nuk shkon.
Në rastin me werf, ky është një komponent tjetër për Kubernetes. Tani, ne kemi një version alfa të werf, për shembull, Helm është inkorporuar ngushtë brenda werf, sepse na u lodh të bëjmë këtë vetë. Ka shumë arsye për këtë, dhe do të flas për arsyet pse ne inkorporuam plotësisht Helm bashkë me Tiller brenda werf. .
Tani, werf është një komponent më i integruar. Ne kemi një timon të gatshëm, një pin timoni - nuk e kuptoj shumë në makina, por ky është një bllok i madh që zgjidh një gamë të gjerë problemesh. Nuk është e nevojshme të kërkojmë për pjesë të ndryshme dhe të mendojmë se si t'i bashkojmë ato. Ne marrim një kombajn të gatshëm, i cili zgjidh një grup të madh problemesh menjëherë. Por brenda, ajo është ndërtuar nga të njëjtat komponentë open source, gjithashtu përdor Docker për ndërtim, Helm për një pjesë të funksionalitetit, dhe ka disa biblioteka tjera. Ky është një mjet i integruar për të marrë një CI/CD të shkëlqyer me shpejtësi dhe lehtësi nga kutia.
A është e vështirë të mbash Kubernetes?
— Ti flas për përvojën tënde, se si e fillove të përdorësh Kubernetes, që për ju është një kornizë, motor, dhe se mbi të mund të vendosësh shumë gjëra të ndryshme: karoseri, timon, të ngjitesh pedalet, sedilet. Ngrihet pyetja — sa e vështirë është për ju të mbani Kubernetes? Keni një përvojë të pasur, sa kohë dhe burime ju nevojiten specifikisht për të mbajtur Kubernetes, në veçanti nga e gjithë e tjera?
Dmitri: Kjo është një pyetje shumë e komplikuar dhe për të përgjigjur, duhet të kuptomë se çfarë do të thotë mbështetje dhe çfarë dëshirojmë nga Kubernetes. Ndoshta do të ndash disa më shumë?
— Sa kam informacion dhe si e shoh, tani shumë ekipe duan të provojnë Kubernetes. Të gjithë po e qasin, e vendosin në gjunjë. Kam ndjesinë se njerëzit nuk e kuptojnë gjithmonë kompleksitetin e këtij sistemi.
Dmitri: Ashtu është.
— Sa e vështirë është të marrësh dhe të vendosësh Kubernetes nga e para, që të jetë gati për prodhim?
Dmitri: Si mendon, sa e vështirë është të transplantosh një zemër? E kuptoj, kjo është një pyetje e ngjashme. Të përdorësh një skalpel dhe të mos gabosh — nuk është aq e vështirë. Nëse të thonë se ku të prenosh, dhe ku të mbyllësh, atëherë procedura vetë nuk është e komplikuar. E vështirë është të garantosh çdo herë se gjithçka do të dalë siç duhet.
Instalimi i Kubernetes dhe bërja që të funksionojë është e thjeshtë: hop! — u instalua, ka shumë mënyra për ta bërë këtë. Por çfarë do të ndodhë kur të shfaqen problemet?
Gjithmonë lindin pyetje — çfarë nuk kemi marrë parasysh? Çfarë nuk kemi bërë? Cilët parametra të bërthamës Linux i kemi thënë gabim? O Zot, a i kemi thënë të gjithë?! Cilët komponentë të Kubernetes e kemi instaluar, dhe cilët jo? Shfaqen mijëra pyetje dhe për të përgjigjur në to, duhet të kesh 15-20 vjet përvojë në këtë industri.
Kam një shembull të freskët në këtë drejtim që mund të zbulojë kuptimin e problemit "A është e vështirë mbajtja e Kubernetes?" Një kohë më parë ne po e shqyrtonim seriozisht nëse duhet të provonim të implementonim Cilium si rrjet në Kubernetes.
Le të sqaroj se çfarë është Cilium. Në Kubernetes ka shumë realizime të ndryshme të sistemit të rrjetit, dhe njëra prej tyre është shumë e bukur — kjo është Cilium. Çfarë e bën atë interesante? Në bërthamën Linux, një kohë më parë u shfaq mundësia për të shkruar hooks për bërthamën, të cilat ndonjëherë ndërhyjnë në sistemin e rrjetit dhe në shumë sisteme të tjera, duke lejuar të kalohen pjesë të mëdha të bërthamës.
Në bërthamën Linux historikisht ka ip rout, netfilter, bridge dhe shumë komponente të tjera të vjetra, që janë 15, 20, 30 vjeçare. Në përgjithësi ato funksionojnë, gjithçka është në rregull, por tani kemi mbushur me kontejnerë, dhe duket si një kumbare prej 15 tullash një mbi tjetrën, dhe ti je duke qëndruar mbi të me një këmbë – një ndjenjë e çuditshme. Ky sistem është zhvilluar historikisht me shumë nuanca, si një apendiks në trup. Në disa situata ka probleme me performancën, për shembull.
Ka një BPF të shkëlqyer dhe mundësinë për të shkruar hook për bërthamën – djemtë shkruan hook e tyre për bërthamën. Paketa vjen në bërthamën Linux, ata e nxjerrin atë direkt në hyrje, e përpunojnë siç duhet pa bridge, pa TCP, pa IP stack – me fjalë të tjera, duke anashkaluar gjithçka që është shkruar në bërthamën Linux, dhe menjëherë e përplasën në kontejner.
Çfarë ndodhi? Një performancë shumë e shkëlqyer, veçori të shkëlqyera – thjesht fantastike! Por ne e shohim këtë dhe shohim se në çdo makinë është instaluar një program që lidhet me API-në e Kubernetes dhe, në bazë të të dhënave që merr nga ky API, gjeneron kodin C dhe kompilon binarët, të cilët ngarkohen në bërthamë, që në hapësirën e bërthamës këto hook të funksionojnë.
Çfarë do të ndodhë nëse diçka shkon keq? Ne nuk e dimë. Për ta kuptuar këtë, duhet të lexoni të gjithë këtë kod, të kuptoni gjithë logjikën, dhe kjo është e komplikuar. Por, nga ana tjetër, ka këto bidge, filtre net-i, IP rout - nuk kam lexuar kodet e tyre, dhe as 40 inxhinierët që punojnë në kompaninë tonë. Ndoshta disa pjesë kuptohen nga disa individë.
Dhe çfarë rëndësie ka? Duket se ka IP rout, bërthamën Linux, dhe ka një mjet të ri - çfarë rëndësie ka, asnjëra nga ato nuk e kuptojmë. Por kemi frikë të përdorim të reja - pse? Sepse nëse një mjet është 30 vjeçare, atëherë gjatë 30 viteve të kaluara të gjitha gabimet janë gjetur, janë hasur në të gjitha rreziqet dhe për të ditur për të gjitha nuk është e nevojshme - punon si një kuti e zezë, dhe gjithmonë punon. Të gjithë e dinë se ku të fusin një screwdriver diagnostikues dhe cili tcpdump të nisin në çastin e duhur. Të gjithë e dinë mirë mjetet diagnostikuese dhe kuptojnë si funksionon ky set komponentesh në bërthamën Linux - jo si është ndërtuar, por si ta përdorin atë.
Por Cilium, i cili nuk ka 30 vjet, akoma nuk është i pjekur. Poashtu ka të njëjtin problem me Kubernetes; është një kopje. Të dyja instalohen shkëlqyeshëm, por, kur diçka shkon keq në prodhim, a jeni të aftë të kuptoni shpejt, se çfarë ka shkuar keq në një situatë kritike?
Kur flasim nëse është e vështirë të mbash Kubernetes — jo, është shumë e lehtë, dhe po, është jashtëzakonisht e vështirë. Kubernetes funksionon shkëlqyer vetëm, por me një miliard nuancash.
Për qasjen "Më ndihmoj fatit"
— A ka kompani ku këto nuanca do të shfaqen pothuajse me siguri? Supozoni se Yandex do të kalojë të gjitha shërbimet në Kubernetes, do të ketë një ngarkesë të madhe.
Dmitri: Jo, 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ë se ai funksionon? Nuk ka mjete të gatshme për të kuptuar se a po shembet aplikacioni, thjesht nuk egziston. Nuk ka një sistem të gatshëm që dërgon alarme — duhet ta konfiguroni këtë alarm dhe çdo grafik. E ne po e përditësojmë Kubernetes.
Ka Ubuntu 16.04. Mundësia është se kjo është një version i vjetër, por ne akoma e përdorim sepse aty kemi LTS. Aty ka systemd, me nuancën se ai nuk pastron grupet C. Kubernetes ekzekuton pods, krijon grupe C, pastaj i fshin pods, dhe ndodhin disa gjëra kështu - nuk e mbaj mend detajet, më vjen keq - që mbeten sslice nga systemd. Kjo çon në atë që me kalimin e kohës çdo makinë fillon të ngadalësohet ndjeshëm. Kjo nuk është vetëm për highload. Nëse fillojnë të ekzekutohen pods të përhershëm, për shembull, nëse ka një Cron Job që vazhdimisht gjeneron pods, atëherë makina me Ubuntu 16.04 pas një jave do të fillojë të ngadalësohet. Aty do të ketë një load average të lartë për shkak se janë krijuar shumë grupe C. Kjo është një problem me të cilin përballet çdo person që thjesht instalon Ubuntu 16 dhe e instalon Kubernetes mbi të.
Supozoni se se ndonjë mënyrë e përditëson systemd ose diçka tjetër, por në bërthamën Linux deri në 4.16 është akoma më e çuditshme – kur flitet për heqjen e C-grupeve, ato në bërthamë vazhdojnë të depërtojnë dhe faktikisht nuk eliminohen. Prandaj, pas një muaji punë në këtë makinë, do të jetë e pamundur të shikosh statistikën e kujtesës për podet. Ne nxjerrim një skedë, e rrotullojmë në program, dhe një skedë e tillë rrotullohet për 15 sekonda, sepse bërthama llogarit brenda vetes miliona C-grupeve, që siç duket janë hequr, por jo – ato vazhdojnë të depërtojnë.
Ka shumë detaje të tilla ende shumë në këtu e atje. Kjo nuk është një çështje me të cilën kompanitë gjigante ndonjëherë mund të përballen nën ngarkesa shumë të mëdha - jo, kjo është një çështje e përditshme. Njerëzit mund të jetojnë kështu për muaj të tërë - vendosën Kubernetes, e vendosën aplikimin - duket se punon. Për shumë është në rregull. Rreth asaj se kur njëherë ky aplikim ndonjëherë do të bjerë, ata as nuk do të kuptojnë, alarmin nuk do të vijë, por për ta kjo është norma. Më parë jetonin në virtualizime pa mbikëqyrje, tani janë shpërngulur në Kubernetes gjithashtu pa mbikëqyrje - çfarë ndryshimi ka?
Problemi është se kur ecim mbi akull, kurrë nuk e dimë trashësinë e tij nëse nuk e kemi matur paraprakisht. Shumë ecnë dhe nuk shqetësohen, sepse kanë ecur edhe më parë.
Nga këndvështrimi im, nuanca dhe kompleksiteti i funksionimit të çdo sistemi është që të garantohet se trashësia e akullit është me të vërtetë e mjaftueshme për të përmbushur detyrat tona. Është fjala për këtë.
Në IT, më duket se ka shumë qasje ‘Më ka ndodhur’. Shumë instalojnë software, përdorin biblioteka programimi me shpresën se do t’u ndodhë. Në përgjithësi, shumë kanë fat. Ndoshta për këtë funksionon.
— Nga vlerësimi im pesimist, kjo duket kështu: kur rreziqet janë të mëdha, dhe aplikacioni duhet të funksionojë, atëherë është e nevojshme mbështetje nga ‘Flant’ ose, ndoshta, nga Red Hat, ose kërkohet një ekip i brendshëm i dedikuar drejtpërdrejt për Kubernetes, i cili është i gatshëm ta mbajë atë.
Dmitri: Objekti është kështu. Të hysh vetë në historinë me Kubernetes me një ekip të vogël përbën disa rreziqe.
Na nevojiten konteinerët?
— Mund të flasësh për sa të përhapur është Kubernetes në Rusi?
Dmitri: Nuk kam këto të dhëna, dhe nuk jam i sigurt se a i kanë vërtet askush. Ne po flasim: “Kubernetes, Kubernetes”, por ka një këndvështrim tjetër mbi këtë çështje. Sa të zakonshëm janë kontejnerët, gjithashtu nuk e di, por e di një numër nga raporte në internet, që 70% e kontejnerëve orkestrohen nga Kubernetes. Ky ishte një burim i besueshëm për një mostër mjaft të madhe në të gjithë botën.
Më pas, pyetja tjetër është - a na nevojiten kontejnerët? Kam një ndjenjë 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ë game-changer absolut në menaxhimin e infrastrukturës. Thjesht absolut - gjithë, asnjë Ansible, Chef, makinat virtuale, Terraform. Nuk po flas për metodat e vjetra kombinate. Kubernetes është një changer absolut, dhe tani do të jetë vetëm kështu.
E qartë është se disa kanë nevojë për disa vite, ndonjëherë disa dhjetëra, për ta kuptuar këtë. Nuk kam dyshim se nuk do të ketë asgjë tjetër përveç Kubernetes dhe këtij këndvështrimi të ri: më nuk e dëmtojmë operacionin, por përdorim infrastructure as code, vetëm që jo me kod, por me yml - infrastrukturë të përshkruar në mënyrë deklarative. Kam ndjesinë se kështu do të jetë gjithmonë.
— Kjo do të thotë, se kompanitë që ende nuk janë kaluar në Kubernetes, patjetër do të kalojnë ose do të mbeten në harresë. A e kuptova mirë?
Dmitri: Kjo nuk është gjithashtu krejtësisht e saktë. Për shembull, nëse kemi për qëllim të nisim një server dns, mund ta nisim në FreeBSD 4.10 dhe ai mund të funksionojë shkëlqyer për 20 vjet. Thjesht të funksionojë dhe kaq. Ndoshta për 20 vjet do të nevojitet të azhurnohet diçka një herë. Nëse flasim për softin në formatin që e kemi nisur dhe ai realisht funksionon shumë vite pa azhurnime ose ndryshime, atëherë sigurisht atje nuk do të ketë Kubernetes. Ai nuk është i nevojshëm atje.
Kushdo që lidhet me CI/CD — kudo ku nevojitet Continuous Delivery, ku kërkohet për të azhurnuar versione, për të bërë ndryshime aktive, kudo ku është e domosdoshme të krijohet qëndrueshmëria ndaj dështimit — vetëm Kubernetes.
Për mikroshërbimet
— Këtu kam një disonancë të vogël. Për të punuar me Kubernetes, nevojitet mbështetje e jashtme ose e brendshme — ky është momenti i parë. E dyta — kur sapo fillojmë zhvillimin, jemi një startup i vogël, nuk kemi asgjë, zhvillimi nën Kubernetes ose për arkitekturën mikroserviz mund të jetë i ndërlikuar dhe jo gjithmonë i justifikuar ekonomikisht. Më intereson mendimi yt — a duhet që startup-et nga zero të fillojnë menjëherë të kodojnë për Kubernetes apo mund të shkruajnë një monolit dhe më pas të kalojnë te Kubernetes?
Dmitri: Pyetje e shkëlqyer. Kam një prezantim në lidhje me mikroservizet Kam hasur shumë herë që njerëzit përpiqen të përdorin një mikroskop për të goditur thumba. Qasja është e drejtë, ne vetë projektimin e softuerit të brendshëm e bëjmë pikërisht në këtë mënyrë. Por kur e bëni këtë, duhet të kuptoni qartë se çfarë po bëni. Më së shumti në mikroservizet unë e urrehem fjalën «mikro». Historikisht, kjo fjalë ka lindur atje, dhe për ndonjë arsye njerëzit mendojnë se mikro është shumë e vogël, më e vogël se milimetri, si mikrometri. Nuk është kështu.
P.sh. ka një monolit që e shkruajnë 300 njerëz, dhe të gjithë që kanë marrë pjesë në zhvillim e kuptojnë se ka probleme, dhe duhet ta ndajnë në mikro-pjesë — rreth 10, secila prej të cilave e shkruajnë 30 njerëz në versionin minimal. Kjo është e rëndësishme, e nevojshme dhe e shkëlqyer. Por kur na vjen një startup ku 3 djem shumë të talentuar kanë shkruar në kolltuk 60 mikroshërbime, çdo herë unë kërkoj korvalol.
Më duket se për këtë janë folur mijëra herë — kemi marrë një monolit të shpërndarë në atë ose këtë formë. Kjo është ekonomikisht e paarsyeshme, shumë e vështirë në përgjithësi. Thjesht e kam parë kaq herë sa më dhemb, prandaj vazhdoj të flas për të.
Për pyetjen fillestare, që ka një konflikt midis faktit që, nga njëra anë, Kubernetes është tmerrësisht e vështirë për t'u përdorur, sepse nuk e di se çfarë mund të prishet ose të mos funksionojë, nga ana tjetër, është e qartë se gjithçka po shkon atje dhe nuk do të ketë asgjë tjetër përveç Kubernetes. Përgjigja është — të vlerësojmë sasinë e përfitimit që vjen, sasinë e detyrave që mund të zgjidhni.. Kjo është njëra anë e peshës. Anë tjetër janë rreziqet që lidhen me ndalesat ose me uljen e kohës së reagimit, nivelit të disponueshmërisë — me uljen e treguesve të performancës.
Çështja është kështu — ose ne lëvizim shpejt, dhe Kubernetes lejon të bëjmë shumë gjëra më shpejt dhe më mirë, ose përdorim zgjidhje të besueshme dhe të provuara, por lëvizim shumë më ngadalë. Ky është një vendim që çdo kompani duhet ta bëjë. Mund ta shohim si një rrugë në xhungël — kur e bën për herë të parë, mund të hasësh një gjarpër, një tigër ose një derr të çmendur, dhe kur ke shkuar 10 herë — e ke thyer rrugën, hequr degët dhe është më e lehtë të ecësh. Me çdo herë e më gjerë rruga. Pastaj, bëhet një rrugë e asfaltuar, dhe më vonë një bulevard i bukur.
Kubernetes po shpejtë dhe nuk qëndron në vend. Përsëri pyetja: Kubernetes, nga njëra anë, është 4-5 binarë, nga ana tjetër — kjo është e gjithë ekosistemi. Kjo është një sistem operativ që e kemi në makinat tona. Çfarë është? Ubuntu apo Curios? Ky është bërthama Linux, shumë komponentë shtesë. Të gjitha këto gjëra këtu hodhën një gjarpër helmues nga rruga, aty vendosën një gardh. Kubernetes evoluon shumë shpejt dhe dinamike, dhe sasia e rreziqeve, sasia e të panjohurave zvogëlohet me çdo muaj dhe, për pasojë, këto pesha rikthehen në ekuilibër.
Në përgjigje të pyetjes se çfarë duhet të bëjë një startup, do të thosha - vijini "Flant", paguani 150,000 rubla dhe merrni një shërbim 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 do të duhet të mësojë të zgjidhë problemet tuaja dhe t'i paguajë atij rrogën në atë kohë, do të merrni një zgjidhje për të gjitha çështjet me çelës në dorë. Po, ka disa të meta. Ne, si një outsourcer, nuk mund të jemi aq të involvuar dhe të reagojmë shpejt ndaj ndryshimeve. Por, kemi shumë ekspertizë, praktikë të gatshme. Ne garantojmë se në çdo situatë ne do të përballim shpejt dhe do të rrisim çdo Kubernetes nga botët e tjera.
Unë këmbyesht rekomandoj outsourcingun për startupet dhe bizneset e vendosura deri në pikën kur mund të dedikoni një ekip prej 10 njerëzish për operacion, sepse përndryshe nuk ka asnjë kuptim. Kjo ka kuptim të jashtëzakonshëm për t'u outsourcuar.
Për Amazonin dhe Google
- A mund të konsiderohet si outsourcing hostimi nga zgjidhja e Amazon ose Google?
Dmitri: Po, sigurisht, kjo zgjidh disa çështje. Por ka përsëri nuanca. Megjithatë, duhet të kuptohet si ta përdorësh. Për shembull, ka mijëra detaje në punën e Amazon AWS: Load Balanceri duhet ngrohur ose duhet të dërgohet një kërkesë paraprakisht që 'djem, do të kemi trafik, lutem ngrohni Load Balancerin!' Këto nuanca duhet të dihen.
Kur i drejtoheni njerëzve që specializohen në këtë, merrni pothuajse të gjitha gjërat standarde të mbyllura. Tani kemi 40 inxhinierë, deri në fund të vitit, ndoshta do të jemi 60 - ne sigurisht që kemi hasur me të gjitha këto gjëra. Edhe nëse në ndonjë projekt ne përballemi me këtë problem përsëri, ne tashmë pyesim shpejt njëri-tjetrin dhe dimë se si ta zgjidhim.
Ndoshta përgjigjja është se, sigurisht, historia e hostimit lehtëson një pjesë të caktuar. Pyetja është, a jeni të gatshëm të besoni këta ofrues hostimi dhe a do të zgjidhin ata problemet tuaja? Amazon dhe Google kanë treguar rezultate të mira. Për të gjitha rastet tona - gjithashtu. Nuk kemi përvojë pozitive nga ndonjë tjetër. Të gjitha cloud-et e tjera me të cilat kemi provuar të punojmë krijojnë shumë probleme - dhe Ager, dhe gjithçka që ka në Rusi, dhe OpenStack të ndryshëm në realizime të ndryshme: Headster, Overage - çfarëdo që dëshironi. Të gjitha këto krijojnë probleme që nuk doni t'i zgjidhni.
Pra, përgjigjja është po, por, në fakt, nuk ka shumë zgjidhje të pjekura të hostuara.
Kush ka nevojë për Kubernetes?
— Dhe megjithatë, kush ka nevojë për Kubernetes? Kush duhet të kalojë në Kubernetes, kush është klienti tipik i "Flant" që vjen për Kubernetes?
Dmitri: Pyetja është interesante, sepse tani, në valën e Kubernetes, shumë na afrohen: «Djem, e dimë që ju bëni Kubernetes, na e bëni!» Ne u përgjigjemi: «Zotërinj, ne nuk bëjmë Kubernetes, ne bëjmë prodhim dhe gjithçka që lidhet me të.» Sepse të bësh prodhim pa bërë të gjithë CI/CD-në dhe të gjithë këtë histori, në kohët moderne është thjesht e pamundur. Të gjithë kanë dalë nga ndarja për të thënë se ne kemi zhvillim për zhvillimin dhe pastaj funksionim për funksionimin.
Klientët tanë presin gjëra të ndryshme, por të gjithë presin ndonjë mrekulli të mirë, që ata kanë këto ose ato probleme, dhe tani – hop! – Kubernetes do t'i zgjidhë. Njerëzit besojnë në mrekulli. Me mendje e kuptojnë që s'ka për të pasur mrekulli, por me shpirt shpresojnë – ndoshta ky Kubernetes tani do të zgjidhë gjithçka për ne, flitet kaq shumë për të! Ndoshta ai tani – çik! – dhe gjuha argjendi, çik! – dhe ne kemi 100% uptime, të gjithë zhvilluesit mund të lëshojnë gjithçka 50 herë në prodhim, dhe nuk jepet. Në përgjithësi, mrekulli!
Kur njerëz të tillë na vizitojnë, ne themi: "Na falni, por nuk ka mrekulli". Për të qënë të shëndetshëm, duhet të ushqehesh mirë dhe të bësh sport. Për të pasur një server të sigurt, ai duhet të ndërtohet siç duhet. Për të pasur një CI/CD komod, ai duhet të realizohet si i tillë. Kjo është shumë punë që duhen bërë.
Dhe përgjigjja për pyetjen, kush ka 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, ata kanë një nevojë të thellë për të ndaluar së menduari, së punuari, dhe së interesuar për të gjitha problemet e infrastrukturës dhe problemet e lançimit të aplikacioneve të tyre. Ata duan që aplikacionet të funksionojnë thjesht dhe të vendosen thjesht. Për ta, Kubernetes është shpresa se do të ndalin së dëgjuari historinë që "ne kemi pasur probleme" apo "nuk mund të dalim live", ose diçka tjetër.
Zakon është se zakonisht na vjen drejtori teknik. Prej tij kërkohen dy gjëra: nga njëra anë, na jep karakteristika, nga ana tjetër - stabilitet. Ne e ofrojmë që ta marrim këtë mbi vete dhe ta realizojmë. Plani ideal, për të qenë më korrekt, është që ti të ndalosh së menduari për këto probleme dhe të mos humbësh kohë. Do të kesh njerëz të veçantë që do ta zgjidhin këtë çështje.
Formulimi se ne ose dikush tjetër ka nevojë për Kubernetes ë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ë eksperimentosh. Le të jemi të sinqertë - të gjithë i duan lodrat. Të gjithë ne ndonjëherë jemi fëmijë, dhe kur shohim ndonjë gjë të re - duam të luajmë me të. Disa e kanë humbur këtë, për shembull, në administrim, sepse tashmë janë lodhur dhe ua ka tejkaluar deri në pikën që thjesht nuk duan. Por kjo nuk është humbur plotësisht për askënd. Për shembull, nëse më janë lodhur lodrat në fushën e administratës së sistemeve dhe DevOps, unë ende i dua lodrat, dhe gjithsesi blej diçka të re.
Mos luani me prodhimin. Ajo që unë kategoriçikisht nuk e rekomandoj të bëni dhe që shoh tani masivisht është: "Ah, një lodër e re!" - vrapuam ta blejmë, e blenë dhe: "Le të shkojmë tani në shkollë, t'ua tregojmë të gjithëve miqtë." Mos e bëni këtë. Më vjen keq, ndjej vetëm se fëmijët e mi po rriten, vazhdimisht shoh diçka tek ta, e vërej në veten time dhe pastaj e përgjithsoj te të tjerët.
Përgjigja përfundimtare: nuk keni nevojë për Kubernetes. Duhet të zgjidhni problemet tuaja.
Mund të arrihet që:
- prodhimi të mos bie;
- edhe nëse përpiqet të bjerë, ne e dimë këtë paraprakisht dhe mund të vendosim diçka tjetër;
- mund ta ndryshojmë me shpejtësinë që kërkojmë për biznesin dhe ta bëjmë këtë lehtësisht, nuk na shkakton probleme.
Kërkesat reale janë dy: besueshmëria dhe dinamikën/fleksibilitetin e lëshimit. Të gjithë ata që po bëjnë projekte IT tani, pa marrë parasysh se në cilin biznes janë - soft për lehtësimin e botës, dhe ata që e kuptojnë këtë, duhet të zgjidhin këto kërkesa. Kubernetes me qasje të duhur, me kuptim të duhur dhe me përvojë të mjaftueshme lejon zgjidhjen e tyre.
Për serverless
— Nëse shohim pak më larg në të ardhmen, kur përpiqemi të zgjidhim problemin e mungesës së dhimbjes së kokës me infrastrukturën, shpejtësinë e lançimit dhe shpejtësinë e ndryshimit të aplikacioneve, shfaqen zgjidhje të reja, si p.sh. serverless. A ndjen ndonjë potencial në këtë drejtim dhe, për ta thënë ndryshe, rrezik për Kubernetes dhe zgjidhje të ngjashme?
Dmitri: Këtu duhet bërë sërish një vërejtje, që unë nuk jam një parashikues që shikon përpara dhe thotë - do të jetë kështu! Megjithatë, sapo bëra të njëjtën gjë. Po shoh poshtë dhe shoh shumë probleme, siç funksionojnë tranzistorët në kompjuter. Është qesharake, apo jo? Po përballemi me disa gabime në CPU.
Të bësh serverless mjaft të besueshëm, të lirë, efikas dhe të përshtatshëm, duke zgjidhur të gjitha çështjet e ekosistemit. Këtu pajtohem me Elon Musk-in që na nevojitet një planet tjetër për të siguruar qëndrushmërinë për njerëzimin. Megjithatë, nuk e di çfarë thotë ai, por kuptoj se nuk jam gati të fluturroj vetë në Mars dhe kjo nuk do të ndodhë nesër.
Me serverless është e qartë se është një koncept ideologjikisht i drejtë, si qëndrueshmëria për njerëzimin — më mirë të kemi dy planete sesa një. Por si ta realizojmë këtë tani? Dërgimi i një ekspedite — nuk është problem, nëse përqendrojmë përpjekjet në këtë. Dërgimi i disa ekspeditave dhe vendosja e disa mijëra njerëzve atje, mendoj se është gjithashtu realist. Po, për ta bërë në tërësi qëndrueshmërinë, që gjysma e njerëzimit të jetonte atje, më duket tani e pamundur, jo e shqyrtuar.
Me serverless është njësoj: është diçka e shkëlqyer, por është e largët nga problemet e vitit 2019. Më afër vitit 2030 — le të arrijmë deri atje. Nuk dyshoj se do të arrijmë, patjetër do të arrijmë (përsëriteni para gjumit), por tani duhet të zgjidhim probleme të tjera. Është si të besosh në një ponin magjik Radugaand. Po, një pakicë 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 nuk mund të shkruash asnjë aplikacion me serverless.
Si do të evoluoj Kubernetes
— Ndërsa ne shkojmë drejt këtij të ardhmeje potencialisht të shkëlqyer, si mendon ti se do të zhvillohet Kubernetes dhe ekosistemi përreth tij?
Dmitri: Kam menduar shumë për këtë dhe kam një përgjigje të qartë. Së pari — stateful është më i vështirë për të bërë stateless. Kubernetes fillimisht investoi më shumë në këtë, ajo filloi me të. Stateless funksionon praktikisht perfekt në Kubernetes, thjesht nuk ka për të kritikuar. Ka ende shumë probleme, për të qenë më të saktë, nuanca me stateful. Tani po funksionon shkëlqyer për ne, por është kjo për ne. Për të bërë që kjo të funksionojë për të gjithë, nevojiten edhe disa vite, të paktën. Ky nuk është një tregues i përshtatshëm, por ndjenja ime nga mendja ime.
Në përfundim, 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 ndonjë database dhe diçka tjetër. Stateful është për eliminimin e të gjithave, për rregullimin e të gjithë defekteve, për përmirësimin e gjitha problemeve me të cilat përballemi tani — le ta quajmë këtë adoptim.
Niveli i panjohur, niveli i problemeve të pazgjidhura, niveli i probabilitetit për të u përballur me diçka, do të bjerë ndjeshëm. Kjo është një histori e rëndësishme. Dhe operatorët janë gjithçka që lidhet me kodifikimin e logjikës së administratës, logjikës së 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 komponentë që na nevojiten për ta bërë të punojë nga kutia me garanci. Kjo zgjidh pikërisht ato dhimbje që duam një bazë të dhënash, por nuk duam ta administrojmë atë, ose duam Kubernetes, por nuk duam ta administrojmë atë.
Kjo histori me zhvillimin e operatorëve në një formë ose tjetër do të jetë e rëndësishme në vitet e ardhshme.
Mendoj se thjeshtësia e operimit duhet të rritet ndjeshëm - kutia do të bëhet gjithnjë e më e zezë, gjithnjë e më e besueshme, me rrotulla 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 që është si Urgant, por më interesante. Aty e pyetën për të ardhmen e kompjuterëve. Ai tha se e ardhmja është në thjeshtësi, ashtu si ishte me aparatin e radios. Aparati i radios fillimisht ishte një gjë e komplikuar. Për të kapur një valë, duhej të rrotulloje levat dhe të kuptoje se si funksiononte, duke kuptuar fiziken e transmetimit të valëve radio. Në fund, në radio mbeti vetëm një levë.
Tani, në vitin 2019, çfarë radio je? Në makinë, aparati i radios gjen të gjitha valët dhe emrat e stacioneve. Fizika e procesit nuk ka ndryshuar për 100 vjet, ka ndryshuar thjeshtësia e përdorimit. Tani, dhe jo vetëm tani, madje që në vitin 1980, kur ishte intervista me Asimovin, të gjithë përdornin radio dhe askush nuk e mendonte se si funksiononte. Ajo gjithmonë ka punuar — kjo është një e vërtetë.
Asimov atëherë tha se me kompjuterët do të jetë njësoj — thjeshtësia e përdorimit do të rritet. Nëse më 1980 duhej një arsim të veçantë për të shtypur butona në kompjuter, në të ardhmen do të mos jetë kështu.
Kam ndjej se me Kubernetes dhe me infrastrukturën gjithashtu do të rritet shumë thjeshtësia e përdorimit. Kjo, sipas meje, është e qartë - e dukshme.
Çfarë do të bëjmë me inxhinierët?
— Çfarë do të ndodhë me inxhinierët, administratorët e sistemeve që mbështesin Kubernetes?
Dmitri: Çfarë ndodhi me të kontablin pas shfaqjes së 1C? Diçka e ngjashme. Më parë llogariteshin në letër - tani në program. Produktiviteti i punës është rritur shumë, dhe puna nuk ka humbur. Nëse më parë për të vendosur një llampë ne duheshin 10 inxhinierë, tani mjafton vetëm një.
Sasia e softuerit dhe numri i detyrave, më duket, tani po rritet me një shpejtësi më të madhe se sa po shfaqen new DevOps dhe rritet efikasiteti. Tani në treg ka një mungesë të dukshme dhe kjo do të vazhdojë për një kohë të gjatë. Më vonë gjithçka do të kalojë në një normë të caktuar, për të cilën efikasiteti i punës do të rritet, do të ketë gjithnjë e më shumë serverless, tek Kubernetes do të lidhet një rrjet nervor që do të menaxhojë të gjitha burimet ashtu siç nevojitet, dhe në përgjithësi do të bëjë gjithçka vetë siç duhet - njeri, largohet e mos ndërhy.
Por të gjitha zgjidhjet, prapë do të duhet që dikush të marrë vendime. Është e qartë se niveli i kualifikimit dhe specializimi i kësaj personi është më i lartë. Tani në departamentin e financës nuk ju nevojiten 10 punonjës që të mbajnë llogaritë për të mos u lodhur. Kjo nuk është thjesht e nevojshme. Shumë dokumente skanohet automatikisht, të njohura nga sistemi i menaxhimit të dokumenteve elektronike. Mjafton një kontabilist i zgjuar, me shumë aftësi dhe një mirëkuptim të mirë.
Në përgjithësi, një rrugë e tillë ekziston në të gjitha industrinë. Me veturat gjithashtu: dikur me veturën vinte një mekanik dhe tre shoferë. Tani, ngasja e një makine është një proces i thjeshtë, në të cilin të gjithë ne marrim pjesë çdo ditë. Askush nuk mendon se makina është diçka komplekse.
DevOps ose inxhinieria sistemike nuk do të zhduken asnjëherë - niveli i lartë dhe efikasiteti i punës do të rriten.
Kam dëgjuar gjithashtu një ide interesante se, në të vërtetë, puna do të rritet.
Dmitri: Sigurisht, njëqind për qind! Sepse sasia e softit që ne shkruajmë po rritet vazhdimisht. Numri i pyetjeve që ne zgjidhim me softin po rritet vazhdimisht. Sasia e punës po rritet. Tani tregu i DevOps është jashtëzakonisht i nxehtë. Kjo është e dukshme në pritjet për pagat. Në thelb, pa u thelluar në detaje, duhet të ketë juniorë që duan X, mesatarë që duan 1,5X, dhe seniorë që duan 2X. Por tani, nëse shohim tregun e pagave të DevOps në Moskë, juniorët duan nga X deri në 3X dhe seniorët duan nga X deri në 3X.
Askush nuk e di sa kushton. Niveli i pagës matet me besimin tënd - është një kaos i plotë, për të qenë e sinqertë, një treg i jashtëzakonshëm.
Sigurisht, kjo situatë do të ndryshojë shumë shpejt - duhet të ndodhë ndonjë ngopje. Me zhvillimin e softit nuk është kështu - megjithëse programuesit nevojiten nga të gjithë, dhe të gjithë kanë nevojë për programues të mirë, tregu e di se kush kushton sa - industria është stabilizuar. Me DevOps tani nuk është kështu.
— Nga ato që kam dëgjuar, kam përfunduar se nuk ia vlen shumë të shqetësohesh, por është koha të zhvillosh aftësitë dhe të përgatitesh që nesër do të ketë më shumë punë, por ajo do të jetë më e kualifikuar.
Dmitri: Sigurisht. Në përgjithësi jetojmë në vitin 2019 dhe rregulli i jetës është: mësimi gjithë jetën — ne mësojmë gjatë gjithë jetës. Më duket se tani të gjithë e dinë këtë dhe e ndjejnë, por diçka e tillë duhet ta bësh. Çdo ditë duhet të ndryshojmë. Nëse nuk e bëjmë këtë, një ditë do të na lënë jashtë profesionit.
Bëhuni të gatshëm për kthesa të papritura në 180 gradë. Nuk e përjashtoj situatën kur diçka do të ndryshojë rrënjësisht, do të shpikim diçka të re — ndodhin të tilla gjëra. Hop! — dhe tani veprojmë ndryshe. Është e rëndësishme të jesh i gatshëm për këtë dhe të mos shqetësohesh. Mund të ndodhë që nesër gjithçka që po bëj do të jetë e panevojshme — asgjë, kam mësuar gjithmonë dhe jam gati të mësoj diçka tjetër. Kjo nuk është një problem. Nuk ia vlen të frikësohesh për sigurinë e punës, por duhet të jesh i gatshëm të mësosh përherë diçka të re.
Ushqime dhe një minutë reklamë
— A do të kesh ndonjë dëshirë?
Dmitri: Po, kam disa dëshira.
E para dhe mercantile – abonohuni te . Të nderuar lexues, hyni në YouTube dhe abonohuni në kanalin tonë. Diku pas një muaji, ne do të fillojmë një zgjerim aktiv në shërbimin e videove ku do të kemi shumë përmbajtje edukative rreth Kubernetes, nga gjërat praktike, deri në laboratorë, nga parimet thelbësore dhe teorike deri tek mënyrat e aplikimit të Kubernetes në nivele parimesh dhe modelet.
E dyta, e cila është mercantile – hyni në dhe na jepni yjet, sepse ne ushqehemi me to. Nëse nuk na jepni yje, do të kemi uri. Kjo është si mana në një lojë kompjuterike. Ne bëjmë diçka, punojmë, përpiqemi, dikush thotë se janë biçikleta të frikshme, dikush tjetër se gjithçka është gabim, por ne vazhdojmë dhe veprojmë në mënyrë të ndershme. Ne shohim problemin, e zgjidhim dhe ndajmë përvojën. Prandaj, na jepni një yll, sepse prej jush nuk humbet asgjë, ndërsa ne përfitojmë, sepse me to ushqehemi.
E treta, e rëndësishme, dhe tashmë jo mercantile – ndaloni së besuari në përralla.. Ju jeni profesionistë. DevOps është një profesion shumë serioz dhe përgjegjës. Ndihmoni të hiqni dorë nga lojërat në vendin e punës. Le të shkurtohet dhe ta kuptoni këtë. Imagjinoni se shkoni në spital dhe aty një doktor eksperimentohet me ju. E kuptoj se disa mund të ndihen të ofenduar, por, ndoshta, kjo nuk është për ju, por për dikë tjetër. Tregoni të tjerëve që ata gjithashtu të ndalojnë. Kjo vërtet prish jetën e të gjithëve ne — shumë fillojnë t'i shohin operacionet, administratorët dhe DevOps si djem që prishin diçka përsëri. Ky “prishje” ndodh shpesh për shkak se ne fillojmë të luajmë, dhe jo të shikojmë me mendjen e ftohtë se çfarë është këtu kështu, e çfarë është kështu.
Kjo nuk do të thotë që nuk duhet të eksperimentohet. Duhet të eksperimentoni, ne vetë e bëjmë këtë. Nëse duam të jemi të sinqertë, ndonjëherë ne gjithashtu luajmë — kjo është, padyshim, shumë keq, por asgjë njerëzore nuk na është e huaj. Le të shpallim vitin 2019 vitin e eksperimenteve serioze të menduara, e jo lojërave në prodhim. Ndoshta kështu.
— Faleminderit shumë!
Dmitri: Faleminderit, Vitali, për kohën dhe intervistën. Të dashur lexues, ju faleminderit shumë nëse arritët deri në këtë moment. Shpresoj që të kemi sjellë të paktën disa mendime për ju.
Në intervistë, Dmitri preku çështjen e werf. Aktualisht, ajo është një thikë shumëfunksionale zvicerane që zgjidh pothuajse të gjitha detyrat. Por nuk ka qenë gjithmonë kështu. në festivalin Dmitri Stolyarov do të flasë për këtë mjet në detaje. Në referatin do të ketë gjithçka: probleme dhe nuanca të fshehura të Kubernetes, mënyra zgjidhjeje të këtyre vështirësive dhe implementimi aktual të werf në detaje. Bashkohuni më 27 dhe 28 maj, do të krijojmë mjete perfekte.
Burimi: habr.com
