Ko‘proq va ko‘proq Kubernetes xizmatlarini yaratishni boshlaganingizda, dastlab oddiy bo‘lgan vazifalar murakkablasha boshlaydi. Masalan, ishlab chiqish guruhlari bir xil nom ostida xizmatlar yoki joylashtirishlarni yarata olmaydi. Agar sizda minglab podalar mavjud bo'lsa, ularni ro'yxatga olish, ularni to'g'ri boshqarish u yoqda tursin, ko'p vaqt talab etadi. Va bu aysbergning faqat uchi.
Keling, nomlar maydoni Kubernetes resurslarini boshqarishni qanday osonlashtirishini ko'rib chiqaylik. Xo'sh, nom maydoni nima? Nomlar maydonini Kubernetes klasteringizdagi virtual klaster sifatida ko'rish mumkin. Bitta Kubernetes klasterida bir-biridan ajratilgan bir nechta nom maydoniga ega bo'lishingiz mumkin. Ular sizga va jamoalaringizga tashkilot, xavfsizlik va hatto tizimning ishlashida yordam berishi mumkin.
Ko'pgina Kubernetes tarqatishlarida klaster "standart" deb nomlangan nom maydoni bilan qutidan chiqadi. Aslida Kubernetes shug'ullanadigan uchta nom maydoni mavjud: standart, kube-tizim va kube-public. Hozirda Kube-public juda tez-tez ishlatilmaydi.
Kube nom maydonini yolg'iz qoldirish yaxshi fikr, ayniqsa Google Kubernetes Engine kabi boshqariladigan tizimda. U sizning xizmatlaringiz va ilovalaringiz yaratilgan joy sifatida "standart" nom maydonidan foydalanadi. Bunda mutlaqo alohida narsa yo'q, faqat Kubernetes uni ishlatish uchun qutidan tashqarida tuzilgan va siz uni olib tashlay olmaysiz. Bu ishga tushirish va past unumdor tizimlar uchun juda yaxshi, lekin men katta ishlab chiqarish tizimlarida standart nom maydonidan foydalanishni tavsiya etmayman. Ikkinchi holda, bir ishlab chiquvchi guruh osongina boshqa birovning kodini qayta yozishi va boshqa jamoaning ishini hatto o'zi ham sezmasdan buzishi mumkin.
Shuning uchun siz bir nechta nomlar maydoni yaratishingiz va ulardan xizmatlaringizni boshqariladigan birliklarga ajratish uchun ishlatishingiz kerak. Nomlar maydoni bitta buyruq bilan yaratilishi mumkin. Agar siz test nomli nom maydoni yaratmoqchi bo'lsangiz, $ kubectl create namespace test buyrug'idan foydalaning yoki oddiygina YAML faylini yarating va uni boshqa Kubernetes manbalari kabi ishlating.
Siz $ kubectl get namespace buyrug'i yordamida barcha nom maydonlarini ko'rishingiz mumkin.
Tugallangach, siz uchta o'rnatilgan nom maydonini va "test" deb nomlangan yangi nom maydonini ko'rasiz. Keling, pod yaratish uchun oddiy YAML faylini ko'rib chiqaylik. Nom maydoni haqida hech qanday eslatma yo'qligini sezasiz.
Agar siz ushbu faylni ishga tushirish uchun kubectl dan foydalansangiz, u hozirgi faol nomlar maydonida mypod modulini yaratadi. Siz uni o'zgartirmaguningizcha, bu standart nom maydoni bo'ladi. Kubernetesga resursingizni qaysi nom maydonida yaratmoqchi ekanligingizni aytishning 2 usuli mavjud. Birinchi usul - resurs yaratishda nomlar maydoni bayrog'idan foydalanish.
Ikkinchi usul - YAML deklaratsiyasida nomlar maydonini ko'rsatish.
Agar siz YAMLda nom maydonini belgilasangiz, resurs har doim shu nom maydonida yaratiladi. Agar siz nom maydoni bayrog'idan foydalanganda boshqa nom maydonidan foydalanishga harakat qilsangiz, buyruq muvaffaqiyatsiz bo'ladi. Endi siz podkastingizni topishga harakat qilsangiz, buni qila olmaysiz.
Bu barcha buyruqlar hozirda faol nomlar maydonidan tashqarida bajarilganligi sababli yuzaga keladi. O'z podkastingizni topish uchun siz nom maydoni bayrog'idan foydalanishingiz kerak, lekin bu tezda zerikarli bo'ladi, ayniqsa siz o'z nom maydonidan foydalanadigan va har bir buyruq uchun ushbu bayroqdan foydalanishni istamaydigan jamoada ishlab chiquvchi bo'lsangiz. Keling, buni qanday tuzatishimiz mumkinligini ko'rib chiqaylik.
Faol nomlar maydoni standart deb nomlanadi. Agar siz YAML resursida nom maydonini belgilamasangiz, barcha Kubernetes buyruqlari ushbu faol standart nom maydonidan foydalanadi. Afsuski, kubectl yordamida faol nomlar maydonini boshqarishga urinish muvaffaqiyatsiz bo'lishi mumkin. Biroq, bu jarayonni ancha osonlashtiradigan Kubens deb nomlangan juda yaxshi vosita mavjud. Kubens buyrug'ini ishga tushirganingizda, faol nomlar maydoni ta'kidlangan barcha nom maydonlarini ko'rasiz.
Faol nom maydonini test nom maydoniga o'tkazish uchun siz shunchaki $kubens test buyrug'ini bajaring. Agar siz yana $kubens buyrug'ini ishga tushirsangiz, yangi faol nomlar maydoni ajratilganligini ko'rasiz - test.
Bu shuni anglatadiki, test nomlar maydonida podni ko'rish uchun nom maydoni bayrog'i kerak emas.
Shunday qilib, nom maydonlari bir-biridan yashiriladi, lekin bir-biridan ajratilmaydi. Bitta nom maydonidagi xizmat boshqa nom maydonidagi xizmat bilan juda oson bog'lanishi mumkin, bu ko'pincha juda foydali. Turli nomlar boʻshliqlari boʻylab muloqot qilish qobiliyati sizning ishlab chiquvchilaringiz xizmati boshqa nomlar maydonida boshqa ishlab chiquvchilar guruhining xizmati bilan bogʻlanishi mumkinligini anglatadi.
Odatda, ilovangiz Kubernetes xizmatiga kirishni xohlasa, siz o'rnatilgan DNS kashfiyot xizmatidan foydalanasiz va shunchaki ilovangizga xizmat nomini berasiz. Biroq, shunday qilish orqali siz bir nechta nom maydonida bir xil nom ostida xizmat yaratishingiz mumkin, bu qabul qilinishi mumkin emas.
Yaxshiyamki, DNS manzilining kengaytirilgan shaklidan foydalanib, buni osonlikcha hal qilish mumkin. Kubernetesdagi xizmatlar umumiy DNS shablonidan foydalangan holda so'nggi nuqtalarini ochib beradi. Bu shunday ko'rinadi:
Odatda, sizga faqat xizmat nomi kerak va DNS to'liq manzilni avtomatik ravishda aniqlaydi.
Biroq, agar siz boshqa nom maydonidagi xizmatga kirishingiz kerak bo'lsa, shunchaki xizmat nomi va nom maydoni nomidan foydalaning:
Misol uchun, agar siz test nomlari maydonida xizmat ma'lumotlar bazasiga ulanishni istasangiz, ma'lumotlar bazasi.test manzilidan foydalanishingiz mumkin.
Agar siz mahsulot nomlari maydonida xizmat ma'lumotlar bazasiga ulanishni istasangiz, database.prod dan foydalanasiz.
Agar siz haqiqatan ham nomlar maydoniga kirishni izolyatsiya qilishni va cheklashni istasangiz, Kubernetes buni Kubernetes tarmoq siyosati yordamida amalga oshirishga imkon beradi. Bu haqda keyingi qismda gaplashaman.
Menga tez-tez savol beriladi, qancha nom maydoni yaratishim kerak va qanday maqsadlarda? Boshqariladigan ma'lumotlar qismi nima?
Agar siz juda ko'p nomlar maydoni yaratsangiz, ular sizning yo'lingizga to'sqinlik qiladi. Agar ularning soni juda oz bo'lsa, siz bunday yechimning barcha afzalliklarini yo'qotasiz. Menimcha, har bir kompaniya o'zining tashkiliy tuzilmasini yaratishda to'rtta asosiy bosqichdan o'tadi. Loyihangiz yoki kompaniyangiz rivojlanish bosqichiga qarab, tegishli nomlar strategiyasini qabul qilishni xohlashingiz mumkin.
Tasavvur qiling-a, siz 5-10 ta mikroservisni ishlab chiqish ustida ishlayotgan kichik jamoaning bir qismisiz va barcha ishlab chiquvchilarni bir xonada osongina to'plashingiz mumkin. Bunday vaziyatda barcha prod xizmatlarini standart nomlar maydonida ishga tushirish mantiqan to'g'ri keladi. Albatta, ko'proq moslashuvchanlik uchun siz ikkita nom maydonidan foydalanishingiz mumkin - prod va dev uchun alohida. Va, ehtimol, siz Minikube kabi biror narsadan foydalanib, o'zingizning ishlanmangizni mahalliy kompyuteringizda sinab ko'rasiz.
Aytaylik, hamma narsa o'zgardi va sizda bir vaqtning o'zida 10 dan ortiq mikroservislarda ishlaydigan jadal rivojlanayotgan jamoa bor. Vaqt keladiki, prod va dev uchun alohida bir nechta klasterlar yoki nomlar maydonidan foydalanish kerak bo'ladi. Siz jamoani bir nechta kichik guruhlarga bo'lishingiz mumkin, shunda ularning har biri o'z mikroservislariga ega va bu jamoalarning har biri dasturiy ta'minotni ishlab chiqish va chiqarishni boshqarish jarayonini osonlashtirish uchun o'z nom maydonini tanlashi mumkin.
Har bir jamoa a'zosi butun tizim qanday ishlashi haqida tushunchaga ega bo'lgach, har bir o'zgarishlarni boshqa barcha ishlab chiquvchilar bilan muvofiqlashtirish tobora qiyinlashib bormoqda. Mahalliy kompyuteringizda to'liq stekni yig'ishga urinish kundan-kunga qiyinlashib bormoqda.
Katta kompaniyalarda ishlab chiquvchilar odatda kim nima ustida ishlayotganini bilishmaydi. Jamoalar xizmat shartnomalari yordamida muloqot qiladilar yoki Istio konfiguratsiya vositasi kabi tarmoq orqali abstraksiya qatlamini qo'shadigan xizmat tarmog'i texnologiyasidan foydalanadilar. Butun stekni mahalliy sifatida ishga tushirishga urinish shunchaki mumkin emas. Men Kubernetesdagi Spinnaker kabi uzluksiz yetkazib berish (CD) platformasidan foydalanishni tavsiya qilaman. Shunday qilib, har bir buyruq, albatta, o'z nom maydoniga muhtoj bo'lgan nuqta keladi. Har bir jamoa hatto ishlab chiqaruvchi muhit va ishlab chiqarish muhiti uchun bir nechta nom maydonini tanlashi mumkin.
Va nihoyat, yirik tadbirkorlik kompaniyalari mavjud bo'lib, ularda ishlab chiquvchilarning bir guruhi boshqa guruhlarning mavjudligi haqida ham bilmaydi. Bunday kompaniya, odatda, yaxshi hujjatlashtirilgan API orqali u bilan o'zaro aloqada bo'lgan uchinchi tomon ishlab chiquvchilarini yollashi mumkin. Har bir bunday guruhda bir nechta jamoalar va bir nechta mikroservislar mavjud. Bunday holda, men ilgari aytib o'tgan barcha vositalardan foydalanishingiz kerak.
Dasturchilar xizmatlarni qo'lda ishlatmasliklari va ularga tegishli bo'lmagan nomlar bo'shliqlariga kirish imkoniga ega bo'lmasliklari kerak. Ushbu bosqichda noto'g'ri tuzilgan ilovalarning "portlash radiusi" ni kamaytirish, hisob-kitob jarayonlarini va resurslarni boshqarishni soddalashtirish uchun bir nechta klasterlarga ega bo'lish tavsiya etiladi.
Shunday qilib, tashkilotingiz tomonidan nomlar bo'shliqlaridan to'g'ri foydalanish Kubernetes-ni yanada boshqariladigan, boshqariladigan, xavfsiz va moslashuvchan qilish imkonini beradi.
Ba'zi reklamalar 🙂
Biz bilan qolganingiz uchun tashakkur. Bizning maqolalarimiz sizga yoqdimi? Ko'proq qiziqarli tarkibni ko'rishni xohlaysizmi? Buyurtma berish yoki do'stlaringizga tavsiya qilish orqali bizni qo'llab-quvvatlang, , Siz uchun biz tomonidan ixtiro qilingan boshlang'ich darajadagi serverlarning noyob analogi: (RAID1 va RAID10, 24 tagacha yadro va 40 Gb gacha DDR4 bilan mavjud).
Amsterdamdagi Equinix Tier IV ma'lumotlar markazida Dell R730xd 2 baravar arzonmi? Faqat shu yerda Gollandiyada! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollardan! Haqida o'qing
Manba: www.habr.com