Kubernetes Obyektlari

Kubernetes - konteyner operatsiyalarini avtomatlashtiradigan open source platforma. Bu konteynerlashtirilgan applicationlarni deploy qilish va scaling(masshtablash) bilan bog'liq ko'plab qo'lda ishlov berish jarayonlarini avtomatlashtiradi. Asosan, Kubernetes distributed systemlarni barqaror ishlash uchun asos yaratadi, applicationngiz uchun masshtablash(scaling ) va failover, deploy qilish patternlarini taʼminlaydi va hokazo. Masalan, Kubernetes tizimingiz uchun canary deploymentni osongina boshqarishi mumkin.

U dastlab Google tomonidan ishlab chiqilgan va hozirda Cloud Native Computing Foundation tomonidan yuritiladi. Tizim yagona birlik sifatida ishlash uchun ulangan kompyuterlarning yuqori darajada mavjud(highly available) clusterini muvofiqlashtiradi. U taqdim etgan abstraction sizga konteynerlashtirilgan applicationlarni alohida machinelarga bog'lamasdan clusterga deploy qilish imkonini beradi.

Kubernetes cluster bo'ylab dastur konteynerlarini yanada samaraliroq taqsimlash(distribution) va rejalashtirishni(scheduling) avtomatlashtiradi. Kubernetes clusteri konteynerlashtirilgan applicationlarni ishga tushiradigan nodelar deb ataladigan worker machinelar(ishchi serverlar) to'plamidan iborat. Har bir clusterda kamida bitta worker node mavjud.

Worker node(lar) dastur workloadning komponentlari bo'lgan podlarni joylashtiradi. Control plane worker nodelarni va clusterdagi podlarni boshqaradi. Production environmentida control plane odatda bir nechta kompyuterlar bo'ylab ishlaydi va cluster odatda xatolarga chidamlilik va yuqori mavjudlikni(high availability) ta'minlaydigan bir nechta nodelarni boshqaradi.

Kubernetes shuningdek, service discovery va load balancing, storage orchestration, avtomatlashtirilgan rollout(ishga tushirish) va rollback(orqaga qaytarish), self-healing(o'z-o'zini davolash), secret va configuration managementni taklif qiladi. Bu xususiyatlar murakkab deployment va operatsiyalarni, jumladan, zero-downtime, oldingi versiyalarga qaytarish(rollback) va applicationlaringiz uchun maxfiy maʼlumotlarni boshqarish imkonini beradi.

Bundan tashqari, Kubernetes kengaytiriladigan boʻlishi uchun moʻljallangan boʻlib, Custom Resource Definitionlari kabi xususiyatlarga ega boʻlib, sizga oʻz API resurslaringizni yaratishga imkon beradi va uni turli workflowlari va foydalanuvchi ehtiyojlariga moslashtiradi. Bu Kubernetesni konteyner orkestratsiyasi va cloud-native development sohasida poydevor sifatida mustahkamlab, uning atrofida tollar, servicelar va qo'llab-quvvatlashning keng ekotizimiga olib keldi.

Kubernetes obyektlari Kubernetes tizimidagi doimiy obyektlardir(persistent entities). Kubernetes ushbu obyektlardan clusteringiz holatini(stateni) ko'rsatish uchun foydalanadi. Kubernetes obyekti odatda o'zi ko'rsatadigan resurs uchun "desired state(kerali holat)" ni belgilaydi. Kubernetes tizimi obyekt tomonidan ko'rsatilgan istalgan holatga mos keladigan joriy holatni doimiy ravishda boshqaradi.

k8s

Har bir obyekt obyekt konfiguratsiyasini belgilaydigan ikkita ichki o'rnatilgan obyekt maydonini o'z ichiga oladi: object spec va object status.

Siz taqdim etishingiz kerak bo'lgan spec(spetsifikatsiya) obyektning kerakli stateni(holatini) tavsiflaydi.
status Kubernetes tizimi tomonidan taqdim etilgan va yangilangan obyektning joriy holatini tavsiflaydi.

Obyektlar odatda YAML yoki JSON fayllarida aniqlanadi va keyin Kubernetes API bilan yaratiladi. Obyekt kind(turi) siz yaratmoqchi bo'lgan Kubernetes obyektining turini belgilaydi, masalan, Pod, Service yoki Deployment.

Diqqat!!! Ushbu qo'llanmada barcha Kubernetes Obyektlari qisqa yoritilgan. Keyingi qismlarda har bir Obyektlar to'liqroq yoritiladi!

Pod

k8s

Kubernetesdagi pod - Kubernetes applicationlarining asosiy qurilish bloki bo'lib, u yaratilishi(create), rejalashtirilishi(schedule) va boshqarilishi mumkin bo'lgan eng kichik deploymment unit vazifasini bajaradi. Bu, asosan, bir yoki bir nechta konteynerlarni o'rab oladigan, odatda mahkam bog'langan va resurslarni bo'lishishi kerak bo'lgan o'ram(wrapper). Har bir Pod o'zining IP manzili bilan ishlaydi, bu unga Kubernetes clusteridagi boshqa Podlar va servicelar bilan bog'lanish imkonini beradi. Pod ichida konteynerlar IP-manzil va port spaceni almashadilar va bir-birlarini localhost orqali topishlari mumkin. Ular, shuningdek, Pod levelida ko'rsatilgan Kubernetes volumelari orqali fayllarni almashishlari mumkin.

Pod yaratilganda, u clusterdagi node ustida ishlashi rejalashtirilgan va jarayon tugatilgunga qadar, Pod o'chirilguncha, Pod biron sababga ko'ra chiqarib yuborilmaguncha yoki node ishlamay qolguncha u erda qoladi. Har bir Pod holati Kubernetes API da taqdim etilgan va uni Kubernetes API yoki uning buyruq qatori interfeysi orqali boshqarish mumkin.

Pod anatomiyasi

Konteynerlar Har bir pod bir yoki bir nechta konteynerlarni ishlatish uchun mo'ljallangan. Bular Docker instancelari yoki application kodingizni saqlaydigan boshqa konteyner runtime muhiti.

Volumelar Pod shared storage volumelari to'plamini belgilashi mumkin. Pod ichidagi konteynerlar ma'lumotlarni almashish uchun ushbu volumelardan foydalanishi mumkin. Volumelar, shuningdek, konteynerni qayta ishga tushirishda ma'lumotlarning saqlanib qolishiga imkon beradi.

Networking Har bir Podga cluster ichida noyob IP-manzil beriladi, bu esa applicationlarga portlardan ziddiyat xavfisiz foydalanish imkonini beradi. Pod ichidagi konteynerlar network namespaceni baham ko'radi, ya'ni ular localhost yordamida bir-biri bilan bog'lanishlari mumkin.

Pod haqida ma'lumot Bunga Pod nomi, noyob(unique) UID va namespacelar kiradi.

Pod Lifecycli

Yaratish(Creation) Pod yaratilganda (odatda Deployment orqali yoki to'g'ridan-to'g'ri YAML faylidagi Pod ta'rifidan), Kubernetes master Podni clusterdagi ma'lum bir nodeda ishlashni rejalashtiradi(schedule).

Ishlash(Running) Nodedagi kubelet, agar mavjud bo'lmasa, kerakli konteyner imagelarini tortib(pull) olgandan so'ng, konteynerning runtimedan foydalanib, Pod spetsifikatsiyasida belgilangan konteynerlarni ishga tushiradi.

Termination Podlar jarayonlari tugallangandan so'ng qulay tarzda tugatilishi yoki ularni majburan o'chirib(force delete) tashlashi mumkin. Pod terminate qilinganda, uning resurslari bo'shatiladi va uning IP manzili qayta ishlanadi.

Kubernetes scheduler resurslar mavjudligi, cheklovlar, affinity specificationlari va boshqa omillarga asoslanib, Pod qaysi nodeda ishlashini aniqlaydi.

Pod Communication

Pod-to-Pod Communication Podlar bir-biri bilan IP manzillari orqali nodelar bo'ylab aloqa qiladi. Nodelar bo'ylab ushbu podlar aro aloqa clusterdagi overlay network orqali amalga oshiriladi.

Pod-to-Service Communication Podlar odatda belgilangan IP-manzilga ega bo'lgan servicelar bilan bog'lanadi. Bu Pod masshtablash(scaling) va Pod nosozliklarini abstraksiya qilish imkonini beradi, chunki Service IP barqaror bo'lib qoladi.

Multi-Container Podlar

Podlar birgalikda ishlashi kerak bo'lgan bir nechta konteynerlarni ishlatishi mumkin. Birgalikda joylashgan ushbu konteynerlar yagona Service ko'rsatish birligini(single cohesive unit) tashkil qiladi, masalan, shared volumeda saqlangan ma'lumotlarga Service ko'rsatadigan bitta konteyner, boshqa sidecar(qo'shni) konteyner esa bu fayllarni refresh qiladi yoki yangilaydi. Ko'p konteynerli(multi-container) Poddagi konteynerlar xuddi bitta konteyner kabi bir xil lifecycle, local network va storagega ega.

k8s

Best Practica!

Podlar stateless va immutable(oʻzgarmas) boʻlishi kerak: hech qanday doimiy(persistent) maʼlumotlarni toʻgʻridan-toʻgʻri Podda saqlamang va Podning compute konfiguratsiyasi qayta ishga tushirilganda ham davom etishini kutmang. Sizda barcha saqlangan ma'lumotlar o'chib ketadi!!!

Stateful applicationlar StatefulSet-dan foydalanishi kerak: Ular doimiy(persistent) ma'lumotlar va holatga oid(stateful) applicationlar bilan ishlash uchun mo'ljallangan bo'lib, hatto Podni qayta yaratish kerak bo'lganda ham bu holat saqlanishini ta'minlaydi.

Stateless applicationlar uchun Deploymentdan foydalaning: Deploymentlar maʼlum miqdordagi Podlar application kodini ishlayotganligiga ishonch hosil qiladi.

Podlar applicationning ish muhitini qamrab oladi: dasturiy ta'minot(software), runtime, kutubxonalar(library) va vaqtinchalik holatlar(ephemeral states). Podlarni tushunish juda muhim, chunki ular Kubernetes clusterida asosiy deploy qilinadigan obyekt bo'lib Service qiladi.

Servicelar

k8s

Kubernetesda Service - bu podlarning logical setini(to'plamini) va ularga kirish(access) policyni belgilaydigan abstraction. Ushbu abstraction iste'molchilarning(consumer) Podlar va Podlarni o'zlari qanday ko'rishlari o'rtasida ajratish imkonini beradi. Podlar doimiy bo'lmagan(non-permanent) resurslar bo'lsa, bu kashf qilish va doimiy mavjudlik(continuous availability) uchun muammo tug'diradi. Servicelar buni Podlarga oʻzining barqaror(stable) IP manzilini va Serviceni tanlash mezonlariga(selector criteria) mos keladigan joriy ishlayotgan Podlar toʻplamiga load-balancing qiluvchi trafikni berish orqali hal qiladi.

Servicelar Kubernetes obyektlarini guruhlash va tanlashning standart usuli bo‘lgan teglar(label) va selectorlardan foydalangan holda Podlar to‘plamiga mos keladi. Misol uchun, Service app=backend labeli bilan barcha podlarni boshqarish mumkin. Pod ushbu labelga ega bo'lsa va selectorga mos kelsa, trafik unga Service orqali yo'naltirilishi mumkin.

k8s

Servicening asosiy rollaridan biri load balancingni(yukni muvozanatlash) boshqarishdir. Kubernetes har bir Servicega o'zining IP-manzilini va DNS nomini beradi, boshqa podlar uni topish va unga kirish uchun foydalanishi mumkin. Trafik Servicening IP-manziliga yo'naltirilganda, Service load balancing policy asosida tarmoq trafigini tegishli Podga avtomatik ravishda taqsimlaydi.

Kubernetes Servicelari bir nechta turlarni qo'llab-quvvatlaydi, ularning har biri Podlarga turli xil kirish imkonini beradi:

ClusterIP

Ushbu default tur Serviceni cluster-internal(ichki) IP-da ko'rsatadi. Ushbu qiymatni tanlash Serviceni faqat cluster ichidan foydalanish imkoniyatini beradi. k8s k8s

NodePort

Bu tur har bir nodening IP-da statik portda (NodePort) Service ko'rsatadi. NodePort Serviceni yo'naltiriladigan ClusterIP Serviceni avtomatik ravishda yaratiladi. NodePort Servicega cluster tashqarisidan <NodeIP>:<NodePort> so'rovi orqali murojaat qilishingiz mumkin. k8s k8s

LoadBalancer

Bu tur cloud providerlarining load balanceridan foydalangan holda Serviceni tashqi ko'rinishda(external) namoyish etadi(expose qiladi). NodePort va ClusterIP Servicelari, ular uchun tashqi load balanceri yo'nalishlari(route) avtomatik ravishda yaratiladi. k8s

ExternalName

Bu tur Serviceni externalNamening mazmuniga (masalan, test.sanjar.uz(domenga)) uning qiymati bilan CNAME yozuvini qaytaradi. Hech qanday proksi-server o'rnatilmagan. k8s

Servicelar Podlarning davom etayotgan holatini kuzatib boradi va trafikni faqat mavjud resurslarga yo'naltiradi, ya'ni Pod o'chib qolsa yoki o'chirilsa, Service trafikni qolgan sog'lom podlardan biriga yo'naltiradi. Bu o'zgaruvchan yangilanishlarni amalga oshirish va applicationlar uchun yuqori mavjudlikni ta'minlash usulini ta'minlaydi.

Selector-based discoveryga qo'shimcha ravishda, Servicelarni Kubernetesdagi DNS orqali topish mumkin. Service yaratilganda, unga DNS nomi beriladi, bu boshqa Servicelarga Servicening IP-manzilini hal qilish va haqiqiy Pod IP-larni bilmasdan muloqot qilish imkonini beradi.

Servicelar Kubernetes clusterida doimiy obyekt bo'lib qoladi, ular ko'pincha ular ko'rsatgan podlardan oshib ketadi. Ushbu barqarorlik tufayli Servicelar Kubernetes-ga asoslangan applicationning network layerining muhim tarkibiy qismidir, chunki ular qayta rejalashtirish(rescheduling) yoki o'z-o'zini davolash(self-healing) tufayli cluster bo'ylab qayerda va qanday harakatlanishidan qat'i nazar, ishlaydigan podlarga kirish uchun izchil kirish nuqtasini ta'minlaydi.

Volumelar

k8s

Kubernetesda volume bu abstraction(mavhum) bo'lib, saqlash muddati Podning ishlash muddatidan tashqari davom etishiga imkon beradi, bu vaqt o'tishi bilan kelishi va ketishi mumkin bo'lgan konteynerlarning vaqtinchalik xususiyatini hisobga olgan holda muhimdir. Kubernetes-dagi volumelar, shuningdek, Pod-dagi konteynerlar o'rtasida taqsimlanadigan fayl tizimlari muammosini ham hal qiladi.

Volumelar local storage, public cloud provayderlari, network storage tizimlari va boshqalar kabi turli xil storage tizimlari bilan qo'llab-quvvatlanishi mumkin, bu turli ehtiyojlarga mos keladigan keng imkoniyatlarni taqdim etadi. Ushbu storage vaqtinchalik(ephemeral) bo'lishi mumkin, u Pod qancha davom etishi yoki doimiy bo'lib, undan foydalanadigan Poddan uzoqroq bo'lishi mumkin.

Pod Level

Pod spetsifikatsiyasi doirasida volume e'lon qilinadi va Pod ichidagi barcha konteynerlar unga kirishi mumkin. Har bir konteynerning volumega kirishi mustaqildir; masalan, bitta konteyner volumega yozishi mumkin, boshqasi esa faqat undan o'qiydi.

Lifecycle

Kubernetes volumening lifecycle uni o'rab turgan Pod bilan bog'langan. U Pod ishga tushirilganda yaratilishi va mountlanishi va Pod o'chirilganda unmount qilinishi va o'chirilishi mumkin, ya'ni ba'zi volume turlari uchun, agar bu persistent volume turi bo'lmasa, ma'lumotlar shu nuqtada yo'qolishi mumkin.

Persistent Volumelar

Podning lifecycledan keyin davom etadigan saqlash ehtiyojlari uchun Kubernetes PersistentVolumes (PV) va PersistentVolumeClaims (PVC) ga ega. PersistentVolume - bu podlardan mustaqil ravishda mavjud bo'lgan cluster resursi va dinamik ravishda yoki administrator tomonidan oldindan tayyorlanishi mumkin. PersistentVolumeClaim - bu PersistentVolume resursiga so'rov(request) va unga claim bo'lib, uni dinamik ravishda ta'minlanishi mumkin bo'lgan saqlash uchun foydalanuvchi so'rovi sifatida ko'rish mumkin.

Sharing and Persistence

Kubernetes bir nechta Podlar tomonidan ishlatilishi mumkin bo'lgan shared volumelarni(umumiy) (ayniqsa, bitta node ichida) va Podni rescheduling va hatto o'chirishda ma'lumotlarning saqlanishini ta'minlaydigan doimiy volumelarni qo'llab-quvvatlaydi.

Volume turlari

Kubernetes tomonidan qo'llab-quvvatlanadigan volumelarning ko'p turlari mavjud, masalan,

emptyDir (Pod nodedan olib tashlanganida o'chiriladi),
hostPath (host nodening fayl tizimidan fayl yoki katalogni Podga o'rnatadi), AWS Elastic Block Store, Google Persistent Disk, Azure Disk Storage, NFS mounts va boshqalar kabi cloud storage servicelari. Kubernetes-dagi volumelar ma'lumotlarni boshqarish va saqlashning moslashuvchan usulini ta'minlaydi, saqlash ehtiyojlarini alohida Podlarning lifecycledan ajratadi. Bu holat komponentlar (podlar va ularning konteynerlari) stateless va transient bo'lgan tizimda saqlanishini ta'minlaydi. Bu qobiliyat stateni saqlash, ma'lumotlarni saqlash yoki ikkalasini ham talab qiladigan applicationlar uchun juda muhimdir.

k8s

Namespacelar

k8s

Kubernetes Namespace - bu clusterni bir nechta virtual clusterlarga bo'lish usuli. Kubernetesda namespacelari bitta cluster ichidagi resurslar guruhlarini ajratish mexanizmini ta'minlaydi. Resurs nomlari namespaceda emas, balki namespaceda yagona bo'lishi kerak. Namespacega asoslangan qamrov faqat namespacedagi obyektlar (masalan, Deploymentlar, Servicelar va boshqalar) uchun qo'llaniladi va cluster miqyosidagi obyektlar (masalan, StorageClass, Nodelar, PersistentVolumelar va boshqalar) uchun emas. Bu jismoniy Kubernetes clusterida alohida workspace(ish maydoni) yoki virtual cluster yaratish kabi. Har bir namespace cluster ichidagi obyektlarni yaxshiroq tashkil qilish, resurslarni izolyatsiya qilish va boshqarish imkonini beruvchi resurslar uchun o'z doirasini ta'minlaydi.

Kubernetes ichida mavjud bo'lgan har qanday resurs default namespaceda yoki cluster operatori tomonidan yaratilgan namespaceda mavjud. Namespacedan tashqarida faqat nodelar va persistent storage volumelari mavjud; bu past darajadagi resurslar har doim clusterdagi har bir namespacega ko'rinadi.

`default` namespace

Obyektlarni namespaceni ko'rsatmasdan yaratganingizda, ular default namespaceda yaratiladi. Kubernetes uchta namespace bilan birga keladi.

default Nomidan ko'rinib turibdiki, bu har bir Kubernetes buyrug'i uchun default bo'yicha reference qilingan namespace va har bir Kubernetes resursi default bo'yicha joylashgan joyda. Yangi namespacelar yaratilgunga qadar, butun cluster default holatda bo'ladi.
kube-system kube-system namespaceni Kubernetes tizim komponentlari uchun ajratilgan. Bunga kube-dns, kube-proxy va boshqa clusterning to'g'ri ishlashi uchun muhim bo'lgan muhim komponentlar kiradi.
kube-public kube-public namespace avtomatik ravishda yaratiladi va barcha foydalanuvchilar (shu jumladan autentifikatsiya qilinmaganlar) tomonidan o'qilishi mumkin. U ko'pincha hamma foydalanuvchilar uchun ochiq bo'lishi kerak bo'lgan resurslar uchun ishlatiladi, masalan, umumiy ma'lumot(public information) yoki konfiguratsiya fayllari.

Nima uchun Kubernetes namespacelaridan foydalanish kerak?

Kubernetes namespacelari uchun ko'plab foydalanish holatlari mavjud, jumladan:

Jamoalar yoki loyihalarga bir-birining ishiga ta'sir qilishdan qo'rqmasdan o'zlarining virtual clusterlarida mavjud bo'lishiga ruxsat berish.
Foydalanuvchilar va jarayonlarni ma'lum namespacelariga cheklash orqali role-based access controls (RBAC) yaxshilash.
cluster resurslarini resurs kvotalari orqali bir nechta jamoalar va foydalanuvchilar o'rtasida taqsimlashni yoqish.
Konteynerli applicationlarni ishlab chiqish, sinovdan o'tkazish va deploymentni ajratishning oson usulini ta'minlash, butun lifecycle bir xil clusterda amalga oshirish imkonini beradi.

Bir nechta Kubernetes namespacelaridan qachon foydalanish kerak?

Kichik jamoalar yoki kichikroq tashkilotlar default namespacedan foydalanishi mumkin. Bu, ayniqsa, developerlar yoki foydalanuvchilarni bir-biridan ajratishning hojati bo'lmasa, dolzarbdir. Biroq, bir namespacega ega bo'lishning ko'plab foydali afzalliklari bor, jumladan:

Izolyatsiya. Katta yoki o'sib borayotgan jamoalar o'z loyihalari va microservicelarini bir-biridan ajratish uchun namespacelardan foydalanishlari mumkin. Jamoalar muammosiz bir xil resurs nomlarini workspacelarida qayta ishlatishlari mumkin. Bundan tashqari, bitta workspacedagi elementlarga amal qilish boshqa workspacelariga hech qachon ta'sir qilmaydi. Masalan Development, Testing, Production namespacelarochib ishlash.
Organization Development, Testing va Production uchun yagona clusterdan foydalanadigan organizatsiyalar test environment ishlab chiqish va test environment uchun namespacelaridan foydalanishi mumkin. Bu developerlar yoki testerlar dasturning lifecycle davomida o'z namespacelarida kiritgan o'zgarishlar ishlab chiqarish kodiga ta'sir qilmasligini ta'minlaydi.
Permissionlar. Namespacelar Kubernetes RBAC-dan foydalanishga imkon beradi, shuning uchun jamoalar permissionlar(ruxsat) yoki abilitielar ro'yxatini bitta nom ostida guruhlaydigan rollarni belgilashlari mumkin. Bu ma'lum bir namespacedagi resurslarga faqat ruxsat(access) berilgan foydalanuvchilar kirishini ta'minlashi mumkin.
Resource Control Protsessor yoki xotiradan foydalanish uchun resurs kvotalarini belgilash orqali polisga asoslangan resurs cheklovlari namespacelarida o'rnatilishi mumkin. Bu har bir loyiha yoki namespace ishga tushirish uchun zarur bo'lgan resurslarga ega bo'lishini va hech bir namespace barcha mavjud resurslarni ishlatmasligini ta'minlaydi.
Performance Namespacelardan foydalanish berilgan clusterning ish faoliyatini(performance) yaxshilashga yordam beradi. Agar cluster turli loyihalar uchun bir nechta namespacega ajratilgan bo'lsa, Kubernetes API operatsiyalarni bajarishda qidirish uchun kamroq elementlarga ega bo'ladi. Bu clusterda ishlayotgan har bir application uchun kechikish vaqtini kamaytirishi va umumiy dastur ishlashini tezlashtirishi mumkin.

Workloads

k8s

Workloads Kubernetes-da ishlaydigan dasturdir. Sizning workloadigiz bitta komponent bo'ladimi yoki birgalikda ishlaydigan bir nechta bo'ladimi, Kubernetes-da siz uni podlar to'plamida ishlatasiz. Kubernetes-da Pod sizning clusteringizdagi ishlaydigan konteynerlar to'plamini ifodalaydi. Kubernetes podlari aniqlangan lifecyclega ega. Misol uchun, bir marta sizning clusteringizda pod ishlayotgan bo'lsa, u ishlayotgan nodedagi tanqidiy nosozlik bu nodedagi barcha podlarning ishlamay qolganligini anglatadi. Kubernetes muvaffaqiyatsizlik darajasini yakuniy deb hisoblaydi: agar node keyinchalik sog'lom bo'lsa ham, tiklanish uchun yangi Pod yaratishingiz kerak bo'ladi. Biroq, hayotni sezilarli darajada osonlashtirish uchun har bir Podni bevosita boshqarishingiz shart emas. Buning o'rniga siz o'z nomingizdan bir qator podlarni boshqaradigan workload resurslaridan foydalanishingiz mumkin. Ushbu manbalar siz ko'rsatgan holatga mos keladigan to'g'ri turdagi podlarning to'g'ri soni ishlayotganiga ishonch hosil qiluvchi kontrollerlarni sozlaydi.

Kubernetes bir nechta built-in workload resourcelarini taqdim etadi:

Deployment va ReplicaSet (eski ReplicationController resursini almashtirish). Deployment sizning clusteringizda stateless applicationlarning workloadini boshqarish uchun juda mos keladi, bu yerda Deploymentdagi har qanday pod bir-birining o'rnini bosadi va kerak bo'lganda almashtirilishi mumkin.
StatefulSet sizga qandaydir tarzda holatni kuzatuvchi bir yoki bir nechta tegishli podlarni ishga tushirish imkonini beradi. Misol uchun, agar sizning workloaddingiz ma'lumotlarni doimiy ravishda yozib olsa, har bir Podga PersistentVolume bilan mos keladigan StatefulSet-ni ishga tushirishingiz mumkin. Oʻsha StatefulSet uchun Podlarda ishlaydigan sizning kodingiz umumiy barqarorlikni yaxshilash uchun maʼlumotlarni bir xil StatefulSetʼdagi boshqa podlarga takrorlashi mumkin.
DaemonSet nodelar uchun local bo'lgan imkoniyatlarni ta'minlovchi podlarni belgilaydi. Har safar clusteringizga DaemonSet spetsifikatsiyasiga mos keladigan nodeni qo'shsangiz, control plane ushbu DaemonSet uchun Podni yangi nodega rejalashtiradi(schedule). DaemonSet-dagi har bir pod classic Unix/POSIX serveridagi tizim demoniga o'xshash ishni bajaradi. DaemonSet sizning clusteringiz ishlashi uchun asosiy bo'lishi mumkin, masalan, cluster tarmog'ini ishga tushirish uchun plagin, u sizga nodeni boshqarishda yordam berishi yoki siz ishlayotgan konteyner platformasini yaxshilaydigan ixtiyoriy xatti-harakatni ta'minlashi mumkin.
Job va CronJob tugallanadigan(completion) va keyin to'xtatiladigan vazifalarni(task) aniqlashning turli usullarini taqdim etadi. Bir marta tugallanadigan vazifani belgilash uchun Job foydalanishingiz mumkin. Bir ishni jadvalga muvofiq bir necha marta bajarish uchun CronJob-dan foydalanishingiz mumkin

Kengroq Kubernetes ekotizimida siz qo'shimcha xatti-harakatlarni ta'minlaydigan uchinchi tomon workload resurslarini topishingiz mumkin. Custom resource definitionidan foydalanib, Kubernetesning asosiy qismi bo'lmagan muayyan xatti-harakatni xohlasangiz, uchinchi tomon workload resourceni qo'shishingiz mumkin. Misol uchun, agar siz applicationingiz uchun Podlar guruhini ishga tushirmoqchi bo'lsangiz, lekin barcha Podlar mavjud bo'lmaguncha ishlashni to'xtatsangiz (ehtimol, ba'zi yuqori o'tkazuvchanlik taqsimoti uchun), u holda siz ushbu xususiyatni ta'minlaydigan extensionni amalga oshirishingiz yoki o'rnatishingiz mumkin.

Labellar va Selectorlar

Kubernetes-da labellar va selectorlar clusteringizdagi obyektlarning kichik to'plamlarini tartibga solish va tanlash imkonini beruvchi key conceptlardir. Ular toifalarga(categorize) ajratish va aniqlash uchun Kubernetes obyektlariga (masalan, Podlar, Servicelar yoki Deploymentlar) biriktirishingiz mumkin bo‘lgan metama’lumotlardir. Labellar obyektlar bilan bog'langan key/value juftliklari bo'lib, selectorlar ushbu labellar asosida obyektlarni filtrlash uchun ishlatiladi.

Labellar

Kubernetesdagi labellar moslashtirilgan key-value pairlari boʻlib, obyektlarga biriktirilgan boʻlib, moslashuvchan tashkil etish va identifikatsiya qilish imkonini beradi. Ular obyektlarni samarali guruhlash, filtrlash va boshqarish uchun metama'lumotlarni taqdim etadi, operatsion vazifalar va dinamik konfiguratsiyaga yordam beradi, obyektlar bo'ylab o'ziga xoslikni ta'minlamasdan tanlab so'rovlar va toifalarga ajratish imkonini beradi.

Labellar key-value pairlaridan iborat, masalan, app: frontend yoki tier: backend. Bitta obyektga bir nechta labelllar qo'shishingiz mumkin, bu obyekt uchun turli perspectivelar yoki toifalarni taqdim etishingiz mumkin. Metadata; ular biriktirilgan obyektlarning xatti-harakatlariga(behavior ) bevosita ta'sir qilmaydi. Ular foydalanuvchilar operatsion yoki tashkiliy maqsadlarda foydalanishlari mumkin bo'lgan identifikatsiya ma'lumotlarini taqdim etadi.

Labellarga misollar

"release" : "stable","release" : "canary"
"environment" : "dev", "environment" : "qa","environment" : "production"
"tier" : "frontend","tier" : "backend","tier" : "cache"
"partition" : "customerA","partition" : "customerB"
"track" : "daily","track" : "weekly"

Label Selectorlar

Namelar va UIDlardan farqli o'laroq, labellar o'ziga xoslikni ta'minlamaydi. Umuman olganda, biz ko'plab obyektlar bir xil label(lar)ga ega bo'lishini kutamiz. Label selectorlari orqali client/user obyektlar to'plamini aniqlay oladi. Label selectori Kubernetesdagi asosiy guruhlash primitividir. API hozirda ikki turdagi selectorlarni qo'llab-quvvatlaydi: equality-based va set-based. Label selectorri vergul bilan ajratilgan bir nechta talablardan(requirement) iborat bo'lishi mumkin. Bir nechta talablar bo'lsa, ularning barchasi bajarilishi kerak, shuning uchun vergul ajratuvchi mantiqiy(logical) AND (&&) operatori vazifasini bajaradi. Bo'sh yoki ko'rsatilmagan selectorlarning semantikasi kontekstga bog'liq va selectorlardan foydalanadigan API turlari ularning haqiqiyligi(validity) va ma'nosini hujjatlashtirishi kerak.

Equality-based requirement

Equality(Tenglik)- yoki inequality-based(tengsizlikka asoslangan) requirementlar label keylari va valuelari bo'yicha filtrlash imkonini beradi. Mos obyektlar barcha belgilangan label cheklovlarini qondirishi kerak, lekin ularda qo'shimcha labellar ham bo'lishi mumkin. Uch xil operatorlar qabul qilinadi =,==,!=. Birinchi ikkitasi tenglikni(equality) ifodalaydi, ikkinchisi esa tengsizlikni(inequality) ifodalaydi. Masalan:

environment = production
tier != frontend

Birinchisi, kaliti environmentga va productionga teng qiymatga ega bo'lgan barcha resurslarni tanlaydi. Ikkinchisi old qismdan farqli daraja va qiymatga equal keyga ega barcha resurslarni va tier key bilan labelsiz barcha resurslarni tanlaydi. Vergul operatori yordamida frontenddan tashqari productiondagi resurslarni filtrlash mumkin: muhit=production,tier!=frontend.

Equality-based yorliq label requirementi uchun foydalanish senariylaridan biri Podlar uchun node selction(tanlash) mezonlarini belgilashdir. Misol uchun, quyidagi Pod namunasi "accelerator=nvidia-tesla-p100" labeli bilan nodelarni tanlaydi.

apiVersion: v1
kind: Pod
metadata:
  name: cuda-test
spec:
  containers:
    - name: cuda-test
      image: "registry.k8s.io/cuda-vector-add:v0.1"
      resources:
        limits:
          nvidia.com/gpu: 1
  nodeSelector:
    accelerator: nvidia-tesla-p100

Set-based requirement

Set-based label requirementlari keylarni valuelar to'plamiga muvofiq filtrlash imkonini beradi. Uch turdagi operatorlar qo'llab-quvvatlanadi: in, notin va exists (faqat kalit identifikator). Masalan:

environment in (production, qa)
tier notin (frontend, backend)
partition
!partition

Birinchi misolda keyi environmentga teng va production yoki qa qiymatiga teng bo'lgan barcha resurslar tanlanadi.
Ikkinchi misolda frontend va backend qismdan boshqa tier va valuelarga teng keyga ega barcha resurslar va tier key bilan labelsiz barcha resurslar tanlanadi.
Uchinchi misol barcha resurslarni, shu jumladan key partitionga ega labelni tanlaydi; qiymatlar tekshirilmaydi.
To'rtinchi misol key partitioni bilan labelsiz barcha resurslarni tanlaydi; qiymatlar tekshirilmaydi.

Xuddi shunday vergul ajratuvchi ham AND operatori vazifasini bajaradi. Shunday qilib, partition key (qiymatidan qat'iy nazar) va qa dan farqli environment bilan resurslarni filtrlash partition,environment notin (qa) yordamida amalga oshirilishi mumkin. Set-based label selectori equality(tenglik)ning umumiy(general) shaklidir, chunki environment=production environment in (production) ga teng; != va and uchun ham xuddi shunday

Set-based requirementlar equality-based requirementlar bilan aralashtirilishi mumkin. Masalan: partition in (customerA, customerB),environment!=qa.

Annotationlar

Kubernetesdagi Annotationlar(izohlar) - bu cluster ichidagi obyektlarga o'zboshimchalik bilan(arbitrary) identifikator bo'lmagan ma'lumotlarni biriktirish uchun ishlatiladigan metama'lumotlar. Ular obyektni aniqlash yoki tanlash uchun ishlatilmaydigan tavsiflovchi ma'lumotlarni qo'shish usulini taklif qiluvchi key-value pairlari. Annotationlar clusterdagi resurslar haqida qo'shimcha context, documentation yoki operatsion eslatmalarni taqdim etish uchun ishlatilishi mumkin.

Kubernetes annotationlarining bir nechta asosiy jihatlari:

Identifikatsiya qilmaydigan metama'lumotlar Labellardan farqli o'laroq, annotationlar obyektlarni tanlash yoki aniqlash uchun ishlatilmaydi. Ular qo'shimcha ma'lumotlarni taqdim etish uchun mo'ljallangan.
Moslashuvchan foydalanish Annotationlar turli xil Kubernetes resurslariga qo'llanilishi mumkin, masalan, podlar, servicelar, deploymentlar va boshqalar, bu foydalanuvchilarga maxsus ma'lumotlarni qo'shish imkonini beradi.
Information va Tooling Annotationlar ko'pincha developerlar, operatorlar va Kubernetes ekotizimidagi turli toollar tomonidan qo'llaniladi. Ular audit, monitoring yoki avtomatlashtirish uchun tafsilotlarni o'z ichiga olishi mumkin.
Turli xil foydalanish holatlari Ular ko'p maqsadli(multiple purpose) va build informationlarini belgilash, operational detaillarni aniqlash, debugging informationni qo'shish yoki hatto dasturga xos(application-specific) konfiguratsiyalarni boshqarishda yordam berish kabi bir nechta maqsadlarga xizmat qilishi mumkin.

Misol uchun, Annotationlar resurs yaratuvchisi haqidagi ma'lumotlarni, versiya tafsilotlarini, application-specific metama'lumotlarni yoki resursni qayd qilish, monitoring qilish yoki boshqarish uchun ishlatiladigan tashqi systems/toollarga pointerlarni o'z ichiga olishi mumkin.

Kubernetes-da annotationlardan foydalanishga misollar sifatida resursning amal qilish muddati haqidagi ma'lumotlarni qo'shish mumkin, masalan:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  annotations:
    expiration-date: "2023-12-31"
spec:
  # pod specification...

yana bir misol

apiVersion: v1
kind: Pod
metadata:
  name: annotations-demo
  annotations:
    imageregistry: "https://hub.docker.com/"
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

Kubernetes Arxitekturasi Kubernetes Cluster sozlash