Pragmatizm va Kubernetes

Kasal tahrir qilish qobiliyatlarimni biroz oldindan ko'rib chiqish

Men bu sarlavha haqida bir oz o'yladim - bu haqiqatan ham "Pragmatizm va Kubernetes" bo'lishi kerak, chunki ba'zi hollarda ikkalasi bir-biriga zid. Ammo men buning yanada qiziqarli va g'azablantiradigan bo'lishini bildim (CLICKBAIT deyishning yaxshi usuli). Xo'sh, bu bola kim va u Kubernetesga qarshi nima qildi? O'ylaymanki, qandaydir tushuntirishlarim bor.

Endi men ushbu maqolani yozmasdan oldin, kimdir shunga o'xshash biror narsa yozganligini bilish uchun tezkor qidiruv o'tkazdim. Ushbu maqola yaqinlashdi va kerakli savollarni berdi, lekin men aytmoqchi bo'lgan narsani aniqlaydigan biron bir topolmadim.

Qidiruv davomida men Kubernetes tomonidan hal qilinayotgan soha odamlari ko'rayotgan ba'zi mashhur muammolarni ham ko'rdim. Men ularni buzish va muhokama qilish maqola uchun yaxshi format bo'lishi mumkin deb o'yladim.

Avval biroz ozgina kontekst, shunchaki bilasizki, men biron bir masalada xiyonat qilmayman va mening fikrlarimning ortida hech bo'lmaganda biron bir fazilat bor. Men turli xil infratuzilma naqshlari bo'yicha bulutda tarqatish quvurlari / dasturlarni va bulutda ishlaydigan dasturlarni (asosan AWS nuqtai nazaridan gapirib beraman) qurganimni aytaman. AMI qo'llaniladigan EC2s, EC2, ECS, Nomad, Kubernetes, EC2'lar qo'g'irchoq tomonidan sozlangan va men unutishni istagan narsalar; Ansible tomonidan o'rnatilgan, sozlangan va boshqariladigan EC2s (qorong'u kunlar).

Ammo bunga etarlicha kirishga harakat qilamiz, shunday emasmi?

Tezlik

Tezlik, ko'p jihatdan texnologik kompaniyalardagi o'zgarishlarning eng katta drayverlaridan biri, ayniqsa hozir hamma Agile Kool Aid-dan ichganligi sababli. Qisqa geribildirim ko'chadan uchun biz tezkor tarqatish kerak, bizning vaqt ichida, tez ishlash uchun ilovalar, bu qo'shimcha kam sonlarni tiklash uchun, ro'yxat davom etmoqda.

Kubernetes stolga tezlikni keltiradigan bir necha usullar mavjud. Ilovalar podkastlar orqali klasterga joylashtirilgan. Bular asosan o'lchovli, mahalliy tarmoqqa ulangan va bitta IP manzil va portni ulashadigan idishlar to'plamidir. Agar siz ularni ilgari ishlatgan bo'lsangiz, ularni docker kompozitsion joylashuvi deb hisoblashingiz mumkin. Bularning barchasi konteynerlarga tushayotganini ko'rib, ilova va uning muhiti doker tasvirlariga joylashtirilgan. Juda tez yuklash vaqtlarini anglatadi (siz dasturni qanday boshlashingizni qarab). Bu shuni anglatadiki, siz ilovangizning yangi versiyasini o'rnatganingizda, sizning joylashuvingiz (kamida) quyidagi vaqtni oladi:

  • Doker rasmingizni yarating
  • Docker rasmingizni docker reestriga yuklang
  • Sizning konteyneringizni ishga tushirish uchun qaysi tugunni aniqlang
  • Idishni boshlang

Albatta, ushbu joylashtirishni optimallashtirishning ko'plab usullari mavjud (bu sizning klasteringizda etarlicha manbalar mavjudligini va gorizontal miqyosda o'lchashni kutishning hojati yo'q degan ma'noni anglatadi), ammo ideal holda bu sizning ilovangizni joylashtirishning eng tezkor usuli bo'ladi. Tabiiyki, bu qurilish vaqtni o'lchash kabi boshqa jihatlarda ham tezlikni oshirishga imkon beradi. Ilovangizning yangi namunalarini ortiqcha yuklarni ko'tarish uchun faqat oxirgi 2 bosqichni bajarish kerak (kerak bo'lganda klasterni ko'paytirish vaqti). Oddiy yuklash skriptiga ega bo'lgan minimal o'lchamdagi doker tasviri chaqmoqning tezkor joylashishiga olib keladi.

Buni aytib, bir nechta fikrlarni ko'rib chiqing:

Birinchidan, bu xususiyatlar Kubernetes-ning o'ziga xos xususiyati emas - ular har qanday konteynerga oid ilovalarning xususiyatlari. Bundan tashqari, Kubernetes oddiy tizim emas. Klaster ishlashda e'tiborga olinadigan juda ko'p turli xil jihatlar mavjud (biz keyinroq muhokama qilamiz). Demak, tezlik sizning maqsadingiz bo'lsa, bunga sodda echimlar bilan erishish mumkin. Masalan, ECS-ni virtual mashinalardan konteynerlarga oson ishlaydigan dasturlarni ishlab chiquvchilar va uni ishlaydigan va qo'llab-quvvatlaydigan muhandislar uchun oling (bu sizning hozirgi sozlashingizga bog'liq). Shuni yodda tutish kerakki, bunday texnologiyani qo'llash nafaqat sizning infratuzilma muhandislaringiz platformani boshqarishni o'rganishlari kerak. Devlar o'zlarining kodlari mahalliy sharoitda qanday ishlashini ko'rishni istasalar, qanday qilib kubectl, helm va minikube kabi narsalarni o'rganishlari kerak. Bularning barchasi vaqt talab etadi (va tezlikni pasaytiradi)

Ikkinchidan (va, ehtimol, eng muhimi), joylashtirishni tezlashtirish qanday qilib biznesga yordam beradi? Kun oxirida bizning barchamizga korxonalarimizga foyda keltirishi uchun pul to'laydilar - sizning va jamoangizning vaqtidan eng zo'r foydalanishingiz vaqtni tejashga sarflaydimi? Ba'zi bir tashkilotlarda mutlaqo, lekin siz ko'pchilik tashkilotlarda bu qiyin ahvolga tushmagan joyni topishingiz mumkin. Dasturiy ta'minotni soddalashtirilgan hayotiy tsiklini (SDLC) ko'rib chiqaylik.

  • Birinchidan, hal qilinishi kerak bo'lgan muammoni aniqlash kerak.
  • Keyin, vazifa ustuvor bo'lishi va ishlab chiquvchilarga topshirilishi kerak.
  • Keyin Devs echimni loyihalashtiradi va ishlab chiqadi.
  • Sinov va tasdiqlash (agar kerak bo'lsa) taklif qilingan echimda amalga oshiriladi.
  • Qaror joylashtirilgan va tasdiqlangan.

Va tsikl davom etmoqda.

Agar tezlik sizning maqsadingiz bo'lsa, biz nima qilishimiz kerakligi aniq - SDLC-dagi yukni toping va uni tezlang. Agar siz joylashish vaqtini 5 daqiqaga tezlashtirsangiz, lekin sinovlarni o'tkazish yoki tasdiqlash uchun bir necha kun kerak bo'ladi, shunda siz sinovdan o'tishga / tasdiqlashga tayyor bo'lgan bir qancha joylarni egallab olasiz. Ehtimol siz ushbu turdagi tushunchalarni tarmoq, ma'lumotlar bazasi / ilova ishlashi va hokazolarda ko'rgansiz, shuning uchun kompaniyangizdagi muammolar qaerda joylashganligini aniqlash juda oson bo'lishi kerak.

Men sizni ogohlantirdim

Yomon rahbarlarni boshdan kechirganliklari sababli yuqori rahbariyat relizlarga bo'lgan ishonchni yo'qotdimi? Keyin, ehtimol siz yaxshiroq, avtomatlashtirilgan sinov va monitoringni amalga oshirishingiz kerak.

Mahsulot menejerlari qanday muammolarni hal qilish kerakligini hal qilish juda uzoq vaqt talab qiladimi? Yoki amalga oshirilgan echim ishlayotganligini tasdiqlash uchunmi? Keyin, ehtimol, ushbu qarorlarni qabul qilish uchun tegishli ma'lumotlarni to'plash ustida ishlashingiz kerak.

Yechim nima uchun u siz o'ylagandek ishlamayotganini aniqlash uchun juda ko'p vaqt ketadi? Ehtimol, infratuzilma / ilovalaringizning mavjudligini oshirish ustida ishlashingiz kerak.

Tezlashtirilishi mumkin bo'lgan narsalar juda ko'p, ammo siz buning mohiyatini tushunasiz.

Yagona ish oqimlari

Bu Kubernetes haqida gapirganda ko'p esga olinadigan ko'rinadi. Bu ishlab chiquvchilar bilan o'zaro munosabatda bo'lish va oxir-oqibat ularning kodlarini ishlatish usullari jihatidan juda ko'p qonunlarni qo'llaydi. Buning eng katta usullaridan biri bu ular uchun ochadigan API orqali. Kubectl klaster uchun interfeys vazifasini bajaradi, ishlab chiquvchilarning kirishini nazorat qiladi va ularga klasterda ishlayotgan narsalarni tekshirish, sirlarni ochish va yaratish va eng asosiysi o'zlarining ilovalarini tarqatish imkoniyatini beradi. Helm-jadvallar va dokerfayllar ishlab chiquvchilarga joylashishlarini shablonlashtirishga imkon beradi va ularning kodlari qayerda va qayerda ishlashini aniqlaydi, hatto tashqi va ichki trafikni unga qanday yo'naltirilganligini ham boshqaradi. Shuningdek, u ishlab chiquvchilarni o'z kodlarini ishlatish uchun qancha manbalar talab qilinishi to'g'risida o'ylashga majbur qiladi (va umid qilamanki, buni qanday optimallashtirish haqida ham o'ylab ko'ring!). Kubernetes-dan foydalanishga qaror qilgan har bir kishi xuddi shu naqshlarga amal qiladi.

Joylashtirish va konfiguratsiya "Devops People" bilan bir qatorda, ishlab chiquvchilar o'rtasida ham oson tushuniladi. Bundan tashqari, yaxshi ishlab chiqilgan bo'lsa, sizning monitoringingiz va kuzatuvchanligingiz uchun echimlar (ehtimol api + prometheus + grafana kabi oddiy narsa) bir xil infratuzilma samaradorligi va APM o'lchovlarini klasterdan, shuningdek, dastur jurnallaridan chiqarishga imkon beradi. Shu tarzda, ishlab chiquvchilar o'zlari yoqtirgan narsani tanlashlari va hamma narsani bir joyda ko'rishlari mumkin.

Bu fikrlarning barchasi o'ta jozibali va ayniqsa, agar siz DevOps makonida bo'lsangiz, og'izda shu payt og'izda qichishish bo'lishi mumkin. Hammasi bir oz texnik utopiya kabi yangray boshladi.

Ammo bizning boshimiz bulutlar ichida juda baland ko'tarilishidan oldin (bu erda nima qilganimni ko'ring?) Haqiqatni sinchkovlik bilan ko'rib chiqaylik. Agar siz hali ham payqamagan bo'lsangiz, asosan mening barcha fikrlarim pastga tushadi:

Ha, ammo Kubernetes bu muammoni hal qilmayapti.

Va bu istisno emas. Men "DevOps makoni" dagi odamlarni yuqorida ko'rsatilgan xususiyatlarga ko'proq jalb qilishlarini aytib o'tdim, chunki bu deyarli barcha DevOps tamoyillarining yakuniy maqsadi. Ishlab chiquvchilar ularning joylashishlarini tushunadigan va ularga egalik qiladigan tashkilot. O'zlarining dasturlarini sinab ko'rish va tuzatish uchun monitoringni qanday sozlashni biling. Resurslardan foydalanishni ko'rib chiqing va optimallashtiring. Ularning kodi infratuzilmaning qaerga mos kelishini umuman tushuning. Gap shundaki; bu juda ko'p narsani talab qiladi va Kubernetes-ni yoqsangiz, bularning hech biri sehrli tarzda bo'lmaydi. Bularning aksariyati munosabatni o'zgartirish va ishonch va moslashish uchun zarur bo'lgan ko'nikmalarni rivojlantirish uchun ko'p vaqt va ochiq fikrni talab qiladi. Siz vakolat bermoqchi bo'lgan boshqa platformalar kabi Kubernetesni qabul qilish uchun ishlab chiquvchilar tomonidan bir xil qarshilikka duch kelishingizni bilib olasiz (agar ko'proq bo'lsa). Ayniqsa, Kubernetes yuqorida aytib o'tilgan barcha amaliyotlarni bitta ulkan portlashda amalga oshiradi, ularga bir vaqtning o'zida bitta kontseptsiyani kiritishga imkon beradi.

Kubernetes ishlab chiqaruvchilarga ularning resurslaridan foydalanishni optimallashtirishni o'rgatmaydi.

Kubernetes, ishlab chiquvchilar o'z kodlari ishlatiladigan infratuzilmani yaxshiroq tushunishni istashlariga qaror qilishlariga majbur qilmaydi.

Kubernetes ishlab chiqaruvchilarga standartlashtirilgan, ko'paytiriladigan joylashish afzalliklarini ko'rsatmaydi. Yoki ular yo'qligining og'rig'i.

Kubernetes ushbu narsalarga erishgandan so'ng bitta echimni taklif qiladi. Hech qanday holatda u yagona ish oqimlari va umuman DevOps amaliyoti bilan muammolaringizni sehrli tarzda hal qilmaydi. Agar siz shunday deb o'ylasangiz, Kubernetes-ni amalga oshirasiz, keyin sizda + 1 ish oqimlari bo'ladi, bu sizning muhandislaringiz o'rganish, saqlash va qo'llab-quvvatlashlari kerak bo'ladi.

Miqdori va narxi

So'nggi 2 ballni guruhlarga bo'ldim, chunki ular bir-biriga juda bog'liq.

Men ko'rib turgan masshtab uchun eng keng tarqalgan dalil:

Xo'sh, Google uni o'z miqyosidagi xizmatlar uchun ishlatishi mumkin, shuning uchun har qanday miqyosda ishonchli ekanligi isbotlangan

Oddiy bo'lsa-da, bu juda yaxshi dalil va bu aslida sizning kompaniyangizga ishonadigan texnologiyani tanlashning juda oson usuli. Biroq, uni tuzli don bilan ham olish kerak. Ha, agar sizning kompaniyangiz Google miqyosida ishlasa va Kubnernetes klasterlarini boshqarishga bag'ishlaydigan etarli muhandislarga ega bo'lsa, demak, ular umuman tarqalmaydilar. Ammo rostini aytsam, ushbu maqolani o'qigan deyarli har bir kishi Google-ga qaraganda kamroq trafikka xizmat ko'rsatadigan kompaniyada ishlaydi. Bu aniq, ammo muhandislar odatda oldindan rejalashtirishadi va ko'lamini kengaytirishni xohlashadi, shuning uchun biz bilgan echimni tanlamasligimiz kerak. Google-ning tezkor qidiruvi sizga deyarli har qanday docker orkestri tizimining taniqli ekanligi va ko'pchilik hech qachon yaqinlashmaydigan masshtabda ishlaydiganligi isbotlangan (masalan, ko'chmanchi, docker to'dasi, ECS).

Sizni allaqachon eshityapman - Ammo buni amalga oshirish uchun ko'p ish va chaynalish kerak.

Kubernetes ham bundan mustasno emas.

Google Kubernetes-ni qurmadi, uni yoqmadi va o'rnatmadi va unutmaydi. Kubernetes tepasida muvaffaqiyatli yugurish uchun ishlab chiquvchilar va bulut / infratuzilma muhandislaridan katta ish talab etiladi (bunga ko'p odamlar ishonadi). Ko'pincha Kubernetes - bu sirli sirli, sizning ilovalaringizni yengilmas qiladi, degan noto'g'ri tushuncha mavjud - bu muvaffaqiyatsizlikka chidamli va masshtablash muammolariga qarshi turadi. Bu arzimas narsada to'g'ri emas va menimcha, umidsizlikni u o'ylaganlarni kutadi.

Narxiga qarab - yana g'oya juda oddiy, agar men o'z virtual ilovalarimning ko'p sonini xuddi shu miqdordagi virtual mashinalarda ishlata olsam, men serverlarga kamroq haq to'layman. Bunga qo'shimcha ravishda, agar menda ushbu misollarni va virtual mashinalarni resurslarni sarflashga moslashtiradigan aqlli tizim bo'lsa, men kamroq pul sarflayman.

Tez maflar

Ammo, ehtimol siz kutganingizdek, bu oson emas. Konteynerlardan foydadan xoli bo'lish uchun o'zlarining dasturlarini o'rnatadigan dasturchilar, qancha dasturlar qulay ishlashi kerakligi to'g'risida o'ylashlari kerak. Bu umuman oddiy ish emas (men bir xil ish oqimlarini muhokama qilayotganda aytgan edim). Va bu siz Kubernetesda bo'lishingizdan yoki yo'qligingizdan qat'iy nazar foyda keltiradi. Sizning dasturingiz har bir manbaga qancha kerakligini aniq bilish, siz minimal kerakli server birligini, virtual mashinani, konteynerni yoki o'zingiz tanlagan narsani tanlashingiz mumkinligini anglatadi.

Ba'zi hollarda, sizning resurslaringizni bir xil virtual mashinalar guruhiga taqsimlash va iqtisodiy samaradorlikning bir xil darajasiga erishish uchun ko'proq muhandislik harakatlari talab etiladi. Tasdiqlangan cpu / xotira / tarmoq manbalariga ega EC2 nusxalari ustiga Kubernetes klasterini boshqarasiz deb tasavvur qiling. Bir kun CPU-ga ulangan sizning ilovalaringiz boshqalarga qaraganda ko'proq miqyosda ishlay boshlaydi. Sizning klasteringiz CPU bo'lmagan manbalardan to'liq foydalanilmay qolmoqda. Garchi ishlab chiqaruvchilaringiz sinab ko'rishgan va ularning ilovalari qanday manbalarga muhtoj bo'lishlarini aniqlab olishgan bo'lsa ham. Resurs talabining har bir o'zgarishi uchun alohida holatlar guruhini yaratish zaruriyati bilan qo'shimcha murakkablik sathi qo'shiladi (ishlab chiqaruvchilar yana bilishi va ko'rib chiqishi kerak).

Buning ustiga siz yaratgan har bir klaster sizning idishlaringizni tartibga solish uchun qo'shimcha resurslarni talab qiladi (bu barcha orkestr platformalari uchun ham amal qiladi). Kubernetes, kamida, ishlab chiqarishdagi serverlar uchun 3 ta qo'shimcha, va ishlab chiqarish bo'lmagan muhitda - orkestrlash va API-ga kirishni talab qiladi. Agar siz sinov va ishlab chiqarish klasterini ishlatayotgan bo'lsangiz, bu qo'shimcha 4 ta holat. Agar siz ularni boshqa guruhlarga (ichki, tashqi, ehtimol sahna muhitiga) ajratib qo'ysangiz, Kubernetes-ni ishga tushirish uchun ahamiyatsiz ortiqcha xarajat talab etiladi. Bu erda shkala paydo bo'ladi - agar siz katta hajmdagi ishlayotgan bo'lsangiz, kubernetlarni tanlashni tanlasangiz, uni kamaytirish o'rniga sizning narxingizni oshirishingiz mumkin. Ayniqsa, agar siz unga to'g'ri ko'chib o'tmasangiz va Kubernetes-dan foydalanishni tanlaganingizdan so'ng ham "meros" platformangizni ishga tushirishga to'g'ri kelsa. Men mandatni meros qilib olish to'g'risida gaplashdim va agar siz qiziqsangiz, ushbu lavozimdagi bir nechta fikrlarga to'xtaldim.

Agar mening dasturim resurs talablari nuqtai nazaridan shunchalik kichkina bo'lsa, mening minimal hisoblash / xotira / tarmog'im birligi bunga to'g'ri kelmasa-chi? Ochig'ini aytganda, sizning dasturingiz umuman siz ishlaydigan serverlarda ishlamasligi kerak - ularni serversiz ishlashga majbur qilish kerak. Tan olaman, bu ishni biroz soddalashtirishi mumkin. Agar siz muvozanatda bo'lsangiz, unda serversiz ishlashning ma'nosi yo'q va shaxsiy mashinalarda ishlash mantiqiy emas, albatta, konteynerlarni ko'rib chiqishingiz kerak. Ammo, shunga qaramay, Kubernetesni emas, balki idishlarni ko'rib chiqing (men sizni ogohlantirdim, bu mening ko'p fikrlarimning asosi edi)

Men shunchaki Kubernetes - bu aql bovar qilmaydigan dastur va men u bilan erishishingiz mumkin bo'lgan ba'zi narsalar aqlni puflamoqda, deb aytib yakunlashni istardim. Men faqat muhandis sifatida ushbu qarorlarni qabul qilishda pragmatizmni hisobga olishimizni so'rayman. O'zining atrofini qurgan ekotizimga singib ketish juda oson, chunki barchamiz sokin narsalarni yaratishni yaxshi ko'ramiz. Shuning uchun biz nima ish qilsak (umid qilamiz). Ammo, ba'zi bir hamkasbimning hafsalasi pir bo'lgan narsa, biz shunchaki ajoyib narsaga asoslangan holda katta texnik qarorlar qabul qilmasligimiz kerak.

Men barcha fikr-mulohazalar, munozaralar va konstruktiv tanqidlarni olqishlayman - yaqinda Twitter-dan foydalanishni boshladim, iltimos, menga o'z fikrlaringiz bilan tvit qiling!