Bugun men ilovalarni qanday yozish va Kubernetesda yaxshi ishlashi uchun arizangiz uchun qanday talablar borligi haqida gaplashmoqchiman. Ilovada bosh og'rig'i bo'lmasligi uchun uning atrofida biron bir "chizish" ixtiro qilishingiz va qurishingiz shart emas - va hamma narsa Kubernetesning o'zi xohlagan tarzda ishlaydi.
Ushbu ma'ruza "ning bir qismidir"" Kechki maktabning ochiq nazariy ma'ruzalarini ko'rishingiz mumkin . Videodan ko'ra matnni afzal ko'rganlar uchun biz ushbu maqolani tayyorladik.
Mening ismim Pavel Selivanov, hozirda men Mail.ru Cloud Solutions kompaniyasida DevOps yetakchi muhandisiman, biz bulutlarni yaratamiz, boshqaruv kubernetlarini yaratamiz va hokazo. Endi mening vazifalarimga ishlab chiqishda yordam berish, ushbu bulutlarni tarqatish, biz yozadigan ilovalarni tarqatish va foydalanuvchilarimiz uchun taqdim etadigan vositalarni to'g'ridan-to'g'ri ishlab chiqish kiradi.
Men DevOps bilan shug'ullanaman, menimcha, oxirgi, ehtimol, uch yil. Ammo, printsipial jihatdan, men DevOps qilayotgan ishni taxminan besh yildan beri qilaman. Undan oldin men asosan administrator ishlari bilan shug'ullanardim. Men Kubernetes bilan ishlashni ancha oldin boshlaganman - u bilan ishlashni boshlaganimdan taxminan to'rt yil o'tdi.
Umuman olganda, men Kubernetes 1.3 versiyasi bo'lganida boshladim, ehtimol, va ehtimol 1.2 - u hali go'daklik davrida. Endi u endi boshlang'ich bosqichida emas - va bozorda Kubernetes qilishni xohlaydigan muhandislarga katta talab borligi aniq. Va kompaniyalar bunday odamlarga juda katta talabga ega. Shuning uchun, aslida, bu ma'ruza paydo bo'ldi.
Agar men gaplashadigan reja bo'yicha gapiradigan bo'lsak, shunday ko'rinadi, qavs ichida (TL;DR) - "juda uzun; o'qimang". Mening bugungi taqdimotim cheksiz ro'yxatlardan iborat bo'ladi.
Aslida, men o'zimga bunday taqdimotlar o'tkazilganda yoqmaydi, lekin bu shunday mavzuki, men ushbu taqdimotni tayyorlayotganimda, men ushbu ma'lumotni qanday qilib boshqacha tartibga solishni tushunmadim.
Umuman olganda, bu ma'lumotlar "ctrl+c, ctrl+v" bo'lib, DevOps bo'limida bizning Wiki-dan olingan bo'lib, u erda ishlab chiquvchilarga qo'yiladigan talablarni yozganmiz: "bolalar, biz sizning ilovangizni ishga tushiramiz. Kubernetes, shunday bo'lishi kerak."
Shuning uchun taqdimot juda katta ro'yxat bo'lib chiqdi. Kechirasiz. Iloji bo'lsa zerikarli bo'lmasligi uchun iloji boricha aytib berishga harakat qilaman.
Endi biz nimani ko'rib chiqamiz:
- bular, birinchi navbatda, jurnallar (ilova jurnallari?), Kubernetesda ular bilan nima qilish kerak, ular bilan nima qilish kerak, ular qanday bo'lishi kerak;
- Kubernetes-dagi konfiguratsiyalar bilan nima qilish kerak, Kubernetes uchun dasturni sozlashning eng yaxshi va eng yomon usullari qanday;
- Keling, umumiy foydalanish imkoniyatini tekshirish nima, ular qanday ko'rinishi kerakligi haqida gapiraylik;
- keling, oqlangan o'chirish nima haqida gapiraylik;
- yana resurslar haqida gapiraylik;
- Keling, ma'lumotlarni saqlash mavzusiga yana bir bor to'xtalib o'tamiz;
- va oxirida men sizga ushbu sirli bulutli ilova atamasi nima ekanligini aytib beraman. Bulutlilik, bu atamaning sifatdoshi sifatida.
Jurnallar
Men jurnallardan boshlashni taklif qilaman - bu jurnallarni Kubernetesda qaerga surtish kerakligi bilan. Endi siz Kubernetes-da dasturni ishga tushirdingiz. Klassiklarga ko'ra, ilgari ilovalar har doim faylning biron bir joyida jurnallarni yozgan. Yomon ilovalar dasturni ishga tushirgan ishlab chiquvchining uy katalogidagi faylga jurnallar yozgan. Yaxshi ilovalar faylga jurnallar yozgan /var/log.
Shunga ko'ra, bundan tashqari, yaxshi ma'murlar o'zlarining infratuzilmalarida bu jurnallar aylanishi mumkin bo'lgan ba'zi narsalarni sozlaganlar - bir xil rsyslog, bu jurnallarga qaraydi va ularga biror narsa yuz berganda, ular juda ko'p, u zaxira nusxalarini yaratadi , jurnallarni u erga qo'yadi. , eski fayllarni, bir haftadan ko'proq, olti oy va boshqa vaqtni o'chiradi. Nazariy jihatdan, dastur jurnallarni yozgani uchun ishlab chiqarish serverlarida (jangovar serverlar?) bo'sh joy tugamasligi uchun bizda qoidalar bo'lishi kerak. Va shunga ko'ra, loglar tufayli butun ishlab chiqarish to'xtamadi.
Biz Kubernetes dunyosiga ko'chib o'tganimizda va u erda xuddi shu narsani ishga tushirganimizda, e'tibor berishingiz mumkin bo'lgan birinchi narsa, odamlar faylga jurnallar yozganlarida, ularni yozishda davom etishlaridir.
Ma'lum bo'lishicha, agar Kubernetes haqida gapiradigan bo'lsak, jurnallarni docker konteyneridan biron bir joyda yozish uchun to'g'ri joy ularni dasturdan Stdout/Stderr deb ataladigan, ya'ni operatsion tizimning standart chiqish oqimlariga yozishdir. standart xato chiqishi. Bu Docker va xususan Kubernetis-da jurnallarni printsipial ravishda qo'yishning eng to'g'ri, eng sodda va mantiqiy usuli. Chunki agar sizning ilovangiz Stdout/Stderr-ga jurnallar yozsa, bu jurnallar bilan nima qilish kerakligini Docker va Kubernetes qo'shimchasi hal qiladi. Docker sukut bo'yicha o'zining maxsus fayllarini JSON formatida yaratadi.
Bu erda savol tug'iladi, bu jurnallar bilan keyin nima qilasiz? Eng oson yo'li aniq, bizda qilish imkoniyati bor kubectl logs va bu "podlar" ning ushbu jurnallariga qarang. Ammo, ehtimol, bu juda yaxshi variant emas - jurnallar bilan yana bir narsa qilish kerak.
Hozircha, keling, bir vaqtning o'zida gaplashaylik, chunki biz jurnallar mavzusiga to'xtalganimiz sababli, jurnallar qanday ko'rinishi kerakligi haqida. Ya'ni, bu Kubernetesga to'g'ridan-to'g'ri taalluqli emas, lekin biz jurnallar bilan nima qilish haqida o'ylashni boshlaganimizda, bu haqda ham o'ylash yaxshi bo'lardi.
Bizning dockerimiz o'z fayllariga joylashtirgan jurnallarni olib, ularni biror joyga yuboradigan do'stona tarzda bizga qandaydir vosita kerak. Umuman olganda, biz odatda Kubernetes ichida DaemonSet ko'rinishidagi qandaydir agentni ishga tushiramiz - jurnallar yig'uvchisi, unga Docker to'playdigan jurnallar qayerda joylashganligi aytiladi. Va bu yig'uvchi agent ularni oddiygina oladi, ehtimol ularni qandaydir tarzda yo'l davomida tahlil qiladi, ehtimol ularni qo'shimcha meta-ma'lumotlar bilan boyitadi va oxir-oqibat ularni saqlash uchun yuboradi. Variantlar allaqachon mavjud. Eng keng tarqalgani, ehtimol, Elasticsearch bo'lib, u erda jurnallarni saqlashingiz mumkin va ularni u erdan qulay tarzda olishingiz mumkin. Keyin, so'rovdan foydalanib, Kibana-dan foydalanib, masalan, ular asosida grafiklarni tuzing, ular asosida ogohlantirishlarni yarating va hokazo.
Eng muhim fikr, yana takrorlamoqchiman, Docker ichida, xususan Kubernetes ichida jurnallaringizni faylda saqlash juda yomon fikr.
Chunki, birinchi navbatda, fayldagi konteyner ichidagi jurnallarni olish qiyin. Siz avval konteynerga kirishingiz kerak, u erda exec-ni ishga tushiring va keyin jurnallarga qarang. Keyingi nuqta shundaki, agar sizda faylda jurnallar mavjud bo'lsa, unda konteynerlar odatda minimalist muhitga ega va odatda jurnallar bilan normal ishlash uchun zarur bo'lgan yordamchi dasturlar mavjud emas. Ularni dafn qiling, ularga qarang, matn muharririda oching. Keyingi daqiqada bizda konteyner ichidagi faylda jurnallar mavjud bo'lsa, agar bu konteyner o'chirilsa, siz tushunasiz, jurnallar u bilan birga o'ladi. Shunga ko'ra, konteynerning har qanday qayta ishga tushirilishi boshqa jurnallar yo'qligini anglatadi. Yana yomon variant.
Va oxirgi nuqta shundaki, konteynerlar ichida odatda sizning arizangiz bo'ladi va tamom - bu odatda ishlaydigan yagona jarayon. Jurnallaringiz bilan fayllarni aylantiradigan har qanday jarayon haqida umuman gap yo'q. Jurnallar faylga yozila boshlashi bilan, bu, kechirasiz, biz ishlab chiqarish serverini yo'qotishni boshlaymiz. Chunki, birinchidan, ularni topish qiyin, ularni hech kim kuzatmaydi, bundan tashqari, hech kim ularni nazorat qilmaydi - shunga ko'ra, serverdagi bo'sh joy tugamaguncha fayl cheksiz o'sadi. Shuning uchun yana bir bor aytamanki, Docker-da, xususan Kubernetes-da faylga kirish yomon fikrdir.
Keyingi nuqta, men bu haqda yana bir bor gaplashmoqchiman - biz jurnallar mavzusiga to'xtalib o'tayotganimiz sababli, ular bilan ishlash qulay bo'lishi uchun jurnallar qanday ko'rinishi haqida gapirish yaxshi bo'lar edi. Aytganimdek, mavzu Kubernetes bilan bevosita bog'liq emas, lekin u DevOps mavzusiga juda mos keladi. Madaniyatni rivojlantirish va ushbu ikki xil bo'lim - Dev va Ops o'rtasidagi do'stlik mavzusida hamma qulay bo'lishi uchun.
Bu shuni anglatadiki, bugungi kunda ideal holda jurnallar JSON formatida yozilishi kerak. Agar sizda qandaydir bosma yoki shunga o'xshash narsalarni kiritganingiz uchun tushunarsiz formatlarda jurnallarni yozadigan o'zingizning tushunarsiz dasturingiz bo'lsa, unda oddiy jurnalni amalga oshirishga imkon beradigan qandaydir ramka, qandaydir o'ramni Google'da qidirish vaqti keldi; u erda JSON da logging parametrlarini yoqing, chunki JSON oddiy format bo'lib, uni tahlil qilish oson.
Agar sizning JSON ba'zi mezonlarga muvofiq ishlamasa, hech kim nima ekanligini bilmaydi, hech bo'lmaganda tahlil qilinadigan formatda jurnallarni yozing. Bu erda, aksincha, masalan, agar siz bir nechta konteynerlarni ishlatayotgan bo'lsangiz yoki shunchaki nginx bilan ishlayotgan bo'lsangiz va ularning har biri o'z logging sozlamalariga ega bo'lsa, unda siz uchun juda noqulay bo'lishi mumkinligi haqida o'ylash kerak. ularni tahlil qiling. Chunki har bir yangi nginx misoli uchun siz o'zingizning parseringizni yozishingiz kerak, chunki ular jurnallarni boshqacha yozadilar. Shunga qaramay, bu barcha nginx misollari bir xil logging konfiguratsiyasiga ega ekanligiga va barcha jurnallarini mutlaqo bir xilda yozishiga ishonch hosil qilish haqida o'ylash kerak edi. Xuddi shu narsa mutlaqo barcha ilovalar uchun amal qiladi.
Oxir-oqibat, men ham olovga yonilg'i qo'shmoqchiman, ideal holda, ko'p qatorli formatli jurnallardan qochish kerak. Gap shundaki, agar siz hech qachon log yig'uvchilar bilan ishlagan bo'lsangiz, ular sizga va'da qilgan narsalarni ko'rgansiz, ular ko'p qatorli jurnallar bilan ishlashlari mumkin, ularni qanday yig'ishni bilishadi va hokazo. Aslida, mening fikrimcha, bugungi kunda biron bir kollektor ko'p qatorli jurnallarni normal, to'liq va xatosiz to'play olmaydi. Insoniy tarzda, qulay va xatosiz bo'lishi uchun.
Ammo stek izi har doim ko'p qatorli jurnallar va ulardan qanday qochish kerak. Bu yerda savol shundan iboratki, jurnal hodisaning yozuvidir va stactrace aslida jurnal emas. Agar biz jurnallarni yig'ib, ularni Elasticsearch-ning biron bir joyiga joylashtirsak, so'ngra ulardan grafiklarni chizsak, saytingizda foydalanuvchi faoliyati haqida ba'zi hisobotlarni tuzsak, keyin siz stek izini olganingizda, bu kutilmagan bir narsa sodir bo'layotganini anglatadi. ilovangizda ishlov berilmagan vaziyat. Va ularni kuzatib boradigan tizimga stek izini avtomatik ravishda yuklash mantiqan.
Bu stek izi bilan ishlash uchun maxsus yaratilgan dasturiy ta'minot (xuddi shu Sentry). U darhol avtomatlashtirilgan vazifalarni yaratishi, ularni kimgadir tayinlashi, stacttraces sodir bo'lganda ogohlantirishi, bu stacttracelarni bir tur bo'yicha guruhlashi va hokazo. Printsipial jihatdan, loglar haqida gapirganda, statraslar haqida gapirishning ma'nosi yo'q, chunki bu, oxir-oqibat, turli maqsadlarga ega bo'lgan turli xil narsalar.
Konfiguratsiya
Keyin biz Kubernetes-dagi konfiguratsiya haqida gaplashamiz: u bilan nima qilish kerak va Kubernetes ichidagi ilovalar qanday sozlanishi kerak. Umuman olganda, men odatda Docker konteynerlar haqida emasligini aytaman. Docker konteynerlar haqida ekanligini hamma biladi, hatto Docker bilan ko'p ishlamaganlar ham. Takror aytaman, Docker konteynerlar haqida emas.
Docker, mening fikrimcha, standartlar haqida. Va deyarli hamma narsa uchun standartlar mavjud: ilovangizni yaratish standartlari, ilovangizni o'rnatish standartlari.
Va bu narsa - biz uni ilgari ishlatgan edik, u faqat konteynerlar paydo bo'lishi bilan mashhur bo'ldi - bu narsa ENV (atrof-muhit) o'zgaruvchilari, ya'ni operatsion tizimingizda joylashgan muhit o'zgaruvchilari deb ataladi. Bu, odatda, ilovangizni sozlashning ideal usuli, chunki agar sizda JAVA, Python, Go, Perl, xudo saqlagan ilovalar bo'lsa va ularning barchasi ma'lumotlar bazasi xostini, ma'lumotlar bazasi foydalanuvchisini, ma'lumotlar bazasi paroli o'zgaruvchilarini o'qiy olsa, bu idealdir. Ma'lumotlar bazasi rejasida xuddi shu tarzda sozlangan to'rt xil tildagi ilovalaringiz bor. Boshqa boshqa konfiguratsiyalar yo'q.
Hamma narsani ENV o'zgaruvchilari yordamida sozlash mumkin. Kubernetes haqida gapirganda, Deployment ichida ENV o'zgaruvchilarini e'lon qilishning ajoyib usuli mavjud. Shunga ko'ra, agar biz maxfiy ma'lumotlar haqida gapiradigan bo'lsak, biz darhol ENV o'zgaruvchilari (ma'lumotlar bazalariga parollar va boshqalar) dan maxfiy ma'lumotlarni sirga surishimiz, maxfiy klaster yaratishimiz va Deployment'dagi ENV tavsifida biz to'g'ridan-to'g'ri e'lon qilmayotganimizni ko'rsatishimiz mumkin. bu o'zgaruvchining qiymati va bu ma'lumotlar bazasi parol o'zgaruvchisining qiymati sirdan o'qiladi. Bu standart Kubernetes harakati. Va bu sizning ilovalaringizni sozlash uchun eng ideal variant. Faqat kod darajasida, bu yana ishlab chiquvchilarga tegishli. Agar siz DevOps bo'lsangiz, so'rashingiz mumkin: “Bolalar, iltimos, ilovangizni muhit o'zgaruvchilarini o'qishga o'rgating. Va biz hammamiz baxtli bo'lamiz."
Agar kompaniyadagi hamma bir xil nomlangan muhit o'zgaruvchilarini o'qisa, bu juda yaxshi. Shunday qilib, ba'zilar postgres ma'lumotlar bazasini kutmoqda, boshqalar ma'lumotlar bazasi nomini kutmoqda, boshqalari boshqa narsani kutmoqda, boshqalari qandaydir dbnni kutmoqda, shuning uchun shunga mos ravishda bir xillik mavjud.
Muammo sizda juda ko'p muhit o'zgaruvchilari mavjud bo'lganda paydo bo'ladi, siz shunchaki Deploymentni ochasiz - va atrof-muhit o'zgaruvchilarining besh yuz qatori mavjud. Bunday holda, sizda atrof-muhit o'zgaruvchilari shunchaki oshib ketdi - va endi o'zingizni qiynashingizga hojat yo'q. Bunday holda, konfiguratsiyalardan foydalanishni boshlash mantiqan to'g'ri keladi. Ya'ni ilovangizni konfiguratsiyalardan foydalanishga o'rgating.
Bitta savol shundaki, konfiguratsiyalar siz o'ylagandek emas. Config.pi foydalanish uchun qulay bo'lgan konfiguratsiya emas. Yoki o'zingizning formatingizdagi ba'zi konfiguratsiyalar, muqobil ravishda iqtidorli - bu men aytmoqchi bo'lgan konfiguratsiya ham emas.
Men qabul qilinadigan formatlardagi konfiguratsiya haqida gapiryapman, ya'ni hozirgacha eng mashhur standart .yaml standartidir. Uni qanday o'qish kerakligi aniq, odam o'qishi mumkin, uni qanday o'qish kerakligi ilovadan aniq.
Shunga ko'ra, YAML-ga qo'shimcha ravishda siz, masalan, JSON-dan ham foydalanishingiz mumkin, tahlil qilish u erdan dastur konfiguratsiyasini o'qish nuqtai nazaridan YAML kabi qulaydir. Odamlar o'qish uchun sezilarli darajada noqulay. Siz formatni sinab ko'rishingiz mumkin, a la ini. Inson nuqtai nazaridan o'qish juda qulay, lekin uni avtomatik ravishda qayta ishlash noqulay bo'lishi mumkin, chunki agar siz o'zingizning konfiguratsiyalaringizni yaratmoqchi bo'lsangiz, ini formatini yaratish allaqachon noqulay bo'lishi mumkin.
Lekin har qanday holatda, qaysi formatni tanlasangiz ham, Kubernetes nuqtai nazaridan bu juda qulay. Siz butun konfiguratsiyangizni ConfigMap-da Kubernetes ichiga qo'yishingiz mumkin. Va keyin ushbu konfiguratsiya xaritasini oling va uni podkastingizga qandaydir maxsus katalogga o'rnatishni so'rang, u erda ilovangiz ushbu konfiguratsiya xaritasidagi konfiguratsiyani xuddi fayl kabi o'qiydi. Ilovangizda juda ko'p konfiguratsiya opsiyalari mavjud bo'lganda buni qilish yaxshidir. Yoki bu qandaydir murakkab tuzilma, u erda uyalar mavjud.
Agar sizda konfiguratsiya xaritasi bo'lsa, unda siz ilovangizni juda yaxshi o'rgatishingiz mumkin, masalan, konfiguratsiya o'rnatilgan fayldagi o'zgarishlarni avtomatik ravishda kuzatish, shuningdek, konfiguratsiyalar o'zgarganda ilovangizni avtomatik ravishda qayta yuklash. Bu odatda ideal variant bo'ladi.
Shunga qaramay, men bu haqda gapirgan edim - maxfiy ma'lumotlar konfiguratsiya xaritasida emas, maxfiy ma'lumotlar o'zgaruvchilarda emas, maxfiy ma'lumotlar sirlarda emas. U yerdan ushbu maxfiy ma'lumotni diplomatiya bilan bog'lang. Odatda biz Kubernetes ob'ektlari, joylashtirishlari, konfiguratsiya xaritalari, xizmatlarining barcha tavsiflarini git-da saqlaymiz. Shunga ko'ra, git-da ma'lumotlar bazasiga parol qo'yish, garchi u sizning kompaniyangizda mavjud bo'lgan git bo'lsa ham, yomon fikr. Chunki, hech bo'lmaganda, git hamma narsani eslab qoladi va u erdan parollarni olib tashlash unchalik oson emas.
Salomatlik tekshiruvi
Keyingi nuqta - bu Sog'liqni saqlash tekshiruvi deb ataladigan narsa. Umuman olganda, salomatlik tekshiruvi sizning arizangiz ishlayotganligini tekshirishdan iborat. Shu bilan birga, biz ko'pincha ma'lum veb-ilovalar haqida gapiramiz, ular uchun, shunga ko'ra, sog'liqni saqlash nuqtai nazaridan (bu erda va bundan keyin tarjima qilmaslik yaxshiroq) bu ba'zi bir maxsus URL bo'lib, ular qayta ishlanadi. standart, ular odatda shunday qilishadi /health.
Ushbu URL manziliga kirishda, shunga ko'ra, bizning ilovamiz "ha, yaxshi, menda hamma narsa yaxshi, 200" yoki "yo'q, men bilan hamma narsa yaxshi emas, taxminan 500" deydi. Shunga ko'ra, agar bizning ilovamiz veb-ilova emas, http bo'lmasa, biz hozir qandaydir demon haqida gapiramiz, biz sog'liqni tekshirishni qanday qilishni aniqlay olamiz. Ya'ni, bu shart emas, agar dastur http bo'lmasa, unda hamma narsa sog'liq tekshiruvisiz ishlaydi va buni hech qanday tarzda amalga oshirib bo'lmaydi. Siz vaqti-vaqti bilan fayldagi ba'zi ma'lumotlarni yangilashingiz mumkin, demoningiz uchun maxsus buyruqni o'ylab topishingiz mumkin, masalan: daemon status, "ha, hammasi yaxshi, demon ishlayapti, u tirik" deb aytadi.
Bu nima uchun? Birinchi va eng aniq narsa, ehtimol, nima uchun sog'liqni tekshirish kerak - dastur ishlayotganini tushunish uchun. Aytmoqchimanki, bu shunchaki ahmoqlik, hozir u yoqilganda, u ishlayotganga o'xshaydi, shuning uchun u ishlayotganiga ishonch hosil qilishingiz mumkin. Va ma'lum bo'lishicha, dastur ishlayapti, konteyner ishlayapti, misol ishlayapti, hammasi yaxshi - va keyin foydalanuvchilar allaqachon texnik yordamdan barcha telefon raqamlarini o'chirib tashlashgan va "siz nimasiz ..., siz" deyishadi. uxlab qoldi, hech narsa ishlamayapti."
Salomatlik tekshiruvi - bu foydalanuvchi nuqtai nazaridan uning ishlashini ko'rishning bir usuli. Usullaridan biri. Keling, buni shunday qo'yaylik. Kubernetes nuqtai nazaridan, bu, shuningdek, dastur qachon ishga tushirilishini tushunishning bir usuli, chunki biz konteyner ishga tushirilgan, yaratilgan va ishga tushirilganda va dastur to'g'ridan-to'g'ri ushbu konteynerda ishga tushirilganda farq borligini tushunamiz. Chunki agar biz o'rtacha java ilovasini olib, uni dockda ishga tushirishga harakat qilsak, qirq soniya, hatto bir daqiqa yoki hatto o'n soniya davomida u juda yaxshi boshlanishi mumkin. Bunday holda, siz hech bo'lmaganda uning portlarini taqillatib qo'yishingiz mumkin, u erda javob bermaydi, ya'ni u hali trafikni qabul qilishga tayyor emas.
Shunga qaramay, sog'lig'ini tekshirish yordamida va biz bu erga aylanayotganimizdan foydalanib, biz Kubernetesda tushunishimiz mumkinki, dasturda nafaqat konteyner ko'tarilgan, balki dasturning o'zi boshlangan, u allaqachon javob beradi. salomatlik tekshiruvi, ya'ni biz u erga trafik jo'natishimiz mumkin.
Men hozir aytmoqchi bo'lgan narsa Kubernetes ichidagi tayyorlik/jonlilik testlari deb ataladi; shunga ko'ra, bizning tayyorlik testlarimiz balanslashda ilova mavjudligi uchun javobgardir. Ya'ni, agar dasturda tayyorgarlik testlari o'tkazilsa, unda hamma narsa yaxshi, mijoz trafigi dasturga boradi. Agar tayyorgarlik testlari o'tkazilmasa, dastur shunchaki ishtirok etmaydi, bu alohida misol balanslashda ishtirok etmaydi, balanslashdan o'chiriladi, mijoz trafigi oqmaydi. Shunga ko'ra, Kubernetes ichida Liveness testlari kerak bo'ladi, shunda ilova tiqilib qolsa, uni qayta ishga tushirish mumkin. Agar Kubernetesda e'lon qilingan ilova uchun jonlilik testi ishlamasa, u holda dastur shunchaki balanslashdan o'chirilmaydi, balki qayta ishga tushiriladi.
Va bu erda men eslatib o'tmoqchi bo'lgan muhim jihat: amaliy nuqtai nazardan, tayyorgarlik testi odatda hayot testidan ko'ra tez-tez qo'llaniladi va tez-tez talab qilinadi. Ya'ni, tayyorlik va jonlilik testlarini shunchaki o'ylamasdan e'lon qilish, chunki Kubernetes buni qila oladi va keling, u qila oladigan hamma narsani ishlataylik, bu juda yaxshi fikr emas. Sababini tushuntiraman. Chunki sinovdagi ikkinchi nuqta - sog'lig'ingizni tekshirishda asosiy xizmatni tekshirish yaxshi fikr bo'ladi. Bu shuni anglatadiki, agar sizda ba'zi ma'lumotlarni taqdim etadigan veb-ilovangiz bo'lsa, u o'z navbatida uni biron bir joydan olishi kerak. Masalan, ma'lumotlar bazasida. Xo'sh, u ushbu REST API-ga kiradigan ma'lumotlarni bir xil ma'lumotlar bazasiga saqlaydi. Keyin, shunga ko'ra, agar sizning sog'lig'ingizni tekshirishingiz oddiygina slashhealth bilan bog'langandek javob bersa, dastur "200, yaxshi, hammasi yaxshi" deb aytadi va shu bilan birga sizning ilovangiz ma'lumotlar bazasiga kirish imkoni yo'q va Healthcheck ilovasi "200, yaxshi, hammasi yaxshi" deydi. ” - Bu yomon sog'liq tekshiruvi. Bu shunday ishlashi kerak emas.
Ya'ni sizning arizangiz, unga so'rov kelganda /health, u shunchaki “200, ok” deb javob bermaydi, avvalo, masalan, ma’lumotlar bazasiga o‘tadi, unga ulanishga harakat qiladi, u yerda juda oddiy narsalarni qiladi, masalan, birini tanlang, shunchaki “bog‘lanish bor-yo‘qligini tekshiradi”. ma'lumotlar bazasi va siz ma'lumotlar bazasini so'rashingiz mumkin. Agar bularning barchasi muvaffaqiyatli bo'lsa, javob "200, yaxshi". Muvaffaqiyatsiz bo'lsa, xatolik borligini, ma'lumotlar bazasi mavjud emasligini aytadi.
Shuning uchun, shu munosabat bilan men yana Tayyorlik/Tiriklik testlariga qaytaman - nima uchun sizga tayyorlik testi kerak bo'ladi, ammo tiriklik testi savol ostida. Chunki agar siz sog'liqni saqlash tekshiruvlarini men aytganimdek tasvirlab bersangiz, u misol qismida mavjud emasligi ma'lum bo'ladi.в или со всех instancemasalan, ma'lumotlar bazasida. Tayyorlik testini e'lon qilganingizda, bizning sog'lig'imizni tekshirish muvaffaqiyatsiz bo'ldi va shunga mos ravishda ma'lumotlar bazasiga kirish imkoni bo'lmagan barcha ilovalar balanslashdan o'chirildi va aslida e'tibordan chetda qolgan holatda "osilib qoladi" va ma'lumotlar bazalari ishlaguncha kutishadi. ish.
Agar biz tiriklik testini e'lon qilgan bo'lsak, tasavvur qiling-a, bizning ma'lumotlar bazamiz buzildi va Kubernetesda hamma narsaning yarmi qayta ishga tusha boshlaydi, chunki jonlilik testi muvaffaqiyatsiz tugadi. Bu siz qayta ishga tushirishingiz kerakligini anglatadi. Bu siz xohlagan narsa emas, men hatto amaliyotda shaxsiy tajribam ham bor edi. Bizda JS-da yozilgan va Mongo ma'lumotlar bazasiga kiritilgan chat ilovasi bor edi. Muammo shundaki, bu mening Kubernetes bilan ishimning boshida edi, biz Kubernetes buni qila oladi, shuning uchun biz undan foydalanamiz, degan printsip bo'yicha testlarning tayyorligi va jonliligini tasvirlab berdik. Shunga ko'ra, bir nuqtada Mongo biroz "zerikarli" bo'lib qoldi va namuna muvaffaqiyatsizlikka uchradi. Shunga ko'ra, yomg'ir sinoviga ko'ra, podalar "o'ldirish" ni boshladi.
Siz tushunganingizdek, ular "o'ldirilganda" bu chat, ya'ni mijozlarning juda ko'p aloqalari bor. Ular, shuningdek, "o'ldirilgan" - yo'q, mijozlar emas, faqat ulanishlar - barchasi bir vaqtning o'zida emas va ular bir vaqtning o'zida o'ldirilmaganligi sababli, ba'zilari oldinroq, ba'zilari keyinroq, bir vaqtning o'zida boshlamaydilar. vaqt. Bundan tashqari, standart tasodifiy, biz har safar dasturning boshlanish vaqtini millisekundlik aniqlik bilan bashorat qila olmaymiz, shuning uchun ular buni bir vaqtning o'zida bir marta bajaradilar. Bitta infospot ko'tariladi, balansga qo'shiladi, barcha mijozlar u erga kelishadi, u bunday yukga bardosh bera olmaydi, chunki u yolg'iz va taxminan aytganda, u erda o'nlab odamlar ishlaydi va u tushadi. Keyingisi ko'tariladi, butun yuk uning ustida, u ham tushadi. Xo'sh, bu sharsharalar kaskadda davom etmoqda. Oxir-oqibat, bu qanday hal qilindi - biz ushbu ilovaga foydalanuvchi trafigini qat'iy to'xtatishimiz, barcha misollar ko'tarilishiga imkon berishimiz va keyin barcha foydalanuvchi trafigini birdaniga boshlashimiz kerak edi, shunda u allaqachon barcha o'nta misollar orasida taqsimlangan.
Agar bu jonlilik testi e'lon qilinmaganida, bu hammasini qayta ishga tushirishga majbur qilmaganida, dastur buni juda yaxshi hal qilgan bo'lardi. Ammo balansdan tortib, biz uchun hamma narsa o'chirib qo'yilgan, chunki ma'lumotlar bazalariga kirish imkoni yo'q va barcha foydalanuvchilar "yiqilib ketishdi". Keyin, ushbu ma'lumotlar bazasi mavjud bo'lganda, hamma narsa balanslash tarkibiga kiradi, ammo ilovalarni qayta ishga tushirish shart emas va bunga vaqt va resurslarni sarflashning hojati yo'q. Ularning barchasi allaqachon shu yerda, ular tirbandlikka tayyor, shuning uchun tirbandlik ochiladi, hamma narsa yaxshi - dastur joyida, hamma narsa ishlashda davom etmoqda.
Shuning uchun, tayyorlik va jonlilik testlari har xil, bundan tashqari siz nazariy jihatdan turli xil sog'liq tekshiruvlarini, bir turdagi radiuslarni, bir turdagi livlarni, masalan, turli narsalarni tekshirishingiz mumkin. Tayyorlik testlari paytida orqa tomonlaringizni tekshiring. Va jonlilik testida, masalan, siz tiriklik testi odatda javob beradigan dastur ekanligini tekshirmaysiz, agar u umuman javob berishga qodir bo'lsa.
Chunki jonlilik testi, umuman olganda, biz "tiqilib qolganda". Cheksiz tsikl boshlandi yoki boshqa narsa - va boshqa so'rovlar ko'rib chiqilmaydi. Shuning uchun, hatto ularni ajratish va ularda boshqa mantiqni amalga oshirish mantiqiy.
Sinovdan o'tganingizda, sog'lig'ingizni tekshirganda nima javob berishingiz kerakligi haqida. Bu haqiqatan ham og'riq. Bu bilan tanish bo'lganlar, ehtimol, kuladi - lekin jiddiy, men hayotimda 200% hollarda "XNUMX" deb javob beradigan xizmatlarni ko'rdim. Ya'ni, kim muvaffaqiyatli. Ammo shu bilan birga, javobning tanasida ular "shunday xato" deb yozadilar.
Ya'ni, javob holati sizga keladi - hamma narsa muvaffaqiyatli. Ammo shu bilan birga, siz tanani tahlil qilishingiz kerak, chunki tana "kechirasiz, so'rov xato bilan yakunlandi" deb aytadi va bu shunchaki haqiqat. Men buni real hayotda ko'rganman.
Va ba'zi odamlar buni kulgili deb hisoblamasliklari uchun, boshqalari esa juda og'riqli deb hisoblasa, u hali ham oddiy qoidaga rioya qilishga arziydi. Salomatlik tekshiruvlarida va printsipial jihatdan veb-ilovalar bilan ishlashda.
Agar hamma narsa yaxshi bo'lsa, ikki yuzinchi javob bilan javob bering. Aslida, har qanday ikki yuzinchi javob sizga mos keladi. Agar siz ragsy-ni juda yaxshi o'qisangiz va ba'zi javob statuslari boshqalardan farq qilishini bilsangiz, mos keladiganlar bilan javob bering: 204, 5, 10, 15, nima bo'lishidan qat'iy nazar. Agar u juda yaxshi bo'lmasa, unda "ikki nol nol". Agar hamma narsa yomon bo'lsa va sog'liq tekshiruvi javob bermasa, har qanday besh yuzdan biriga javob bering. Shunga qaramay, agar siz qanday javob berishni tushunsangiz, turli xil javob holatlari bir-biridan qanday farq qiladi. Agar tushunmasangiz, 502 sizning tanlovingiz, agar biror narsa noto'g'ri bo'lsa, tibbiy tekshiruvlarga javob berishingiz mumkin.
Bu yana bir nuqta, men asosiy xizmatlarni tekshirish haqida bir oz qaytmoqchiman. Agar siz, masalan, ilovangiz ortida turgan barcha asosiy xizmatlarni tekshirishni boshlasangiz - umuman olganda. Mikroservis arxitekturasi nuqtai nazaridan bizda "past ulanish" tushunchasi mavjud - ya'ni sizning xizmatlaringiz bir-biriga minimal bog'liq bo'lganda. Agar ulardan biri muvaffaqiyatsiz bo'lsa, qolganlari bu funksiyasiz ishlashda davom etadilar. Ba'zi funksiyalar shunchaki ishlamaydi. Shunga ko'ra, agar siz barcha tibbiy ko'riklarni bir-biriga bog'lasangiz, infratuzilmada bitta narsa qulab tushasiz va u tushib ketganligi sababli, barcha xizmatlarning barcha tibbiy tekshiruvlari ham muvaffaqiyatsiz bo'la boshlaydi - va umuman olganda, ko'proq infratuzilma mavjud. butun mikroservis arxitekturasi №. U erda hamma narsa qorong'i bo'lib ketdi.
Shuning uchun yana bir bor takrorlamoqchimanki, siz asosiy xizmatlarni tekshirishingiz kerak, ularsiz sizning arizangiz yuz foiz hollarda o'z vazifasini bajara olmaydi. Ya'ni, agar sizda REST API mavjud bo'lsa, u orqali foydalanuvchi ma'lumotlar bazasiga saqlaydi yoki ma'lumotlar bazasidan oladi, keyin ma'lumotlar bazasi yo'q bo'lsa, foydalanuvchilaringiz bilan ishlashga kafolat bera olmaysiz.
Ammo, agar sizning foydalanuvchilaringiz, ularni ma'lumotlar bazasidan olib tashlaganingizda, qo'shimcha ravishda frontendga javob yuborishdan oldin kiritgan boshqa backend metama'lumotlari bilan boyitilgan bo'lsa va bu backend mavjud bo'lmasa, bu sizning ma'lumotlaringizni berganingizni anglatadi. metama'lumotlarning hech qanday qismisiz javob bering.
Keyinchalik, ilovalarni ishga tushirishda bizda og'riqli muammolar mavjud.
Aslida, bu nafaqat Kubernetesga, balki umuman olganda, qandaydir ommaviy rivojlanish madaniyati va xususan DevOps Kubernetes bilan bir vaqtda tarqala boshladi. Shuning uchun, umuman olganda, siz Kubernetessiz ilovangizni chiroyli tarzda o'chirib qo'yishingiz kerak bo'ladi. Kubernetesdan oldin ham odamlar buni qilishgan, ammo Kubernetes paydo bo'lishi bilan biz bu haqda ommaviy gapira boshladik.
Chiroyli o'chirish
Umuman olganda, Graceful Shutdown nima va u nima uchun kerak? Bu sizning ilovangiz biron sababga ko'ra ishlamay qolganda, buni qilishingiz kerak app stop - yoki siz, masalan, operatsion tizimdan signal olasiz, ilovangiz buni tushunishi va bu haqda biror narsa qilishi kerak. Albatta, eng yomon stsenariy bu sizning arizangiz SIGTERMni olganida va "SIGTERM, keling, kutamiz, ishlaymiz, hech narsa qilmang" kabi bo'ladi. Bu mutlaqo yomon variant.
Deyarli bir xil yomon variant - bu sizning arizangiz SIGTERM-ni olganida va "ular segterm deyishdi, ya'ni biz tugatyapmiz, men ko'rmadim, foydalanuvchi so'rovlarini bilmayman, qanday turdagi ekanligini bilmayman. Men hozir ishlayotgan so'rovlar, ular SIGTERM deyishdi, bu biz tugatayotganimizni anglatadi " Bu ham yomon variant.
Qaysi variant yaxshi? Birinchi nuqta - operatsiyalarni bajarishni hisobga olish. Yaxshi variant, agar serveringiz SIGTERM qabul qilsa, nima qilishini hisobga olishi kerak.
SIGTERM - bu yumshoq o'chirish, u maxsus ishlab chiqilgan, uni kod darajasida ushlab turish mumkin, uni qayta ishlash mumkin, ayting, hozir kuting, avval bizda mavjud bo'lgan ishni tugatamiz, keyin biz chiqamiz.
Kubernetes nuqtai nazaridan, bu shunday ko'rinadi. Kubernetes klasterida ishlayotgan podkastga “iltimos, to‘xtating, keting” desak yoki biz qayta ishga tushamiz yoki Kubernetes podkastlarni qayta yaratganda yangilanish sodir bo‘lsa, Kubernetes podkastga xuddi shu SIGTERM xabarini yuboradi va kutadi. bir oz vaqt, va , bu u kutayotgan vaqt, u ham sozlangan, diplomlarda shunday maxsus parametr mavjud va u Graceful ShutdownTimeout deb ataladi. Siz tushunganingizdek, bu bejiz aytilmagan va biz hozir bu haqda gaplashayotganimiz ham bejiz emas.
U erda biz SIGTERM-ni ilovaga jo'natganimizdan va dastur biror narsa uchun aqldan ozganga o'xshaydi yoki "yopishib qolgan" va tugamasligini tushunganimizda qancha vaqt kutishimiz kerakligini aniq aytishimiz mumkin - va biz buni qilishimiz kerak. uni SIGKILL yuboring, ya'ni uning ishini qiyin yakunlang. Ya'ni, shunga ko'ra, bizda ishlaydigan qandaydir demon bor, u operatsiyalarni qayta ishlaydi. Biz tushunamizki, demon ishlaydigan operatsiyalarimiz bir vaqtning o'zida o'rtacha 30 soniyadan ortiq davom etmaydi. Shunga ko'ra, SIGTERM kelganida, biz demonimiz SIGTERMdan 30 soniyadan keyin tugatishi mumkinligini tushunamiz. Biz buni, masalan, 45 soniyani har qanday holatda yozamiz va SIGTERM deb aytamiz. Shundan so'ng biz 45 soniya kutamiz. Nazariy jihatdan, bu vaqt ichida jin o'z ishini tugatib, o'zini tugatishi kerak edi. Ammo, agar to'satdan buni qila olmasa, demak u tiqilib qolgan bo'lishi mumkin - u endi bizning so'rovlarimizga odatdagidek ishlov bermayapti. Va 45 soniya ichida siz xavfsiz tarzda, aslida, uni mixlashingiz mumkin.
Va bu erda, aslida, hatto 2 jihatni ham hisobga olish mumkin. Birinchidan, tushuningki, agar siz so'rov olgan bo'lsangiz, u bilan qandaydir tarzda ishlay boshladingiz va foydalanuvchiga javob bermadingiz, lekin siz, masalan, SIGTERMni oldingiz. Uni takomillashtirish va foydalanuvchiga javob berish mantiqan. Bu boradagi birinchi nuqta. Bu erda ikkinchi nuqta shundan iboratki, agar siz o'zingizning arizangizni yozsangiz, odatda arxitekturani shunday tuzingki, sizga ilovangiz uchun so'rov keladi, keyin siz biron bir ishni boshlaysiz, biron bir joydan fayllarni yuklab olishni, ma'lumotlar bazasini yuklab olishni boshlaysiz va hokazo. - Bu. Umuman olganda, sizning foydalanuvchi, so'rovingiz yarim soat davomida osilib turadi va unga javob berishingizni kutadi - keyin, ehtimol, siz arxitektura ustida ishlashingiz kerak. Ya'ni, agar sizning operatsiyalaringiz qisqa bo'lsa, SIGTERMni e'tiborsiz qoldirish va uni o'zgartirish mantiqiy ekanligini hisobga oling. Agar sizning operatsiyalaringiz uzoq bo'lsa, unda bu holda SIGTERMni e'tiborsiz qoldirishning ma'nosi yo'q. Bunday uzoq operatsiyalarni oldini olish uchun arxitekturani qayta loyihalash mantiqan. Shunday qilib, foydalanuvchilar shunchaki o'tirib, kutishmaydi. Bilmayman, u yerda qandaydir veb-rozetka yasang, serveringiz mijozga yuboradigan teskari ilgaklarni yarating, boshqa har qanday narsa, lekin foydalanuvchini yarim soat osib qo'yishga majburlamang va seansni kuting. unga javob bering. Chunki uning qayerda buzilishini oldindan aytib bo'lmaydi.
Ilovangiz tugagach, tegishli chiqish kodini taqdim etishingiz kerak. Ya'ni, agar sizning arizangizni yopish, to'xtatish so'ralgan bo'lsa va u odatdagidek o'zini to'xtata olgan bo'lsa, unda siz 1,5,255 va hokazo chiqish kodini qaytarishingiz shart emas. Nol kodi bo'lmagan har qanday narsa, hech bo'lmaganda Linux tizimlarida, men bunga aminman, muvaffaqiyatsiz deb hisoblanadi. Ya'ni, bu holda sizning arizangiz xato bilan yakunlangan deb hisoblanadi. Shunga ko'ra, do'stona tarzda, agar sizning arizangiz xatosiz yakunlangan bo'lsa, siz chiqishda 0 deb aytasiz. Agar arizangiz biron sababga ko'ra muvaffaqiyatsiz bo'lsa, siz chiqishda 0 emas deb aytasiz. Va siz ushbu ma'lumot bilan ishlashingiz mumkin.
Va oxirgi variant. Agar foydalanuvchi so'rov yuborsa va uni qayta ishlash paytida yarim soat davomida osib qo'ysa, bu yomon. Ammo umuman olganda, men mijoz tomonidan nimaga arziydiganligi haqida ham aytmoqchiman. Sizda mobil ilova, front-end va boshqalar bormi, muhim emas. Shuni inobatga olish kerakki, umuman olganda, foydalanuvchi seansi tugatilishi mumkin, hamma narsa sodir bo'lishi mumkin. So'rov yuborilishi mumkin, masalan, to'liq ishlov berilmagan va javob qaytarilmagan. Sizning old qismingiz yoki mobil ilovangiz - umuman olganda, har qanday frontend, keling, buni hisobga olish kerak. Agar siz veb-rozetkalar bilan ishlasangiz, bu men boshdan kechirgan eng yomon og'riqdir.
Ba'zi oddiy chatlarni ishlab chiquvchilar buni bilmasalar, veb-rozet buzilib ketishi mumkin. Ular uchun proksi-serverda biror narsa sodir bo'lganda, biz faqat konfiguratsiyani o'zgartiramiz va u qayta yuklanadi. Tabiiyki, bu holatda barcha uzoq muddatli sessiyalar yirtilgan. Ishlab chiquvchilar bizga yugurib kelib: "Bolalar, nima qilyapsizlar, barcha mijozlarimiz uchun chat buzildi!" Biz ularga: “Nima qilyapsan? Mijozlaringiz qayta ulana olmayaptimi? Ular: "Yo'q, sessiyalar yirtilmasligi kerak", deyishadi. Qisqasi, bu aslida bema'nilik. Mijoz tomonini hisobga olish kerak. Ayniqsa, men aytganimdek, websockets kabi uzoq muddatli seanslar bilan u buzilishi mumkin va foydalanuvchi sezmagan holda siz bunday seanslarni qayta o'rnatishingiz kerak bo'ladi. Va keyin hamma narsa mukammal bo'ladi.
Resurslar
Aslida, bu erda men sizga to'g'ridan-to'g'ri voqeani aytib beraman. Yana real hayotdan. Resurslar haqida eshitgan eng yomon narsa.
Bu holda manbalar, aytmoqchimanki, siz Kubernetes klasterlaringizdagi podkalarga qo'yishingiz mumkin bo'lgan so'rovlar, cheklovlar. Ishlab chiquvchidan eshitgan eng kulgili gap... Oldingi ish joyidagi dasturchi hamkasblarimdan biri bir kuni shunday degan edi: “Mening ilovam klasterda ishga tushmaydi”. Men bu boshlanmayotganini ko'rdim, lekin u resurslarga to'g'ri kelmadi yoki ular juda kichik chegaralar qo'yishdi. Muxtasar qilib aytganda, dastur resurslar tufayli ishga tusha olmaydi. Men aytaman: "Resurslar tufayli boshlanmaydi, siz qancha kerakligini o'zingiz hal qilasiz va adekvat qiymatni belgilaysiz." U shunday deydi: "Qanday manbalar?" Men unga Kubernetes, so'rovlar bo'yicha cheklovlar va blah, blah, blah o'rnatilishi kerakligini tushuntira boshladim. Erkak besh daqiqa tingladi, bosh irg'adi va dedi: "Men bu erga ishlab chiquvchi sifatida ishlash uchun keldim, men hech qanday manbalar haqida hech narsa bilishni xohlamayman. Men bu yerga kod yozish uchun keldim va tamom." Bu achinarli. Bu ishlab chiquvchi nuqtai nazaridan juda achinarli tushuncha. Ayniqsa, zamonaviy dunyoda, ta'bir joiz bo'lsa, ilg'or devoplar.
Nima uchun resurslar umuman kerak? Kubernetesda 2 turdagi resurslar mavjud. Ba'zilari so'rovlar, boshqalari esa chegaralar deb ataladi. Resurslardan biz tushunamizki, asosan, har doim faqat ikkita asosiy cheklovlar mavjud. Ya'ni, Kubernetesda ishlaydigan konteyner uchun CPU vaqt chegaralari va RAM cheklovlari.
Cheklov sizning ilovangizda resursdan qanday foydalanish mumkinligiga yuqori chegara qo'yadi. Ya'ni, shunga ko'ra, agar siz chegaralarda 1 Gb RAM desangiz, u holda sizning ilovangiz 1 Gb dan ortiq RAMdan foydalana olmaydi. Va agar u birdan xohlasa va buni amalga oshirishga harakat qilsa, u holda oom killer deb ataladigan, xotiradan chiqib ketgan, ya'ni sizning arizangizni o'ldiradigan jarayon keladi - ya'ni u shunchaki qayta ishga tushadi. Ilovalar CPU asosida qayta ishga tushmaydi. CPU nuqtai nazaridan, agar dastur chegaralarda ko'rsatilganidan ko'proq foydalanishga harakat qilsa, protsessor shunchaki qat'iy tanlanadi. Bu qayta ishga tushirishga olib kelmaydi. Bu chegara - bu yuqori chegara.
Va iltimos bor. So'rov - bu Kubernetes sizning Kubernetes klasteringizdagi tugunlar ilovalar bilan qanday to'ldirilganligini qanday tushunishidir. Ya'ni, so'rov sizning arizangizning o'ziga xos majburiyatidir. Unda men foydalanmoqchi bo'lgan narsa aytiladi: "Men uchun shuncha ko'p protsessor va shuncha xotirani zaxiralashingizni xohlayman." Bunday oddiy analogiya. Agar bizda jami 8 ta protsessor bo'lgan tugun bo'lsa-chi, men bilmayman. Va u erga pod keladi, uning so'rovlarida 1 protsessor, ya'ni tugunda 7 ta protsessor qolgan. Ya'ni, shunga ko'ra, har birining so'rovlarida 8 protsessor bo'lgan ushbu tugunga 1 ta podkast kelishi bilanoq, tugun, xuddi Kubernetes nuqtai nazaridan, protsessor tugab qolgan va so'rovlari bo'lgan ko'proq podkastlar bo'lishi mumkin emas. ushbu tugunda ishga tushirildi. Agar barcha tugunlarda protsessor tugasa, Kubernetes klasterda protsessor tugab qolganligi sababli podkastlaringizni ishga tushirish uchun mos tugunlar yo‘qligini aytishni boshlaydi.
Nima uchun so'rovlar kerak va nima uchun so'rovlarsiz, menimcha, Kubernetesda hech narsa ishga tushirishning hojati yo'q? Keling, gipotetik vaziyatni tasavvur qilaylik. Siz ilovangizni so'rovlarsiz ishga tushirasiz, Kubernetes sizda qancha narsa borligini, uni qaysi tugunlarga bosishingiz mumkinligini bilmaydi. Xo'sh, u tugunlarga itaradi, silkitadi, suradi. Bir nuqtada siz ilovangizga trafik olishni boshlaysiz. Va ilovalardan biri to'satdan resurslardan chegaralarga ko'ra ega bo'lgan chegaralargacha foydalana boshlaydi. Ma'lum bo'lishicha, yaqin atrofda boshqa dastur bor va u ham resurslarga muhtoj. Tugun aslida resurslardan jismoniy tugashni boshlaydi, masalan, OP. Tugun aslida resurslardan jismoniy tugashni boshlaydi, masalan, tasodifiy kirish xotirasi (RAM). Tugun quvvati tugagach, birinchi navbatda docker javob berishni to'xtatadi, keyin kubelet, keyin esa OS. Ular shunchaki hushidan ketishadi va HAMMA siz uchun ishlashni to'xtatadi. Ya'ni, bu sizning tuguningiz tiqilib qolishiga olib keladi va siz uni qayta ishga tushirishingiz kerak bo'ladi. Qisqasi, vaziyat unchalik yaxshi emas.
Va agar sizda so'rovlar bo'lsa, chegaralar unchalik farq qilmaydi, hech bo'lmaganda chegaralar yoki so'rovlardan ko'p marta ko'p bo'lmasa, Kubernetes klasterlari tugunlari bo'ylab ilovalarni oddiy, oqilona to'ldirishingiz mumkin. Shu bilan birga, Kubernetes taxminan qancha narsani qayerga qo'yishi, qanchasi qayerda ishlatilishini biladi. Ya'ni, bu shunchaki bir lahza. Buni tushunish muhimdir. Va bu ko'rsatilganligini nazorat qilish muhimdir.
Ma'lumotlarni saqlash
Bizning keyingi fikrimiz ma'lumotlarni saqlash haqida. Ular bilan nima qilish kerak va umuman, Kubernetesda qat'iylik bilan nima qilish kerak?
O'ylaymanki, yana bizning ichimizda , Kubernetesda ma'lumotlar bazasi haqida mavzu bor edi. Menimcha, men hamkasblaringiz sizga: "Kubernetesda ma'lumotlar bazasini ishga tushirish mumkinmi?" Degan so'raganlarini taxminan bilaman. Negadir, mening hamkasblaringiz sizga Kubernetesda ma'lumotlar bazasini ishga tushirish mumkinmi degan savolni bersangiz, buning iloji yo'qligini aytishlari kerak edi.
Bu erda mantiq oddiy. Har holda, men yana bir bor tushuntirib beraman, agar siz haqiqatan ham juda zo'r yigit bo'lsangiz, u taqsimlangan tarmoq xotirasining nosozliklarga chidamli tizimini qura oladigan bo'lsangiz, ma'lumotlar bazasini bu holatda qanday joylashtirishni tushuning, konteynerlardagi bulut qanday ishlashini tushuning. umumiy ma'lumotlar bazasida. Katta ehtimol bilan, sizda uni qanday ishlatish haqida hech qanday savol yo'q. Agar sizda shunday savol bo'lsa va siz ishlab chiqarishda hammasi ochilib, o'limgacha turishiga va hech qachon tushmasligiga ishonch hosil qilishni istasangiz, unda bu sodir bo'lmaydi. Ushbu yondashuv bilan o'zingizni oyog'ingizga otish kafolatlanadi. Shuning uchun qilmaslik yaxshiroqdir.
Ilovamiz saqlamoqchi bo'lgan ma'lumotlar, foydalanuvchilar yuklaydigan ba'zi rasmlar, ilovamiz ishga tushirish paytida yaratadigan ba'zi narsalar bilan nima qilishimiz kerak? Kubernetesda ular bilan nima qilish kerak?
Umuman olganda, ideal holda, ha, albatta, Kubernetes juda yaxshi ishlab chiqilgan va odatda fuqaroligi bo'lmagan ilovalar uchun ishlab chiqilgan. Ya'ni, umuman ma'lumot saqlamaydigan ilovalar uchun. Bu ideal.
Lekin, albatta, ideal variant har doim ham mavjud emas. Xo'sh? Birinchi va eng oddiy nuqta, qandaydir S3 ni olishdir, faqat uy qurilishi emas, u qanday ishlashi ham noma'lum, lekin ba'zi provayderdan. Yaxshi, oddiy provayder - va ilovangizga S3 dan foydalanishni o'rgating. Ya'ni, foydalanuvchi faylni yuklamoqchi bo'lganda, "bu erda, iltimos, uni S3-ga yuklang" deb ayting. U uni olmoqchi bo'lganida, ayting: "Mana, S3 ga havola va uni bu yerdan oling." Bu ideal.
Agar to'satdan biron bir sababga ko'ra ushbu ideal variant mos kelmasa, sizda siz yozmagan, ishlab chiqmagan yoki qandaydir dahshatli meros bo'lgan ilovangiz bo'lsa, u S3 protokolidan foydalana olmaydi, lekin mahalliy kataloglar bilan ishlashi kerak. mahalliy papkalar. Ko'proq yoki kamroq oddiy narsani oling, Kubernetes-ni joylashtiring. Ya'ni, Cefni minimal vazifalar uchun darhol qilichbozlik qilish, menimcha, yomon fikr. Chunki Ceph, albatta, yaxshi va moda. Ammo agar siz nima qilayotganingizni tushunmasangiz, Cefga biror narsa qo'yganingizdan so'ng, siz juda oson va shunchaki uni boshqa hech qachon olib tashlamaysiz. Chunki, siz bilganingizdek, Ceph o'z klasteridagi ma'lumotlarni oddiy fayllar ko'rinishida emas, balki ikkilik shaklda saqlaydi. Shuning uchun, agar to'satdan Ceph klasteri buzilib qolsa, u holda siz boshqa hech qachon ma'lumotlaringizni olmaysiz degan to'liq va yuqori ehtimollik bor.
Bizda Ceph bo'yicha kurs bo'ladi, mumkin .
Shuning uchun, NFS serveri kabi oddiy narsani qilish yaxshiroqdir. Kubernetes ular bilan ishlashi mumkin, siz NFS serveri ostida katalog o'rnatishingiz mumkin - ilovangiz xuddi mahalliy katalogga o'xshaydi. Shu bilan birga, tabiiyki, siz yana NFS bilan biror narsa qilishingiz kerakligini tushunishingiz kerak, ba'zida unga kirish imkonsiz bo'lib qolishi mumkinligini tushunishingiz kerak va bu holda nima qilish kerakligi haqidagi savolni ko'rib chiqishingiz kerak. Ehtimol, uni alohida mashinada bir joyda zaxiralash kerak.
Men gapirgan keyingi nuqta, agar ilovangiz ish paytida ba'zi fayllarni yaratsa nima qilish kerak. Misol uchun, u ishga tushirilganda, u dastur faqat ishga tushirish vaqtida oladigan ba'zi ma'lumotlarga asoslangan ba'zi statik faylni yaratadi. Qanday daqiqa. Agar bunday ma'lumotlar ko'p bo'lmasa, unda siz umuman bezovta qilishingiz shart emas, faqat ushbu dasturni o'zingiz uchun o'rnating va ishlang. Bu erda yagona savol nima, qarang. Ko'pincha, WordPress va boshqalar kabi barcha turdagi eski tizimlar, ayniqsa o'zgartirilgan ayyor plaginlar, ayyor PHP ishlab chiquvchilari bilan ular ko'pincha o'zlari uchun qandaydir fayl yaratish uchun uni qanday qilishni bilishadi. Shunga ko'ra, biri bitta faylni, ikkinchisi ikkinchi faylni yaratadi. Ular boshqacha. Mijozlarning Kubernetes klasterida muvozanat tasodifan sodir bo'ladi. Shunga ko'ra, ular misol uchun qanday qilib birgalikda ishlashni bilishmaydi. Biri bitta ma'lumotni beradi, ikkinchisi foydalanuvchiga boshqa ma'lumot beradi. Bu siz qochishingiz kerak bo'lgan narsadir. Ya'ni, Kubernetes-da siz ishga tushirgan hamma narsa bir nechta holatlarda ishlashi kafolatlanadi. Chunki Kubernetes harakatlanuvchi narsadir. Shunga ko'ra, u xohlagan vaqtda, hech kimdan so'ramasdan, har qanday narsani ko'chirishi mumkin. Shuning uchun, siz bunga ishonishingiz kerak. Bir misolda ishga tushirilgan hamma narsa ertami-kechmi muvaffaqiyatsiz bo'ladi. Qanchalik ko'p bandlovlar bo'lsa, shuncha yaxshi. Ammo yana aytamanki, agar sizda bir nechta bunday fayllar bo'lsa, ularni to'g'ridan-to'g'ri ostiga qo'yishingiz mumkin, ular oz miqdorda tortishadi. Agar ulardan bir oz ko'proq bo'lsa, ehtimol siz ularni idishning ichiga itarib yubormasligingiz kerak.
Men Kubernetesda shunday ajoyib narsa borligini maslahat beraman, siz hajmdan foydalanishingiz mumkin. Xususan, bo'sh dir tipidagi hajm mavjud. Ya'ni, Kubernetes siz boshlagan serverda avtomatik ravishda o'z xizmat kataloglarida katalog yaratadi. Va siz undan foydalanishingiz uchun uni sizga beradi. Faqat bitta muhim nuqta bor. Ya'ni, sizning ma'lumotlaringiz konteyner ichida emas, balki siz ishlayotgan xostda saqlanadi. Bundan tashqari, Kubernetes bunday bo'sh dirslarni oddiy konfiguratsiyada boshqarishi mumkin va ularning maksimal hajmini nazorat qila oladi va undan oshib ketishiga yo'l qo'ymaydi. Bitta nuqta shundaki, siz bo'sh direktda yozgan narsangiz pod qayta ishga tushirilganda yo'qolmaydi. Ya'ni, agar sizning podingiz xatolik bilan tushib qolsa va yana ko'tarilsa, bo'sh dirdagi ma'lumotlar hech qaerga ketmaydi. U uni yangi boshida yana ishlatishi mumkin - va bu yaxshi. Agar sizning podingiz biror joyga ketsa, u tabiiy ravishda ma'lumotsiz ketadi. Ya'ni, bo'sh dir bilan ishga tushirilgan tugunning podasi yo'qolishi bilanoq, bo'sh dir o'chiriladi.
Bo'sh dirijyorning yana nimasi yaxshi? Masalan, u kesh sifatida ishlatilishi mumkin. Tasavvur qilaylik, bizning ilovamiz tezda biror narsani yaratadi, uni foydalanuvchilarga beradi va buni uzoq vaqt bajaradi. Shuning uchun, masalan, dastur uni yaratadi va foydalanuvchilarga beradi va shu bilan birga uni biron bir joyda saqlaydi, shunda foydalanuvchi keyingi safar xuddi shu narsa uchun kelganida, uni darhol hosil qilish uchun tezroq bo'ladi. Kubernetesdan xotirada yaratish uchun bo'sh direktorni so'rash mumkin. Shunday qilib, sizning keshlaringiz odatda chaqmoq tezligida ishlashi mumkin - diskka kirish tezligi nuqtai nazaridan. Ya'ni sizning xotirangizda bo'sh dir bor, OTda u xotirada saqlanadi, lekin siz uchun, pod ichidagi foydalanuvchi uchun u faqat mahalliy katalogga o'xshaydi. Hech qanday sehrni o'rgatish uchun sizga ilova kerak emas. Siz shunchaki faylingizni to'g'ridan-to'g'ri olib, katalogga joylashtirasiz, lekin aslida OS xotirasida. Bu ham Kubernetes nuqtai nazaridan juda qulay xususiyatdir.
Minioda qanday muammolar bor? Minio bilan bog'liq asosiy muammo shundaki, bu narsa ishlashi uchun u biror joyda ishlayotgan bo'lishi kerak va u erda qandaydir fayl tizimi, ya'ni saqlash bo'lishi kerak. Va bu erda biz Sef bilan bir xil muammolarga duch kelamiz. Ya'ni, Minio o'z fayllarini biror joyda saqlashi kerak. Bu shunchaki fayllaringizga HTTP interfeysi. Bundan tashqari, funksionallik Amazon S3-ga qaraganda ancha yomonroq. Ilgari u foydalanuvchini to'g'ri avtorizatsiya qila olmagan. Endi, men bilganimdek, u allaqachon turli xil avtorizatsiyalarga ega chelaklarni yaratishi mumkin, ammo yana menimcha, asosiy muammo, aytganda, asosiy saqlash tizimida.
Xotiradagi Empty dir limitlarga qanday ta'sir qiladi? Hech qanday tarzda cheklovlarga ta'sir qilmaydi. Bu sizning konteyneringiz xotirasida emas, balki uy egasining xotirasida yotadi. Ya'ni, sizning konteyneringiz xotiradagi bo'sh direktorni ishg'ol qilingan xotiraning bir qismi sifatida ko'rmaydi. Uy egasi buni ko'radi. Shunga ko'ra, ha, kubernetlar nuqtai nazaridan, siz undan foydalanishni boshlaganingizda, xotirangizning bir qismini bo'sh diraga bag'ishlayotganingizni tushunish yaxshi bo'lar edi. Va shunga ko'ra, xotira nafaqat ilovalar tufayli, balki kimdir bu bo'sh dirslarga yozganligi sababli ham tugashi mumkinligini tushuning.
Bulutlilik
Va yakuniy submavzu - Cloudnative nima. Nima uchun kerak? Bulutlilik va boshqalar.
Ya'ni, zamonaviy bulut infratuzilmasida ishlashga qodir va yozilgan ilovalar. Lekin, aslida, Cloudnative yana bir shunday jihatga ega. Bu nafaqat zamonaviy bulut infratuzilmasining barcha talablarini inobatga oladigan dastur, balki ushbu zamonaviy bulut infratuzilmasi bilan qanday ishlashni, uning ushbu bulutlarda ishlashining afzalliklari va kamchiliklaridan foydalanishni ham biladi. Haddan oshib, bulutlarda ishlamang, balki bulutda ishlashning afzalliklaridan foydalaning.
Misol tariqasida Kubernetesni olaylik. Ilovangiz Kubernetesda ishlamoqda. Ilovangiz har doim, aniqrogʻi ilovangizning administratorlari har doim xizmat hisobini yaratishi mumkin. Ya'ni, Kubernetesning o'zida o'z serverida avtorizatsiya uchun hisob. U erda bizga kerakli huquqlarni qo'shing. Va siz Kubernetes-ga ilovangizdan kirishingiz mumkin. Bu tarzda nima qila olasiz? Misol uchun, ilovadan boshqa ilovalaringiz, boshqa shunga o'xshash misollaringiz qaerda joylashganligi va agar kerak bo'lsa, qandaydir tarzda Kubernetes tepasida joylashganligi haqida ma'lumot oling.
Shunga qaramay, yaqinda bizda bir ish bor edi. Bizda navbatni kuzatadigan bitta nazoratchi bor. Va bu navbatda ba'zi yangi vazifalar paydo bo'lganda, u Kubernetesga o'tadi - va Kubernetes ichida u yangi podkastni yaratadi. Bu podka yangi vazifani beradi va bu pod doirasida pod vazifani bajaradi, boshqaruvchining o'ziga javob yuboradi va keyin boshqaruvchi bu ma'lumot bilan biror narsa qiladi. Masalan, u ma'lumotlar bazasini qo'shadi. Ya'ni, yana bir bor, bu bizning ilovamiz Kubernetes-da ishlashining ortiqcha tomoni. Ilovamizning funksionalligini qandaydir tarzda kengaytirish va qulayroq qilish uchun biz o'rnatilgan Kubernetes funksiyasidan foydalanishimiz mumkin. Ya'ni, dasturni qanday ishga tushirish, ishchini qanday ishga tushirish haqida qandaydir sehrni yashirmang. Kubernetes-da, agar dastur Python-da yozilgan bo'lsa, siz shunchaki ilovaga so'rov yuborasiz.
Agar biz Kubernetesdan tashqariga chiqsak ham xuddi shunday. Bizning Kubernetlarimiz biror joyda ishlaydi - agar u qandaydir bulutda bo'lsa yaxshi bo'ladi. Shunga qaramay, biz ishlayotgan joyda bulutning imkoniyatlaridan foydalanishimiz mumkin va hatto foydalanishimiz kerak, deb o'ylayman. Bulut bizga beradigan oddiy narsalardan. Balanslash, ya'ni biz bulut balanslagichlarini yaratishimiz va ulardan foydalanishimiz mumkin. Bu biz foydalanishimiz mumkin bo'lgan to'g'ridan-to'g'ri afzallik. Chunki bulut balansi, birinchidan, uning qanday ishlashi, qanday sozlanganligi uchun javobgarlikni bizdan ahmoqona olib tashlaydi. Bundan tashqari, bu juda qulay, chunki oddiy Kubernetes bulutlar bilan birlashishi mumkin.
Xuddi shu narsa masshtablash uchun ham amal qiladi. Oddiy Kubernetes bulutli provayderlar bilan integratsiyalashishi mumkin. Agar klasterda tugunlar tugasa, ya'ni tugun maydoni tugasa, siz qo'shishingiz kerakligini qanday tushunishni biladi - Kubernetesning o'zi sizning klasteringizga yangi tugunlar qo'shadi va ular ustida podkastlarni ishga tushirishni boshlaydi. Ya'ni yuking kelganda o'choqlar ko'payib keta boshlaydi. Klasterdagi tugunlar ushbu podalar uchun tugasa, Kubernetes yangi tugunlarni ishga tushiradi va shunga mos ravishda podalar soni hali ham ko'payishi mumkin. Va bu juda qulay. Bu klasterni tezda kengaytirish uchun to'g'ridan-to'g'ri imkoniyatdir. Juda tez emas, bu bir soniya emas, balki yangi tugunlarni qo'shish uchun bir daqiqaga o'xshaydi.
Ammo mening tajribamdan yana, bu men ko'rgan eng zo'r narsadir. Cloudnative klasteri kunning vaqtiga qarab o'lchaganida. Bu orqa ofisdagi odamlar tomonidan ishlatiladigan backend xizmati edi. Ya'ni, ular ertalab soat 9 da ishga kelishadi, tizimga kirishni boshlaydilar va shunga mos ravishda hammasi ishlayotgan Cloudnative klasteri shishib, ishga kelgan har bir kishi dastur bilan ishlashi uchun yangi podlarni ishga tushira boshlaydi. Ular 8:6 yoki 30:XNUMX da ishdan ketganlarida, Kubernetes klasterlari ilovadan boshqa hech kim foydalanmayotganini payqashadi va qisqarishni boshlaydilar. XNUMX foizgacha tejash kafolatlanadi. O'sha paytda u Amazonda ishlagan; o'sha paytda Rossiyada buni yaxshi qila oladigan hech kim yo'q edi.
Sizga to'g'ridan-to'g'ri aytaman, tejamkorlik 30 foizni tashkil etadi, chunki biz Kubernetes-dan foydalanamiz va bulutning imkoniyatlaridan foydalanamiz. Endi buni Rossiyada qilish mumkin. Men hech kimga reklama qilmayman, albatta, lekin aytaylik, buni qila oladigan provayderlar bor, uni tugmachadan tashqarida taqdim eting.
Oxirgi bir jihatga ham e'tiboringizni qaratmoqchiman. Ilovangiz, infratuzilmangiz bulutli bo‘lishi uchun nihoyat Infratuzilma deb nomlangan yondashuvni kod sifatida moslashtirishni boshlash mantiqan to‘g‘ri keladi.Ya’ni, sizning ilovangiz, to‘g‘rirog‘i, infratuzilmangiz xuddi shu tarzda kerak bo‘ladi. kod Ilovangizni, biznes mantiqingizni kod shaklida tasvirlab bering. Va u bilan kod sifatida ishlang, ya'ni uni sinab ko'ring, chiqaring, git-da saqlang, unga CICD-ni qo'llang.
Aynan shu narsa, birinchi navbatda, infratuzilmangizni doimo nazorat qilish, uning qanday holatda ekanligini tushunish imkonini beradi. Ikkinchidan, xatolarga olib keladigan qo'lda operatsiyalardan qoching. Uchinchidan, siz doimo bir xil qo'lda vazifalarni bajarishingiz kerak bo'lganda, aylanma deb ataladigan narsadan qoching. To'rtinchidan, bu sizga muvaffaqiyatsizlikka uchragan taqdirda tezroq tiklanish imkonini beradi. Rossiyada har safar men bu haqda gapirganimda, har doim juda ko'p odamlar bor: "Ha, bu aniq, lekin sizda yondashuvlar bor, qisqasi, hech narsani tuzatishga hojat yo'q". Lekin bu haqiqat. Agar infratuzilmangizda biror narsa buzilgan bo'lsa, Cloudnative yondashuvi nuqtai nazaridan va Infratuzilmani Kodeks sifatida ko'rib chiqsangiz, uni tuzatish, serverga borish, nima buzilganligini aniqlash va uni tuzatish osonroq. serverni o'chirish va uni qayta yaratish uchun. Va bularning barchasini qayta tiklayman.
Bu masalalarning barchasi ushbu sahifada batafsilroq muhokama qilinadi . Havola orqali dastur va shartlar bilan tanishishingiz mumkin. Qulay tomoni shundaki, siz uyda yoki kuniga 1-2 soat ishlash orqali Kubernetesni o'rganishingiz mumkin.
Manba: www.habr.com