Pavel Selivanov, Southbridge yechimlari arxitektori va Slurm oʻqituvchisi DevOpsConf 2019 da taqdimot qildi. Bu maʼruza Kubernetes “Slurm Mega” boʻyicha chuqurlashtirilgan kurs mavzularidan birining bir qismidir.
18-20 noyabr kunlari Moskvada boʻlib oʻtadi.
- Moskva, 22-24 noyabr.
har doim mavjud.
Kesim ostida hisobotning stenogrammasi keltirilgan.
Xayrli kun, hamkasblar va ularga hamdard bo'lganlar. Bugun men xavfsizlik haqida gapiraman.
Qarasam, bugun zalda qo‘riqchilar ko‘p. Agar men xavfsizlik olamidagi atamalarni siz uchun odatiy bo'lmagan tarzda ishlatsam, sizdan oldindan uzr so'rayman.
Taxminan olti oy oldin men bitta ommaviy Kubernetes klasteriga duch keldim. Ommaviy degani n-sonli nomlar maydoni mavjudligini bildiradi; bu nom maydonlarida ularning nom maydonida izolyatsiya qilingan foydalanuvchilar mavjud. Bu foydalanuvchilarning barchasi turli kompaniyalarga tegishli. Xo'sh, bu klaster CDN sifatida ishlatilishi kerak deb taxmin qilingan. Ya'ni, ular sizga klaster beradilar, u erda foydalanuvchi beradilar, siz u yerga o'z nomlar maydoniga borasiz, frontlarni joylashtirasiz.
Mening oldingi kompaniyam bunday xizmatni sotishga harakat qildi. Va mendan ushbu yechim mos keladimi yoki yo'qligini bilish uchun klasterni teshishni so'rashdi.
Men bu klasterga keldim. Menga cheklangan huquqlar, cheklangan nomlar maydoni berildi. U yerdagi yigitlar xavfsizlik nimaligini tushunishdi. Ular Kubernetes-da Rolga asoslangan kirishni boshqarish (RBAC) haqida o'qishdi - va ular podlarni joylashtirishdan alohida ishga tushira olmasligim uchun uni burishdi. Men o'rnatmasdan podni ishga tushirish orqali hal qilmoqchi bo'lgan muammoni eslay olmayman, lekin men shunchaki podni ishga tushirmoqchi edim. Omad tilayman, men klasterda qanday huquqlarga ega ekanligimni, nima qilishim mumkinligini, nima qila olmasligimni va u erda nimani buzganliklarini ko'rishga qaror qildim. Shu bilan birga, men sizga RBACda nima noto'g'ri sozlanganligini aytib beraman.
Ikki daqiqadan so'ng men ularning klasteriga administratorni qabul qildim, barcha qo'shni nom maydonlarini ko'rib chiqdim, u erda xizmatni sotib olgan va ishga tushirgan kompaniyalarning ishlab chiqarish jabhalarini ko'rdim. Birovning oldiga borib, bosh sahifaga qandaydir so'kinish so'zlarini qo'yishdan o'zimni zo'rg'a to'xtatdim.
Men buni qanday qilganimni va o'zingizni bundan qanday himoya qilishni misollar bilan aytib beraman.
Lekin birinchi navbatda o'zimni tanishtiraman. Mening ismim Pavel Selivanov. Men Sautbridjda arxitektorman. Men Kubernetes, DevOps va har xil ajoyib narsalarni tushunaman. Southbridge muhandislari va men bularning barchasini qurmoqdamiz va men maslahat beraman.
Asosiy faoliyatimizga qo'shimcha ravishda biz yaqinda Slurms deb nomlangan loyihalarni ishga tushirdik. Biz Kubernetes bilan ishlash qobiliyatimizni biroz ommaga etkazishga, boshqa odamlarni K8 bilan ishlashga o'rgatishga harakat qilmoqdamiz.
Bugun nima haqida gaplashaman? Hisobot mavzusi aniq - Kubernetes klasterining xavfsizligi haqida. Ammo men darhol aytmoqchimanki, bu mavzu juda katta - va shuning uchun men nima haqida gapirmasligimni darhol aniqlamoqchiman. Men Internetda allaqachon yuz marta ishlatilgan hackneyed atamalar haqida gapirmayman. Barcha turdagi RBAC va sertifikatlar.
Men Kubernetes klasteridagi xavfsizlik borasida meni va hamkasblarimni nima qiynalayotgani haqida gapiraman. Biz bu muammolarni Kubernetes klasterlarini taqdim etuvchi provayderlar orasida ham, bizga kelgan mijozlar orasida ham ko'ramiz. Va hatto boshqa konsalting boshqaruv kompaniyalaridan bizga kelgan mijozlardan. Ya'ni, fojia ko'lami aslida juda katta.
Bugun men gaplashadigan uchta nuqta bor:
- Foydalanuvchi huquqlari va pod huquqlari. Foydalanuvchi huquqlari va pod huquqlari bir xil narsa emas.
- Klaster haqida ma'lumot to'plash. Men ushbu klasterda maxsus huquqlarga ega bo'lmasdan, sizga kerak bo'lgan barcha ma'lumotlarni klasterdan to'plashingiz mumkinligini ko'rsataman.
- Klasterga DoS hujumi. Agar biz ma'lumot to'play olmasak, biz har qanday holatda klaster qo'yishimiz mumkin. Klaster boshqaruv elementlariga DoS hujumlari haqida gapiraman.
Men aytib o'tadigan yana bir umumiy narsa - bularning barchasini sinab ko'rganim, buning hammasi ishlaydi, deb ayta olaman.
Biz Kubespray yordamida Kubernetes klasterini o'rnatishni asos qilib olamiz. Agar kimdir bilmasa, bu aslida Ansible uchun rollar to'plami. Biz undan doimiy ravishda ishimizda foydalanamiz. Yaxshi tomoni shundaki, siz uni istalgan joyda o'rashingiz mumkin - uni temir bo'laklarga yoki biror joyda bulutga o'rashingiz mumkin. Bitta o'rnatish usuli printsipial jihatdan hamma narsa uchun ishlaydi.
Ushbu klasterda menda Kubernetes v1.14.5 bo'ladi. Biz ko'rib chiqadigan butun Cube klasteri nomlar maydoniga bo'lingan, har bir nom maydoni alohida jamoaga tegishli va bu jamoa a'zolari har bir nom maydoniga kirish huquqiga ega. Ular turli nomlar bo'shliqlariga kira olmaydi, faqat o'zlariga. Ammo butun klasterga huquqlarga ega bo'lgan ma'lum bir administrator hisobi mavjud.
Men birinchi navbatda klaster uchun administrator huquqlarini olishimizga va'da berdim. Bizga Kubernetes klasterini buzadigan maxsus tayyorlangan pod kerak. Biz qilishimiz kerak bo'lgan narsa uni Kubernetes klasteriga qo'llashdir.
kubectl apply -f pod.yamlUshbu pod Kubernetes klasterining ustalaridan biriga etib boradi. Va bundan keyin klaster bizga admin.conf nomli faylni mamnuniyat bilan qaytaradi. Cube-da ushbu fayl barcha administrator sertifikatlarini saqlaydi va shu bilan birga klaster API ni sozlaydi. Menimcha, Kubernetes klasterlarining 98 foiziga administratorga kirish juda oson.
Takror aytaman, bu pod klasteringizdagi o'z takliflarini bitta kichik nom maydoniga joylashtirish huquqiga ega bo'lgan bitta ishlab chiquvchi tomonidan yaratilgan, barchasi RBAC tomonidan mahkamlangan. Uning huquqlari yo'q edi. Ammo shunga qaramay sertifikat qaytarildi.
Va endi maxsus tayyorlangan pod haqida. Biz uni har qanday rasmda ishlatamiz. Misol tariqasida debian:jessie ni olaylik.
Bizda bu narsa bor:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Tolerantlik nima? Kubernetes klasteridagi magistrlar odatda ifloslanish deb ataladigan narsa bilan belgilanadi. Va bu "infektsiya" ning mohiyati shundan iboratki, u podslarni asosiy tugunlarga tayinlash mumkin emasligini aytadi. Ammo hech kim hech qanday podada "infektsiyaga" bardoshli ekanligini ko'rsatishni bezovta qilmaydi. Toleratsiya bo'limida aytilishicha, agar biron bir tugunda NoSchedule bo'lsa, unda bizning tugunimiz bunday infektsiyaga toqat qiladi - va hech qanday muammo yo'q.
Bundan tashqari, biz aytamizki, bizning pastki nafaqat bag'rikeng, balki xo'jayinni ham aniq nishonga olishni xohlaydi. Chunki ustalarda bizga kerak bo‘lgan eng mazali narsa – barcha sertifikatlar bor. Shuning uchun biz nodeSelector deymiz - va bizda masterlar bo'yicha standart yorliq mavjud, bu sizga klasterdagi barcha tugunlardan aynan master bo'lgan tugunlarni tanlash imkonini beradi.
Bu ikki bo'lim bilan u albatta ustaga keladi. Va u erda yashashga ruxsat beriladi.
Lekin xo'jayinning oldiga kelishning o'zi kifoya emas. Bu bizga hech narsa bermaydi. Shunday qilib, bizda ikkita narsa bor:
hostNetwork: true
hostPID: true Biz ishga tushiradigan podimiz yadro nom maydonida, tarmoq nom maydonida va PID nom maydonida yashashini aniqlaymiz. Pod masterda ishga tushirilgandan so'ng, u ushbu tugunning barcha haqiqiy, jonli interfeyslarini ko'rishi, barcha trafikni tinglashi va barcha jarayonlarning PID-ni ko'rishi mumkin bo'ladi.
Keyin mayda-chuyda narsalar haqida gap boradi. etcd oling va xohlaganingizni o'qing.
Eng qiziq narsa bu Kubernetes xususiyati bo'lib, u erda sukut bo'yicha mavjud.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host Va uning mohiyati shundan iboratki, biz podkastda aytishimiz mumkinki, biz ushbu klasterga huquqsiz ham, hostPath tipidagi hajmni yaratmoqchimiz. Bu biz ishga tushiradigan xostdan yo'lni olish va uni hajm sifatida qabul qilishni anglatadi. Va keyin biz uni nom deb ataymiz: host. Biz butun hostPath-ni podka ichiga o'rnatamiz. Ushbu misolda, /host katalogiga.
Yana takrorlayman. Biz podkastga masterga kelishini, hostNetwork va hostPID-ni u yerdan olishini va masterning butun ildizini shu pod ichiga o'rnatishni aytdik.
Siz tushunasizki, Debian-da bizda bash ishlaydi va bu bash root ostida ishlaydi. Ya'ni, biz Kubernetes klasterida hech qanday huquqlarga ega bo'lmasdan, faqat masterda ildiz oldik.
Keyin butun vazifa /host /etc/kubernetes/pki pastki katalogiga o'tish, agar adashmasam, u erda klasterning barcha asosiy sertifikatlarini oling va shunga mos ravishda klaster ma'muri bo'ling.
Agar siz bunga shu tarzda qarasangiz, foydalanuvchi qanday huquqlarga ega bo'lishidan qat'i nazar, bular podsdagi eng xavfli huquqlardir:
Agar men klasterning ba'zi nomlar maydonida podkastni ishga tushirish huquqiga ega bo'lsam, bu pod sukut bo'yicha ushbu huquqlarga ega. Imtiyozli podlarni ishga tushirishim mumkin va bular odatda tugunga asoslangan barcha huquqlardir.
Mening sevimli narsam - Root foydalanuvchisi. Va Kubernetesda ushbu "Ildiz bo'lmagan holda ishga tushirish" opsiyasi mavjud. Bu xakerlardan himoya qilishning bir turi. "Moldova virusi" nima ekanligini bilasizmi? Agar siz to'satdan xaker bo'lsangiz va mening Kubernetes klasterimga kirsangiz, unda biz, kambag'al ma'murlar, so'raymiz: “Iltimos, mening klasterimni buzib kirishni podkastlaringizda ko'rsating, root bo'lmagan sifatida ishlating. Aks holda, siz podkastingizdagi jarayonni root ostida boshqarasiz va meni buzish siz uchun juda oson bo'ladi. Iltimos, o'zingizni o'zingizdan saqlang."
Xost yo'li hajmi, menimcha, Kubernetes klasteridan kerakli natijani olishning eng tezkor usuli.
Lekin bularning barchasi bilan nima qilish kerak?
Kubernetesga duch kelgan har qanday oddiy ma'murga kelishi kerak bo'lgan fikr: "Ha, men sizga aytdim, Kubernetes ishlamaydi. Unda teshiklar bor. Va butun Kub bema'nilikdir." Aslida hujjat degan narsa bor, u yerga qarasangiz bo‘lim bor .
Bu yaml ob'ekti - biz uni Kubernetes klasterida yaratishimiz mumkin - bu podkastlar tavsifida xavfsizlik jihatlarini nazorat qiladi. Ya'ni, aslida u ishga tushirilganda podlarda joylashgan har qanday hostNetwork, hostPID, ma'lum hajm turlaridan foydalanish huquqlarini boshqaradi. Pod Security Policy yordamida bularning barchasini tasvirlash mumkin.
Pod xavfsizlik siyosatining eng qiziq tomoni shundaki, Kubernetes klasterida barcha PSP o'rnatuvchilari shunchaki tasvirlanmagan, ular sukut bo'yicha o'chirib qo'yilgan. Pod Security Policy qabul qilish plagini yordamida yoqilgan.
Mayli, keling, Pod Security Policy-ni klasterga joylashtiraylik, deylik, nomlar maydonida faqat administratorlar kirishi mumkin bo'lgan ba'zi xizmat podkastlari mavjud. Aytaylik, boshqa barcha holatlarda podalar cheklangan huquqlarga ega. Chunki ishlab chiquvchilar sizning klasteringizda imtiyozli podlarni ishga tushirishlari shart emas.
Va bizda hamma narsa yaxshi bo'lib tuyuladi. Va bizning Kubernetes klasterimizni ikki daqiqada buzib bo'lmaydi.
Muammo bor. Katta ehtimol bilan, agar sizda Kubernetes klasteringiz bo'lsa, u holda klasteringizda monitoring o'rnatilgan. Men hatto sizning klasteringizda monitoring bo'lsa, u Prometey deb nomlanishini taxmin qilishgacha borgan bo'lardim.
Men sizga aytmoqchi bo'lgan narsa Prometey operatori uchun ham, uning sof shaklida taqdim etilgan Prometey uchun ham amal qiladi. Savol shundaki, agar men administratorni klasterga tezda kirita olmasam, bu men ko'proq izlashim kerakligini anglatadi. Va men sizning monitoringingiz yordamida qidirishim mumkin.
Ehtimol, hamma Habré-da bir xil maqolalarni o'qiydi va monitoring monitoring nomlar maydonida joylashgan. Helm diagrammasi hamma uchun taxminan bir xil deb ataladi. O'ylaymanki, agar siz stabil/prometeyni o'rnatsangiz, siz taxminan bir xil nomlarga ega bo'lasiz. Va, ehtimol, men sizning klasteringizdagi DNS nomini taxmin qilishim shart emas. Chunki bu standart.
Keyinchalik bizda ma'lum bir podkastni ishga tushirishingiz mumkin bo'lgan ma'lum bir ishlab chiquvchi mavjud. Va keyin bu poddan shunday qilish juda oson:
$ curl http://prometheus-kube-state-metrics.monitoring prometheus-kube-state-metrics - Kubernetes API-ning o'zidan ko'rsatkichlarni to'playdigan Prometey eksportchilaridan biri. U erda juda ko'p ma'lumotlar bor, sizning klasteringizda nima ishlaydi, u nima, u bilan qanday muammolar bor.
Oddiy misol sifatida:
kube_pod_container_info{namespace=“kube-system”,pod=”kube-apiserver-k8s- 1″,container=”kube-apiserver”,image=
"gcr.io/google-containers/kube-apiserver:v1.14.5"
,image_id=»docker-pullable://gcr.io/google-containers/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1
Imtiyozsiz poddan oddiy jingalak so'rovini amalga oshirish orqali siz quyidagi ma'lumotlarni olishingiz mumkin. Agar siz Kubernetesning qaysi versiyasini ishlayotganingizni bilmasangiz, u sizga osonlikcha aytib beradi.
Va eng qizig'i shundaki, kube-state ko'rsatkichlariga kirishdan tashqari, siz Prometeyning o'ziga to'g'ridan-to'g'ri kirishingiz mumkin. U erdan ko'rsatkichlarni to'plashingiz mumkin. Siz hatto u erdan ko'rsatkichlarni yaratishingiz mumkin. Hatto nazariy jihatdan, siz Prometeydagi klasterdan bunday so'rovni yaratishingiz mumkin, bu uni shunchaki o'chirib qo'yadi. Va sizning monitoringingiz klasterdan umuman ishlashni to'xtatadi.
Va bu erda har qanday tashqi monitoring sizning monitoringingizni kuzatib boradimi degan savol tug'iladi. Men Kubernetes klasterida o'zim uchun hech qanday oqibatlarsiz ishlash imkoniyatiga ega bo'ldim. Siz u yerda ishlayotganimni bilmay qolasiz, chunki endi hech qanday monitoring yo'q.
Xuddi PSP bilan bo'lgani kabi, muammo shundaki, bu ajoyib texnologiyalar - Kubernetes, Prometey - ular ishlamaydi va teshiklarga to'la. Unchalik emas.
Bunday narsa bor - .
Agar siz oddiy administrator bo'lsangiz, unda siz Tarmoq siyosati haqida bilasiz, bu klasterda allaqachon ko'p bo'lgan yana bir yaml ekanligini bilasiz. Va ba'zi Tarmoq siyosatlari, albatta, kerak emas. Va agar siz Tarmoq siyosati nima ekanligini, bu Kubernetesning yaml xavfsizlik devori ekanligini o'qisangiz ham, u nomlar bo'shliqlari, podlar o'rtasidagi kirish huquqlarini cheklash imkonini beradi, keyin siz Kubernetesdagi yaml formatidagi xavfsizlik devori keyingi abstraktsiyalarga asoslangan deb qaror qildingiz. ... Yo'q, yo'q. Bu, albatta, kerak emas.
Agar siz xavfsizlik bo'yicha mutaxassislaringizga Kubernetes yordamida siz juda oson va oddiy xavfsizlik devorini va bunda juda nozik xavfsizlik devorini yaratishingiz mumkinligini aytmagan bo'lsangiz ham. Agar ular buni hali bilmasa va sizni bezovta qilmasa: "Yaxshi, menga bering, menga bering ..." Keyin har qanday holatda, sizning klasteringizdan tortib olinadigan ba'zi xizmat ko'rsatish joylariga kirishni bloklash uchun sizga Tarmoq siyosati kerak bo'ladi. hech qanday ruxsatisiz.
Men keltirgan misolda bo'lgani kabi, Kubernetes klasteridagi istalgan nom maydonidan kube holati ko'rsatkichlarini hech qanday huquqqa ega bo'lmasdan olishingiz mumkin. Tarmoq siyosatlari boshqa barcha nomlar bo'shliqlaridan monitoring nom maydoniga yopiq kirish imkoniyatiga ega va bu: kirish yo'q, muammo yo'q. Mavjud barcha diagrammalarda, ham standart Prometey, ham operatorda joylashgan Prometey, rul qiymatlarida ular uchun tarmoq siyosatini oddiygina yoqish imkoniyati mavjud. Siz shunchaki uni yoqishingiz kerak va ular ishlaydi.
Bu erda haqiqatan ham bitta muammo bor. Oddiy soqolli administrator sifatida siz tarmoq siyosati kerak emas deb qaror qildingiz. Va Habr kabi manbalar haqidagi har xil maqolalarni o'qib chiqqandan so'ng, siz flanelni, ayniqsa xost-shlyuz rejimini tanlashingiz mumkin bo'lgan eng yaxshi narsa deb qaror qildingiz.
Nima qilish kerak?
Siz Kubernetes klasteringizda mavjud bo'lgan tarmoq yechimini qayta joylashtirishga urinib ko'rishingiz mumkin, uni yanada funktsional narsa bilan almashtirishga harakat qiling. Xuddi shu Calico uchun, masalan. Ammo men darhol aytmoqchimanki, Kubernetes ishchi klasterida tarmoq echimini o'zgartirish vazifasi juda ahamiyatsiz. Men buni ikki marta hal qildim (har ikki marta ham, nazariy jihatdan), lekin biz buni Slurmsda qanday qilishni ham ko'rsatdik. Talabalarimiz uchun biz Kubernetes klasterida tarmoq yechimini qanday o'zgartirishni ko'rsatdik. Asos sifatida, siz ishlab chiqarish klasterida ishlamay qolish vaqti yo'qligiga ishonch hosil qilishga harakat qilishingiz mumkin. Lekin, ehtimol, muvaffaqiyatga erisha olmaysiz.
Va muammo aslida juda oddiy hal qilinadi. Klasterda sertifikatlar mavjud va sizning sertifikatlaringiz bir yildan keyin tugashini bilasiz. Xo'sh, va odatda klasterdagi sertifikatlar bilan oddiy yechim - biz nima uchun tashvishlanyapmiz, biz yaqin atrofda yangi klasterni ko'taramiz, eskisini chirigan holga keltiramiz va hamma narsani qayta joylashtiramiz. To'g'ri, u chirigan bo'lsa, biz bir kun o'tirishimiz kerak, lekin bu erda yangi klaster.
Yangi klasterni ko'targaningizda, bir vaqtning o'zida flanel o'rniga Calico qo'shing.
Sertifikatlaringiz yuz yil davomida berilgan bo'lsa va siz klasterni qayta joylashtirmoqchi bo'lmasangiz nima qilish kerak? Kube-RBAC-proksi kabi narsa mavjud. Bu juda ajoyib ishlanma, u sizga Kubernetes klasteridagi har qanday podkastga yonbosh idish sifatida joylashtirish imkonini beradi. Va u aslida Kubernetesning RBAC orqali ushbu podkastga avtorizatsiyani qo'shadi.
Bitta muammo bor. Ilgari ushbu Kube-RBAC-Proksi yechimi operatorning Prometeyiga qurilgan edi. Ammo keyin u ketdi. Endi zamonaviy versiyalar sizning tarmoq siyosatingiz borligiga tayanadi va ular yordamida uni yopadi. Va shuning uchun biz diagrammani biroz qayta yozishimiz kerak bo'ladi. Aslida, agar siz borsangiz , buni yonboshlar sifatida ishlatish misollari mavjud va jadvallarni minimal darajada qayta yozish kerak bo'ladi.
Yana bitta kichik muammo bor. Prometey o'z ko'rsatkichlarini hammaga tarqatadigan yagona odam emas. Kubernetes klasterining barcha komponentlari ham o‘z ko‘rsatkichlarini qaytarishi mumkin.
Lekin men allaqachon aytganimdek, agar siz klasterga kira olmasangiz va ma'lumot to'play olmasangiz, hech bo'lmaganda zarar etkazishingiz mumkin.
Shunday qilib, men tezda Kubernetes klasterini buzishning ikkita usulini ko'rsataman.
Buni sizga aytsam kulasiz, bu ikkita haqiqiy hayotdir.
Birinchi usul. Resurslarning kamayishi.
Keling, yana bir maxsus podni ishga tushiraylik. Unda shunday bo'lim bo'ladi.
resources:
requests:
cpu: 4
memory: 4Gi Ma'lumki, so'rovlar - bu so'rovlar bilan ma'lum podalar uchun xostda ajratilgan CPU va xotira miqdori. Agar bizda Kubernetes klasterida to'rt yadroli xost mavjud bo'lsa va u erga to'rtta CPU podlari so'rovlar bilan kelsa, bu boshqa so'rovlar bilan podkastlar ushbu xostga kela olmaydi.
Agar men bunday podni ishga tushirsam, buyruqni bajaraman:
$ kubectl scale special-pod --replicas=...Keyin boshqa hech kim Kubernetes klasteriga joylashtira olmaydi. Chunki barcha tugunlarda so'rovlar tugaydi. Shunday qilib, men sizning Kubernetes klasteringizni to'xtataman. Agar buni kechqurun qilsam, joylashtirishni uzoq vaqt to'xtata olaman.
Agar biz Kubernetes hujjatlarini yana bir bor ko'rib chiqsak, biz Limit Range deb nomlangan narsani ko'ramiz. U klaster ob'ektlari uchun resurslarni o'rnatadi. Yamlda Limit Range ob'ektini yozishingiz, uni ma'lum nomlar maydoniga qo'llashingiz mumkin - va keyin bu nom maydonida siz pods uchun standart, maksimal va minimal resurslarga ega ekanligingizni aytishingiz mumkin.
Bunday narsaning yordami bilan biz jamoalarning ma'lum mahsulot nomlari bo'shliqlarida foydalanuvchilarni o'z podlarida har xil yomon narsalarni ko'rsatish qobiliyatini cheklashimiz mumkin. Ammo, afsuski, agar siz foydalanuvchiga bir nechta CPU so'rovlari bilan podlarni ishga tushira olmasligini aytsangiz ham, bunday ajoyib o'lchov buyrug'i mavjud yoki ular asboblar paneli orqali masshtabni amalga oshirishi mumkin.
Va bu erdan ikkinchi usul kelib chiqadi. Biz 11 podlarni ishga tushiramiz. Bu o'n bir milliard. Bu men bunday raqamni o'ylab topganim uchun emas, balki o'zim ko'rganim uchun.
Haqiqiy hikoya. Kechqurun men ofisdan chiqmoqchi edim. Men burchakda o'tirgan bir guruh ishlab chiquvchilarni ko'rmoqdaman va o'zlarining noutbuklari bilan nimadir qilishmoqda. Men yigitlarning oldiga boraman va so'rayman: "Sizga nima bo'ldi?"
Bir oz oldin, kechqurun soat to'qqiz atrofida, ishlab chiquvchilardan biri uyga ketishga tayyorlanayotgan edi. Va men qaror qildim: "Endi men arizamni bittaga qisqartiraman." Men birini bosdim, lekin internet biroz sekinlashdi. Yana birini bosdi, birini bosdi va Enter tugmasini bosdi. Men qo'limdan kelgan hamma narsani qo'ldan boy berdim. Keyin Internet hayotga kirdi - va hamma narsa bu raqamga tusha boshladi.
To'g'ri, bu voqea Kubernetesda sodir bo'lmagan; o'sha paytda bu Nomad edi. Bu shu bilan yakunlandiki, bir soatlik bizning Nomad-ni miqyosni kengaytirishga bo'lgan doimiy urinishlaridan to'xtatishga urinishlarimizdan so'ng, Nomad masshtabni to'xtatmasligini va boshqa hech narsa qilmasligini aytdi. — Charchadim, ketyapman. Va u egilib qoldi.
Tabiiyki, men Kubernetesda ham xuddi shunday qilishga harakat qildim. Kubernetes o'n bir milliard podsdan mamnun emas edi, u shunday dedi: "Men qila olmayman. Ichki og'iz himoyachilaridan oshib ketadi." Ammo 1 000 000 000 pods mumkin.
Bir milliardga javoban, Kub o'ziga tortilmadi. U haqiqatan ham o'sishni boshladi. Jarayon qanchalik uzoq davom etsa, yangi podlarni yaratish uchun unga ko'proq vaqt kerak bo'ldi. Ammo jarayon hali ham davom etdi. Yagona muammo shundaki, agar men o'z nomlar maydonimda podlarni cheksiz ishga tushira olsam, so'rovlar va cheklovlarsiz ham ba'zi vazifalar bilan shu qadar ko'p podlarni ishga tushirishim mumkinki, bu vazifalar yordamida tugunlar xotirada, CPUda to'plana boshlaydi. Men juda ko'p podlarni ishga tushirganimda, ulardan olingan ma'lumotlar saqlashga, ya'ni va hokazolarga tushishi kerak. Va u erga juda ko'p ma'lumot kelganda, saqlash juda sekin qaytib kela boshlaydi - va Kubernetes zerikarli bo'la boshlaydi.
Va yana bir muammo... Ma’lumki, Kubernetes boshqaruv elementlari bitta markaziy narsa emas, balki bir nechta komponentlardir. Xususan, boshqaruvchi menejer, rejalashtiruvchi va boshqalar mavjud. Bu bolalarning barchasi bir vaqtning o'zida keraksiz, ahmoqona ishlarni qilishni boshlaydilar, bu vaqt o'tishi bilan ko'proq vaqt talab qila boshlaydi. Tekshirish moslamasi yangi podkastlarni yaratadi. Rejalashtiruvchi ular uchun yangi tugunni topishga harakat qiladi. Tez orada klasteringizdagi yangi tugunlar tugaydi. Kubernetes klasteri sekinroq va sekinroq ishlay boshlaydi.
Ammo men bundan ham uzoqroqqa borishga qaror qildim. Ma'lumki, Kubernetesda xizmat deb ataladigan narsa mavjud. Xo'sh, sizning klasterlaringizda sukut bo'yicha, xizmat IP-jadvallar yordamida ishlaydi.
Agar siz, masalan, bir milliard podsni ishga tushirsangiz va keyin Kubernetisni yangi xizmatlar yaratishga majburlash uchun skriptdan foydalansangiz:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done Klasterning barcha tugunlarida taxminan bir vaqtning o'zida tobora ko'proq yangi iptables qoidalari yaratiladi. Bundan tashqari, har bir xizmat uchun bir milliard iptables qoidalari yaratiladi.
Men bularning barchasini bir necha ming, o'ntagacha tekshirdim. Va muammo shundaki, bu ostonada allaqachon tugunga ssh qilish juda muammoli. Chunki paketlar juda ko'p zanjirlardan o'tib, o'zlarini juda yaxshi his qila boshlaydi.
Va bu ham Kubernetes yordamida hal qilinadi. Bunday Resurs kvotasi ob'ekti mavjud. Klasterdagi nomlar maydoni uchun mavjud resurslar va ob'ektlar sonini belgilaydi. Biz Kubernetes klasterining har bir nom maydonida yaml ob'ektini yaratishimiz mumkin. Ushbu ob'ektdan foydalanib, bizda ushbu nomlar maydoni uchun ma'lum miqdordagi so'rovlar va chegaralar ajratilganligini aytishimiz mumkin, keyin esa bu nomlar maydonida 10 ta xizmat va 10 ta podkast yaratish mumkinligini aytishimiz mumkin. Va bitta ishlab chiquvchi kamida kechqurun o'zini bo'g'ib qo'yishi mumkin. Kubernetes unga shunday deydi: "Siz o'z podlarni bu miqdorga ko'paytira olmaysiz, chunki resurs kvotadan oshib ketadi." Mana, muammo hal qilindi. .
Shu munosabat bilan bir muammoli nuqta paydo bo'ladi. Kubernetesda nom maydoni yaratish qanchalik qiyin bo'lib qolganini his qilyapsiz. Uni yaratish uchun biz ko'p narsalarni hisobga olishimiz kerak.
Resurs kvotasi + Limit oralig'i + RBAC
• Nomlar maydoni yarating
• Ichkarida chegara yarating
• Ichki resurs kvotasi yarating
• CI uchun xizmat hisobini yarating
• CI va foydalanuvchilar uchun rol bog'lashni yarating
• Majburiy emas, kerakli xizmat podkastlarini ishga tushiring
Shuning uchun, fursatdan foydalanib, o'z ishlanmalarimni baham ko'rmoqchiman. SDK operatori deb ataladigan narsa bor. Bu Kubernetes klasteri uchun operatorlarni yozish usulidir. Ansible yordamida bayonot yozishingiz mumkin.
Avvaliga bu Ansibleda yozilgan edi, keyin men SDK operatori borligini ko'rdim va Ansible rolini operatorga qayta yozdim. Ushbu bayonot sizga Kubernetes klasterida buyruq deb nomlangan ob'ektni yaratishga imkon beradi. Buyruqning ichida bu buyruq uchun muhitni yamlda tasvirlash imkonini beradi. Va jamoaviy muhitda bu bizga juda ko'p resurslarni ajratayotganimizni tasvirlash imkonini beradi.
Kichik .
Va xulosa qilib. Bularning barchasi bilan nima qilish kerak?
Birinchidan. Pod xavfsizlik siyosati yaxshi. Kubernetes o'rnatuvchilarning hech biri ularni bugungi kunga qadar ishlatmayotganiga qaramay, siz ularni klasteringizda ishlatishingiz kerak.
Tarmoq siyosati boshqa keraksiz xususiyat emas. Bu klasterda haqiqatan ham kerak bo'lgan narsa.
LimitRange/ResourceQuota - uni ishlatish vaqti keldi. Biz buni uzoq vaqt oldin qo'llashni boshladik va uzoq vaqt davomida hamma undan foydalanayotganiga amin bo'ldim. Ma'lum bo'lishicha, bu kamdan-kam uchraydi.
Hisobot davomida aytib o'tganlarimga qo'shimcha ravishda, klasterga hujum qilish imkonini beruvchi hujjatsiz xususiyatlar mavjud. Yaqinda chiqarilgan .
Ba'zi narsalar juda achinarli va og'riqli. Masalan, muayyan sharoitlarda Kubernetes klasteridagi kublar ruxsatsiz foydalanuvchiga warlocks katalogining mazmunini berishi mumkin.
Sizga aytgan hamma narsani qanday qilib takrorlash bo'yicha ko'rsatmalar mavjud. ResourceQuota va Pod Security Policy qanday koʻrinishini koʻrsatuvchi ishlab chiqarish misollari boʻlgan fayllar mavjud. Va bularning barchasiga tegishingiz mumkin.
Barchangizga rahmat.
Manba: www.habr.com