Бир нечта контейнерни битта серверда Docker ёрдамида ишга тушириш осон, аммо лойиҳангиз ўсиб, ўнлаб ёки юзлаб контейнерлар бир нечта серверда тақсимланиши керак бўлганда вазият тубдан мураккаблашади. Қайси контейнер қайси серверда ишлаши, бири ишдан чиқса нима бўлиши, юк ошганда янги нусхаларни қандай қўшиш кераклиги каби саволлар пайдо бўлади. Айнан шу муаммоларни ҳал қилиш учун Kubernetes — қисқартмаси K8s — яратилган бўлиб, у контейнерларни автоматик тарзда бошқарадиган оркестрация тизимидир.
Kubernetes нима ва нима учун керак
Kubernetes дастлаб Google ичида ишлаб чиқилган ва кейинчалик очиқ кодли лойиҳага айланган платформа бўлиб, унинг вазифаси контейнерлаштирилган иловаларни автоматик жойлаштириш, миқёслаш ва бошқаришдир. Оддий қилиб айтганда, агар Docker контейнерни яратиш ва ишга тушириш воситаси бўлса, Kubernetes кўплаб контейнерларни дирижёр каби мувофиқлаштирадиган тизимдир. У сиз учун контейнерларни қайси серверга жойлаштиришни ҳал қилади, уларнинг соғлиғини кузатиб боради ва бирор нарса бузилганда ўзи тузатишга ҳаракат қилади.
K8s нинг энг муҳим афзалликларидан бири ўз-ўзини тиклаш хусусиятидир. Агар бирор контейнер ишдан чиқса ёки жавоб бермай қолса, Kubernetes буни дарҳол сезади ва автоматик равишда янги нусхасини ишга туширади. Бундан ташқари, горизонтал миқёслаш имконияти туфайли юк ошганда иловангизнинг янги нусхалари автоматик қўшилади, юк камайганда эса ортиқча нусхалар ўчирилади. Янги версияни чиқариш ҳам хавфсиз кечади, чунки Kubernetes эски нусхаларни аста-секин янгиларига алмаштириб, агар хато чиқса орқага қайтариш имконини беради.
Асосий тушунчалар
Kubernetes билан ишлашни бошлаш учун бир нечта асосий тушунчани билиш керак. Энг кичик бирлик Pod деб аталади — бу бир ёки бир нечта контейнерни ўз ичига оладиган энг майда бошқарув бирлиги. Одатда битта Pod ичида битта асосий контейнер ишлайди, лекин ёрдамчи контейнерлар ҳам бўлиши мумкин. Подлар Node деб аталадиган жисмоний ёки виртуал серверларда жойлашади, яъни Node — бу иш бажариладиган ҳақиқий машина, кластер эса ана шундай Node'лар тўпламидан иборат.
Deployment эса Подларни қандай бошқаришни белгилайдиган кўрсатма ҳисобланади: у сизнинг иловангиздан нечта нусха ишлаб туриши кераклигини, қайси тасвирдан фойдаланишни ва янгиланиш стратегиясини аниқлайди. Service эса Подларга барқарор тармоқ манзили беради, чунки Подлар доимий ўчиб-ёниб туриши мумкин ва уларнинг IP манзиллари ўзгаради, Service эса улар ортида турган барқарор кириш нуқтаси вазифасини бажаради. Ниҳоят, namespace кластер ичидаги ресурсларни мантиқий гуруҳларга ажратиш учун ишлатилади — масалан, ишлаб чиқиш ва синов муҳитларини бир-биридан ажратиш учун.
Docker Compose'дан фарқи
Кўпчилик Docker Compose билан таниш бўлиб, уни бир нечта контейнерни битта сервер ичида бирга ишга тушириш учун ишлатади. Compose ажойиб восита, аммо унинг чегараси бор: у фақат битта серверда ишлайди ва серверингиз ишдан чиқса, бутун иловангиз тўхтайди. Kubernetes эса кўплаб серверлардан ташкил топган кластер билан ишлайди, яъни бир нечта жисмоний ёки виртуал машинани ягона ресурслар майдони сифатида бирлаштиради.
Бу фарқ жуда муҳим, чунки Kubernetes кластерда бир Node ишдан чиқса, ундаги Подларни автоматик равишда бошқа Node'ларга кўчиради ва илова ишлашда давом этади. Docker Compose'да бундай автоматик тикланиш ёки бир нечта сервер ўртасида юкни тақсимлаш имконияти йўқ. Шунинг учун Compose'ни маҳаллий ишлаб чиқиш ва кичик лойиҳалар учун, Kubernetes'ни эса катта ва юқори ишончлилик талаб қиладиган ишлаб чиқариш муҳитлари учун мос деб ҳисоблаш мумкин.
Оддий Deployment мисоли
Kubernetes'да ресурслар YAML форматидаги конфигурация файллари орқали тавсифланади. Қуйида оддий веб-илова учун Deployment мисоли келтирилган бўлиб, у учта нусхани ишга туширади ва ҳар бирига 80-портни очади:
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: nginx
image: nginx:1.25
ports:
- containerPort: 80
Бу файлда replicas: 3 қатори Kubernetes'га илованинг айнан учта нусхасини доимо ишлаб туришини буюради. Агар нусхалардан бири ўчиб қолса, Kubernetes дарҳол янгисини ишга тушириб, сони доим учтага тенг бўлишини таъминлайди. Ушбу файлни kubectl apply -f deployment.yaml буйруғи билан кластерга юборишингиз мумкин, ва Kubernetes қолган ишни ўзи бажаради.
Қачон Kubernetes керак ва қачон ортиқча
Kubernetes кучли восита бўлса-да, у ҳар бир лойиҳа учун мос келавермайди. Агар сизда битта кичик веб-сайт ёки оддий илова бўлса, Kubernetes'ни ўрнатиш ва бошқариш мураккаблиги олиб келадиган фойдадан кўра кўпроқ бош оғриғи бўлиши мумкин. Бундай ҳолатларда оддий хостинг, битта сервер ёки Docker Compose анча амалий ва арзон ечим бўлади.
Kubernetes ҳақиқатан ҳам фойдали бўладиган вазиятлар — бу кўплаб микросервислардан иборат катта лойиҳалар, юқори юк ва доимий ишлашни талаб қиладиган тизимлар, ҳамда тез-тез янгиланишлар чиқариладиган ишлаб чиқарувчи жамоалар. Мураккабликни камайтириш учун кўпчилик булутли провайдерлар бошқариладиган Kubernetes хизматларини таклиф қилади — бунда кластернинг асосий қисми провайдер томонидан бошқарилади ва сиз фақат иловаларингизга эътибор қаратасиз. Агар лойиҳангиз ҳали кичик бўлса, K8s'ни кейинроқ, ҳақиқий эҳтиёж пайдо бўлганда жорий қилиш кўпинча энг оқилона ёндашувдир.
Хулоса қилиб айтганда, Kubernetes контейнерларни миқёсда бошқаришнинг замонавий стандартига айланган кучли тизимдир. У ўз-ўзини тиклаш, автоматик миқёслаш ва хавфсиз деплой каби имкониятлар билан катта лойиҳаларни барқарор сақлашга ёрдам беради, аммо унинг мураккаблигини ҳисобга олиб, фақат ҳақиқатан ҳам керак бўлганда қўллаш мақсадга мувофиқдир.