arafasida Vitaliy Xabarov intervyu oldi Dmitriy Stolyarov (), Flant kompaniyasining texnik direktori va hammuassisi. Vitaliy Dmitriydan Flant nima qilishi, Kubernetes, ekotizim rivojlanishi, qo'llab-quvvatlash haqida so'radi. Biz Kubernetes nima uchun kerakligini va umuman kerakmi yoki yo'qligini muhokama qildik. Shuningdek, mikroservislar haqida, Amazon AWS, DevOps-ga “menga omad kulib boqadi” yondashuvi, Kubernetesning kelajagi, nima uchun, qachon va qanday qilib u dunyoni egallashi, DevOps istiqbollari va muhandislar bu jarayonda qanday tayyorgarlik ko'rishlari kerak. soddalashtirish va neyron tarmoqlari bilan yorqin va yaqin kelajak.
DevOps Deflop-da podkast shaklida tinglang - DevOps haqida rus tilidagi podkast, quyida esa matnli versiya.
Bu erda va pastda u savollar beradi Express42 muhandisi.
"Flant" haqida
- Salom Dima. Siz texnik direktorsiz "” va uning asoschisi. Iltimos, ayting-chi, kompaniya nima qiladi va unda nima bor?
Dmitriy: Tashqaridan qaraganda, biz hamma uchun Kubernetes o'rnatish va u bilan nimadir qilish bilan shug'ullanadigan yigitlar kabi ko'rinadi. Ammo bu unday emas. Biz Linux bilan shug'ullanadigan kompaniya sifatida ish boshladik, lekin juda uzoq vaqt davomida bizning asosiy faoliyatimiz ishlab chiqarish va yuqori yuklangan kalitlarga topshirilgan loyihalarga xizmat ko'rsatish edi. Odatda biz butun infratuzilmani noldan quramiz va keyin uzoq, uzoq vaqt davomida buning uchun javobgarmiz. Shuning uchun, "Flant" pul oladigan asosiy ish bu mas'uliyatni o'z zimmasiga olish va kalit ishlab chiqarishni amalga oshirish.
Men, texnik direktor va kompaniya asoschilaridan biri sifatida, ishlab chiqarishning qulayligini oshirish, uning ishlashini soddalashtirish, ma'murlarning hayotini osonlashtirish va ishlab chiquvchilarning hayotini yaxshilash uchun kunu tunni o'tkazaman. zavqli.
Kubernetes haqida
- So'nggi paytlarda men "Flant" dan ko'plab hisobotlarni ko'rmoqdaman va Kubernetes haqida. Uning oldiga qanday keldingiz?
Dmitriy: Men bu haqda ko'p marta gapirganman, lekin buni takrorlashga umuman qarshi emasman. Menimcha, bu mavzuni takrorlash to'g'ri, chunki sabab va oqibat o'rtasida chalkashlik bor.
Bizga haqiqatan ham vosita kerak edi. Ko‘p muammolarga duch keldik, kurashdik, ularni turli tayoqchalar bilan yengib, asbobga ehtiyoj sezdik. Biz turli xil variantlarni ko'rib chiqdik, o'z velosipedlarimizni qurdik va tajriba orttirdik. Asta-sekin biz Docker-dan deyarli paydo bo'lishi bilanoq foydalanishni boshladik - taxminan 2013 yil. Uning paydo bo'lishi paytida biz konteynerlar bilan juda ko'p tajribaga ega edik, biz allaqachon "Docker" ning analogini - Python-da o'zimizning ba'zi tayoqchalarimizni yozgan edik. Dockerning paydo bo'lishi bilan tayoqchalarni tashlash va ishonchli va jamiyat tomonidan qo'llab-quvvatlanadigan yechimdan foydalanish mumkin bo'ldi.
Kubernetes bilan hikoya o'xshash. U tezlasha boshlagan paytda - biz uchun bu 1.2-versiya - bizda Shell va Chef-da bir nechta tayoqchalar bor edi, biz ularni qandaydir tarzda Docker bilan tartibga solishga harakat qildik. Biz Rancher va boshqa turli xil echimlarni jiddiy ko'rib chiqdik, ammo keyin Kubernetes paydo bo'ldi, unda hamma narsa biz qilgandek yoki undan ham yaxshiroq amalga oshiriladi. Shikoyat qiladigan hech narsa yo'q.
Ha, bu yerda qandaydir nomukammallik bor, u yerda qandaydir nomukammallik bor - kamchiliklar ko'p va 1.2 umuman dahshatli, lekin ... Kubernetes qurilayotgan binoga o'xshaydi - siz loyihaga qaraysiz va tushunasiz. bu salqin bo'ladi. Agar bino hozirda poydevor va ikki qavatga ega bo'lsa, unda siz hali ko'chib o'tmaslik yaxshiroq ekanligini tushunasiz, ammo dasturiy ta'minot bilan bunday muammolar yo'q - siz allaqachon foydalanishingiz mumkin.
Bizda Kubernetes-dan foydalanish yoki yo'qligini o'ylagan paytimiz yo'q edi. Biz uni paydo bo'lishidan ancha oldin kutgan edik va o'zimiz analoglarni yaratishga harakat qildik.
Kubernetes haqida
- Siz Kubernetesning o'zini rivojlantirishda bevosita ishtirok etasizmi?
Dmitriy: O'rtacha. Aksincha, biz ekotizimni rivojlantirishda ishtirok etamiz. Biz ma'lum miqdordagi tortishish so'rovlarini yuboramiz: Prometeyga, turli operatorlarga, Helmga - ekotizimga. Afsuski, men qilayotgan har bir ishimizni kuzatib bora olmayman va men noto'g'ri bo'lishim mumkin, ammo bizda bitta hovuz yo'q.
- Shu bilan birga, siz Kubernetes atrofida ko'plab vositalaringizni ishlab chiqasizmi?
Dmitriy: Strategiya shunday: biz boramiz va mavjud bo'lgan barcha narsalarga so'rovlar yuboramiz. Agar tortishish so'rovlari u erda qabul qilinmasa, biz ularni o'zimiz bog'laymiz va ular bizning qurilishlarimiz bilan qabul qilinmaguncha yashaymiz. Keyin, u yuqoriga yetganda, biz yuqori oqim versiyasiga qaytamiz.
Misol uchun, bizda Prometey operatori bor, u bilan biz yig'ilishning yuqori oqimiga 5 marta o'tdik. Bizga qandaydir xususiyat kerak, biz tortib olish so‘rovini yubordik, ertaga uni chiqarishimiz kerak, lekin biz uning yuqori oqimga chiqarilishini kutmoqchi emasmiz. Shunga ko'ra, biz o'zimiz uchun yig'amiz, barcha klasterlarimizga negadir kerak bo'lgan xususiyatimiz bilan yig'amiz. Keyin, masalan, yuqorida ular buni bizga: "Bolalar, keling, umumiy holat uchun qilaylik" degan so'zlar bilan o'girsalar, biz yoki boshqa birov uni tugatadi va vaqt o'tishi bilan u yana birlashadi.
Biz mavjud bo'lgan hamma narsani rivojlantirishga harakat qilamiz.. Hali mavjud bo'lmagan, hali ixtiro qilinmagan yoki ixtiro qilingan, lekin amalga oshirishga ulgurmagan ko'plab elementlar - biz qilyapmiz. Va biz jarayon yoki velosiped qurishni sanoat sifatida yoqtirganimiz uchun emas, balki shunchaki ushbu vositaga muhtojmiz. Ko'pincha savol tug'iladi, nega biz u yoki bu narsani qildik? Javob oddiy - ha, chunki biz oldinga borishimiz, ba'zi amaliy muammolarni hal qilishimiz kerak edi va biz buni bu tula bilan hal qildik.
Yo'l har doim shunday: biz juda ehtiyotkorlik bilan qidiramiz va agar biz nondan trolleybus yasash bo'yicha hech qanday yechim topmasak, biz o'zimiz non va trolleybusimizni qilamiz.
Flanta vositalari
— Bilaman, Flant hozirda addon operatorlari, shell operatorlari va dapp/werf vositalariga ega. Men tushunganimdek, bu turli xil mujassamlardagi bir xil asbob. Flaunt ichida juda ko‘p turli xil vositalar mavjudligini ham tushunaman. Bu shunday?
Dmitriy: Bizda GitHub-da ko'p narsa bor. Hozir eslaganimdek, bizda status xaritasi bor - Grafana uchun panel, uni hamma uchratgan. Medium-da Kubernetes monitoringi haqida deyarli har ikkinchi maqolada aytib o'tilgan. Status xaritasi nima ekanligini qisqacha tushuntirishning iloji yo'q - bu alohida maqolani talab qiladi, ammo bu vaqt o'tishi bilan holatni kuzatish uchun juda foydali narsa, chunki Kubernetesda biz ko'pincha vaqt o'tishi bilan holatni ko'rsatishimiz kerak. Shuningdek, bizda LogHouse bor, ClickHouse-ga asoslangan narsa va Kubernetes-da jurnallarni yig'ish uchun qora sehr.
Ko'p kommunal xizmatlar! Va bundan ham ko'proq bo'ladi, chunki bu yil bir qator ichki echimlar chiqariladi. Addon operatoriga asoslangan juda katta bo'lganlardan Kubernetes uchun bir qator qo'shimchalar mavjud, ala sert menejerini qanday to'g'ri o'rnatish kerak - sertifikatlarni boshqarish vositasi, Prometeyni aksessuarlar to'plami bilan qanday qilib to'g'ri o'rnatish - bular yigirmaga yaqin turlidir. ma'lumotlarni eksport qiladigan va ushbu Prometey uchun biror narsa to'playdigan ikkilik fayllar eng ajoyib grafikalar va ogohlantirishlarga ega. Bularning barchasi klasterga joylashtirilgan Kubernetes-ga qo'shimchalar to'plami bo'lib, u oddiydan salqin, murakkab, avtomatikga aylanadi, unda ko'p muammolar allaqachon hal qilingan. Ha, biz juda ko'p ish qilamiz.
Ekotizim rivojlanishi
— Menimcha, bu ushbu vosita va undan foydalanish usullarini ishlab chiqishga juda katta hissa qo'shganga o'xshaydi. Yana kim ekotizim rivojlanishiga xuddi shunday hissa qo'shishini taxmin qila olasizmi?
Dmitriy: Rossiyada bizning bozorda ishlaydigan kompaniyalardan hech kim hatto yaqin emas. Albatta, bu baland ovozda bayonot, chunki Mail va Yandex kabi yirik o'yinchilar bor - ular ham Kubernetes bilan nimadir qilishyapti, lekin ular hatto bizdan ko'ra ko'proq ishlaydigan butun dunyo bo'ylab kompaniyalarning hissasiga yaqinlashmaydi. Adashmasam, Flantni 80 kishilik xodimlar va har bir Kubernetesda 300 ta muhandisdan iborat Red Hat bilan solishtirish qiyin. Taqqoslash qiyin. Bizda RnD bo'limida 6 kishi bor, shu jumladan men ham barcha asboblarimizni kesib tashladilar. 6 kishi va 300 Red Hat muhandislari - solishtirish qiyin.
- Biroq, bu 6 kishining ham haqiqatdan ham foydali va begona qiladigan ishni qila olishi, amaliy muammoga duch kelganida va jamiyatga yechimini berganida - qiziqarli holat. Men tushunamanki, o'zlarining rivojlanishi va Kubernetes qo'llab-quvvatlash jamoasi bo'lgan yirik texnologiya kompaniyalarida, printsipial jihatdan, xuddi shu vositalarni ishlab chiqish mumkin. Bu ular uchun Kubernetes-dan foydalanadigan butun jamoaga turtki berib, jamiyatga nima ishlab chiqish va berish mumkinligi haqidagi misoldir.
Dmitriy: Bu, ehtimol, integratorning o'ziga xos xususiyati, o'ziga xosligi. Bizda ko'plab loyihalar bor va biz juda ko'p turli vaziyatlarni ko'ramiz. Biz uchun qo‘shimcha qiymat yaratishning asosiy yo‘li bu holatlarni tahlil qilish, umumiy tomonlarini topish va ularni biz uchun imkon qadar arzon qilishdir. Bu biz faol ravishda izlayotgan narsadir. Rossiya va dunyo haqida gapirish men uchun qiyin, ammo kompaniyada Kubernetesda ishlaydigan 40 ga yaqin DevOps muhandislari bor. Menimcha, Rossiyada Kubernetesni tushunadigan, agar mavjud bo'lsa, shunga o'xshash mutaxassislar soni ko'p emas.
Men DevOps muhandisi lavozimi haqida hamma narsani tushunaman, hamma hamma narsani tushunadi va DevOps muhandislarini DevOps muhandislari deb atashga odatlangan, biz buni muhokama qilmaymiz. Ushbu 40 ta ajoyib DevOps muhandislari har kuni muammolarga duch kelishadi va ularni hal qilishadi, biz shunchaki ushbu tajribani tahlil qilamiz va umumlashtirishga harakat qilamiz. Biz tushunamizki, agar u bizning ichimizda qolsa, unda bir yoki ikki yil ichida vosita foydasiz bo'ladi, chunki jamiyatda bir joyda tayyor Tula paydo bo'ladi. Ushbu tajribani ichkarida to'plashning ma'nosi yo'q - bu shunchaki energiya va vaqtni dev/nullga sarflashdir. Va biz umuman afsuslanmaymiz. Biz hamma narsani katta mamnuniyat bilan nashr etamiz va odamlar undan foydalanishlari va o'z tajribalarini qo'shishlari uchun uni nashr qilish, rivojlantirish, targ'ib qilish, targ'ib qilish kerakligini tushunamiz - keyin hamma narsa o'sadi va yashaydi. Keyin, ikki yildan so'ng, asbob axlatga ketmaydi. Quvvatni to'ldirishda davom etish achinarli emas, chunki kimdir sizning asbobingizdan foydalanayotgani aniq va ikki yildan keyin hamma uni ishlatmoqda.
Bu dapp/werf bilan bizning katta strategiyamizning bir qismidir. Biz buni qachon boshlaganimizni eslay olmayman, 3 yil oldin bo'lganga o'xshaydi. Dastlab, u odatda qobiqda edi. Bu kontseptsiyaning ajoyib isboti edi, biz ba'zi shaxsiy muammolarimizni hal qildik - u ishladi! Ammo qobiq bilan bog'liq muammolar mavjud, uni yanada kengaytirish mumkin emas, qobiqda dasturlash boshqa vazifadir. Bizda Rubyda yozish odati bor edi, shunga ko‘ra Rubyda biz nimanidir qayta tikladik, ishlab chiqdik, rivojlantirdik, rivojlandik va shunday holatga duch keldikki, jamoa, “xohlaymizmi, xohlamaymiz” demaydigan olomon paydo bo‘ladi. Bu qanchalik kulgili bo'lmasin, uning burni Rubyda. Biz bularning barchasini nazorat ro'yxatidagi birinchi nuqtani qondirish uchun Go'da yozishimiz kerakligini tushundik: DevOps vositasi statik ikkilik bo'lishi kerak. Go-dan foydalanish yoki Go-dan foydalanmaslik unchalik muhim emas, lekin Go-da yozilgan statik ikkilik yaxshiroq.
Biz kuchimizni sarfladik, Go'da dappni qayta yozdik va uni werf deb nomladik. Dapp endi qo'llab-quvvatlanmaydi, ishlab chiqilmaydi, ba'zi so'nggi versiyalarda ishlaydi, lekin yuqoriga mutlaq yangilanish yo'li mavjud va siz unga amal qilishingiz mumkin.
Dapp nima uchun yaratilgan?
— Dapp nima uchun yaratilgani, qanday muammolarni hal qilishini qisqacha aytib bera olasizmi?
Dmitriy: Birinchi sabab - yig'ish. Dastlab, Docker ko'p bosqichli imkoniyatlarga ega bo'lmaganida, biz qurishda jiddiy muammolarga duch keldik va biz o'zimiz ko'p bosqichli qildik. Keyin tasvirni tozalash bilan bog'liq yana bir qancha muammolarga duch keldik. CI/CD bilan shug'ullanadigan har bir kishi, ertami-kechmi, to'plangan tasvirlar to'plami borligi muammosiga duch keladi, qandaydir tarzda keraksiz narsalarni tozalash va kerakli narsalarni qoldirish kerak.
Ikkinchi sabab - joylashtirish. Ha, Helm bor, lekin u faqat ba'zi muammolarni hal qiladi. Bu qanchalik kulgili bo'lmasin, "Helm - Kubernetes uchun paket menejeri" deb yozilgan. Aynan nima "the". Shuningdek, “Paket menejeri” soʻzlari ham bor – paket menejeridan odatda nima kutiladi? Biz deymiz: “Paket menejeri – paketni yetkazib bering!” va biz u bizga: "Paket yetkazildi" deb aytishini kutamiz.
Qizig'i shundaki, biz: "Rulm, paketni o'rnating" deymiz va u uni o'rnatgan deb javob berganida, u o'rnatishni endigina boshlagani ma'lum bo'ldi - u Kubernetesga: "Bu narsani ishga tushiring!" Degan va u boshlanganmi yoki yo'qmi. , u ishlaydimi yoki yo'qmi, Helm bu masalani umuman hal qilmaydi.
Ma'lum bo'lishicha, Helm shunchaki Kubernetes-ga ma'lumotlarni yuklaydigan matnli protsessordir.
Ammo har qanday joylashtirishning bir qismi sifatida biz dastur ishlab chiqarishga chiqarilganmi yoki yo'qligini bilishni xohlaymizmi? Roll out to prod degani, dastur u yerga ko'chirilgan, yangi versiya o'rnatilgan va hech bo'lmaganda u erda ishlamay qoladi va to'g'ri javob beradi. Helm bu muammoni hech qanday tarzda hal qilmaydi. Buni hal qilish uchun siz ko'p kuch sarflashingiz kerak, chunki siz Kubernetesga tarqatish va u erda nima sodir bo'layotganini - u joylashtirilganmi yoki chiqarilganmi - kuzatish buyrug'ini berishingiz kerak. Bundan tashqari, joylashtirish, tozalash va yig'ish bilan bog'liq bir qator vazifalar mavjud.
rejalari
Bu yil biz mahalliy rivojlanishga ham kirishamiz. Biz Vagrantda ilgari bo'lgan narsaga erishmoqchimiz - biz "vagrant up" ni yozdik va virtual mashinalarni joylashtirdik. Biz Git-da loyiha mavjud bo'lgan nuqtaga erishmoqchimiz, biz u erda "werf up" deb yozamiz va u ushbu loyihaning mahalliy mini-Kubda joylashtirilgan mahalliy nusxasini oladi va rivojlanish uchun qulay bo'lgan barcha kataloglar ulanadi. Rivojlanish tiliga qarab, bu boshqacha tarzda amalga oshiriladi, ammo shunga qaramay, o'rnatilgan fayllar ostida mahalliy ishlab chiqishni qulay tarzda amalga oshirishingiz mumkin.
Biz uchun keyingi qadam - bu dasturchilarga do'stona munosabatda bo'lishga investitsiya qiling. Loyihani bitta vosita bilan tezda mahalliy sifatida joylashtirish uchun uni ishlab chiqing, Git-ga suring va u quvurlarga qarab bosqichga yoki sinovlarga chiqariladi va keyin ishlab chiqarishga o'tish uchun xuddi shu vositadan foydalaning. Mahalliy muhitdan sotishgacha bo'lgan infratuzilmaning bu birligi, birlashishi, takrorlanishi biz uchun juda muhim nuqtadir. Ammo bu hali werfda mavjud emas - biz buni qilishni rejalashtirmoqdamiz.
Ammo dapp/werf yo'li har doim boshida Kubernetes bilan bir xil bo'lgan. Biz muammolarga duch keldik, ularni vaqtinchalik echimlar yordamida hal qildik - qobiqdan foydalanib, har qanday narsadan foydalanib, o'zimiz uchun ba'zi echimlarni topdik. Keyin ular qandaydir tarzda to'g'rilashga, umumlashtirishga va bu vaqtinchalik echimlarni ikkiliklarga birlashtirishga harakat qilishdi, biz ularni oddiygina baham ko'ramiz.
Bu hikoyani o'xshashliklar bilan ko'rishning yana bir usuli bor.
Kubernetes - bu dvigatelli avtomobil ramkasi. Eshiklar, oynalar, radiolar, Rojdestvo daraxti yo'q - hech narsa yo'q. Faqat ramka va dvigatel. Va u erda Helm - bu rul. Salqin - rul bor, lekin sizga rul, rul tokchasi, vites qutisi va g'ildiraklar ham kerak va siz ularsiz qilolmaysiz.
Werf holatida bu Kubernetesning yana bir komponentidir. Faqat hozir werf ning alfa versiyamizda, masalan, Helm werf ichida tuzilgan, chunki biz buni o'zimiz qilishdan charchadik. Buning uchun ko'p sabablar bor, men sizga nima uchun biz butun rulni werf ichidagi tiller bilan birga yig'ganimiz haqida batafsil aytib beraman. .
Endi werf yanada integratsiyalashgan komponent hisoblanadi. Biz tayyor rulni, rulni olamiz - men mashinalarda unchalik yaxshi emasman, lekin bu juda ko'p muammolarni hal qiladigan katta blok. Biz o'zimiz katalogni ko'rib chiqishimiz, boshqa qismdan birini tanlashimiz, ularni bir-biriga qanday qilib burama qilish haqida o'ylashimiz shart emas. Biz bir vaqtning o'zida ko'p sonli muammolarni hal qiladigan tayyor kombaynni olamiz. Ammo ichkarida u bir xil ochiq manba komponentlaridan tashkil topgan bo'lib, u hali ham yig'ish uchun Docker-dan, ba'zi funksiyalar uchun Helm-dan foydalanadi va bir nechta boshqa kutubxonalar mavjud. Bu salqin CI/CDni qutidan tez va qulay tarzda chiqarish uchun o'rnatilgan vositadir.
Kubernetesni saqlash qiyinmi?
- Siz Kubernetes-dan foydalanishni boshlagan tajribangiz haqida gapiryapsiz, bu siz uchun ramka, dvigatel va unga juda ko'p turli narsalarni biriktirishingiz mumkin: korpus, rul, pedallar vintlari, o'rindiqlar. Savol shundaki, Kubernetes qo'llab-quvvatlashi siz uchun qanchalik qiyin? Sizda katta tajriba bor, Kubernetesni hamma narsadan ajratilgan holda qo'llab-quvvatlashga qancha vaqt va resurslar sarflaysiz?
Dmitriy: Bu juda qiyin savol va javob berish uchun biz yordam nima ekanligini va Kubernetesdan nimani xohlayotganimizni tushunishimiz kerak. Ehtimol, siz buni oshkor qilasizmi?
— Men bilishimcha va ko'rib turganimdek, hozir ko'plab jamoalar Kubernetesni sinab ko'rmoqchi. Har kim unga o'zini jabduq qiladi, tizzasiga qo'yadi. Odamlar bu tizimning murakkabligini har doim ham tushuna olmasligini his qilyapman.
Dmitriy: Xuddi shunday.
— Kubernetes ishlab chiqarishga tayyor bo'lishi uchun uni yo'qdan olish va o'rnatish qanchalik qiyin?
Dmitriy: Sizningcha, yurakni transplantatsiya qilish qanchalik qiyin? Bu murosasiz savol ekanligini tushunaman. Skalpeldan foydalanish va xato qilmaslik unchalik qiyin emas. Agar ular qayerda kesish va qayerda tikish kerakligini aytishsa, unda protseduraning o'zi murakkab emas. Vaqt o'tishi bilan hamma narsa yaxshi bo'lishini kafolatlash qiyin.
Kubernetes-ni o'rnatish va uni ishga tushirish oson: chik! — O'rnatilgan, o'rnatish usullari juda ko'p. Muammolar yuzaga kelganda nima bo'ladi?
Har doim savollar tug'iladi: biz hali nimani hisobga olmadik? Biz hali nima qilmadik? Qaysi Linux yadrosi parametrlari noto'g'ri ko'rsatilgan? Rabbiy, biz ularni ko'rsatdikmi?! Biz qaysi Kubernetes komponentlarini yetkazib berdik va qaysi biri yo'q? Minglab savollar tug'iladi va ularga javob berish uchun bu sohada 15-20 yil vaqt sarflash kerak bo'ladi.
Menda ushbu mavzu bo'yicha yaqinda bir misol bor, u "Kubernetesni saqlash qiyinmi?" Degan muammoning ma'nosini ochib berishi mumkin. Bir muncha vaqt oldin biz Cilium-ni Kubernetes-da tarmoq sifatida joriy etishni jiddiy ko'rib chiqdik.
Cilium nima ekanligini tushuntirib beraman. Kubernetes-da tarmoq quyi tizimining turli xil ilovalari mavjud va ulardan biri Cilium. Uning ma'nosi nima? Yadroda bir muncha vaqt oldin yadro uchun kancalar yozish mumkin bo'ldi, ular qandaydir tarzda tarmoq quyi tizimi va boshqa turli quyi tizimlarni bosib oladi va yadrodagi katta qismlarni chetlab o'tishga imkon beradi.
Linux yadrosi tarixan IP-marshrut, ortiqcha filtr, ko'priklar va 15, 20, 30 yoshli turli xil eski komponentlarga ega. Umuman olganda, ular ishlaydi, hamma narsa zo'r, lekin hozir ular konteynerlarni yig'ishdi va u bir-birining ustiga 15 ta g'ishtdan iborat minoraga o'xshaydi va siz uning ustida bir oyoq ustida turasiz - g'alati tuyg'u. Ushbu tizim tarixan tanadagi appendiks kabi ko'plab nuanslar bilan rivojlangan. Ba'zi hollarda, masalan, ishlash bilan bog'liq muammolar mavjud.
Ajoyib BPF va yadro uchun ilgaklar yozish qobiliyati mavjud - bolalar yadro uchun o'zlarining ilgaklarini yozdilar. Paket Linux yadrosiga kiradi, ular uni kirish joyida olib tashlaydilar, uni ko'priklarsiz, TCPsiz, IP steksiz - qisqasi, Linux yadrosida yozilgan hamma narsani chetlab o'tib, o'zlari kerak bo'lganda qayta ishlaydilar va keyin tupuradilar. uni idishga soling.
Nima bo'ldi? Juda ajoyib ishlash, ajoyib xususiyatlar - shunchaki ajoyib! Ammo biz buni ko'rib chiqamiz va har bir mashinada Kubernetes API-ga ulanadigan dastur mavjudligini va ushbu API-dan olingan ma'lumotlarga asoslanib, C kodini ishlab chiqaradi va yadroga yuklaydigan ikkilik fayllarni kompilyatsiya qiladi, shunda bu ilgaklar ishlaydi. yadro bo'shlig'ida.
Agar biror narsa noto'g'ri bo'lsa nima bo'ladi? Biz bilmaymiz. Buni tushunish uchun siz ushbu kodning barchasini o'qib chiqishingiz, barcha mantiqni tushunishingiz kerak va bu qanchalik qiyinligi hayratlanarli. Ammo, boshqa tomondan, bu ko'priklar, tarmoq filtrlari, IP marshrutlari bor - men ularning manba kodlarini o'qimaganman va bizning kompaniyamizda ishlaydigan 40 muhandis ham bor. Ehtimol, faqat bir nechtasi ba'zi qismlarni tushunadi.
Va qanday farq bor? Ma'lum bo'lishicha, IP yo'nalishi, Linux yadrosi va yangi vosita bor - bu qanday farq qiladi, biz u yoki bu narsani tushunmayapmiz. Lekin biz yangi narsalarni ishlatishdan qo'rqamiz - nega? Chunki agar asbob 30 yoshda bo'lsa, unda 30 yil ichida barcha xatolar topildi, barcha xatolarga qadam qo'yildi va siz hamma narsani bilishingiz shart emas - u qora quti kabi ishlaydi va har doim ishlaydi. Qaysi diagnostik tornavidani qaysi joyga yopishtirish kerakligini, qaysi tcpdumpni qaysi vaqtda ishlashini hamma biladi. Har bir inson diagnostika yordam dasturlarini yaxshi biladi va ushbu komponentlar to'plami Linux yadrosida qanday ishlashini tushunadi - u qanday ishlashini emas, balki undan qanday foydalanishni tushunadi.
Va ajoyib salqin Cilium 30 yoshda emas, u hali etuk emas. Kubernetesda bir xil muammo bor, nusxa ko'chiring. Cilium ajoyib ishlaydi, Kubernetes ajoyib ishlaydi, lekin ishlab chiqarishda biror narsa noto'g'ri bo'lsa, siz tanqidiy vaziyatda nima noto'g'ri bo'lganini tezda tushuna olasizmi?
Kubernetesni saqlab qolish qiyinmi desak - yo'q, juda oson va ha, nihoyatda qiyin. Kubernetes o'z-o'zidan ajoyib ishlaydi, lekin milliardlab nuanslarga ega.
"Men omadli bo'laman" yondashuvi haqida
— Bu nuanslar paydo bo'lishi deyarli kafolatlangan kompaniyalar bormi? Aytaylik, Yandex to'satdan barcha xizmatlarni Kubernetesga o'tkazsa, u erda katta yuk bo'ladi.
Dmitriy: Yo'q, bu yuk haqida emas, balki eng oddiy narsalar haqida. Misol uchun, bizda Kubernetes bor, biz u erda dasturni joylashtirdik. Bu ishlayotganini qanday bilasiz? Ilovaning qulab tushmasligini tushunish uchun oddiygina tayyor vosita yo'q. Ogohlantirishlarni yuboradigan tayyor tizim yo'q, siz ushbu ogohlantirishlarni va har bir jadvalni sozlashingiz kerak. Va biz Kubernetes-ni yangilayapmiz.
Menda Ubuntu 16.04 bor. Bu eski versiya, deb aytishingiz mumkin, lekin biz hali ham uni ishlatamiz, chunki u LTS. Systemd mavjud, uning ogohlantirishi shundaki, u C-guruhlarini tozalamaydi. Kubernetes podlarni ishga tushiradi, C-guruhlarini yaratadi, keyin podlarni o'chiradi va qandaydir tarzda ma'lum bo'ldi - tafsilotlarni eslay olmayman, afsuski - tizimli bo'laklar qoladi. Bu vaqt o'tishi bilan har qanday mashina kuchli sekinlasha boshlaganiga olib keladi. Bu hatto yuqori yuklanish haqida ham savol emas. Agar doimiy podlar ishga tushirilsa, masalan, doimiy podkalarni ishlab chiqaradigan Cron Job mavjud bo'lsa, Ubuntu 16.04 bilan ishlaydigan mashina bir haftadan keyin sekinlasha boshlaydi. Bir guruh C-guruhlari yaratilganligi sababli doimiy ravishda yuqori yuk o'rtacha bo'ladi. Bu Ubuntu 16 va Kubernetes-ni oddiygina o'rnatgan har qanday odam duch keladigan muammo.
Aytaylik, u qandaydir tarzda systemd yoki boshqa narsani yangilaydi, lekin Linux yadrosida 4.16 ga qadar bu yanada qiziqarliroq - C-guruhlarini o'chirib tashlaganingizda, ular yadroda oqadi va aslida o'chirilmaydi. Shu sababli, ushbu mashinada bir oy ishlagandan so'ng, subserver tomonidan xotira bo'yicha statistikani ko'rish mumkin bo'lmaydi. Biz faylni chiqaramiz, uni dasturga aylantiramiz va bitta fayl 15 soniya davomida aylanadi, chunki yadro o'z ichidagi million C-guruhlarini hisoblash uchun juda ko'p vaqt ketadi, ular o'chirilganga o'xshaydi, lekin yo'q - ular oqmoqda. .
Hali ham u erda va u erda bunday mayda narsalar juda ko'p. Bu gigant kompaniyalar ba'zan juda og'ir yuklar ostida duch keladigan muammo emas - yo'q, bu kundalik narsalar masalasi. Odamlar bir necha oy shunday yashashlari mumkin - ular Kubernetes-ni o'rnatdilar, dasturni joylashtirdilar - bu ishlayotganga o'xshaydi. Ko'pchilik uchun bu normal holat. Ular hatto bir kun kelib ushbu ilova biron bir sababga ko'ra ishdan chiqishini bilishmaydi, ular ogohlantirish olishmaydi, lekin ular uchun bu odatiy hol. Ilgari biz virtual mashinalarda monitoringsiz yashar edik, endi biz Kubernetesga o'tdik, shuningdek, kuzatuvsiz ham - farq nima?
Savol shundaki, biz muz ustida yurganimizda, biz uni oldindan o'lchamagunimizcha, uning qalinligini hech qachon bilmaymiz. Ko'p odamlar yurishadi va tashvishlanmanglar, chunki ular ilgari yurishgan.
Mening fikrimcha, har qanday tizimni ishlatishning nuansi va murakkabligi muzning qalinligi bizning muammolarimizni hal qilish uchun etarli bo'lishini ta'minlashdir. Bu haqida.
IT sohasida, menimcha, "men omadli bo'laman" yondashuvlari juda ko'p. Ko'p odamlar omadli bo'ladi degan umidda dasturiy ta'minotni o'rnatadilar va dasturiy ta'minot kutubxonalaridan foydalanadilar. Umuman olganda, ko'p odamlar omadli. Shuning uchun ham ishlaydi.
- Mening pessimistik baholashimga ko'ra, shunday ko'rinadi: agar xavflar yuqori bo'lsa va dastur ishlashi kerak bo'lsa, u holda Flant-dan, ehtimol Red Hat-dan yordam kerak bo'ladi yoki sizga Kubernetesga tayyor bo'lgan o'z ichki guruhingiz kerak bo'ladi. uni tortib olish uchun.
Dmitriy: Ob'ektiv ravishda shunday. Kichkina jamoa uchun Kubernetes hikoyasiga mustaqil ravishda kirish bir qator xavflarni o'z ichiga oladi.
Bizga konteynerlar kerakmi?
— Kubernetlar Rossiyada qanchalik keng tarqalganligini ayta olasizmi?
Dmitriy: Menda bu ma'lumotlar yo'q va boshqa hech kimda borligiga ishonchim komil emas. Biz: "Kubernetes, Kubernetes" deymiz, ammo bu masalani ko'rib chiqishning yana bir usuli bor. Men konteynerlarning qanchalik keng tarqalganligini ham bilmayman, lekin Internetdagi hisobotlardan shuni bilamanki, konteynerlarning 70 foizi Kubernetes tomonidan boshqariladi. Bu butun dunyo bo'ylab juda katta namuna uchun ishonchli manba edi.
Keyin yana bir savol - bizga konteynerlar kerakmi? Mening shaxsiy hissiyotim va Flant kompaniyasining umumiy pozitsiyasi shundaki, Kubernetes de-fakto standartdir.
Kubernetesdan boshqa hech narsa bo'lmaydi.
Bu infratuzilmani boshqarish sohasidagi mutlaq o'yinni o'zgartiradi. Faqat mutlaq - bu, endi Ansible, Chef, virtual mashinalar, Terraform yo'q. Men eski kolxoz usullari haqida gapirmayapman. Kubernetes - bu eng yaxshi o'zgartiruvchi, va endi faqat shunday bo'ladi.
Buni anglash uchun kimgadir bir-ikki yil, boshqalarga esa bir necha o‘n yillar kerak bo‘lishi aniq. Kubernetes va yangi ko'rinishdan boshqa hech narsa bo'lmasligiga shubham yo'q: biz endi operatsion tizimga zarar etkazmaymiz, balki undan foydalanamiz. kod sifatida infratuzilma, faqat kod bilan emas, balki yml bilan - deklarativ tarzda tavsiflangan infratuzilma. Har doim shunday bo'lishini his qilaman.
— Ya'ni, hali Kubernetesga o'tmagan kompaniyalar unga albatta o'tadilar yoki unutishadi. Men sizni to'g'ri tushundimmi?
Dmitriy: Bu ham mutlaqo to'g'ri emas. Misol uchun, agar bizning vazifamiz DNS serverini ishga tushirish bo'lsa, u holda u FreeBSD 4.10 da ishga tushirilishi mumkin va u 20 yil davomida mukammal ishlashi mumkin. Shunchaki ishlang va hammasi shu. Ehtimol, 20 yil ichida biror narsani bir marta yangilash kerak bo'ladi. Agar biz ishga tushirgan formatdagi dasturiy ta'minot haqida gapiradigan bo'lsak va u aslida ko'p yillar davomida hech qanday yangilanishlarsiz, o'zgarishlarsiz ishlasa, unda, albatta, u erda Kubernetes bo'lmaydi. U erda kerak emas.
CI/CD bilan bog'liq hamma narsa - Uzluksiz yetkazib berish kerak bo'lgan joyda, versiyalarni yangilashingiz, faol o'zgartirishlar kiritishingiz kerak bo'lgan joyda, xatolarga bardoshlilikni yaratishingiz kerak bo'lgan joyda - faqat Kubernetes.
Mikroservislar haqida
- Bu erda menda ozgina dissonans bor. Kubernetes bilan ishlash uchun sizga tashqi yoki ichki yordam kerak - bu birinchi nuqta. Ikkinchidan, biz endigina rivojlanishni boshlayotganimizda, biz kichik startapmiz, bizda hali hech narsa yo'q, Kubernetes yoki umuman mikroservis arxitekturasini ishlab chiqish murakkab bo'lishi mumkin va har doim ham iqtisodiy jihatdan oqlanmaydi. Meni sizning fikringiz qiziqtiradi - startaplar darhol Kubernetes uchun noldan yozishni boshlashlari kerakmi yoki ular hali ham monolit yozib, keyin faqat Kubernetesga kelishlari mumkinmi?
Dmitriy: Ajoyib savol. Menda mikroservislar haqida hisobot bor Men odamlar mikroskop bilan mixlarni bolg'acha urishga harakat qilishlariga ko'p marta duch kelganman. Yondashuvning o'zi to'g'ri, biz ichki dasturiy ta'minotimizni shu tarzda ishlab chiqamiz. Ammo buni qilganingizda, nima qilayotganingizni aniq tushunishingiz kerak. Mikroservislar haqida men eng yomon ko'rgan narsa bu "mikro" so'zi. Tarixan, bu so'z kelib chiqqan va ba'zi sabablarga ko'ra, odamlar mikrometr kabi mikrometriya, millimetrdan kam deb o'ylashadi. Bu unday emas.
Misol uchun, 300 kishi yozgan monolit bor va ishlab chiqishda ishtirok etgan har bir kishi u erda muammolar borligini tushunadi va uni mikro qismlarga bo'lish kerak - taxminan 10 bo'lak, ularning har biri 30 kishi tomonidan yoziladi. minimal versiyada. Bu muhim, zarur va salqin. Ammo bizga startap kelganda, u yerda 3 ta juda zo'r va iqtidorli yigitlar tizzalariga 60 ta mikroservis yozgan, men har safar Corvalolni qidiraman.
Menimcha, bu haqda minglab marta aytilgan - ular u yoki bu shaklda taqsimlangan monolitga ega bo'lishdi. Bu iqtisodiy jihatdan asosli emas, umuman olganda, bu juda qiyin. Men buni juda ko'p marta ko'rganman, bu meni juda xafa qildi, shuning uchun men bu haqda gapirishda davom etaman.
Dastlabki savolga, bir tomondan, Kubernetesdan foydalanish qo'rqinchli ekanligi o'rtasida ziddiyat bor, chunki u erda nima sinishi yoki ishlamasligi noma'lum, boshqa tomondan, hamma narsa u erga borishi va Kubernetesdan boshqa hech narsa bo'lmaydi. Javob - keladigan foyda miqdorini, hal qila oladigan vazifalar miqdorini torting. Bu shkalaning bir tomonida. Boshqa tomondan, ishlamay qolish yoki javob vaqtining pasayishi, mavjudlik darajasi yoki ishlash ko'rsatkichlarining pasayishi bilan bog'liq xavflar mavjud.
Mana, biz tez harakat qilamiz va Kubernetes bizga ko'p narsalarni tezroq va yaxshiroq qilish imkonini beradi yoki biz ishonchli, vaqt sinovidan o'tgan echimlardan foydalanamiz, lekin ancha sekinroq harakat qilamiz. Bu har bir kompaniya tanlashi kerak. Siz buni o'rmondagi yo'l deb o'ylashingiz mumkin - birinchi marta yurganingizda siz ilon, yo'lbars yoki aqldan ozgan bo'rsiqni uchratishingiz mumkin va siz 10 marta yurganingizda, siz yo'lni bosib o'tgansiz, olib tashlangansiz. novdalar va yurish osonroq. Har safar yo'l kengayadi. Keyin asfalt yo'l, keyin esa chiroyli bulvar.
Kubernetes bir joyda turmaydi. Yana savol: Kubernetes, bir tomondan, 4-5 binar, boshqa tomondan, bu butun ekotizim. Bu bizning mashinalarimizda mavjud bo'lgan operatsion tizim. Nima bu? Ubuntu yoki Curios? Bu Linux yadrosi, qo'shimcha komponentlar to'plami. Bularning barchasi shu erda, bitta zaharli ilon yo'ldan uloqtirildi, u erda panjara o'rnatildi. Kubernetes juda tez va dinamik rivojlanmoqda va xatarlar hajmi, noma'lumlar hajmi har oy kamayadi va shunga mos ravishda bu tarozilar muvozanatlanadi.
Startap nima qilishi kerak degan savolga javob bergan bo'lardim - Flaunt-ga keling, 150 ming rubl to'lang va DevOps oson xizmatini kalit bilan oling. Agar siz bir nechta ishlab chiquvchilarga ega kichik startap bo'lsangiz, bu ishlaydi. Muammolaringizni hal qilishni va ayni paytda ish haqini to'lashni o'rganishi kerak bo'lgan o'z DevOps-laringizni yollash o'rniga, siz barcha masalalarga kalit taslim bo'lasiz. Ha, ba'zi kamchiliklari bor. Biz, autsorser sifatida, u qadar ishtirok eta olmaymiz va o'zgarishlarga tezda javob beramiz. Ammo bizda juda ko'p tajriba va tayyor amaliyotlar mavjud. Biz har qanday vaziyatda biz buni tezda aniqlab olishimizga va har qanday Kubernetlarni o'liklardan tiriltirishimizga kafolat beramiz.
Men startaplar va tashkil etilgan korxonalarga 10 kishilik jamoani operatsiyalarga bag'ishlashingiz mumkin bo'lgan hajmgacha autsorsingni tavsiya qilaman, chunki aks holda foyda yo'q. Buni autsorsing qilish, albatta, mantiqiy.
Amazon va Google haqida
— Amazon yoki Google yechimidagi xostni autsorsing sifatida ko'rib chiqish mumkinmi?
Dmitriy: Ha, albatta, bu bir qator muammolarni hal qiladi. Ammo yana nuances bor. Siz hali ham uni qanday ishlatishni tushunishingiz kerak. Misol uchun, Amazon AWS ishida minglab kichik narsalar mavjud: Yuk balanslagichini isitish kerak yoki “bolalar, bizda trafik paydo bo'lmoqda, biz uchun Load Balancerni qizdiring! ” Ushbu nuanslarni bilishingiz kerak.
Bu borada ixtisoslashgan odamlarga murojaat qilganingizda, siz deyarli barcha odatiy narsalarni yopib qo'yasiz. Hozirda bizda 40 nafar muhandis bor, yil oxiriga kelib ularning soni 60 nafarga yetishi mumkin - bularning barchasiga albatta duch kelganmiz. Agar biron bir loyihada bu muammoga yana duch kelsak ham, biz tezda bir-birimizdan so'raymiz va uni qanday hal qilishni bilamiz.
Ehtimol, javob, albatta, joylashtirilgan hikoya ba'zi qismlarni osonlashtiradi. Savol shundaki, siz ushbu hosterlarga ishonishga tayyormisiz va ular sizning muammolaringizni hal qiladimi. Amazon va Google yaxshi natijalarga erishdi. Bizning barcha holatlarimiz uchun - aniq. Bizda boshqa ijobiy tajribalar yo'q. Biz ishlashga harakat qilgan barcha boshqa bulutlar juda ko'p muammolarni keltirib chiqaradi - Ager va Rossiyadagi barcha narsalar va turli xil ilovalardagi OpenStack-ning barcha turlari: Headster, Overage - xohlaganingizcha. Ularning barchasi siz hal qilishni istamaydigan muammolarni keltirib chiqaradi.
Shuning uchun, javob ha, lekin aslida, juda ko'p etuk hosted echimlar mavjud emas.
Kubernetes kimga kerak?
- Kubernetes kimga kerak? Kubernetes uchun maxsus kelgan Flaunt mijozi bo'lgan Kubernetes-ga kim allaqachon o'tishi kerak?
Dmitriy: Bu qiziq savol, chunki hozir, Kubernetes to'lqinida bizga ko'p odamlar kelishadi: "Bolalar, biz bilamizki, siz Kubernetes qilyapsiz, buni biz uchun qiling!" Biz ularga javob beramiz: "Janoblar, biz Kubernetes qilmaymiz, biz ishlab chiqaramiz va u bilan bog'liq hamma narsani qilamiz." Chunki barcha CI/CD va butun voqeani qilmasdan mahsulot ishlab chiqarish mumkin emas. Har bir inson bizda rivojlanish yo'li bilan rivojlanish, keyin esa ekspluatatsiya yo'li bilan ekspluatatsiya qilish degan bo'linishdan uzoqlashdi.
Bizning mijozlarimiz har xil narsalarni kutishadi, lekin hamma yaxshi mo''jizani kutmoqda, ularda ma'lum muammolar bor, va hozir - hop! - Kubernetes ularni hal qiladi. Odamlar mo''jizalarga ishonishadi. Ularning ongida ular mo''jiza bo'lmasligini tushunishadi, lekin qalblarida ular bu Kubernetes biz uchun hamma narsani hal qilishiga umid qilishadi, ular bu haqda juda ko'p gapirishadi! Birdan u aksiradi! - va kumush o'q, aksirish! — va bizda 100% ish vaqti bor, barcha ishlab chiquvchilar ishlab chiqarishga kirishganlarini 50 marta chiqarishlari mumkin va u buzilmaydi. Umuman olganda, mo''jiza!
Bunday odamlar bizga kelganda, biz: "Kechirasiz, lekin mo''jizalar sodir bo'lmaydi" deymiz. Sog'lom bo'lish uchun to'g'ri ovqatlanish va mashq qilish kerak. Ishonchli mahsulotga ega bo'lish uchun uni ishonchli qilish kerak. Qulay CI/CDga ega bo'lish uchun uni shunday qilish kerak. Bu juda ko'p ish qilish kerak.
Kubernetes kimga kerak degan savolga javob berish uchun Kubernetes hech kimga kerak emas.
Ba'zi odamlar Kubernetes kerak degan noto'g'ri tushunchaga ega. Odamlarga kerak, ular o'ylashni, o'rganishni, infratuzilmaning barcha muammolari va ularning ilovalarini ishga tushirish muammolari bilan qiziqishni to'xtatishga chuqur ehtiyoj sezadilar. Ular ilovalarning shunchaki ishlashini va oddiygina joylashtirilishini xohlashadi. Ular uchun Kubernetes "biz u erda yotgan edik" yoki "biz chiqa olmaymiz" yoki boshqa gaplarni eshitishni to'xtatadi degan umiddir.
Texnik direktor odatda bizga keladi. Ular undan ikkita narsani so'rashadi: bir tomondan, bizga xususiyatlarni bering, boshqa tomondan, barqarorlik. Biz buni o'z zimmamizga olishni va buni qilishni taklif qilamiz. Kumush o'q, to'g'rirog'i kumush bilan qoplangan, bu muammolar haqida o'ylashni va vaqtni behuda sarflashni to'xtatasiz. Sizda bu masalani yopadigan maxsus odamlar bo'ladi.
Bizga yoki boshqa birovga Kubernetes kerak degan so'zlar noto'g'ri.
Administratorlarga haqiqatan ham Kubernetes kerak, chunki bu juda qiziqarli o'yinchoq, siz u bilan o'ynashingiz va o'ynashingiz mumkin. Rostini aytaylik — hamma oʻyinchoqlarni yaxshi koʻradi. Biz hammamiz qayerdadir bolamiz va yangisini ko'rganimizda, u bilan o'ynashni xohlaymiz. Ba'zi odamlar buni rad etishdi, masalan, ma'muriyatda, chunki ular allaqachon etarlicha o'ynagan va allaqachon charchagan, ular shunchaki xohlamaydilar. Ammo bu hech kimga to'liq yo'qolgan emas. Misol uchun, agar men uzoq vaqt davomida tizim boshqaruvi va DevOps sohasidagi o'yinchoqlardan charchagan bo'lsam, men hali ham o'yinchoqlarni yaxshi ko'raman va hali ham yangilarini sotib olaman. Hamma odamlar, qandaydir tarzda, hali ham qandaydir o'yinchoqlarni xohlashadi.
Ishlab chiqarish bilan o'ynashning hojati yo'q. Men nima qilishni qat'iyan tavsiya etmayman va hozir ko'rayotgan narsam: "Oh, yangi o'yinchoq!" - ular uni sotib olish uchun yugurishdi, sotib olishdi va: "Keling, uni hozir maktabga olib boramiz va barcha do'stlarimizga ko'rsatamiz." Buni qilmang. Kechirasiz, farzandlarim endigina ulg‘ayishyapti, men doimo bolalarda nimanidir ko‘raman, o‘zimda sezaman, keyin boshqalarga umumlashtiraman.
Yakuniy javob: sizga Kubernetes kerak emas. Muammolaringizni hal qilishingiz kerak.
Siz nimaga erishishingiz mumkin:
- mahsulot tushmaydi;
- u yiqilib tushmoqchi bo'lsa ham, biz bu haqda oldindan bilamiz va biror narsa qo'yishimiz mumkin;
- Biz uni biznesimiz talab qiladigan tezlikda o'zgartirishimiz mumkin va biz buni qulay qilishimiz mumkin; bu bizga hech qanday muammo tug'dirmaydi.
Ikkita haqiqiy ehtiyoj bor: ishonchlilik va dinamik/moslashuvchan ishlab chiqarish. Hozirda qandaydir IT-loyihalar bilan shug‘ullanayotgan har bir kishi, qaysi biznesda bo‘lishidan qat’iy nazar – dunyoni yengillashtirish uchun yumshoq va buni tushunadigan har bir kishi bu ehtiyojlarni hal qilishi kerak. Kubernetes to'g'ri yondashuv, to'g'ri tushunish va etarli tajriba bilan ularni hal qilishga imkon beradi.
Serversiz haqida
— Agar siz kelajakka biroz uzoqroq nazar tashlasangiz, u holda infratuzilma bilan bosh og'rig'i yo'qligi muammosini hal qilish uchun harakat qilish tezligi va ilovalarni o'zgartirish tezligi bilan yangi echimlar paydo bo'ladi, masalan, serversiz. Siz ushbu yo'nalishda biron bir potentsialni his qilyapsizmi va aytaylik, Kubernetes va shunga o'xshash echimlar uchun xavf bormi?
Dmitriy: Shu oʻrinda yana bir taʼkidlab oʻtishimiz kerakki, men oldinga qarab, “Shunday boʻladi!” degan koʻruvchi emasman. Garchi men xuddi shu narsani qilgan bo'lsam ham. Men oyoqlarimga qarayman va u erda bir qancha muammolarni ko'raman, masalan, tranzistorlar kompyuterda qanday ishlaydi. Bu kulgili, to'g'rimi? Biz protsessorda ba'zi xatolarga duch kelyapmiz.
Barcha ekotizim muammolarini hal qilib, serversizni ancha ishonchli, arzon, samarali va qulay qiling. Bu erda men Ilon Maskning insoniyatga chidamlilikni yaratish uchun ikkinchi sayyora kerakligi haqidagi fikriga qo'shilaman. Garchi u nima deyayotganini bilmasam ham, o'zim Marsga uchishga tayyor emasligimni va ertaga bu sodir bo'lmasligini tushunaman.
Serversiz holda, bu mafkuraviy jihatdan to'g'ri bo'lgan narsa, masalan, insoniyat uchun xatolarga chidamlilik - ikkita sayyoraga ega bo'lish bittadan yaxshiroqdir. Lekin buni hozir qanday qilishimiz mumkin? Agar siz o'z kuchingizni unga jamlasangiz, bitta ekspeditsiya yuborish muammo emas. Bir necha ekspeditsiya jo‘natib, bir necha ming kishini u yerga joylashtirish ham, menimcha, real. Ammo insoniyatning yarmi u erda yashashi uchun uni to'liq xatolarga bardoshli qilish, menimcha, endi imkonsizdek tuyuladi.
Serversiz birma-bir: narsa ajoyib, ammo bu 2019 yilgi muammolardan yiroq. 2030 yilga yaqinroq - keling, buni ko'rish uchun yashaylik. Biz yashashimizga shubham yo'q, biz albatta yashaymiz (yotishdan oldin takrorlang), lekin endi biz boshqa muammolarni hal qilishimiz kerak. Bu xuddi ertakdagi Kamalak ponisiga ishongandek. Ha, ishlarning bir necha foizi hal qilinadi va ular mukammal tarzda hal qilinadi, lekin sub'ektiv ravishda serversiz kamalakdir ... Men uchun bu mavzu juda uzoq va tushunarsiz. Men gapirishga tayyor emasman. 2019 yilda serversiz bitta dastur yoza olmaysiz.
Kubernetes qanday rivojlanadi
— Biz bu potentsial ajoyib uzoq kelajak sari harakatlanar ekanmiz, sizningcha, Kubernetes va uning atrofidagi ekotizim qanday rivojlanadi?
Dmitriy: Men bu haqda ko'p o'yladim va aniq javob oldim. Birinchisi, davlat to'g'risidagi ma'lumotlar - axir, fuqaroligi bo'lmagan holda qilish osonroq. Kubernetes dastlab bunga ko'proq sarmoya kiritdi, hammasi shundan boshlandi. Fuqaroliksizlar Kubernetesda deyarli mukammal ishlaydi, shikoyat qiladigan hech narsa yo'q. Statefullning so'zlariga ko'ra, hali ko'p muammolar, aniqrog'i, nuanslar mavjud. U erda hamma narsa biz uchun juda yaxshi ishlaydi, lekin bu biz. Bu hamma uchun ishlashi uchun kamida yana bir necha yil kerak bo'ladi. Bu hisoblangan ko'rsatkich emas, balki mening boshimdagi tuyg'u.
Bir so'z bilan aytganda, davlat to'g'risidagi ma'lumotlar juda kuchli rivojlanishi kerak va rivojlanadi, chunki bizning barcha ilovalarimiz holatini saqlaydi; fuqaroligi bo'lmagan ilovalar mavjud emas. Bu illyuziya; sizga har doim ma'lumotlar bazasi va boshqa narsa kerak. Statefull - bu mumkin bo'lgan hamma narsani tuzatish, barcha xatolarni tuzatish, odamlar duch kelayotgan barcha muammolarni yaxshilash - keling, buni qabul qilish deb ataymiz.
Noma'lumlik darajasi, hal qilinmagan muammolar darajasi, biror narsaga duch kelish ehtimoli darajasi sezilarli darajada pasayadi. Bu muhim hikoya. Operatorlar esa - boshqaruv mantig'ining kodifikatsiyasi bilan bog'liq bo'lgan hamma narsa, oson xizmatni olish uchun boshqarish mantig'i: MySQL oson xizmati, RabbitMQ oson xizmati, Memcache oson xizmati - umuman olganda, biz ishlashimiz kafolatlanishi kerak bo'lgan barcha komponentlar. quti. Bu shunchaki biz ma'lumotlar bazasini xohlayotgan og'riqni hal qiladi, lekin uni boshqarishni xohlamaydi yoki Kubernetesni xohlamaydi, lekin uni boshqarishni xohlamaydi.
Operatorning u yoki bu shaklda rivojlanishi haqidagi ushbu hikoya keyingi bir necha yil ichida muhim bo'ladi.
O'ylaymanki, foydalanish qulayligi sezilarli darajada oshishi kerak - quti tobora qora rangga aylanadi, tobora ishonchli bo'ladi, oddiy tugmachalar ko'payadi.
Men bir marta YouTube-da Saturday Night Live shousida 80-yillardagi Isaak Asimov bilan eski intervyuni tingladim - Urgant kabi dastur, faqat qiziqarli. Ular undan kompyuterlarning kelajagi haqida so'rashdi. Uning so'zlariga ko'ra, kelajak xuddi radioda bo'lgani kabi soddalikda. Radio qabul qilgich dastlab murakkab narsa edi. To'lqinni ushlash uchun siz tugmachalarni 15 daqiqaga burishingiz, shishlarni aylantirishingiz va umuman hamma narsa qanday ishlashini bilishingiz, radio to'lqinlarini uzatish fizikasini tushunishingiz kerak edi. Natijada, radioda faqat bitta tugmacha qoldi.
Hozir 2019-yilda qaysi radio bor? Mashinada radio qabul qiluvchi barcha to'lqinlarni va stantsiyalarning nomlarini topadi. Jarayonning fizikasi 100 yil ichida o'zgarmadi, lekin foydalanish qulayligi bor. Hozir va nafaqat hozir, 1980 yilda, Azimov bilan suhbat bo'lganida, hamma radiodan foydalangan va uning qanday ishlashi haqida hech kim o'ylamagan. U doim ishlagan — bu berilgan.
Keyin Asimov kompyuterlar bilan ham shunday bo'lishini aytdi. foydalanish qulayligi ortadi. Agar 1980 yilda kompyuterda tugmachalarni bosish uchun maxsus ta'lim olish kerak bo'lsa, kelajakda bunday bo'lmaydi.
Men Kubernetes va infratuzilma bilan foydalanish qulayligida ham katta o'sish bo'lishini his qilyapman. Bu, mening fikrimcha, aniq - bu sirtda yotadi.
Muhandislar bilan nima qilish kerak?
— Kubernetesni qo'llab-quvvatlovchi muhandislar va tizim ma'murlari bilan nima bo'ladi?
Dmitriy: 1C paydo bo'lganidan keyin buxgalterga nima bo'ldi? Taxminan bir xil. Bundan oldin ular qog'ozda hisoblashgan - endi dasturda. Mehnat unumdorligi kattalik bilan ortdi, lekin mehnatning o'zi yo'qolmadi. Agar ilgari lampochkani vidalash uchun 10 ta muhandis kerak bo'lsa, endi bittasi etarli bo'ladi.
Menimcha, dasturiy ta'minot miqdori va vazifalar soni yangi DevOps paydo bo'lishidan va samaradorlikdan ko'ra tezroq o'sib bormoqda. Endi bozorda o'ziga xos tanqislik mavjud va u uzoq vaqt davom etadi. Keyinchalik, hamma narsa ma'lum bir me'yorga qaytadi, bunda ish samaradorligi oshadi, ko'proq serversiz bo'ladi, Kubernetesga neyron biriktiriladi, u barcha resurslarni kerakli darajada tanlaydi va umuman olganda hamma narsani o'zi qiling, kerak bo'lganda - odam uzoqlashadi va aralashmaydi.
Ammo kimdir qaror qabul qilishi kerak. Bu odamning malakasi va ixtisosligi darajasi yuqoriroq ekanligi aniq. Hozirgi kunda buxgalteriya bo'limida qo'llari charchamasligi uchun kitoblarni yuritadigan 10 nafar xodim kerak emas. Bu shunchaki kerak emas. Ko'pgina hujjatlar elektron hujjat aylanishi tizimi tomonidan avtomatik ravishda skanerlanadi va tan olinadi. Bitta aqlli bosh buxgalter yetarli, u allaqachon ancha yuqori ko'nikmalarga ega va yaxshi tushungan.
Umuman olganda, barcha sohalarda shunday. Avtomobillar bilan ham xuddi shunday: ilgari mashina mexanik va uchta haydovchi bilan kelgan. Hozirgi kunda mashina haydash hammamiz har kuni qatnashadigan oddiy jarayondir. Hech kim mashinani murakkab narsa deb o'ylamaydi.
DevOps yoki tizim muhandisligi yo'qolmaydi - yuqori darajadagi va samarali ish ortadi.
— Ish haqiqatan ham ortadi, degan qiziqarli fikrni ham eshitdim.
Dmitriy: Albatta, yuz foiz! Chunki biz yozayotgan dasturiy ta'minot miqdori doimiy ravishda o'sib bormoqda. Biz dasturiy ta'minot yordamida hal qiladigan muammolar soni doimiy ravishda o'sib bormoqda. Ish hajmi ortib bormoqda. Endi DevOps bozori juda qizib ketgan. Buni ish haqi boʻyicha taxminlarda koʻrish mumkin. Yaxshi ma'noda, tafsilotlarga kirmasdan, X ni xohlaydigan o'smirlar, 1,5X ni xohlaydigan o'rta va 2X ni xohlaydigan kattalar bo'lishi kerak. Va endi, agar siz Moskva DevOps ish haqi bozoriga qarasangiz, kichik o'quvchi X dan 3X gacha, katta yoshli esa X dan 3X gacha istaydi.
Bu qancha turadi, hech kim bilmaydi. Ish haqi darajasi sizning ishonchingiz bilan o'lchanadi - to'liq jinnixona, rostini aytsam, juda qizib ketgan bozor.
Albatta, bu vaziyat juda tez orada o'zgaradi - biroz to'yinganlik bo'lishi kerak. Dasturiy ta'minotni ishlab chiqish bilan bir xil emas - hamma ishlab chiquvchilarga muhtoj va hamma yaxshi ishlab chiquvchilarga muhtoj bo'lishiga qaramay, bozor kimning nimaga loyiqligini tushunadi - sanoat o'rnini bosdi. Hozir DevOps bilan bunday emas.
— Eshitishimga ko‘ra, hozirgi tizim administratori ortiqcha tashvishlanmasa kerak, degan xulosaga keldim, lekin malakasini oshirish va ertaga ish ko‘p bo‘lishiga, lekin u yuqori malakali bo‘lishiga tayyorgarlik ko‘rish vaqti keldi.
Dmitriy: Yuz foiz. Umuman olganda, biz 2019 yilda yashayapmiz va hayot qoidasi quyidagicha: umr bo'yi o'rganish - biz butun hayotimiz davomida o'rganamiz. Menimcha, endi hamma buni allaqachon biladi va his qiladi, lekin bilishning o'zi etarli emas - buni qilish kerak. Har kuni oʻzgarishimiz kerak. Agar biz buni qilmasak, ertami-kechmi biz kasbning chetiga tushib qolamiz.
180 graduslik keskin burilishlarga tayyor bo'ling. Men biror narsaning tubdan o'zgarishi yoki yangi narsa ixtiro qilinishi ehtimolini istisno qilmayman - bu sodir bo'ladi. Hop! - va biz endi boshqacha harakat qilamiz. Bunga tayyor bo'lish va tashvishlanmaslik kerak. Ertaga men qiladigan hamma narsa keraksiz bo'lib chiqishi mumkin - hech narsa, men butun umrimni o'rgandim va boshqa narsani o'rganishga tayyorman. Bu muammo emas. Ish xavfsizligidan qo'rqmasligingiz kerak, lekin doimo yangi narsalarni o'rganishga tayyor bo'lishingiz kerak.
Istaklar va bir daqiqa reklama
— Biror tilagingiz bormi?
Dmitriy: Ha, bir nechta tilaklarim bor.
Birinchi va eng savdogar - obuna bo'ling . Hurmatli o'quvchilar, YouTube ga kiring va kanalimizga obuna bo'ling. Taxminan bir oy ichida biz videoxizmatni faol ravishda kengaytirishni boshlaymiz. Bizda Kubernetes haqida ochiq va har xil boʻlgan koʻplab taʼlim mazmuni boʻladi: amaliy narsalardan tortib to laboratoriyalargacha, chuqur fundamental nazariy narsalar va Kubernetes-dan foydalanish boʻyicha. tamoyillar va naqshlar darajasi.
Ikkinchi savdo istagi - borish va yulduzlarni qo'ying, chunki biz ular bilan oziqlanamiz. Agar bizga yulduz bermasangiz, bizda yeydigan hech narsa bo'lmaydi. Bu kompyuter o'yinidagi mana kabi. Biz biror narsa qilamiz, biror narsa qilamiz, harakat qilamiz, kimdir bu dahshatli velosipedlar, kimdir hamma narsa noto'g'ri ekanligini aytadi, lekin biz davom etamiz va mutlaqo halol harakat qilamiz. Biz muammoni ko'ramiz, uni hal qilamiz va tajribamiz bilan o'rtoqlashamiz. Shuning uchun, bizga yulduz bering, bu sizga qimmatga tushmaydi, lekin bu bizga foyda keltiradi, chunki biz ular bilan oziqlanamiz.
Uchinchi, muhim va endi tijorat bo'lmagan istak ertaklarga ishonishni bas qiling. Siz professionallarsiz. DevOps - bu juda jiddiy va mas'uliyatli kasb. Ish joyingizda o'ynashni to'xtating. Siz uchun bosing va siz buni tushunasiz. Tasavvur qiling-a, siz kasalxonaga keldingiz va u erda shifokor siz bilan tajriba o'tkazmoqda. Bu kimgadir haqoratli bo'lishi mumkinligini tushunaman, lekin bu siz haqingizda emas, balki boshqa birov haqida. Boshqalarga ham to'xtashlarini ayting. Bu haqiqatan ham barchamiz uchun hayotni buzadi - ko'pchilik operatsiyalarni, administratorlarni va DevOpsni yana nimanidir buzgan do'stlar sifatida ko'rishni boshlaydi. Bu ko'pincha biz o'ynash uchun borganimiz va bu erda va bu erda nima borligiga sovuq ong bilan qaramaganimiz sababli "buzilgan".
Bu siz tajriba o'tkazmasligingiz kerak degani emas. Biz tajriba o'tkazishimiz kerak, buni o'zimiz qilamiz. Rostini aytsam, biz o'zimiz ham ba'zan o'ynaymiz - bu, albatta, juda yomon, lekin biz uchun hech qanday insoniy narsa begona emas. Keling, 2019 yilni ishlab chiqarishdagi o'yinlar emas, balki jiddiy, puxta o'ylangan tajribalar yili deb e'lon qilaylik. Balki shundaydir.
- Katta rahmat!
Dmitriy: Vitaliy, vaqt ajratganingiz uchun ham, suhbat uchun ham rahmat. Hurmatli o'quvchilar, agar siz to'satdan shu darajaga etgan bo'lsangiz, sizga katta rahmat. Umid qilamanki, biz sizga kamida bir nechta fikrlarni keltirdik.
Intervyuda Dmitriy werf masalasiga to'xtalib o'tdi. Endi bu deyarli barcha muammolarni hal qiladigan universal Shveytsariya pichog'i. Lekin har doim ham shunday emas edi. Yoniq festivalda Dmitriy Stolyarov ushbu vosita haqida batafsil gapirib beradi. Hisobotda Hamma narsa bo'ladi: Kubernetesning muammolari va yashirin nuanslari, ushbu qiyinchiliklarni hal qilish variantlari va werfning joriy tatbiq etilishi. 27 va 28 may kunlari bizga qo'shiling, biz mukammal vositalarni yaratamiz.
Manba: www.habr.com