Ko'pchilik dasturni Kubernetesga o'tkazish kifoya deb o'ylaydi (Helm yordamida yoki qo'lda) - va baxt bo'ladi. Lekin hamma narsa juda oddiy emas.
komanda DevOps muhandisi Julian Gindining maqolasini tarjima qildi. U o'z kompaniyasi migratsiya jarayonida qanday tuzoqlarga duch kelganini aytadi, shunda siz bir xil rakega qadam qo'ymaysiz.
Birinchi qadam: Pod so'rovlari va cheklovlarini o'rnating
Keling, bizning podalar ishlaydigan toza muhitni o'rnatishdan boshlaylik. Kubernetes podlarni rejalashtirish va o'chirishda ajoyib. Ammo ma'lum bo'lishicha, rejalashtiruvchi ba'zan muvaffaqiyatli ishlashi uchun qancha resurslar kerakligini hisoblash qiyin bo'lsa, podkastni joylashtira olmaydi. Bu erda resurslar va cheklovlar uchun so'rovlar paydo bo'ladi. So'rovlar va cheklovlarni belgilashning eng yaxshi yondashuvi haqida ko'p bahs-munozaralar mavjud. Ba'zida bu fandan ko'ra ko'proq san'atga o'xshaydi. Mana bizning yondashuvimiz.
Pod so'rovlari podani optimal joylashtirish uchun rejalashtiruvchi tomonidan ishlatiladigan asosiy qiymatdir.
dan : Filtrlash bosqichi Podni rejalashtirish mumkin bo'lgan tugunlar to'plamini belgilaydi. Masalan, PodFitsResources filtri tugunning poddan ma'lum resurs so'rovlarini qondirish uchun etarli resurslarga ega yoki yo'qligini tekshiradi.
Biz dastur so'rovlaridan qancha resurslarni taxmin qilishimiz mumkin bo'lgan tarzda foydalanamiz aslida Ilova to'g'ri ishlashi uchun unga kerak. Shunday qilib, rejalashtiruvchi tugunlarni real tarzda joylashtirishi mumkin. Dastlab, biz har bir Pod uchun yetarli resurslarni taʼminlash uchun soʻrovlarni ortiqcha rejalashtirishni xohladik, lekin biz rejalashtirish vaqti sezilarli darajada oshganini va baʼzi Podlar toʻliq rejalashtirilmaganini payqadik, goʻyo ular uchun resurs soʻrovlari yoʻq edi.
Bunday holda, rejalashtiruvchi ko'pincha podkalarni "siqib chiqaradi" va ularni qayta rejalashtirishga qodir emas edi, chunki boshqaruv tekisligi dastur uchun qancha resurslar kerakligini bilmas edi, bu rejalashtirish algoritmining asosiy komponentidir.
Pod chegaralari pod uchun aniqroq chegara hisoblanadi. Bu klaster konteynerga ajratadigan maksimal resurslar miqdorini ifodalaydi.
Yana, dan : Agar konteynerda xotira chegarasi 4 GiB bo'lsa, kubelet (va konteynerning ishlash vaqti) uni amalga oshiradi. Ish vaqti konteynerning belgilangan resurs chegarasidan ko'proq foydalanishiga yo'l qo'ymaydi. Misol uchun, konteynerdagi jarayon ruxsat etilgan xotira hajmidan ko'proq foydalanishga harakat qilganda, tizim yadrosi jarayonni "xotira tugadi" (OOM) xatosi bilan tugatadi.
Konteyner har doim resurs so'rovida ko'rsatilganidan ko'proq resurslardan foydalanishi mumkin, lekin u hech qachon chegaradan ortiq foydalana olmaydi. Ushbu qiymatni to'g'ri belgilash qiyin, lekin bu juda muhim.
Ideal holda, biz podkastlarning resurslarga bo'lgan talablari jarayonning hayot aylanishi davomida tizimdagi boshqa jarayonlarga aralashmasdan o'zgarishini xohlaymiz - bu chegaralarni belgilashdan maqsad.
Afsuski, men qanday qiymatlarni belgilash bo'yicha aniq ko'rsatmalar bera olmayman, lekin biz o'zimiz quyidagi qoidalarga amal qilamiz:
- Yukni sinab ko'rish vositasidan foydalanib, biz trafikning asosiy darajasini simulyatsiya qilamiz va pod resurslaridan (xotira va protsessor) foydalanishni kuzatamiz.
- Pod so'rovlarini o'zboshimchalik bilan past qiymatga o'rnating (resurs chegarasi so'rovlar qiymatidan taxminan 5 baravar ko'p) va kuzating. So'rovlar juda past darajada bo'lsa, jarayon boshlanmaydi, bu ko'pincha sirli Go ish vaqti xatolariga sabab bo'ladi.
Shuni ta'kidlaymanki, yuqoriroq resurslar chegaralari rejalashtirishni qiyinlashtiradi, chunki podkada etarli resurslar mavjud bo'lgan maqsadli tugun kerak.
Vaziyatni tasavvur qiling-a, sizda 4 GB xotira kabi juda yuqori resurs chegarasiga ega engil veb-serveringiz mavjud. Ehtimol, bu jarayon gorizontal ravishda kengaytirilishi kerak va har bir yangi podkad kamida 4 GB mavjud xotiraga ega tugunga rejalashtirilishi kerak. Agar bunday tugun bo'lmasa, klaster ushbu podkastni qayta ishlash uchun yangi tugunni kiritishi kerak, bu biroz vaqt talab qilishi mumkin. Tez va silliq o'lchovni ta'minlash uchun resurs so'rovlari va cheklovlar o'rtasidagi minimal farqga erishish muhimdir.
Ikkinchi qadam: Jonlilik va tayyorlik testlarini o'rnating
Bu Kubernetes hamjamiyatida tez-tez muhokama qilinadigan yana bir nozik mavzu. Jonlilik va Tayyorlik testlarini yaxshi tushunish juda muhim, chunki ular dasturiy ta'minotning barqaror ishlashi mexanizmini ta'minlaydi va ishlamay qolish vaqtini minimallashtiradi. Biroq, ular to'g'ri sozlanmagan bo'lsa, ilovangizning ishlashiga jiddiy ta'sir ko'rsatishi mumkin. Quyida ikkala namuna nima ekanligi haqida qisqacha ma'lumot berilgan.
Tiriklik konteyner ishlayotganligini ko'rsatadi. Agar u muvaffaqiyatsiz bo'lsa, kubelet konteynerni o'ldiradi va uning uchun qayta ishga tushirish siyosati yoqiladi. Agar konteyner Liveness Probe bilan jihozlanmagan bo'lsa, unda aytilganidek, standart holat muvaffaqiyatli bo'ladi .
Jonli zondlar arzon bo'lishi kerak, ya'ni ko'p resurslarni iste'mol qilmasligi kerak, chunki ular tez-tez ishlaydi va Kubernetesga dastur ishlayotgani haqida xabar berishi kerak.
Agar siz har soniyada ishga tushirish parametrini o'rnatsangiz, bu soniyada 1 ta so'rov qo'shadi, shuning uchun ushbu trafikni qayta ishlash uchun qo'shimcha resurslar talab qilinishini unutmang.
Kompaniyamizda Liveness testlari ma'lumotlar (masalan, masofaviy ma'lumotlar bazasi yoki keshdan) to'liq mavjud bo'lmasa ham, ilovaning asosiy komponentlarini sinovdan o'tkazadi.
Biz ilovalarda 200 javob kodini qaytaradigan "salomatlik" so'nggi nuqtasini o'rnatdik. Bu jarayon ishlayotganligi va so'rovlarni ko'rib chiqa olishi (lekin hali trafik emas) ko'rsatkichidir.
Namuna Tayyorlik konteyner so'rovlarga xizmat ko'rsatishga tayyorligini bildiradi. Agar tayyorlik tekshiruvi muvaffaqiyatsiz bo'lsa, so'nggi nuqta boshqaruvchisi podkastga mos keladigan barcha xizmatlarning so'nggi nuqtalaridan pod IP-manzilini olib tashlaydi. Bu Kubernetes hujjatlarida ham aytilgan.
Tayyorlik tekshiruvlari ko'proq resurslarni iste'mol qiladi, chunki ular dastur so'rovlarni qabul qilishga tayyorligini ko'rsatadigan tarzda backendga tegishi kerak.
Jamiyatda ma'lumotlar bazasiga to'g'ridan-to'g'ri kirish yoki yo'qligi haqida ko'p bahs-munozaralar mavjud. Qo'shimcha xarajatlarni hisobga olgan holda (tekshiruvlar tez-tez amalga oshiriladi, lekin ularni nazorat qilish mumkin), biz ba'zi ilovalar uchun trafikka xizmat ko'rsatishga tayyorlik faqat ma'lumotlar bazasidan yozuvlar qaytarilganligini tekshirgandan so'ng hisoblanishiga qaror qildik. Yaxshi ishlab chiqilgan tayyorgarlik sinovlari yuqori darajadagi mavjudlikni ta'minladi va joylashtirish paytida to'xtab qolish vaqtini yo'q qildi.
Agar siz ilovangizning tayyorligini tekshirish uchun maʼlumotlar bazasiga soʻrov oʻtkazishga qaror qilsangiz, uning iloji boricha arzonligiga ishonch hosil qiling. Keling, ushbu so'rovni ko'rib chiqaylik:
SELECT small_item FROM table LIMIT 1Kubernetes-da ushbu ikkita qiymatni qanday sozlashimizga misol:
livenessProbe:
httpGet:
path: /api/liveness
port: http
readinessProbe:
httpGet:
path: /api/readiness
port: http periodSeconds: 2
Siz ba'zi qo'shimcha konfiguratsiya parametrlarini qo'shishingiz mumkin:
initialDelaySeconds- konteynerning ishga tushirilishi va zondlarning ishga tushirilishi o'rtasida necha soniya o'tadi.periodSeconds— namunalar orasidagi kutish oralig'i.timeoutSeconds— sekundlar soni, shundan keyin pod favqulodda holat deb hisoblanadi. Oddiy vaqt tugashi.failureThresholdpodkaga qayta ishga tushirish signali yuborilgunga qadar sinovdagi muvaffaqiyatsizliklar soni.successThreshold- pod tayyor holatga o'tishdan oldingi muvaffaqiyatli sinovlar soni (podjak ishga tushganda yoki tiklanganda nosozlikdan keyin).
Uchinchi qadam: Podning standart tarmoq siyosatini o'rnatish
Kubernetes "tekis" tarmoq topografiyasiga ega, sukut bo'yicha barcha podlar bir-biri bilan bevosita muloqot qiladi. Ba'zi hollarda bu istalmagan.
Potentsial xavfsizlik muammosi shundaki, tajovuzkor tarmoqdagi barcha podslarga trafik yuborish uchun bitta zaif dasturdan foydalanishi mumkin. Ko'pgina xavfsizlik sohalarida bo'lgani kabi, bu erda ham eng kam imtiyozlar printsipi qo'llaniladi. Ideal holda, tarmoq siyosati podkastlar orasidagi qaysi ulanishlarga ruxsat berilgan va qaysi biri yo'qligini aniq ko'rsatishi kerak.
Misol uchun, quyida ma'lum bir nom maydoni uchun barcha kiruvchi trafikni rad etadigan oddiy siyosat mavjud:
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
spec:
podSelector: {}
policyTypes:
- Ingress
Ushbu konfiguratsiyaning vizual ko'rinishi:
(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
Batafsil ma'lumot .
To'rtinchi qadam: Ilgaklar va Init konteynerlari bilan shaxsiy xatti-harakatlar
Bizning asosiy maqsadlarimizdan biri ishlab chiquvchilar uchun to'xtab qolmasdan Kubernetes-da joylashtirishni ta'minlash edi. Bu qiyin, chunki ilovalarni o'chirish va ulardan foydalanilgan resurslarni chiqarish uchun ko'plab variantlar mavjud.
Maxsus qiyinchiliklar paydo bo'ldi . Ushbu podlarni ketma-ket joylashtirishda faol ulanishlar muvaffaqiyatli yakunlanmaguncha uzilib qolganini payqadik.
Internetdagi keng qamrovli tadqiqotlardan so'ng, Kubernetes podni o'chirishdan oldin Nginx ulanishlarining tugashini kutmasligi ma'lum bo'ldi. Oldindan to'xtash kancasi yordamida biz quyidagi funksiyalarni amalga oshirdik va ishlamay qolishdan butunlay xalos bo'ldik:
lifecycle:
preStop:
exec:
command: ["/usr/local/bin/nginx-killer.sh"]
Ammo nginx-killer.sh:
#!/bin/bash
sleep 3
PID=$(cat /run/nginx.pid)
nginx -s quit
while [ -d /proc/$PID ]; do
echo "Waiting while shutting down nginx..."
sleep 10
done
Yana bir juda foydali paradigma - bu muayyan ilovalarni ishga tushirish uchun init konteynerlaridan foydalanish. Bu, ayniqsa, dastur boshlanishidan oldin bajarilishi kerak bo'lgan resurslarni ko'p talab qiladigan ma'lumotlar bazasini ko'chirish jarayoniga ega bo'lsangiz foydalidir. Bundan tashqari, asosiy dastur uchun bunday cheklovni o'rnatmasdan, ushbu jarayon uchun yuqoriroq manba chegarasini belgilashingiz mumkin.
Yana bir keng tarqalgan sxema - init konteyneridagi sirlarga kirish, bu hisobga olish ma'lumotlarini asosiy modulga beradi, bu esa asosiy dastur modulining o'zidan sirlarga ruxsatsiz kirishni oldini oladi.
Odatdagidek, hujjatlardan iqtibos: init konteynerlari foydalanuvchi kodini yoki ilovaning konteyner tasvirining xavfsizligini buzadigan yordamchi dasturlarni xavfsiz boshqaradi. Keraksiz vositalarni alohida saqlash orqali siz ilovaning konteyner tasvirining hujum yuzasini cheklaysiz.
Beshinchi qadam: yadro konfiguratsiyasi
Nihoyat, yanada ilg'or texnika haqida gapiraylik.
Kubernetes - bu juda moslashuvchan platforma bo'lib, sizga ish yuklarini o'zingizga mos keladigan tarzda ishlatish imkonini beradi. Bizda juda ko'p resurs talab qiladigan yuqori samarali ilovalar mavjud. Keng qamrovli yuk sinovlarini o'tkazganimizdan so'ng, biz Kubernetes standart sozlamalari amalda bo'lganida ilovalardan biri kutilgan trafik yukini ushlab turishda qiynalayotganini aniqladik.
Biroq, Kubernetes faqat ma'lum bir pod uchun yadro parametrlarini o'zgartiradigan imtiyozli konteynerni ishga tushirishga imkon beradi. Ochiq ulanishlarning maksimal sonini o'zgartirish uchun biz foydalanganmiz:
initContainers:
- name: sysctl
image: alpine:3.10
securityContext:
privileged: true
command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]
Bu ko'pincha kerak bo'lmaydigan yanada ilg'or texnika. Ammo agar ilovangiz og'ir yukni engishga qiynalayotgan bo'lsa, ushbu sozlamalardan ba'zilarini o'zgartirishga urinib ko'rishingiz mumkin. Ushbu jarayon va turli qiymatlarni o'rnatish haqida ko'proq ma'lumot - har doimgidek .
Xulosa
Kubernetes tayyor echim kabi ko'rinishi mumkin bo'lsa-da, ilovalarning muammosiz ishlashini ta'minlash uchun bir nechta asosiy qadamlarni bajarish kerak.
Kubernetes-ga o'tish davomida "yukni sinovdan o'tkazish sikli" ga rioya qilish muhim: dasturni ishga tushiring, uni yuk ostida sinab ko'ring, o'lchovlar va masshtablash xatti-harakatlarini kuzating, ushbu ma'lumotlar asosida konfiguratsiyani sozlang, so'ngra ushbu tsiklni yana takrorlang.
Kutilayotgan trafik haqida real bo'ling va qaysi komponentlar birinchi bo'lib buzilganini ko'rish uchun undan tashqariga chiqishga harakat qiling. Ushbu takroriy yondashuv bilan, muvaffaqiyatga erishish uchun sanab o'tilgan tavsiyalarning faqat bir nechtasi etarli bo'lishi mumkin. Yoki u chuqurroq moslashtirishni talab qilishi mumkin.
Har doim o'zingizga quyidagi savollarni bering:
- Ilovalar qancha resurslarni iste'mol qiladi va bu miqdor qanday o'zgaradi?
- Haqiqiy o'lchov talablari qanday? Ilova o'rtacha qancha trafikni boshqaradi? Eng yuqori trafik haqida nima deyish mumkin?
- Xizmat qanchalik tez-tez kengaytirilishi kerak? Trafikni qabul qilish uchun yangi podlar qanchalik tez ishga tushishi kerak?
- Po'choqlar qanchalik chiroyli tarzda yopiladi? Bu umuman kerakmi? Ishlamasdan turib tarqatishga erishish mumkinmi?
- Qanday qilib xavfsizlik xatarlarini minimallashtirish va har qanday buzilgan podlardan zararni cheklash mumkin? Har qanday xizmatlarda ularga kerak bo'lmagan ruxsatlar yoki ruxsatlar bormi?
Kubernetes minglab xizmatlarni klasterda joylashtirish uchun eng yaxshi amaliyotlardan foydalanish imkonini beruvchi ajoyib platformani taqdim etadi. Biroq, barcha ilovalar boshqacha. Ba'zan amalga oshirish biroz ko'proq mehnat talab qiladi.
Yaxshiyamki, Kubernetes barcha texnik maqsadlarga erishish uchun kerakli sozlamalarni taqdim etadi. Resurs so'rovlari va cheklovlari, Jonlilik va tayyorlik tekshiruvlari, boshlang'ich konteynerlari, tarmoq siyosatlari va yadro sozlamalari kombinatsiyasidan foydalanib, siz nosozliklarga chidamlilik va tezkor miqyosda yuqori ishlashga erishishingiz mumkin.
Yana nimani o'qish kerak:
- .
- .
- .
Manba: www.habr.com