diff --git a/pages/guides/k8s/k8s-klasterlarni-loyihalash.en-UZ.mdx b/pages/guides/k8s/k8s-klasterlarni-loyihalash.en-UZ.mdx index 06430cf..e394e16 100644 --- a/pages/guides/k8s/k8s-klasterlarni-loyihalash.en-UZ.mdx +++ b/pages/guides/k8s/k8s-klasterlarni-loyihalash.en-UZ.mdx @@ -49,11 +49,11 @@ Kubernetes klasterlarini loyihalashda turli yondashuvlar mavjud: ### Kamchiliklari -* **Yagona nuqtadagi nosozlik xavfi->** Agar klaster nosozlikka uchrasa, barcha applicationlar ta'sir ko'rsatadi. Misol uchun: **Yandex** servicelari uchun yagona klaster ishlatilsa, klasterning control plane qismi ishlamay qolsa, barcha applicationlar(masalan Yandex GO Yandex Eats va boshqalar) ishlamay qoladi. Bu katta biznes yo'qotishlariga olib kelishi mumkin, yana bir misol bunda **DEV, TEST, PROD** environmentlar bitta clusterda bo'lgani uchun **DEV** environmentdagi xatolik yoki clusterda qilingan xato butun klasterga o'z tasirini ko'rsatadi. +* **Yagona nuqtadagi nosozlik xavfi->** Agar klaster nosozlikka uchrasa, barcha applicationlar ta'sir ko'rsatadi. Misol uchun: **Yandex** servicelari uchun yagona klaster ishlatilsa, klasterning control plane qismi ishlamay qolsa, barcha applicationlar(masalan **Yandex Go Yandex Eats** va boshqalar) ishlamay qoladi. Bu katta biznes yo'qotishlariga olib kelishi mumkin, yana bir misol bunda **DEV, TEST, PROD** environmentlar bitta clusterda bo'lgani uchun **DEV** environmentdagi xatolik yoki clusterda qilingan xato butun klasterga o'z tasirini ko'rsatadi. -* **Xavfsizlik izolyatsiyasining yetishmasligi->** Applicationlar bir xil hardware va tarmoq resurslarini shared ishlatadi. Bu xavfsizlik zaifliklariga olib kelishi mumkin. Masalan Yandex Market service xavfsizlik zaifligi bo'lsa, bu zaiflik orqali Yandex Taxi yoki Yandex Music servicelariga kirib olish xavfi oshadi. +* **Xavfsizlik izolyatsiyasining yetishmasligi->** Applicationlar bir xil hardware va tarmoq resurslarini shared ishlatadi. Bu xavfsizlik zaifliklariga olib kelishi mumkin. Masalan **Yandex Market** service xavfsizlik zaifligi bo'lsa, bu zaiflik orqali **Yandex Go** yoki **Yandex Music** servicelariga kirib olish xavfi oshadi. -* ** Resurslar uchun raqobat->** Turli servicelar va jamoalar bir xil resurslar uchun raqobatlashadi, bu esa applicationlarning ish faoliyatiga salbiy ta'sir qilishi mumkin. Misol uchun **Yandex GO** platformasining ertalab **08:00-09:00 va 18:00-19:00** vaqt oralig'ida foydalanuvchilar platformadan ko'p foydalanasihadi va Yandex GO applicationlari birdan yuqori load ostida qoladi, va bu boshqa applicationlarning (masalan, Yandex Eats va Yandex Musics va boshqalar) ishlashini sekinlashtiradi sababi Yandex Go applicationlari high load tushib resurslarni yeb qo'yayapti )). +* **Resurslar uchun raqobat->** Turli servicelar va jamoalar bir xil resurslar uchun raqobatlashadi, bu esa applicationlarning ish faoliyatiga salbiy ta'sir qilishi mumkin. Misol uchun **Yandex Go** platformasining ertalab **08:00-09:00 va 18:00-19:00** vaqt oralig'ida foydalanuvchilar platformadan ko'p foydalanishadi va **Yandex Go** applicationlari birdan yuqori load ostida qoladi, va bu boshqa applicationlarning (masalan, **Yandex Eats** va **Yandex Musics** va boshqalar) ishlashini sekinlashtiradi sababi **Yandex Go** applicationlari high load tushib resurslarni yeb qo'yayapti )). * **Murakkab boshqaruv->** Ko'p jamoalar bir xil klasterdan foydalanganda, ularning kirish huquqlari va resurslaridan foydalanishlarini tartibga solish murakkablashadi. Har bir jamoa uchun **RBAC** rolelarini sozlash va boshqarish uchun qo'shimcha vaqt va kuch talab qilinadi. Agar bir jamoa noto'g'ri ruxsatga ega bo'lsa, boshqa servicelarga zarar yetkazishi mumkin. @@ -63,11 +63,11 @@ Kubernetes klasterlarini loyihalashda turli yondashuvlar mavjud: * **Kam xarajat va kam murakkablik talab qilinganida->** Resurslarni tejash va boshqaruvni soddalashtirish muhim bo'lsa. -* ***Qoshimcha izolyatsiya talab qilinmasa->** Agar applicationar xavfsizlik izolyatsiyasini talab qilmasa va bir-biriga ta'sir qilmaydigan darajada mustaqil ishlasa. +* **Qoshimcha izolyatsiya talab qilinmasa->** Agar applicationar xavfsizlik izolyatsiyasini talab qilmasa va bir-biriga ta'sir qilmaydigan darajada mustaqil ishlasa. * **Tezkor prototiplar uchun->** Yangi servicelar yoki applicationlarni tezroq ishga tushirish uchun umumiy klasterdan foydalanish mumkin. -**One Large Shared Cluster** kichik va o'rta hajmdagi tashkilotlar uchun samarali bo'lishi mumkin, chunki u infratuzilma xarajatlarini kamaytiradi va boshqaruvni soddalashtiradi. Ammo katta hajmdagi servicelarni boshqaruvchi kompaniyalar uchun bu yondashuv xavfsizlik va ishlash muammolariga olib kelishi mumkin. Yandex kabi kompaniyalar bu yondashuvni faqat kichik servicelar yoki environmentlar uchun qo'llashi mumkin, chunki asosiy servicelar uchun alohida klasterlar yaxshiroq ishlaydi. +**One Large Shared Cluster** kichik va o'rta hajmdagi tashkilotlar uchun samarali bo'lishi mumkin, chunki u infratuzilma xarajatlarini kamaytiradi va boshqaruvni soddalashtiradi. Ammo katta hajmdagi servicelarni boshqaruvchi kompaniyalar uchun bu yondashuv xavfsizlik va ishlash muammolariga olib kelishi mumkin. **Yandex** kabi kompaniyalar bu yondashuvni faqat kichik servicelar yoki environmentlar uchun qo'llashi mumkin, chunki asosiy servicelar uchun alohida klasterlar yaxshiroq ishlaydi. ## Many Small Single-Use Clusters @@ -77,21 +77,21 @@ Kubernetes klasterlarini loyihalashda turli yondashuvlar mavjud: ### Afzalliklari -* **Xavfsizlik va izolyatsiya->** Har bir application yoki project alohida klasterda ishlaydi, bu esa yuqori xavfsizlikni ta'minlaydi. Bir applicationning nosozligi boshqa applicationlarga ta'sir qilmaydi. Masalan Yandex Go platformasida Ordering amangement alohida clusterda va u clujster shunga moslab konfig qilingan bu clusterda load oshsa butunlay Yandex Go ishlamay qolmaydi balki ordering managenment service ishlamaydi xolos va boshqa servicelarga tasir qilmaydi. +* **Xavfsizlik va izolyatsiya->** Har bir application yoki project alohida klasterda ishlaydi, bu esa yuqori xavfsizlikni ta'minlaydi. Bir applicationning nosozligi boshqa applicationlarga ta'sir qilmaydi. Masalan **Yandex Go** platformasida **Ordering amangement** alohida clusterda va u cluster shunga moslab konfig qilingan bu clusterda load oshsa butunlay **Yandex Go** ishlamay qolmaydi balki ordering managenment service ishlamaydi xolos va boshqa servicelarga tasir qilmaydi. -* ** Resurslar bo'yicha mustaqillik->** Har bir klaster o'z resurslariga ega bo'ladi, bu resurslar uchun raqobatni yo'q qiladi. Misol uchun Yandex Music jonli kontsert streamlarini boshqarish uchun maxsus klaster yaratadi. Bu klaster faqat tadbir davomida ishlaydi va boshqa servicelarga load(yuklama) bermaydi. +* **Resurslar bo'yicha mustaqillik->** Har bir klaster o'z resurslariga ega bo'ladi, bu resurslar uchun raqobatni yo'q qiladi. Misol uchun **Yandex Music** jonli kontsert streamlarini boshqarish uchun maxsus klaster yaratadi. Bu klaster faqat tadbir davomida ishlaydi va boshqa servicelarga load(yuklama) bermaydi. -* **Moslashuvchanlik->** Har bir klaster o'zining maxsus talablariga mos keladigan konfiguratsiyaga ega bo'lishi mumkin. Masalan Yandex Market **"11 11"** aksiyalari davomida yangi mahsulotlarni tezda boshqarish uchun vaqtinchalik klaster yaratadi. Ushbu klaster boshqa servicelarga load bermasdan, aksiyani samarali boshqaradi. +* **Moslashuvchanlik->** Har bir klaster o'zining maxsus talablariga mos keladigan konfiguratsiyaga ega bo'lishi mumkin. Masalan **Yandex Market "11 11"** aksiyalari davomida yangi mahsulotlarni tezda boshqarish uchun vaqtinchalik klaster yaratadi. Ushbu klaster boshqa servicelarga load bermasdan, aksiyani samarali boshqaradi. -* **Nosozliklarni izolyatsiyalash->** Bir klasterdagi nosozlik boshqa klasterlarning ishlashiga ta'sir qilmaydi. Masalan Yandex Go'da "Shopir akalarni ulash" klasteri ishlamay qolgan taqdirda, "Soqqa boshqaruvi" yoki "Geolokatsiya servicelari" klasterlari ishlashda davom etadi. +* **Nosozliklarni izolyatsiyalash->** Bir klasterdagi nosozlik boshqa klasterlarning ishlashiga ta'sir qilmaydi. Masalan **Yandex Go**'da **"Shopir akalarni ulash"** klasteri ishlamay qolgan taqdirda, **"Soqqa boshqaruvi"** yoki **"Geolokatsiya servicelari"** klasterlari ishlashda davom etadi. ### Kamchiliklari -* **Boshqaruvning murakkabligi->** Ko'p klasterlarni boshqarish murakkab bo'lishi mumkin, ayniqsa, ular uchun monitoring, yangilanishlar(upgrade) va xavfsizlikni bir joyda boshqarish qiyinlashadi. Yandex IT jamoasi bir vaqtning o'zida 30 dan ortiq vaqtinchalik klasterlarni boshqarishi kerak. Bu esa yangilanishlar va xavfsizlikni ta'minlashni murakkablashtiradi, bu uchun yandexda devopslar ko'p bo'lishi kerak )) +* **Boshqaruvning murakkabligi->** Ko'p klasterlarni boshqarish murakkab bo'lishi mumkin, ayniqsa, ular uchun monitoring, yangilanishlar(upgrade) va xavfsizlikni bir joyda boshqarish qiyinlashadi. **Yandex IT** jamoasi bir vaqtning o'zida 30 dan ortiq vaqtinchalik klasterlarni boshqarishi kerak. Bu esa yangilanishlar va xavfsizlikni ta'minlashni murakkablashtiradi, bu uchun yandexda devopslar ko'p bo'lishi kerak )) -* **Ko'proq xarajatlar->** Har bir klaster uchun alohida control planelar talab qilinadi, bu esa infratuzilma xarajatlarini oshiradi. Yandex Music jonli tadbirlar uchun maxsus klasterlar tashkil qiladi. Tadbir tugagach, ushbu klasterlar kamdan-kam ishlatiladi, lekin infratuzilma xarajatlari saqlanib qoladi. +* **Ko'proq xarajatlar->** Har bir klaster uchun alohida control planelar talab qilinadi, bu esa infratuzilma xarajatlarini oshiradi. **Yandex Music** jonli tadbirlar uchun maxsus klasterlar tashkil qiladi. Tadbir tugagach, ushbu klasterlar kamdan-kam ishlatiladi, lekin infratuzilma xarajatlari saqlanib qoladi. -* **Resurslardan kam foydalanish->** Kichik klasterlarda resurslardan to'liq foydalanilmay qolishi mumkin, chunki ular boshqa klasterlar bilan share qilinmaydi. Masalan Yandex Disk yangi funksiyalarini sinash uchun yaratilgan klaster bir oy davomida kamdan-kam ishlatiladi, lekin server resurslari band bo'lib turaveradi. +* **Resurslardan kam foydalanish->** Kichik klasterlarda resurslardan to'liq foydalanilmay qolishi mumkin, chunki ular boshqa klasterlar bilan share qilinmaydi. Masalan **Yandex Disk** yangi funksiyalarini sinash uchun yaratilgan klaster bir oy davomida kamdan-kam ishlatiladi, lekin server resurslari band bo'lib turaveradi. ### Qachon foydalanish kerak? @@ -105,7 +105,7 @@ Kubernetes klasterlarini loyihalashda turli yondashuvlar mavjud: * **Vaqtinchalik servicelar->** Mavsumiy yoki vaqtinchalik tadbirlar uchun. -**Many Small Single-Use Clusters** yondashuvi maxsus talablar va vaqtinchalik servicelar uchun ideal. Yandex kabi katta kompaniyalarda ushbu yondashuv sinov muhiti, mavsumiy tadbirlar va yuqori yuklama(huigh load) talab qiladigan servicelar uchun qo'llanadi. Ammo ko'p sonli klasterlarni boshqarish va infratuzilma xarajatlari bo'yicha o'z cheklovlariga ega. Bu yondashuvni servicelarning izolyatsiyasi va xavfsizligi muhim bo'lgan joylarda ishlatish eng samarali hisoblanadi. +**Many Small Single-Use Clusters** yondashuvi maxsus talablar va vaqtinchalik servicelar uchun ideal. **Yandex** kabi katta kompaniyalarda ushbu yondashuv sinov muhiti, mavsumiy tadbirlar va yuqori yuklama(high load) talab qiladigan servicelar uchun qo'llanadi. Ammo ko'p sonli klasterlarni boshqarish va infratuzilma xarajatlari bo'yicha o'z cheklovlariga ega. Bu yondashuvni servicelarning izolyatsiyasi va xavfsizligi muhim bo'lgan joylarda ishlatish eng samarali hisoblanadi. ## Cluster Per Application @@ -114,23 +114,23 @@ Kubernetes klasterlarini loyihalashda turli yondashuvlar mavjud: ![k8s](https://raw.githubusercontent.com/devops-journey-uz/assets/main/images/tutorials/k8s/k8s-klasterlarni-loyihalash/3.png) ### Afzalliklari -* **To'liq izolyatsiya->** Har bir project o'z resurslariga ega bo'lib, bir-biridan to'liq izolyatsiya qilingan. Bir projectning ishlamay qolishi boshqa projectga ta'sir qilmaydi. Masalan **Yandex** o'zining **Yandex GO** service applicationlari uchun alohida klaster va **Yandex Eats** uchun yana bitta klaster tashkil etadi. Yandex Go ishlamay qolsa ham Yandex Eats ishlashda davom etadi bir birga ta'sir qilmaydi. +* **To'liq izolyatsiya->** Har bir project o'z resurslariga ega bo'lib, bir-biridan to'liq izolyatsiya qilingan. Bir projectning ishlamay qolishi boshqa projectga ta'sir qilmaydi. Masalan **Yandex** o'zining **Yandex Go** service applicationlari uchun alohida klaster va **Yandex Eats** uchun yana bitta klaster tashkil etadi. **Yandex Go** ishlamay qolsa ham **Yandex Eats** ishlashda davom etadi bir biriga ta'sir qilmaydi. -* **Maxsus konfiguratsiyalar->** Har bir klaster application o'ziga xos talablariga mos keladigan tarzda konfiguratsiya qilinishi mumkin. Masalan Yandex Go real vaqt rejimida buyurtmalarni boshqarish uchun yuqori yuklamalarni(high load) ko'tara oladigan kuchli hardware resurslarini talab qiladi. Shu bilan birga, Yandex Music stream servicelari uchun yuqori tarmoq(network) kenglikka ega konfiguratsiyaga ega bo'ladi. +* **Maxsus konfiguratsiyalar->** Har bir klaster application o'ziga xos talablariga mos keladigan tarzda konfiguratsiya qilinishi mumkin. Masalan **Yandex Go** real vaqt rejimida buyurtmalarni boshqarish uchun yuqori yuklamalarni(high load) ko'tara oladigan kuchli hardware resurslarini talab qiladi. Shu bilan birga, **Yandex Music** stream servicelari uchun yuqori tarmoq(network) kenglikka ega konfiguratsiyaga ega bo'ladi. -* **Xavfsizlikni oshirish->** Har bir klaster alohida firewall va qoidalariga ega bo'lgani uchun bir applicationning xavfsizlik muammosi boshqalarga ta'sir qilmaydi. Masalan Yandex Taxi mijozlarning to'lov ma'lumotlarini himoya qilish uchun kuchli xavfsizlik talablari bilan boshqariladi. Shu bilan birga, Yandex Musicda saqlanadigan ma'lumotlar (masalan, foydalanuvchi pleylistlari) uchun boshqa xavfsizlik darajasi talab qilinadi. +* **Xavfsizlikni oshirish->** Har bir klaster alohida firewall va qoidalariga ega bo'lgani uchun bir applicationning xavfsizlik muammosi boshqalarga ta'sir qilmaydi. Masalan **Yandex Go** mijozlarning to'lov ma'lumotlarini himoya qilish uchun kuchli xavfsizlik talablari bilan boshqariladi. Shu bilan birga, **Yandex Musicda** saqlanadigan ma'lumotlar (masalan, foydalanuvchi pleylistlari) uchun boshqa xavfsizlik darajasi talab qilinadi. -* **Moslashuvchanlik->** Applicationlarni alohida klasterlarda boshqarish yangi servicelarni qo'shishni osonlashtiradi va texnik talablar o'zgarganda qulay sozlash imkonini beradi. Masalan Yandex Books yaratildi. Ushbu service uchun yangi klaster yaratiladi va u mavjud servicelarga ta'sir qilmasdan mustaqil ishlaydi. +* **Moslashuvchanlik->** Applicationlarni alohida klasterlarda boshqarish yangi servicelarni qo'shishni osonlashtiradi va texnik talablar o'zgarganda qulay sozlash imkonini beradi. Masalan **Yandex Books** yaratildi. Ushbu service uchun yangi klaster yaratiladi va u mavjud servicelarga ta'sir qilmasdan mustaqil ishlaydi. ### Kamchiliklari -* **Ko'p xarajatlar->** Har bir klaster uchun control plane va boshqa infratuzilma resurslari talab qilinadi, bu esa infratuzilma xarajatlarini oshiradi. Masalan Yandexda 10 ta alohida service bo'lsa, har bir service uchun alohida klaster yaratish qo'shimcha serverlar, tarmoqlar va monitoring tizimlarini talab qiladi. Bu kichik kompaniyalar uchun qimmatga tushadi. -* ** Murakkab boshqaruv->** Bir nechta klasterlarni boshqarish va monitoring qilish murakkab bo'ladi. Yandex'da har bir service uchun alohida monitoring tollarini o'rnatish va kuzatib borish katta IT jamoasini talab qiladi. Klasterlarni yangilash va xavfsizlikni boshqarish ko'p vaqt va kuch talab etadi. -* **Resurslardan kam foydalanish->** Kichikroq servicelar uchun klasterlarning barcha resurslari to'liq ishlatilmasligi mumkin. Yandex Disk uchun yangi test(testing) muhiti klasteri yaratildi. Ammo bu klaster resurslardan to'liq foydalanmaydi, chunki service faqat test jarayonida ishlatiladi +* **Ko'p xarajatlar->** Har bir klaster uchun control plane va boshqa infratuzilma resurslari talab qilinadi, bu esa infratuzilma xarajatlarini oshiradi. Masalan **Yandex**da 10 ta alohida service bo'lsa, har bir service uchun alohida klaster yaratish qo'shimcha serverlar, tarmoqlar va monitoring tizimlarini talab qiladi. Bu kichik kompaniyalar uchun qimmatga tushadi. +* **Murakkab boshqaruv->** Bir nechta klasterlarni boshqarish va monitoring qilish murakkab bo'ladi. **Yandex**'da har bir service uchun alohida monitoring tollarini o'rnatish va kuzatib borish katta IT jamoasini talab qiladi. Klasterlarni yangilash va xavfsizlikni boshqarish ko'p vaqt va kuch talab etadi. +* **Resurslardan kam foydalanish->** Kichikroq servicelar uchun klasterlarning barcha resurslari to'liq ishlatilmasligi mumkin. **Yandex Disk** uchun yangi test(testing) muhiti klasteri yaratildi. Ammo bu klaster resurslardan to'liq foydalanmaydi, chunki service faqat test jarayonida ishlatiladi ### Qachon foydalanish kerak? -* **Katta miqyosli tizimlar->** Yandex kabi yirik kompaniyalarda har bir servicening mustaqilligi va xavfsizligi muhim. Shu sababli asosiy servicelar uchun alohida klasterlar zarur. +* **Katta miqyosli tizimlar-> Yandex** kabi yirik kompaniyalarda har bir servicening mustaqilligi va xavfsizligi muhim. Shu sababli asosiy servicelar uchun alohida klasterlar zarur. * **Maxsus talablar mavjud bo'lganda->** Agar servicelar bir-biridan butunlay farq qiluvchi talab va konfiguratsiyalarga ega bo'lsa, bu yondashuv mos keladi. @@ -138,7 +138,7 @@ Kubernetes klasterlarini loyihalashda turli yondashuvlar mavjud: * **Yangi servicelarni qo'shish->** Agar kompaniya yangi servicelarni tezkor tarzda yaratishni xohlasa, har bir service uchun mustaqil klaster yaratish qulaylikni oshiradi. -**Cluster Per Application** yondashuvi katta tashkilotlar uchun qulay, chunki u servicelarning mustaqilligini ta'minlaydi va xavfsizlikni oshiradi. Ammo bu yondashuv infratuzilma xarajatlari va boshqaruv murakkabligi bo'yicha kichik kompaniyalar uchun mos kelmasligi mumkin. Yandex kabi kompaniyalarda bu yondashuv asosiy servicelar uchun samarali ishlaydi. +**Cluster Per Application** yondashuvi katta tashkilotlar uchun qulay, chunki u servicelarning mustaqilligini ta'minlaydi va xavfsizlikni oshiradi. Ammo bu yondashuv infratuzilma xarajatlari va boshqaruv murakkabligi bo'yicha kichik kompaniyalar uchun mos kelmasligi mumkin. **Yandex** kabi kompaniyalarda bu yondashuv asosiy servicelar uchun samarali ishlaydi. ## Cluster Per Environment @@ -148,21 +148,21 @@ Kubernetes klasterlarini loyihalashda turli yondashuvlar mavjud: ### Afzalliklari -* **Muhitlar(environment) orasidagi izolyatsiya->** Har bir environment mustaqil ishlaydi, bu esa bir environmentdagi nosozlikning boshqasiga ta'sir qilish xavfini yo'q qiladi. Masalan Yandexda yangi Yandex Music funksiyasini ishlab chiqishda dasturchilar uni **DEV** klasterida sinab ko'rishadi. Bu jarayon **PROD** klasteriga ta'sir qilmaydi va userlar uchun service uzulishlarsiz ishlashni davom etadi. +* **Muhitlar(environment) orasidagi izolyatsiya->** Har bir environment mustaqil ishlaydi, bu esa bir environmentdagi nosozlikning boshqasiga ta'sir qilish xavfini yo'q qiladi. Masalan **Yandexd**a yangi **Yandex Music** funksiyasini ishlab chiqishda dasturchilar uni **DEV** klasterida sinab ko'rishadi. Bu jarayon **PROD** klasteriga ta'sir qilmaydi va userlar uchun service uzulishlarsiz ishlashni davom etadi. -* **Maxsus konfiguratsiyalar->** Har bir klaster maxsus talablar va konfiguratsiyalarga moslashtiriladi. Masalan Yandex GOda prod(production) klasteri yuqori quvvatli serverlar va yaxshi load balancing tizimlariga ega. Shu bilan birga, test va dev klasteri oddiyroq konfiguratsiyaga ega bo'lib, test jarayonlari uchun yetarli. +* **Maxsus konfiguratsiyalar->** Har bir klaster maxsus talablar va konfiguratsiyalarga moslashtiriladi. Masalan **Yandex Go**'da prod(production) klasteri yuqori quvvatli serverlar va yaxshi load balancing tizimlariga ega. Shu bilan birga, test va dev klasteri oddiyroq konfiguratsiyaga ega bo'lib, test jarayonlari uchun yetarli. -* **Xavfsizlikni oshirish->** prod(production) klasteri test yoki dev klasteridan to'liq izolyatsiya qilinadi, bu ma'lumotlarning xavfsizligini ta'minlaydi. Masalan Yandex GOda test klasteri faqat test ma'lumotlari bilan ishlaydi, foydalanuvchilar ma'lumotlari esa prod klasterida saqlanadi. +* **Xavfsizlikni oshirish->** prod(production) klasteri test yoki dev klasteridan to'liq izolyatsiya qilinadi, bu ma'lumotlarning xavfsizligini ta'minlaydi. Masalan **Yandex Go**'da test klasteri faqat test ma'lumotlari bilan ishlaydi, foydalanuvchilar ma'lumotlari esa prod klasterida saqlanadi. -* **Nosozliklarni izolyatsiyalash->** Test environmentdagi xatoliklar proddagi servicelariga ta'sir qilmaydi. Masalan Yandex Eats'da test klasterida payment bo'yich issue chiqdi yoki xavfsizlik bo'yicha issue topildi bunday holda bu muammolar faqat test klasteri uchun prod klasterga hech qanday ta'siri bo'lmaydi. +* **Nosozliklarni izolyatsiyalash->** Test environmentdagi xatoliklar proddagi servicelariga ta'sir qilmaydi. Masalan **Yandex Eats**'da test klasterida payment bo'yich issue chiqdi yoki xavfsizlik bo'yicha issue topildi bunday holda bu muammolar faqat test klasteri uchun prod klasterga hech qanday ta'siri bo'lmaydi. ### Kamchiliklari -* **Ko'proq xarajatlar-> Har bir environment uchun alohida klaster yaratish infratuzilma xarajatlarini oshiradi. Yandex misolida Yandex uchun prod, test va dev environmentlarini alohida boshqarish har bir klaster uchun qo'shimcha serverlar, tarmoq resurslari va monitoring tizimlarini talab qiladi. +* **Ko'proq xarajatlar->** Har bir environment uchun alohida klaster yaratish infratuzilma xarajatlarini oshiradi. Yandex misolida Yandex uchun prod, test va dev environmentlarini alohida boshqarish har bir klaster uchun qo'shimcha serverlar, tarmoq resurslari va monitoring tizimlarini talab qiladi. * **Murakkab boshqaruv->** Ko'plab klasterlarni boshqarish va ularni sinxronlashtirish murakkablikni oshiradi. Yandex IT jamoasi prod environmentdagi xavfsizlik qoidalarini(security rule) test va dev klasterlarida ham sinxronlashtirishi kerak, bu esa qo'shimcha vaqt va resurs talab qiladi. -* **Resurslardan kam foydalanish->** Kichikroq environment uchun yaratilgan klasterlar to'liq yuklanmaydi(load bo'lmaydi), bu resurslarni noto'liq ishlatishga olib keladi. Yandex GO test klasteri faqat test davrida ishlatiladi, lekin qolgan vaqt davomida resurslar bo'sh qoladi. +* **Resurslardan kam foydalanish->** Kichikroq environment uchun yaratilgan klasterlar to'liq yuklanmaydi(load bo'lmaydi), bu resurslarni noto'liq ishlatishga olib keladi. **Yandex Go** test klasteri faqat test davrida ishlatiladi, lekin qolgan vaqt davomida resurslar bo'sh qoladi. ### Qachon foydalanish kerak? @@ -186,7 +186,7 @@ Kubernetes klasterlarini loyihalashda turli yondashuvlar mavjud: * **Tarmoqli kechikishni kamaytirish->** Servicelar foydalanuvchilarga yaqin joyda joylashgani uchun tarmoq trafigi tezkor bo'ladi. Masalan Yandex Rossiya foydalanuvchilari uchun Moskva yoki Sankt-Peterburgda joylashgan klasterlardan foydalanadi. Yevropa foydalanuvchilari uchun esa Frankfurt shahrida joylashgan klaster xizmat ko'rsatadi. -* **Servicening barqarorligini(stabillik) oshirish->** Bitta hududdagi nosozlik boshqa hududlardagi foydalanuvchilarga ta'sir qilmaydi. Yandex GOning Yevropa klasterida nosozlik yuzaga kelsa, Rossiya yoki Osiyo foydalanuvchilari bundan ta'sir ko'rmaydi. +* **Servicening barqarorligini(stabillik) oshirish->** Bitta hududdagi nosozlik boshqa hududlardagi foydalanuvchilarga ta'sir qilmaydi. Yandex Go'ning Yevropa klasterida nosozlik yuzaga kelsa, Rossiya yoki Osiyo foydalanuvchilari bundan ta'sir ko'rmaydi. * **Huquqiy va mintaqaviy talablarni qondirish->** Har bir hududning huquqiy talablariga moslashish oson bo'ladi. Masalan Yevropa Ittifoqi ma'lumotlarni saqlash uchun **GDPR** (General Data Protection Regulation) talablariga rioya qilishi kerak. Shu sababli, Yandex Yevropa foydalanuvchilari ma'lumotlarini Frankfurt klasterida saqlaydi.