Kubernetes Arxitekturasi

Mundarija

Kubernetes Arxitekturasi

Quyidagi Kubernetes arxitektura diagrammasi Kubernetes clusterining barcha komponentlarini va tashqi tizimlarning Kubernetes clusteriga qanday ulanishini ko'rsatadi.

Kubernetes haqida tushunishingiz kerak bo'lgan birinchi va eng muhim narsa - bu distributed system(taqsimlangan tizim). Ya'ni, u tarmoq orqali turli serverlar bo'ylab tarqalgan bir nechta komponentlarga ega. Bu serverlar virtual mashinalar(vm virtual machine) yoki bare metal serverlar bo'lishi mumkin. Biz uni Kubernetes Clusteri deb ataymiz.

Kubernetes clusteri control plane nodelari va worker nodelardan iborat.

Quyidagi rasmda Kubernetes Container tashuvchi kema sifatida ko'rsatilgan.

Control Plane

Control plane conrtainer orkestratsiyasi(container orchestration) va clusterning kerakli stateini(state) saqlab turish uchun javobgardir. U quyidagi tarkibiy qismlarga ega.

kube-apiserver
etcd
kube-scheduler
kube-controller-manager
cloud-controller-manager

Worker Node

Worker nodelari conrtainerlashtirilgan applicationlarni(appliationla) ishga tushirish uchun javobgardir. Worker node quyidagi komponentlarga ega.

kubelet
kube-proxy
Container runtime

Kubernetes Control Plane Komponentlari

Birinchidan, har bir control plane komponentini va har bir komponent ortidagi muhim tushunchalarni ko'rib chiqaylik.

kube-apiserver

kube-api serveri Kubernetes API-ni ochib(expose) beruvchi Kubernetes clasterining central hubidir. Oxirgi foydalanuvchilar va boshqa cluster komponentlari API serveri orqali cluster bilan gaplashadi. Juda kamdan-kam hollarda monitoring tizimlari va uchinchi tomon Servicelari cluster bilan o'zaro aloqa qilish uchun API serverlari bilan gaplashishi mumkin. Shunday qilib, siz clusterni boshqarish uchun kubectl dan foydalansangiz, backendda siz HTTP REST API orqali API serveri bilan bog'lanasiz. Biroq, scheduler(scheduler), controller va boshqalar kabi ichki cluster komponentlari gRPC yordamida API serveri bilan gaplashadi. API serveri va clusterdagi boshqa komponentlar o'rtasidagi aloqa clusterga ruxsatsiz kirishni oldini olish uchun TLS orqali amalga oshiriladi.

Kubernetes api-serveri quyidagilar uchun javobgardir

API management(boshqaruvi): Cluster API so'nggi nuqtasini ochib beradi va barcha API so'rovlarini bajaradi.
Autentifikatsiya (client sertifikatlari, tashuvchi tokenlari(bearer token) va HTTP asosiy autentifikatsiyasidan foydalanish) va avtorizatsiya (ABAC va RBAC evaluation).
API so'rovlarini(request) qayta ishlash va API obʼyektlari kabi pods, servicelar va boshqalar uchun maʼlumotlarni tekshirish (Validation and Mutation Admission Controllers)
Bu etcd bilan aloqa(communicate) qiladigan yagona komponent.
api-server control plane va worker node komponentlari o'rtasidagi barcha jarayonlarni(process) muvofiqlashtiradi.
api-serverda o'rnatilgan bastion apiserver proksi-server mavjud. Bu API server jarayonining bir qismidir. U asosan clusterdan tashqaridan ClusterIP servicelariga kirishni ta'minlash uchun ishlatiladi, garchi bu servicelar odatda faqat clusterning o'zida mavjud bo'lsa ham.

etcd

Kubernetes distributed system bo'lib, uning distributed(taqsimlangan) tabiatini qo'llab-quvvatlaydigan etcd kabi samarali distributed databaselar bazasiga muhtoj. U ham backend Serviceini kashf qilish, ham ma'lumotlar bazasi sifatida ishlaydi. Siz uni Kubernetes clusterining miyasi deb atashingiz mumkin.

etcd open source (opens in a new tab) kuchli izchil, distributed key-value storedir. Xo'sh, bu nimani anglatadi?

Strongly consistent Agar nodega yangilanish amalga oshirilsa, strong consistency uning clusteridagi barcha boshqa nodelarga darhol yangilanishini ta'minlaydi. Bundan tashqari, agar siz CAP teoremasiga qarasangiz, kuchli mustahkamlik va & Bo'limga chidamlilik bilan 100% mavjudlikka erishish mumkin emas.

Distributed etcd bir nechta nodelarda cluster sifatida mustahkamlikdan voz kechmasdan ishlash uchun mo'ljallangan.

Key Value Store ma'lumotlarni keylar va valuelar sifatida saqlaydigan aloqador bo'lmagan ma'lumotlar bazasi. Shuningdek, u key-valueli API-ni ham ochib beradi. Ma'lumotlar ombori BboltDB (opens in a new tab) forki bo'lgan BoltDB (opens in a new tab) ustiga qurilgan.

etcd mustahkam mustahkamlik va mavjudlik uchun raft consensus algoritmidan foydalanadi. U yuqori darajadagi mavjudlik va nodelarning nosozliklariga dosh berish uchun leader-member uslubida ishlaydi.

Xo'sh, etcd Kubernetes bilan qanday ishlaydi?

Oddiy qilib aytganda, kubernetes object detaillarini olish uchun kubectl dan foydalansangiz, uni etcd dan olasiz. Bundan tashqari, objectni pod kabi deploy qilganingizda, yozuv etcd da yaratiladi.

Xulosa qilib aytganda, bu yerda siz etcd haqida bilishingiz kerak bo'lgan narsalar.

etcd barcha konfiguratsiyalar, statelar va Kubernetes objectlari metama'lumotlarini (podlar, secretlar, daemonsetlar, deploymentlar, configmaplar, statefulset va boshqalarni) saqlaydi.
etcd clientga Watch() API yordamida eventlarga subscribe qilish imkonini beradi. Kubernetes api-server object statetidagi(state) o'zgarishlarni(change) kuzatish uchun etcd-ning watch funksiyasidan foydalanadi.
etcd gRPC yordamida key-value API-ni ochib beradi. Bundan tashqari, gRPC gatewayi barcha HTTP API chaqiruvlarini gRPC messagelariga tarjima qiladigan RESTful proksi-server hisoblanadi. Bu uni Kubernetes uchun ideal ma'lumotlar bazasiga aylantiradi.
etcd barcha objectlarni /registry directory keyi ostida key-value formatida saqlaydi. Masalan, default namespacedagi Nginx nomli pod haqida ma'lumotni /registry/pods/default/nginx ostida topish mumkin.

Bundan tashqari, etcd control planedagi yagona Statefulset komponentidir.

kube-scheduler

kube-scheduler worker nodelarida Kubernetes podlarini rejalashtirish(scheduling) uchun javobgardir. Siz podni o'rnatganingizda, siz protsessor, xotira, affinity, nosozliklar(taints) yoki bardoshlik(tolerations), priority(ustuvorlik), persistent volume(PV) kabi pod talablarini belgilaysiz. Schedulerning asosiy vazifasi cretae so'rovini(requestini) aniqlash va talablarga javob beradigan pod uchun eng yaxshi nodeni tanlashdir. Quyidagi rasmda schedulerni qanday ishlashining yuqori darajadagi umumiy ko'rinishi ko'rsatilgan.

Kubernetes clusterida bir nechta worker nodelari bo'ladi. Xo'sh, qanday qilib scheduler barcha worker nodelardan nodeni tanlaydi?

Bu yerda scheduler qanday ishlaydi.

Eng yaxshi nodeni tanlash uchun kube-scheduler filtrlash va baholash(scoring) operatsiyalaridan foydalanadi.
Filtrlashda scheduler podni rejalashtirish mumkin bo'lgan eng mos nodelarni topadi. Misol uchun, podni ishga tushirish uchun resurs mavjud bo'lgan besh worker mode mavjud bo'lsa, u barcha besh nodeni tanlaydi. Agar nodelar bo'lmasa, pod rejalashtirilmaydi va rejalashtirish navbatiga o'tkaziladi. Agar bu katta cluster bo'lsa, aytaylik, 100 worker modelari va scheduler barcha nodelarni takrorlamaydi. percentageOfNodesToScore deb nomlangan scheduler konfiguratsiya parametri mavjud. Default qiymat odatda 50% ni tashkil qiladi. Shunday qilib, u nodelarning 50% dan ortig'ini round-robin rejimda takrorlashga harakat qiladi. Agar worker modelar bir nechta zonalar bo'ylab tarqalgan bo'lsa, scheduler turli zonalardagi nodelarni takrorlaydi. Juda katta clusterlar uchun standart percentageOfNodesToScore 5% ni tashkil qiladi.
Baholash(scoring) bosqichida scheduler filtrlangan worker nodelariga ball qo'yish orqali nodelarni tartiblaydi. Scheduler bir nechta scheduling pluginlariga chaqiruv qilish orqali reytingni amalga oshiradi. Nihoyat, podni scheduling(rejalashtirish) uchun eng yuqori darajaga ega worker node tanlanadi. Agar barcha nodelar bir xil darajaga ega bo'lsa, node tasodifiy tanlanadi.
Node tanlangandan so'ng, scheduler API serverida binding event yaratadi. Binding event pod va nodeni bog'lashni anglatadi.

Scheduler haqida bilish kerak bo'lgan narsalar.

Bu API serverida pod create(yaratish) eventlarini tinglaydigan controller.
Scheduler ikki bosqichdan iborat. Scheduling sikli va Binding sikli. Birgalikda u scheduling konteksti deb ataladi. Scheduling sikli worker nodeni tanlaydi va binding sikli bu o'zgarishni clusterga qo'llaydi.
Scheduler har doim yuqori high-priority podlarni scheduling(rejalashtirish) uchun low-priority podlardan oldinroq joylashtiradi. Bundan tashqari, ba'zi hollarda, pod tanlangan nodeda ishlay boshlagandan so'ng, poddan chiqarib yuborilishi yoki boshqa nodelarga ko'chirilishi mumkin. Agar siz ko'proq tushunishni istasangiz, Kubernetes pod priority (opens in a new tab) qo'llanmasini o'qib ko'ring.
Siz maxsus schedulerlarni yaratishingiz va nativ scheduler bilan bir qatorda clusterda bir nechta schedulerlarni ishga tushirishingiz mumkin. Podni deploy qilganizda, pod manifestida maxsus schedulerni belgilashingiz mumkin. Shunday qilib, scheduling qarorlari custom scheduler mantig'i asosida qabul qilinadi.
Schedulerda ulanadigan scheduling framework mavjud. Ya'ni, siz o'zingizning custom plugingizni scheduling workflowiga qo'shishingiz mumkin.

Kube Controller Manager

Controller nima? Controllerlar (opens in a new tab) infinite control sikllarini ishga tushiradigan dasturlardir. Ya'ni, u doimiy ishlaydi va ob'ektlarning actual va kerakli statetini kuzatadi. Actual va kerakli statetida farq bo'lsa, kubernetes resource/object kerakli statetida bo'lishini ta'minlaydi.

Kubernetes-da controllerlar clusteringiz statetini(holatini) kuzatadigan, keyin kerak bo'lganda o'zgartirishlar kiritadigan yoki so'raydigan boshqaruv sikllari. Har bir controller joriy cluster statetini kerakli statega yaqinlashtirishga harakat qiladi.

Aytaylik, siz deploymentni create qilmoqchisiz, manifest YAML faylida kerakli stateni belgilaysiz (deklarativ yondashuv). Masalan, 2 replica(nusxa), bitta volume mount qilish, configmap va boshqalar. O'rnatilgan deployment controlleri deploymentning har doim kerakli stateda bo'lishini ta'minlaydi. Agar foydalanuvchi deploy,mentni 5 ta replica bilan yangilasa, deployment controlleri uni taniydi va kerakli state 5 relicada(nusxa) bo'lishini ta'minlaydi.

Kube controller manageri barcha Kubernetes controllerlarini boshqaradigan komponentdir. Kubernetes resources/objects kabi podlar, namespacelari, joblar, replicasetlar tegishli controllerlar tomonidan boshqariladi. Shuningdek,kube scheduleri ham Kube controller manageri tomonidan boshqariladigan controller hisoblanadi.

Quyida muhim built-in Kubernetes controllerlarining ro'yxati keltirilgan.

Deployment controller
Replicaset controller
DaemonSet controller
Job Controller (Kubernetes Jobs)
CronJob Controller
endpoints controller
namespace controller
service accounts controller.
Node controller

Kube controller manageri haqida nimalarni bilishingiz kerak.

U barcha controllerlarni boshqaradi va controllerlar clusterni kerakli holatda(state) saqlashga harakat qiladilar.
Siz kubernetesni custom resource definition bilan bog'langan custom controllerlar bilan kengaytirishingiz mumkin.

Cloud Controller Manager (CCM)

Kubernetes cloud environmentda o'rnatilganda, cloud controller manageri Cloud Platform API va Kubernetes clusteri o'rtasida ko'prik vazifasini bajaradi.

Shunday qilib, kubernetesning asosiy komponentlari mustaqil ishlashi mumkin va cloud provayderlariga pluginlar yordamida kubernetes bilan integratsiya qilish imkonini beradi. (Masalan, kubernetes clusteri va AWS cloud API o'rtasidagi interfeys)

Cloud controller integratsiyasi Kubernetes clusteriga misollar(nodelar uchun), Load Balancerlari(servicelar uchun) va Storage Volumelari(persistent volume uchun) kabi cloudli resurslarni taʼminlash imkonini beradi.

Cloud Controller Manager cloudga xos komponentlarning (nodelar, Loadbalancerlar, storage va h.k.) kerakli stateni(holatini) taʼminlaydigan cloud platformasiga xos controllerlar to'plamini o'z ichiga oladi. Quyida cloud controller manageri tarkibiga kiruvchi uchta asosiy controllerlar keltirilgan.

Node Controller: Bu controller cloud provayderi API bilan gaplashish orqali nodega oid ma'lumotlarni yangilaydi. Masalan, node labeling va annotation, hostnameni olish, protsessor va xotira mavjudligi, nodelarning salomatligi(nodes health) va boshqalar.

Route Controller: U cloudli platformada tarmoq(network) routelarini sozlash uchun javobgardir. Shunday qilib, turli nodelardagi podlar bir-biri bilan gaplashishi mumkin.

Service Controller kubernetes servicelari uchun load balancerlarini(yuk blanslagich) deploy qilish, IP manzillarini belgilash va h.k. bilan shug'ullanadi.

Quyida cloud controller managerining ba'zi classic misollari keltirilgan.

Load balancer turidagi Kubernetes Serviceni deploy qilish. Bu yerda Kubernetes Cloud-specific(cloudga xos) Loadbalancerni taqdim etadi va Kubernetes servici bilan birlashadi.

Cloud storage yechimlari bilan quvvatlangan podlar uchun Provisioning storage volume (PV).

Umumiy Cloud Controller Manageri kubernetes tomonidan ishlatiladigan cloudga xos resurslarning lifecycleni boshqaradi.

Kubernetes Worker Node Componentlari

Endi worker node komponentlarining har birini ko'rib chiqamiz.

Kubelet

Kubelet - bu clusterdagi har bir nodeda ishlaydigan agent komponenti. t conrtainer sifatida ishlamaydi, aksincha, systemd tomonidan boshqariladigan daemon sifatida ishlaydi.

U API serverida worker nodelarni ro'yxatdan o'tkazish va podSpec(Pod spetsifikatsiyasi - YAML yoki JSON) bilan asosan API serveridan ishlash uchun javobgardir. podSpec podSpec ichida ishlashi kerak bo'lgan conrtainerlarni, ularning resurslarini (masalan, protsessor va xotira chegaralari) va environment o'zgaruvchilari, volumelar va labellar kabi boshqa sozlamalarni belgilaydi. Keyin conrtainerlarni yaratish(create) orqali podSpec-ni kerakli statega(holatga) keltiradi. Kubernetesda kubelet asosiy komponent bo'lib, u har bir worker nodeda ishlaydi va node va unda ishlaydigan conrtainerlar bilan bog'liq bir nechta muhim vazifalarni bajaradi. Quyida kubeletning asosiy majburiyatlari keltirilgan:

Pod Lifecycle Management Kubelet conrtainerlarning Podda ishlashini ta'minlaydi. API serveridan olingan Pod spetsifikatsiyalari asosida conrtainerlarni ishga tushiradi(start), to'xtatadi(stop) va qayta ishga tushiradi(restart).

Node Registration(nodeni ro'yxatdan o'tkazish) Kubelet nodeni Kubernetes clusterida qayd etib, node resurslari va boshqa tegishli ma'lumotlarni taqdim etadi.

Resource Management(Resurslarni boshqarish) Kubelet conrtainerlarning resurslardan foydalanishni (masalan, protsessor va xotira) nazorat qiladi va bu ma'lumotni API serveriga xabar qiladi. U conrtainerlar uchun o'rnatilgan resurs cheklovlarini(limit) amalga oshiradi.

Health Checks(Salomatlik tekshiruvlari) Kubelet ishlaydigan conrtainerlarning sog'lig'ini tekshiradi. U sog'lig'ini tekshirishda muvaffaqiyatsizlikka uchragan conrtainerlarni qayta ishga tushiradi va vaziyat haqida API serveriga xabar beradi.

Container Runtime Interface (CRI) Implementation Kubelet conrtainerlarning ishlash muddatini (masalan, Docker yoki containerd) conrtainerlarning hayot aylanishini( lifecycle) boshqarish uchun o'zaro ta'sir qiladi. U conrtainer imagelarini pull qilib olish, conrtainerlarni ishga tushirish(start) va to'xtatish(stop) va hokazo operatsiyalarni bajaradi.

Volume Management Kubelet Poddagi conrtainerlar tomonidan ishlatiladigan volumelarni mounting va unmountingni boshqaradi.

Node-Level Security Kubelet nodedagi barcha conrtainerlar Pod spetsifikatsiyasida belgilangan xavfsizlik xususiyatlariga mos kelishini ta'minlaydi.

Log Management Kubelet conrtainer loglarini yig'ish va boshqarish bilan shug'ullanadi, bu ularni muammolarni bartaraf etish va tahlil qilish uchun mavjud qiladi.

Kubelet conrtainerlarda muayyan buyruqlarni bajarishi mumkin, masalan, nosozliklarni tuzatish yoki dastur holatini(state) tekshirish uchun foydalaniladi. Qisqa qilib aytganda, kubelet conrtainerlarning har bir nodeda kutilganidek ishlashini ta'minlash, resurslarni boshqarish, salomatligini tekshirish va Kubernetes ishchi nodedagi conrtainerlarni boshqarish bilan bog'liq boshqa vazifalarni bajarish uchun javobgardir.

kube proxy

kube-proxy Kubernetes-dagi asosiy tarmoq komponenti bo'lib, clusterdagi turli nodelar bo'ylab pod-lar bilan tarmoq aloqasini boshqarish uchun javobgardir. U har bir nodeda ishlaydi va ushbu nodelarda tarmoq rulelarini saqlaydi. Ushbu qoidalar(rule) cluster ichidagi yoki tashqarisidagi tarmoq seanslariga pod-larga ulanish imkonini beradi. kube-proxy Kubernetes clusterining ichida ham, tashqarisida ham tarmoq muhiti izchil va predictable qilinadigan bo'lishini ta'minlaydi. Kubernetes-da service - bu ichki yoki tashqi trafikka bir qator podlarni expose(tashqariga ochish) qilish usuli. Service obyektini yaratganingizda, u unga tayinlangan virtual IP-ni oladi. U clusterIP deb ataladi. Unga faqat Kubernetes clusterida kirish mumkin. Endpoint obyekti Service obyekti ostidagi pod guruhlarining barcha IP manzillari va portlarini o'z ichiga oladi. Endpointlar controlleri pod IP manzillari (endpoint) ro'yxatini saqlash uchun javobgardir. Service controlleri Servicening entpointlarini configratsiya qilish uchun javobgardir. Siz ClusterIP-ga ping yubora olmaysiz, chunki u ping qo'shiladigan pod IP-lardan farqli o'laroq, faqat servicelarni topish uchun ishlatiladi.

kube-proxy - bu daemonset sifatida har bir nodeda ishlaydigan demon. Bu podlar uchun Kubernetes servicelari kontseptsiyasini amalga oshiradigan proxy komponentidir. (load balancingga ega bo'lgan podlar to'plami uchun yagona DNS). U birinchi navbatda UDP, TCP va SCTP-ni proksi-server qiladi va HTTP-ni tushunmaydi. Service (ClusterIP) yordamida podlarni expose qilganingizda, kube-proxy service obyekti ostida guruhlangan backend pods (endpointlar) ga trafik jo'natish uchun tarmoq rule (qoidalarini) yaratadi. Ya'ni, barcha load balancing va servicelarni aniqlash kube-proxy tomonidan amalga oshiriladi.

kube-proxy qanday ishlaydi

kube-proxy service (ClusterIP) va tegishli pod IP va portlar (endpointlar) haqida ma'lumot olish uchun API serveri bilan gaplashadi. Shuningdek, u service va endpointlardagi o'zgarishlarni kuzatib boradi. Keyin kube-proxy service ortidagi podlarga trafikni yo'naltirish qoidalarini(rule) create/updatey(aratish/yangilash) uchun quyidagi rejimlardan birini ishlatadi. kube-proxy bir nechta rejimlardan(mode) birida ishlashi mumkin: userspace, iptables yoki IPVS. Eng ko'p ishlatiladigan rejimlar iptables va IPVS bo'lib, ularning eski userspace rejimiga nisbatan samaradorligi tufayli.

IPTables mode: Bu standart rejim. IPTables rejimida trafik IPtable qoidalari bilan boshqariladi. Bu shuni anglatadiki, har bir service uchun IPtable qoidalari yaratilgan. Ushbu qoidalar ClusterIP-ga keladigan trafikni ushlaydi va keyin uni backend podlariga yo'naltiradi. Bundan tashqari, ushbu rejimda kube-proxy load balancing(yukni muvozanatlash) uchun tasodifiy backend podni tanlaydi. Ulanish o'rnatilgandan so'ng, requestlar ulanish to'xtatilgunga qadar bir xil podga o'tadi.
IPVS mode: IPVS (IP Virtual Server) 1000 dan ortiq servicelarga ega clusterlar uchun IPVS ish faoliyatini yaxshilashni taklif qiladi. U backend uchun quyidagi load-balancing algoritmlarini qo'llab-quvvatlaydi.

rr: round-robin : Bu standart rejim.
lc: least connection(eng kam ulanish) (ochiq ulanishlarning eng kichik soni)
dh: destination hashing
sh: source hashing
sed: shortest expected delay (kutilgan eng qisqa kechikish)
nq: never queue

Userspace(eskirgan): Ushbu rejimda kube-proxy Kubernetes masterini Serviuce va Endpoint obyektlarini qo'shish va o'chirish uchun kuzatib boradi. Har bir Service uchun u local nodeda portni (tasodifiy tanlangan) ochadi. Ushbu "proxy-port" ga har qanday ulanishlar Servicening backend podlaridan biriga proksilangan (shuningdek, tasodifiy tanlangan). Bu unchalik samarali emas, chunki trafik addon "hop" orqali o'tadi.
Kernelspace: Bu rejim faqat Windows tizimlari uchun.

Kube-proxy IPtables va IPVS rejimi o'rtasidagi ishlash farqini tushunishni istasangiz, ushbu maqolani (opens in a new tab) o'qib chiqishingiz mumkin.

Shuningdek, siz Kubernetes clusterini kube-proxysiz Cilium (opens in a new tab) bilan almashtirib ishga tushirishingiz mumkin.

kube-proxy funksiyalari

Service Abstraction: kube-proxy IP-tarjima uchun tarmoq qoidalarini(network rule) saqlab, Kubernetes service sifatida podlar guruhini abstrakt qiladi. Bu shuni anglatadiki, client Servicega ulanganda kube-proxy trafikni asosiy podlardan biriga yo'naltiradi.

Load Balancing Kubernetes Service uchun bir nechta pod bo'lsa, kube-proxy load balanceri kiruvchi trafikni muvozanatlashtiradi. Bu trafikning mavjud podlarga taqsimlanishini ta'minlaydi.

TCP/UDP Packet Forwarding(paketlarni yo'naltirish) kube-proxy TCP va UDP paketlarini tegishli backend Podlariga yo'naltirish uchun javobgardir.

Session Affinity u iptables yordamida session affinitini saqlab turishi mumkin, bu esa clientning requestlari har safar session markerlari asosida bir xil Podga yuborilishini ta'minlaydi.

kube-proxy servicelardan foydalanish imkoniyatini boshqarsa-da, u Podlarning bir-biri bilan qanday aloqa qilishini cheklovchi plosilarni qo'llamaydi. Bu kube-proxy bilan birgalikda ishlaydigan network plagini tomonidan boshqarilishi mumkin bo'lgan Kubernetes network polisining roli.

Container Runtime

Ehtimol siz Java Runtime (JRE) haqida bilasiz. Bu xostda Java dasturlarini ishga tushirish uchun zarur bo'lgan dasturiy ta'minot. Xuddi shu tarzda, container runtime conrtainerlarni ishga tushirish uchun zarur bo'lgan dasturiy ta'minot komponentidir. container runtime Kubernetes clusteridagi barcha nodelarda ishlaydi. U conrtainer registrlaridan imagelarni olish(pull), conrtainerlarni ishga tushirish, conrtainerlar uchun resurslarni taqsimlash va izolyatsiya qilish hamda xostdagi conrtainerning butun hayot aylanishini(lifecycle) boshqarish uchun javobgardir.

Buni yaxshiroq tushunish uchun ikkita asosiy tushunchani ko'rib chiqaylik:

Container Runtime Interface (CRI) Bu Kubernetes-ga turli container runtimelari bilan o'zaro aloqada bo'lishga imkon beruvchi API to'plamidir. Bu turli container runtimelarini Kubernetes bilan almashtirib ishlatish imkonini beradi. CRI containerlarni yaratish, ishga tushirish, to'xtatish va o'chirish, shuningdek, imagelar va container tarmoqlarini boshqarish uchun APIni belgilaydi.

Open Container Initiative (OCI) Bu container formatlari va runtimelari uchun standartlar to'plami

Kubernetes Container Runtime Interface (CRI) bilan mos keladigan bir nechta container runtimelarini (CRI-O, Docker Engine, containerd va boshqalar) qo'llab-quvvatlaydi. Bu shuni anglatadiki, ushbu containerning barcha runtimelari CRI interfeysini amalga oshiradi va gRPC CRI API-larini (runtime va image servicening endpointlari) namoyish etadi.

Kubernetes tizimni container runtimedan ajratish uchun turli runtimelarini ulash imkonini beruvchi Container Runtime Interface (CRI) ni taqdim etdi. CRI ikkita asosiy gRPC servicelarini belgilaydi:

RuntimeService: containerlarning hayot aylanishini(lifecycle) boshqarish uchun javobgar.
ImageService: Imagelarni boshqarish operatsiyalari uchun javobgar.

Nodelarda ishlaydigan Kubernetes komponenti bo'lgan Kubelet container runtime bilan faqat CRI tomonidan belgilangan ushbu gRPC API orqali o'zaro ta'sir qiladi.

Xo'sh, Kubernetes container runtimedan qanday foydalanadi?

Kubelet bo'limida bilib olganimizdek, kubelet agenti containerning ishlash davrini(lifecycle) boshqarish uchun CRI API-lardan foydalangan holda container runtime bilan o'zaro ta'sir qilish uchun javobgardir. Shuningdek, u container runtimedan barcha container ma'lumotlarini oladi va uni boshqaruv tekisligiga beradi. Keling, CRI-O container runtime interfeysiga misol keltiraylik. Bu yerda container runtime kubernes bilan qanday ishlashi haqida yuqori darajadagi umumiy ma'lumot.

API serveridan pod uchun yangi request(soo'rov) bo'lganda, kubelet Kubernetes Container Runtime Interface orqali kerakli containerlarni ishga tushirish uchun CRI-O demoni bilan gaplashadi. CRI-O containerlar/imagelar kutubxonasi(library) yordamida configratsiya qilingan container registridan kerakli container imageni tekshiradi va pull qilib tortib oladi. Keyin CRI-O container uchun OCI runtime spetsifikatsiyasini (JSON) yaratadi. Keyin CRI-O runtime spetsifikatsiyasiga muvofiq container jarayonini boshlash uchun OCI bilan mos runtimeni (runc) ishga tushiradi.

Umumiy container runtimelari quyidagilarni o'z ichiga oladi:

Docker Dastlab Kubernetes Dockerdan to'g'ridan-to'g'ri foydalangan. Docker dastur va uning bog'liqliklarini har qanday Linux serverida ishlashi mumkin bo'lgan virtual containerga to'playdi.

containerd sanoat standartidagi asosiy container runtime. U Linux va Windows uchun demon sifatida mavjud bo'lib, u o'zining xost tizimining to'liq container lifecycleni boshqara oladi: imageni uzatish va saqlash, containerni execute qilish va nazorat qilish, low-level storage va tarmoq qo'shimchalari va boshqalar.

CRI-O OCI (Open Container Initiative) mos runtimelaridan foydalanishni ta'minlash uchun Kubernetes CRI dasturi. Bu faqat Kubernetes-ga e'tibor qaratgan container va Docker-ga yengil(lightweight) muqobildir. Container tarmog'i tarmoq interfeyslarini sozlaydigan va IP manzillari, marshrutlash qoidalari va DNS sozlamalari kabi tarmoq sozlamalarini qo'llaydigan CNI plaginlari bilan birgalikda ishlanadi.

Kubernetes cluster addon komponentlari(addons)

Kubernetes cluster addon komponentlari Kubernetes funksiyalarini kengaytiruvchi qo'shimcha xizmatlar va resurslardir. Ular odatda Kubernetes clusterida podlar va servicelar sifatida ishlaydi, lekin clusterdan tashqarida ham bo'lishi va kerak bo'lganda u bilan bog'lanishi mumkin. Ushbu addonlar Kubernetes imkoniyatlarini tarmoq, xavfsizlik, monitoring va boshqalar kabi sohalarda yaxshilaydi.

Kubernetes clusterining ba'zi keng tarqalgan addon komponentlarini:

DNS CoreDNS yoki Kube-DNS Kubernetes servicelari cluster ichidagi domen nomlarini hal qilish uchun foydalanishi mumkin bo'lgan DNS server. U Kubernetes servicelari va podlari uchun DNS yozuvlarini(record) tayinlaydi, bu ularni cluster ichida topish va muloqot qilish imkonini beradi.
Web UI (Dashboard) Kubernetes Dashboard Kubernetes clusterlari uchun umumiy maqsadli, veb-ga asoslangan foydalanuvchi interfeysi. U foydalanuvchilarga clusterda ishlaydigan appliationlarni, shuningdek, clusterning o'zini boshqarish va muammolarni bartaraf etish imkonini beradi.
Container Resource Monitoring Metrics Server clusterdagi resurslardan foydalanish ma'lumotlarini jamlaydi va uni Horizontal Pod Autoscaler kabi boshqa komponentlar uchun mavjud qiladi. Prometheus va Grafana Ko'pincha birgalikda foydalaniladi, Prometheus belgilangan vaqt oralig'ida sozlangan targetlardan metrikalarni kuzatadi va to'playdi, qoida ifodalarini baholaydi, natijalarni ko'rsatadi va ma'lum shartlar bajarilganda ogohlantirishlarni ishga tushirishi mumkin. Grafana Prometheus tomonidan to'plangan ma'lumotlarni vizualizatsiya qilish uchun ishlatiladi.
Network Pluginlari Container Network Interface (CNI) pluginlari. Pod aloqasini qo'llab-quvvatlash uchun tarmoq qatlamini taqdim etadi. Masalan, Calico, Flannel va Weave.
Ingress Controllerlar Nginx Ingress Controller, HAProxy Ingress Controller va boshqalar. Ular clusterdagi servicelarga tashqi kirishni boshqaradi, odatda HTTP. Ular Kubernetes servicelari uchun reverse proxy va load balancer vazifasini bajaradi.
Backup va Recovery Velero Kubernetes clusteri resurslari va persistent volumelarining zaxira nusxasini yaratuvchi(backup oluvchi) va tiklaydigan falokatlarni tiklash va ma'lumotlar migratsiyasi uchun addon.
Service Mesh Istio va Linkerd: Mikroservislarni ulash, boshqarish va himoya qilishning yagona usulini ta'minlovchi addonlar, odatda Service Mesh deb ataladi. Ular trafikni yo'naltirish, barqarorlik va kuzatuvchanlik kabi ilg'or tarmoq xususiyatlarini ta'minlaydi.
Horizontal Pod Autoscaling Autoscaling Controllerlar: Metrics Server tomonidan to'plangan ko'rsatkichlar orqali applicationlarni autoscaling qiluvchi. Applicationlarni kattalashtirish va kichraytirish, muvozanatda ushlab turish.
Security va Policy Addonlar Pod Security Policy (PSP) Pod ishga tushirish uchun amal qilishi kerak bo'lgan xavfsizlik spetsifikatsiyalarini, jumladan, foydalanuvchi ruxsatlari, volume turlari va boshqalarni belgilaydi. Network Policies Calico kabi addonlar, shuningdek, podlar orasidagi trafik oqimini boshqarish uchun Kubernetes network policini amalga oshirishga yordam beradi.
Storage Class Provayderlar CSI (Container Storage Interface) kabi provayderlar. StorageClasslar asosida saqlashni yaratish jarayonini avtomatlashtirish, ular turli xil saqlash turlari va darajalarini aniqlay oladi (masalan, SSD va HDD).
Cluster-level Logging Elasticsearch va Kibana (Elastic Stack). Elasticsearch - bu loglarni indekslaydigan va saqlaydigan qidiruv va tahlil mexanizmi. Kibana - bu Elasticsearch-da saqlangan loglarni qidirish va ko'rish uchun ishlatiladigan veb-UI. Fluentd: Birlashtirilgan logging qatlamlari uchun open-source ma'lumotlar yig'uvchisi(data collector), masalan, Elasticsearch tomonidan yaxshiroq foydalanish uchun ma'lumotlarni to'plash va ishlatish imkonini beradi.

Addonlar turli yo'llar bilan boshqarilishi mumkin:

Helm Charts: Helm - bu Kubernetes uchun paket menejeri bo'lib, u ko'pgina addonlarning lifecycleni boshqarish uchun ishlatiladi.

Kubernetes Operatorlari: Kubernetes funksiyalarini kengaytiruvchi maxsus kontrollerlar, complex stateful appliationlar instancelarini create qilish, configratsiya va boshqarish.

Addon Manager Clusterda ishlaydigan addonlarni boshqarish dasturi, ammo u zamonaviyroq yechimlar foydasiga eskirgan.

Kubernetesga Kirish Kubernetes Obyektlari