10.8-bob: Kubernetes asoslari

10-QISM — DevOps va Deploy · 8-mavzu

1. Kirish va motivatsiya

10.4da Docker Compose bilan butun stack'ni — ilova, PostgreSQL, Redis, Nginx — bitta compose.yaml faylda, bir buyruq bilan ko'tarishni o'rgandik. Bu — kichik va o'rta loyiha uchun ajoyib yechim, holatlarning ~90%i shu bilan yopiladi. Lekin Compose'ning bitta tubdan kelib chiqadigan chegarasi bor: u faqat bitta mashinada ishlaydi. O'sha bitta server yiqilsa — butun ilovangiz bilan birga yiqiladi. Trafik kutilganidan o'n barobar oshsa — bitta serverning RAM/CPU'si yetmaydi, va siz yarim tunda qo'lda yangi server ko'tarib, yukni taqsimlashga urinishingizga to'g'ri keladi. Yangilik chiqarayotganda biror konteyner xato bersa — qo'lda orqaga qaytarish (rollback) kerak. Konteyner yiqilsa — uni kim qayta ko'taradi?

Endi tasavvur qiling: o'nlab server, ularda yuzlab konteyner, har birining sog'lig'ini kuzatish, yiqilganini qayta ko'tarish, yukka qarab nusxalar sonini oshirib-kamaytirish, yangi versiyani uzilishsiz tarqatish, va bularning hammasi avtomatik. Buni qo'lda yoki Compose bilan boshqarib bo'lmaydi — bu konteyner orkestratsiyasi (container orchestration — ko'p konteynerni ko'p mashinada muvofiqlashtirib boshqarish) muammosi. Junior dasturchi bitta serverga deploy qilib to'xtaydi; senior esa loyiha o'sganda uni klaster (cluster — birga ishlaydigan mashinalar to'plami)ga ko'taradi va o'zini o'zi davolaydigan (self-healing), avtomatik masshtablanadigan tizim quradi. Bu — Kubernetes.

Kubernetes (qisqacha K8s — "K" va "s" orasida 8 ta harf bor) — Google ichki tajribasidan tug'ilgan, hozir ochiq kodli, sanoat standartiga aylangan konteyner orkestratsiya tizimi. U sizga deklarativ (declarative — "men nima xohlayman"ni yozasiz, "qanday qilishni" K8s o'zi hal qiladi) tarzda: "menga shu ilovaning 3 ta nusxasi doim ishlab tursin, yiqilsa qayta ko'tar, yukka qarab oshir, yangilanishni uzilishsiz tarqat" deb aytish imkonini beradi. Siz istalgan holatni (desired state) ta'riflaysiz, Kubernetes esa doimiy ravishda haqiqiy holatni o'sha istalgan holatga yaqinlashtiradi (reconciliation — moslashtirish tsikli). Bu bob: K8s arxitekturasi (control plane, node), asosiy obyektlar (Pod, ReplicaSet, Deployment, Service, Ingress, ConfigMap, Secret, Namespace, Volume/PVC), kubectl buyruqlari, YAML manifest sintaksisi, self-healing (probe'lar), scaling (HPA), va lokal/managed K8s.

O'xshatish: Kubernetes — katta logistika markazining dirijyori (yoki port menejeri). Compose 10.4-bob bitta orkestrning dirijyori edi — bitta sahnada bir nechta cholg'u. Kubernetes esa butun bir port shahrini boshqaradi: o'nlab kema (server/node), har birida yuzlab konteyner (yuk konteynerlari — bu yerda dasturiy konteynerlar). Siz port menejeriga "men har doim 3 ta sovutgichli konteyner ishlab tursin xohlayman" deb buyurtma (manifest) berasiz. Menejer o'zi hal qiladi: qaysi kemaga joylash (scheduling), birortasi buzilsa — darrov yangisini topib o'rniga qo'yish (self-healing), bayram oldidan yuk ko'paysa — vaqtincha 10 taga oshirish (autoscaling), eski konteynerlarni bittalab yangisiga almashtirish (rolling update — port to'xtamaydi). Siz endi har bir konteyner bilan emas, butun port bilan bitta buyurtma varag'i (YAML) orqali ishlaysiz. Eshik raqamlari (Service — barqaror manzil) o'zgarmaydi, garchi ichidagi konteynerlar doim almashsa ham. Kirish darvozasi (Ingress) — qaysi mijoz qaysi ombor (servis)ga borishini yo'naltiradi.

Nega muhim?

• Self-healing va miqyos — yiqilgan konteyner avtomatik ko'tariladi, yukka qarab nusxalar oshadi (qo'lda emas).
• Uzilishsiz deploy — rolling update + rollback (foydalanuvchi sezmaydi, xato bo'lsa darrov orqaga).
• Sanoat standarti — AWS (EKS), Google (GKE), Azure (AKS) — hammasi K8s'ni boshqariladigan xizmat sifatida beradi.
• Intervyu/ish — 2026da o'rta/katta backend e'lonlarida "Kubernetes" eng ko'p so'raladigan DevOps ko'nikmasi (Compose'dan keyingi qadam).

2. Nazariya — chuqur tushuntirish

2.1. Container orchestration nima va nega (Compose chegarasi)

  COMPOSE 10.4-bob — BITTA mashinada ishlaydi:
  ┌──────────────── 1 SERVER ────────────────┐
  │  [app] [db] [redis] [nginx]               │
  └───────────────────────────────────────────┘
   server yiqilsa — HAMMASI yiqiladi (yagona nuqta)
   trafik 10x oshsa — bitta server yetmaydi
   konteyner yiqilsa — qo'lda qayta ko'tariladi
   scale qo'lda (--scale), avtomatik EMAS

  ORCHESTRATION (K8s) — KO'P mashinada (klaster):
  ┌─ node1 ─┐ ┌─ node2 ─┐ ┌─ node3 ─┐
  │ app app │ │ app db  │ │ redis   │    konteynerlar TAQSIMLANGAN
  └─────────┘ └─────────┘ └─────────┘
   node yiqilsa — K8s konteynerni BOSHQA node'ga ko'chiradi
   avto-scale (yukka qarab oshadi/kamayadi)
   self-healing (yiqilgan o'zi qayta ko'tariladi)
   rolling update (uzilishsiz yangilash)

Container orchestration (konteyner orkestratsiyasi) — ko'p konteynerni ko'p mashinada avtomatik joylashtirish, kuzatish, masshtablash va tiklash. Compose (10.4: 2.12) ajoyib, lekin bitta xost bilan cheklangan: o'sha server yagona buzilish nuqtasi (single point of failure) — yiqilsa hammasi ketadi, trafik oshsa bittaning resursi yetmaydi, konteyner yiqilsa qo'lda ko'tarasiz. Kubernetes bu muammolarni hal qiladi: konteynerlarni klaster (bir nechta server)ga taqsimlaydi, bitta server yiqilsa konteynerni boshqasiga ko'chiradi, yukka qarab avtomatik nusxa qo'shadi (autoscaling — 2.10), yiqilgan konteynerni o'zi qayta ko'taradi (self-healing — 2.11), va yangilanishni uzilishsiz tarqatadi (rolling update — 2.4). Compose'dan K8s'ga o'tish — "bitta server" tafakkuridan "klaster" tafakkuriga o'tish. Lekin esda tutish kerak: K8s murakkab — uni faqat haqiqatan kerak bo'lganda (katta miqyos, yuqori mavjudlik) qo'shish tavsiya etiladi; kichik loyiha umrining oxirigacha Compose'da qolishi mumkin.

2.2. K8s arxitekturasi — control plane va worker node

  KUBERNETES KLASTERI = CONTROL PLANE (miya) + WORKER NODE'lar (ishchi)

  ┌──────────── CONTROL PLANE (boshqaruv markazi) ────────────┐
  │  ┌─ kube-apiserver ─┐   HAMMA ulanadigan markaz (API)     │
  │  │ (barcha so'rov   │   kubectl, har komponent shu yerga  │
  │  └──────────────────┘                                       │
  │  ┌─ etcd ─────────┐   klaster HOLATI (key-value DB)        │
  │  │ (yagona haqiqat │   "nima ishlashi kerak" shu yerda     │
  │  └─────────────────┘                                        │
  │  ┌─ scheduler ────┐   yangi Pod'ni QAYSI node'ga joylash   │
  │  ┌─ controller-mgr┐   holatni kuzatadi, mos keltiradi      │
  └────────────────────────────────────────────────────────────┘
                          │ (apiserver orqali)
       ┌──────────────────┼──────────────────┐
  ┌─ NODE 1 ─────────┐ ┌─ NODE 2 ─────────┐   WORKER (ish bajaradi)
  │ kubelet          │ │ kubelet          │   node "agenti"
  │ kube-proxy       │ │ kube-proxy       │   tarmoq qoidalari
  │ container runtime│ │ container runtime│   containerd (konteyner)
  │  [Pod] [Pod]     │ │  [Pod] [Pod]     │   haqiqiy ilova shu yerda
  └──────────────────┘ └──────────────────┘

Kubernetes arxitekturasi ikki qismdan iborat. Control plane (boshqaruv tekisligi — klaster "miyasi") — qarorlar qabul qiladi: kube-apiserver (API server — klaster markazi: kubectl, har bir komponent, har bir so'rov shu yerga keladi; klasterning yagona kirish nuqtasi); etcd (izchil va yuqori mavjud key-value bazasi — klasterning butun holati shu yerda saqlanadi: "nima ishlashi kerak", "hozir nima ishlayapti" — yagona haqiqat manbai); kube-scheduler (rejalashtiruvchi — yangi Podni qaysi nodega joylashni hal qiladi, resurs va cheklovlarga qarab); kube-controller-manager (kontroller menejeri — doimiy tsiklda holatni kuzatadi va haqiqiy holatni istalgan holatga mos keltiradi — 2.3). Worker node'lar (ishchi tugunlar — haqiqiy ilova shu yerda ishlaydi): kubelet (har node'dagi agent — Pod'lar ishlayotganini, konteynerlar sog'ligini ta'minlaydi, control plane bilan gaplashadi); kube-proxy (tarmoq qoidalarini saqlaydi — Service'lar uchun trafik yo'naltirish — 2.5); container runtime (konteynerni haqiqatan ishlatadigan dastur — containerd yoki CRI-O; Docker'dan keyin standart containerd bo'ldi). Siz kubectl bilan faqat apiserver bilan gaplashasiz; qolgan hamma narsa avtomatik.

2.3. Pod — eng kichik birlik (bir yoki ko'p konteyner)

  POD — Kubernetes'da eng KICHIK joylashtiriladigan birlik:
   konteyner EMAS, Pod (konteynerni "o'rab turuvchi" qatlam)

  ┌──────────── POD ────────────┐
  │  ┌─ konteyner ─┐            │   odatda 1 ta konteyner (eng keng holat)
  │  │  app:3000   │            │
  │  └─────────────┘            │
  │  ┌─ sidecar ───┐ (ixtiyoriy)│   ba'zan 2-konteyner (yordamchi):
  │  │  log-agent  │            │     log yig'uvchi, proxy
  │  └─────────────┘            │
  │  ULASHILGAN: 1 IP, tarmoq, volume (konteynerlar localhost bilan gaplashadi)
  └─────────────────────────────┘

   POD — VAQTINCHALIK (ephemeral): yiqilsa o'chadi, IP o'zgaradi
   POD'ni TO'G'RIDAN yaratma  Deployment ishlatadi (2.4)

Pod — Kubernetes'da eng kichik joylashtiriladigan birlik. Muhim tushuncha: K8s konteynerni to'g'ridan-to'g'ri boshqarmaydi — u konteynerni Pod ichiga "o'raydi". Pod — bir yoki bir nechta chambarchas bog'liq konteynerni o'z ichiga oladi, ular bitta IP manzil, tarmoq va saqlash (volume)ni ulashadi (shuning uchun bir Pod ichidagi konteynerlar localhost orqali gaplashadi). Eng keng tarqalgan holat — bitta Pod = bitta konteyner (sizning ilovang). Ko'p konteynerli Pod — ilg'or naqsh: asosiy konteyner + sidecar (yordamchi — masalan log yig'uvchi, proxy). Ikki tub xususiyat: (1) Pod vaqtinchalik (ephemeral) — yiqilsa o'chadi, yangisi boshqa IP bilan ko'tariladi (shuning uchun Pod IP'siga ishonmaslik kerak — Service kerak, 2.5); (2) Pod'ni to'g'ridan-to'g'ri yaratmaslik kerak — buning o'rniga Deployment ishlatiladi (u Pod'larni o'zi yaratadi va boshqaradi — 2.4). Pod manifesti: apiVersion: v1, kind: Pod, spec.containers.

2.4. ReplicaSet va Deployment (deklarativ, rolling update, rollback)

  IERARXIYA: Deployment  ReplicaSet  Pod'lar

  ┌─ DEPLOYMENT (sen YOZASAN — "3 nusxa, image X") ─┐
  │  ┌─ ReplicaSet (3 ta Pod doim ishlasin) ─────┐  │
  │  │   [Pod] [Pod] [Pod]                        │  │   1 yiqilsa  2 qoldi
  │  └────────────────────────────────────────────┘  │   RS DARROV 3-ni ko'taradi
  └──────────────────────────────────────────────────┘

  REPLICASET — nusxalar (replica) sonini USHLAB turadi:
   "3 ta bo'lsin" deyiladi; 1 yiqilsa  o'zi yangi 1 ta ko'taradi

  DEPLOYMENT — ReplicaSet ustida (yangilash/orqaga qaytarishni boshqaradi):
  ROLLING UPDATE (image yangilansa — UZILISHSIZ):
    eski:  [v1][v1][v1]
          [v1][v1][v2]    bittalab almashadi (xizmat to'xtamaydi)
          [v1][v2][v2]
          [v2][v2][v2]
  ROLLBACK:  kubectl rollout undo   xato bo'lsa OLDINGI versiyaga qayt

ReplicaSet va Deployment — ilova ishlatishning asosiy mexanizmi. Ierarxiya: Deployment ReplicaSet Pod. ReplicaSet — belgilangan nusxalar (replica) sonini doim ushlab turadi: "3 ta Pod ishlasin" desangiz, biri yiqilsa darrov yangi bittasini ko'taradi (bu — self-healing'ning bir qismi — 2.11). Lekin ReplicaSet'ni ham to'g'ridan ishlatmaslik kerak — uning ustida Deployment turadi. Deployment — eng ko'p ishlatiladigan obyekt: deklarativ (siz istalgan holatni yozasiz — qaysi image, nechta replicas), va K8s o'sha holatga keltiradi. Eng kuchli imkoniyatlari: (1) rolling update — imageni yangilasangiz, Deployment yangi ReplicaSet yaratib, Pod'larni bittalab almashtiradi (eski yiqilmaguncha yangi ko'tariladi) — xizmat to'xtamaydi (uzilishsiz, zero-downtime); (2) rollback — yangi versiya xato bo'lsa, kubectl rollout undo bilan oldingi ishlaydigan versiyaga darrov qaytasiz. selector.matchLabels Deployment qaysi Pod'larni boshqarishini belgilaydi va template.metadata.labels bilan mos kelishi shart (2.9 — label/selector). Stateless ilova (backend API) uchun Deployment — standart; stateful (DB identifikatori muhim) uchun StatefulSet ishlatiladi.

2.5. Service — Pod'larga barqaror manzil (service discovery)

  MUAMMO: Pod VAQTINCHALIK — IP doim o'zgaradi 2.3-bob
   app Pod'i db Pod'ining IP'sini qanday topadi? (IP ertaga boshqacha)

  YECHIM: SERVICE — Pod'lar oldida BARQAROR manzil (IP + DNS nomi):

  ┌─ Service "db" (barqaror IP + DNS) ─┐
  │   selector: app=db                 │   LABEL bilan Pod topadi 2.9-bob
  └────────────────────────────────────┘
         │ avtomatik yo'naltiradi (yukni taqsimlab)
    ┌────┼────┐
  [db-Pod][db-Pod]   Pod'lar almashsa ham, Service NOMI o'zgarmaydi

  TURLARI (type):
  ClusterIP     faqat KLASTER ICHIDA (default — appdb, ichki)
  NodePort      har node'da port ochadi (test uchun)
  LoadBalancer  bulut LB orqali TASHQARIGA (public — prod)

  SERVICE DISCOVERY:  app  "http://db:5432"   NOM bilan (IP kerak emas)

Service — Pod'larning vaqtinchaligini hal qiladi. Muammo: Pod yiqilib qayta ko'tarilsa IP o'zgaradi 2.3-bob — app Pod'i db Pod'ining doim o'zgaradigan IP'sini qanday topadi? Yechim — Service: Pod'lar to'plami oldida barqaror IP va doimiy DNS nomi beradi. Service Pod'larni label/selector orqali topadi 2.9-bob: selector: app=db — app=db belgisi bo'lgan hamma Pod'ga trafikni avtomatik taqsimlaydi (yukni balanslaydi). Pod'lar almashsa ham Service nomi o'zgarmaydi. Service discovery (servis topish): ilova boshqa servisga nomi bilan ulanadi — http://db:5432 (IP kerak emas, K8s ichki DNS hal qiladi — Compose'dagi servis nomi g'oyasiga o'xshash, 10.4: 2.4). Turlari (type): ClusterIP (default — faqat klaster ichida, appdb kabi ichki aloqa uchun); NodePort (har node'da statik port ochadi — 30000-32767, asosan test); LoadBalancer (bulut provayderining load balanceri orqali tashqariga ochadi — public production trafik uchun). Service'da port (Service tinglaydigan port) va targetPort (Pod'dagi port) farqlanadi.

2.6. Ingress — HTTP routing, domen va TLS

  MUAMMO: har servis uchun alohida LoadBalancer = qimmat + ko'p IP
   10 ta servis = 10 ta bulut LB = 10 ta hisob 

  YECHIM: INGRESS — BITTA kirish nuqtasi, HTTP'ni domen/yo'l bo'yicha yo'naltiradi:

       Internet (https://saytim.uz)
              │
   ┌─ INGRESS CONTROLLER (nginx) ─┐   BITTA tashqi IP + TLS (HTTPS)
   │  saytim.uz/         web-svc  │
   │  saytim.uz/api      api-svc  │   DOMEN va YO'L bo'yicha routing
   │  admin.saytim.uz    admin-svc│
   └───────────────────────────────┘
        │           │           │
     [web-svc]  [api-svc]  [admin-svc]   Service'lar (2.5)

   INGRESS ≠ SERVICE: Ingress faqat HTTP/HTTPS (7-qatlam), domen/yo'l/TLS
   Ishlashi uchun INGRESS CONTROLLER kerak (nginx-ingress o'rnatiladi)

Ingress — HTTP/HTTPS trafikni klasterga bitta darvoza orqali kirituvchi obyekt. Muammo: har bir servisga alohida LoadBalancer Service qo'ysangiz — har biri uchun alohida bulut LB va tashqi IP kerak (qimmat). Ingress buni hal qiladi: bitta tashqi kirish nuqtasi, va u domen (host) va yo'l (path) bo'yicha trafikni ichki Service'larga yo'naltiradi. Masalan saytim.uz/api api-svc, saytim.uz/ web-svc, admin.saytim.uz admin-svc. Ingress TLS (HTTPS) ni ham hal qiladi — sertifikatni Secret'da saqlab 2.7-bob, Ingress'da tls bo'limida ko'rsatasiz (10.2'dagi Nginx SSL g'oyasi, lekin K8s darajasida). Ingress ≠ Service: Service har qanday TCP/UDP portni ochadi (4-qatlam), Ingress esa faqat HTTP/HTTPS (7-qatlam) — domen, yo'l, TLS bilan. Eng muhim: Ingress o'zi hech narsa qilmaydi — uni Ingress controller (masalan nginx-ingress — bu aslida 10.2'dagi Nginx reverse proxyning K8s ichidagi varianti) bajaradi, shuni klasterga alohida o'rnatish kerak. pathType: Prefix (yo'l boshini moslaydi) eng keng ishlatiladi. Eslatma: 2026da yangi loyihalar uchun K8s Gateway APIni tavsiya qiladi (Ingress "muzlatilgan" — yangi imkoniyat qo'shilmaydi), lekin Ingress hali eng keng tarqalgan.

2.7. ConfigMap va Secret (konfiguratsiya va maxfiy ma'lumot)

  MUAMMO: sozlama/parolni image ICHIGA yozma (har muhitda boshqacha + sir tarqaydi)
   "12-factor" tamoyili: konfiguratsiya KODDAN ajratilgan bo'lsin 5.8-bob

  CONFIGMAP — oddiy (maxfiy EMAS) sozlama (key-value):
  ┌─ ConfigMap "app-config" ─┐
  │ NODE_ENV: production      │   oddiy matn (ochiq saqlanadi)
  │ LOG_LEVEL: info           │
  └───────────────────────────┘

  SECRET — MAXFIY ma'lumot (parol, token, kalit):
  ┌─ Secret "app-secret" ────┐
  │ DB_PASSWORD: <base64>     │   base64 (shifr EMAS! faqat kodlash)
  │ JWT_SECRET: <base64>      │
  └───────────────────────────┘

  ISHLATISH: Pod'ga env yoki fayl sifatida ulanadi (2.8 Misol)
   Secret base64 — bu SHIFRLASH EMAS (oson dekodlanadi) — Git'ga TUSHMASIN!

ConfigMap va Secret — konfiguratsiyani koddan ajratish mexanizmi. Tamoyil (5.8 — env, 12-factor): sozlama va parolni image ichiga yozma (har muhitda boshqacha bo'ladi, parol sir bo'lib qolishi kerak). ConfigMap — maxfiy bo'lmagan konfiguratsiya: NODE_ENV, LOG_LEVEL, API URL'lari (key-value, oddiy matn, ochiq saqlanadi; maks 1 MiB). Secret — maxfiy ma'lumot: DB paroli, JWT kaliti, API tokenlari. Juda muhim tushunmovchilik: Secret qiymatlari base64 bilan kodlanadi — bu shifrlash EMAS (base64 oson orqaga dekodlanadi, faqat "ko'zga ko'rinmas" qiladi)! Haqiqiy himoya uchun etcd'da shifrlashni yoqish yoki tashqi secret menejer (Vault, AWS Secrets Manager — 10.11) kerak. Ikkalasi ham Pod'ga ikki usulda ulanadi: muhit o'zgaruvchisi (env) yoki fayl (volume sifatida mount). Eng muhim qoida: Secret manifestlari Git'ga tushmasin (10.11 — secrets boshqaruvi). Compose'dagi .env g'oyasi (10.4: 2.7), lekin K8s'da rasmiy obyekt sifatida.

2.8. ConfigMap/Secret'ni Pod'ga ulash (env va volume)

  IKKI XIL ULASH USULI:

  1) MUHIT O'ZGARUVCHISI (env) — eng keng:
     env:
       - name: DB_PASSWORD
         valueFrom:
           secretKeyRef:            Secret'dan BITTA kalit
             name: app-secret
             key: DB_PASSWORD
     envFrom:
       - configMapRef:              ConfigMap'dagi HAMMA kalit env bo'ladi
           name: app-config

  2) FAYL (volume mount) — config fayllar uchun:
     volumes:
       - name: cfg
         configMap: { name: app-config }
     volumeMounts:
       - name: cfg
         mountPath: /etc/config      har kalit /etc/config/<kalit> fayli bo'ladi

   env — Pod qayta ko'tarilganda yangilanadi
   volume mount — avtomatik yangilanadi (kubelet sinxron — fayllar uchun)

ConfigMap/Secret'ni ulash — ikki usul. (1) Muhit o'zgaruvchisi (env — eng keng): valueFrom.secretKeyRef / configMapKeyRef bilan bitta kalitni olib, env nomi beriladi; yoki envFrom bilan ConfigMap/Secret'dagi barcha kalitni avtomatik env qilasiz. Ilova process.env.DB_PASSWORD bilan o'qiydi 5.8-bob. (2) Fayl (volume mount): ConfigMap/Secret'ni volumesda e'lon qilib, volumeMounts bilan papkaga ulaysiz — har bir kalit alohida fayl bo'ladi (/etc/config/<kalit>); bu — config fayl (nginx.conf, sertifikat) uchun qulay. Farq: env orqali ulangan qiymat o'zgarsa — Pod qayta ko'tarilishi kerak (env Pod boshlanganda o'qiladi); volume orqali ulangan fayl esa kubelet tomonidan avtomatik yangilanadi (Pod'ni qayta ko'tarmasdan). Production'da DB paroli — Secret'dan env; katta config fayl — ConfigMap'dan volume. Bu — konfiguratsiyani toza, qayta ishlatiladigan tarzda boshqarish usuli.

2.9. Namespace, label va selector

  NAMESPACE — klaster ICHIDA mantiqiy AJRATISH (papka kabi):
  ┌─ default ──┐ ┌─ kube-system ─┐ ┌─ team-a ──┐ ┌─ prod ──┐
  │ sening Pod │ │ K8s tizimi    │ │ A jamoa   │ │ ishlab  │
  └────────────┘ └───────────────┘ └───────────┘ └─────────┘
   bir xil nom turli namespace'da bo'lishi mumkin (ajratilgan)
   kubectl get pods -n prod    -n bilan namespace tanlash

  LABEL — obyektga "yorliq" (key-value), tartiblash uchun:
  labels:
    app: backend           Pod'ga yopishtiriladi
    env: production

  SELECTOR — label bo'yicha TANLASH (Service/Deployment shu bilan topadi):
  selector:
    matchLabels:
      app: backend         "app=backend" Pod'larni boshqaradi/yo'naltiradi

   LABEL/SELECTOR — K8s'ni bog'lab turuvchi YELIM (ServicePod, DeployPod)

Namespace, label, selector — K8s'ni tartibga soluvchi uch tushuncha. Namespace — klaster ichida resurslarni mantiqiy ajratish (papka kabi). Boshlang'ich namespace'lar: default (siz yaratgan obyektlar shu yerda, agar ko'rsatmasangiz), kube-system (K8s tizim komponentlari — 2.2), kube-public, kube-node-lease. Foydasi: bir nechta jamoa/muhit (dev/staging/prod) bitta klasterni ulashganda izolyatsiya va resurs kvotasi. kubectl ... -n <namespace> bilan tanlaysiz. Label (yorliq) — obyektga yopishtiriladigan key-value (app: backend, env: production) — tartiblash va tanlash uchun. Selector — label bo'yicha tanlash mexanizmi: selector.matchLabels: {app: backend} — app=backend belgili Pod'larni tanlaydi. Bu — K8s'ni bog'lab turuvchi yelim: Service Pod'larni selector bilan topadi 2.5-bob, Deployment o'z Pod'larini selector bilan boshqaradi 2.4-bob. Eng keng tarqalgan xato — selector va Pod label'i mos kelmasligi (Service Pod'ga ulanmaydi — Xato 4). Production'da default namespace'ni ishlatmaslik kerak — har loyiha/muhitga alohida namespace yaratiladi.

2.10. Scaling — manual va HPA (avtomatik)

  SCALING — nusxalar (replica) sonini o'zgartirish (gorizontal — 9.9):

  1) MANUAL (qo'lda):
     kubectl scale deployment app --replicas=5    3 dan 5 ga (darrov)

  2) HPA (HorizontalPodAutoscaler) — AVTOMATIK (yukka qarab):
  ┌─ HPA: app, min=2, max=10, CPU target=70% ─┐
  │  CPU 30%  2 nusxa (kam yuk, minimal)      │
  │  CPU 85%  6 nusxa (yuk oshdi, K8s oshirdi)│   AVTOMATIK
  │  CPU pasaysa  yana kamaytiradi            │
  └────────────────────────────────────────────┘

  HPA TALABLARI (majburiy):
   metrics-server o'rnatilgan (CPU/RAM o'lchaydi)
   Pod'da resources.requests.cpu ko'rsatilgan (aks holda HPA ishlamaydi)

  FORMULA: kerakli = ceil(hozirgi × hozirgiMetrik / maqsadMetrik)

Scaling — nusxalar sonini boshqarish (gorizontal masshtablash — 9.9). (1) Manual: kubectl scale deployment app --replicas=5 — darrov belgilangan songa keltiradi. (2) HPA (HorizontalPodAutoscaler) — avtomatik: yukka (CPU/RAM yoki maxsus metrika) qarab nusxalar sonini o'zi oshiradi/kamaytiradi. Masalan min=2, max=10, CPU target=70%: CPU 85%ga chiqsa K8s nusxa qo'shadi, pasaysa kamaytiradi. HPA ikki shart bilan ishlaydi (juda keng adashtiriladi): (1) klasterda metrics-server o'rnatilgan bo'lishi kerak (u CPU/RAM o'lchaydi); (2) Deployment'da resources.requests.cpu ko'rsatilgan bo'lishi shart — aks holda HPA CPU foizini hisoblay olmaydi va hech narsa qilmaydi (Xato — eng keng). Formula: kerakli = ceil(hozirgiNusxa × hozirgiMetrik / maqsadMetrik). HPA — Compose'da yo'q bo'lgan (qo'lda --scale) imkoniyat (10.4: 2.10); bu Kubernetes'ning eng kuchli ustunliklaridan biri. autoscaling/v2 API ishlatiladi (bir nechta metrika qo'llab-quvvatlanadi).

2.11. Self-healing — liveness va readiness probe

  SELF-HEALING — K8s ilovani O'ZI davolaydi (odam aralashuvisiz):
   konteyner yiqilsa kubelet qayta ko'taradi (restartPolicy: Always)
   lekin "jarayon ishlayapti" ≠ "ilova SOG'LOM"  PROBE kerak

  LIVENESS PROBE — "ilova TIRIKMI?" (osilib qolmadimi):
    livenessProbe: { httpGet: { path: /healthz, port: 8080 } }
     FAIL bo'lsa  konteynerni QAYTA ISHGA TUSHIRADI (restart)

  READINESS PROBE — "trafik qabul qilishga TAYYORMI?":
    readinessProbe: { httpGet: { path: /ready, port: 8080 } }
     FAIL bo'lsa  Service'dan UZADI (trafik yubormaydi), restart QILMAYDI
     masalan DB ulanmaguncha "tayyor emas" (yangi so'rov bormasin)

  STARTUP PROBE — sekin ishga tushadigan ilova uchun (boshlang'ich grace)

   LIVENESS = qayta tirilt ;  READINESS = trafikdan vaqtincha uz

Self-healing — Kubernetes'ning markaziy ustunligi. Asosiy mexanizm: konteyner yiqilsa, kubelet uni **restartPolicy**ga qarab qayta ko'taradi (Always — default). Lekin muammo: "jarayon ishlayapti" ≠ "ilova sog'lom" — ilova osilib qolishi yoki DB'ga ulanmasligi mumkin, lekin jarayon hali "tirik". Shuning uchun probe (zond — sog'liq tekshiruvi) kerak. Liveness probe ("tirikmi?") — ilova osilib qolmadimi tekshiradi (masalan httpGet: /healthz); fail bo'lsa konteynerni qayta ishga tushiradi (restart — osilgan ilovani "tiriltadi"). Readiness probe ("tayyormi?") — ilova trafik qabul qilishga tayyormi (masalan DB ulanmaguncha tayyor emas); fail bo'lsa Pod'ni Service endpoint'idan uzadi (yangi so'rov yubormaydi), lekin restart qilmaydi — ilova o'ziga kelguncha kutadi. Startup probe — sekin ishga tushadigan ilova uchun boshlang'ich vaqt beradi (boshqa probe'lar shu o'tguncha o'chiriladi). Farqni yodda tutish kerak: liveness = qayta tirilt (osilgan), readiness = trafikdan vaqtincha uz (band/tayyor emas). Probe'lar (initialDelaySeconds, periodSeconds, failureThreshold) — production ilova uchun majburiy (10.4: 2.6 healthcheck g'oyasi, lekin K8s'da kuchliroq).

2.12. Volume va PersistentVolumeClaim (ma'lumot saqlash)

  MUAMMO: Pod VAQTINCHALIK 2.3-bob  ichidagi ma'lumot Pod o'chsa YO'QOLADI
   DB Pod'i yiqilsa — bazadagi hamma ma'lumot ketadimi? 

  YECHIM: PERSISTENT VOLUME (PV) + PVC — Pod'dan AJRATILGAN saqlash:

  ┌─ PVC (so'rov: "menga 10Gi kerak") ─┐
  │  accessModes: [ReadWriteOnce]       │   Pod RESURS so'ragandek SAQLASH so'raydi
  │  resources: { storage: 10Gi }       │
  └─────────────────────────────────────┘
            │ bog'lanadi (bind)
  ┌─ PV (haqiqiy disk — bulut diski/EBS) ─┐   StorageClass AVTOMATIK yaratadi
  └────────────────────────────────────────┘
   Pod o'chsa ham PVC/PV QOLADI  ma'lumot saqlanadi 

  ACCESS MODES: RWO (1 node yozadi) | ROX (ko'p o'qiydi) | RWX (ko'p yozadi)
   DB uchun PVC MAJBURIY (Compose'dagi named volume g'oyasi — 10.4: 2.5)

Volume va PVC — Pod'ning vaqtinchaligiga qarshi ma'lumot saqlash. Muammo: Pod o'chsa ichidagi ma'lumot yo'qoladi 2.3-bob — DB Pod'i yiqilsa baza ketmasligi kerak. Yechim — PersistentVolume (PV) va PersistentVolumeClaim (PVC): saqlashni Pod hayotidan ajratish. PVC — foydalanuvchining saqlash so'rovi (Pod CPU/RAM so'raganidek, "menga 10Gi disk kerak" deydi); PV — haqiqiy saqlash resursi (bulut diski — AWS EBS, GCP PD). Zamonaviy yo'l — StorageClass orqali dinamik provayding: PVC so'rov yuborsa, K8s mos PV'ni avtomatik yaratadi (admin oldindan tayyorlamaydi). Pod PVC'ni volumes.persistentVolumeClaim bilan ulaydi — va Pod o'chsa ham PVC/PV qoladi, ma'lumot saqlanadi. Access modes: ReadWriteOnce (RWO — bitta node yozadi, eng keng — DB uchun), ReadOnlyMany (ROX — ko'p node o'qiydi), ReadWriteMany (RWX — ko'p node yozadi). DB (PostgreSQL, MongoDB) Pod'i uchun PVC majburiy (Compose'dagi named volume g'oyasi — 10.4: 2.5, lekin klaster darajasida). Stateful ilova odatda StatefulSet + PVC bilan ishlatiladi.

2.13. Declarative vs imperative, lokal va managed K8s

  IKKI YONDASHUV:
  IMPERATIVE (buyruq bilan — "qanday"):
    kubectl run app --image=app:1.0      tez, lekin Git'da iz qolmaydi
    kubectl scale deployment app --replicas=5
     o'rganish/test uchun yaxshi, PRODUCTION uchun emas

  DECLARATIVE (manifest bilan — "nima"):   TAVSIYA (GitOps)
    kubectl apply -f deployment.yaml     YAML Git'da, takrorlanadi
     istalgan holat yoziladi, K8s mos keltiradi

  K8s QAYERDA ISHLATILADI:
  LOKAL (o'rganish/dev — bepul):
    minikube   bitta node VM'da    |  kind  Docker ichida K8s
  MANAGED (production — bulut boshqaradi control plane'ni):
    EKS (AWS) | GKE (Google) | AKS (Azure)   10.6 (sen faqat node to'laysan)

Declarative vs imperative va K8s qayerda ishlashi. Imperative (buyruq bilan — "qanday qilish"): kubectl run, kubectl scale — tez, lekin Git'da iz qolmaydi, takrorlanmaydi (o'rganish/test uchun yaxshi). Declarative (manifest bilan — "nima kerak" — tavsiya etiladi): kubectl apply -f file.yaml — istalgan holatni YAML'ga yozib, Git'ga qo'yasiz (GitOps), K8s o'sha holatga keltiradi va saqlaydi. Compose'dagi deklarativlik g'oyasi (10.4: 2.1) bu yerda yanada kuchli — butun infratuzilma kod sifatida (10.10 — IaC). K8s qayerda ishlaydi: (1) Lokal (o'rganish/dev, bepul) — minikube (bitta node'li klaster VM'da) yoki kind (Kubernetes-in-Docker — Docker konteynerlari ichida klaster); bularda mashq qilasiz. (2) Managed (production) — bulut provayderi control plane'ni o'zi boshqaradi: EKS (AWS), GKE (Google), AKS (Azure — 10.6). Siz faqat worker node'lar (va ish) uchun to'laysiz, control plane (apiserver, etcd, scheduler — 2.2) murakkabligini bulut o'z bo'yniga oladi. Boshlash uchun: minikube/kind'da o'rganib, keyin production'da managed K8s ishlatiladi — control plane'ni o'zingiz boshqarishga urinish katta xato (juda murakkab).

2.14. Boshqa workload turlari — StatefulSet, DaemonSet, Job/CronJob

  DEPLOYMENT — stateless (backend API) uchun standart 2.4-bob. Lekin K8s'da
  boshqa MAQSADLAR uchun alohida workload obyektlari bor:

  STATEFULSET — STATE muhim ilova (DB, Kafka, Redis-cluster):
     har Pod BARQAROR nom oladi: db-0, db-1, db-2 (tartibli, o'zgarmas)
     har Pod'ga BARQAROR PVC (db-0 o'z diskiga qaytadi — 2.12)
     tartibli ko'tarish/o'chirish (0  1  2 ; teskari o'chadi)
     Headless Service bilan (clusterIP: None) — har Pod'ning DNS'i

  DAEMONSET — HAR node'da AYNAN 1 nusxa (node qo'shilsa — avtomatik):
     log yig'uvchi (Fluentd), monitoring agenti (node-exporter — 10.9),
      tarmoq plagini — "har mashinada bittadan ishlashi kerak" bo'lganlar

  JOB — BIR MARTALIK vazifa (bajarilib TUGAYDI, doim ishlamaydi):
     migratsiya, hisobot, batch — muvaffaqiyatli tugasa "Completed"
  CRONJOB — JADVAL bo'yicha Job (cron sintaksisi — 6.x g'oyasi):
     "0 3 * * *" (har kecha 03:00) — backup, tozalash, hisobot

Boshqa workload turlari. Deployment 2.4-bob — stateless ilova (backend API, har nusxa bir xil, tartib muhim emas) uchun standart. Lekin K8s boshqa maqsadlar uchun alohida obyektlar beradi. StatefulSet — holati muhim (stateful) ilova uchun: ma'lumotlar bazasi (PostgreSQL, MongoDB), Kafka, Redis-cluster. Deployment'dan farqi: (1) har Pod barqaror, tartibli nom oladi (db-0, db-1, db-2 — o'zgarmas identifikator), (2) har Pod o'zining barqaror PVCsiga ega (db-0 qayta ko'tarilsa aynan o'z diskiga qaytadi — 2.12), (3) Pod'lar tartibli ko'tariladi va teskari tartibda o'chadi, (4) odatda headless Service (clusterIP: None) bilan ishlaydi — har Pod'ning o'z DNS nomi bo'ladi (masalan db-0.db). Bu — DB replikatsiyasi kabi "kim primary, kim replica" muhim bo'lgan holatlar uchun zarur. DaemonSet — har node'da aynan bitta Pod ishlashini ta'minlaydi (klaster o'sib node qo'shilsa — yangi node'da avtomatik ko'tariladi). Foydasi: har mashinada ishlashi kerak bo'lgan infratuzilma agentlari — log yig'uvchi (Fluentd), node metrikasi (node-exporter — 10.9), tarmoq plagini. Job — bir martalik vazifa: bajarilib tugaydi (doim ishlamaydi) — DB migratsiyasi, hisobot generatsiyasi, batch ish; muvaffaqiyatli tugasa Pod Completed holatida qoladi. CronJob — jadval bo'yicha takrorlanadigan Job: cron sintaksisi ("0 3 * * *" — har kecha 03:00) bilan backup, tozalash, davriy hisobot. ExternalName — Service'ning maxsus turi 2.5-bob: selector emas, tashqi DNS nomiga taxallus (my-db db.example.com) — klaster ichidan tashqi xizmatga barqaror nom bilan ulanish uchun.

2.15. Resurs QoS, RBAC va Helm (paket menejeri)

  QoS SINFLARI (resources'ga qarab — K8s AVTOMATIK belgilaydi):
    Guaranteed   requests == limits (ikkalasi bor, teng) — eng himoyalangan
    Burstable    requests < limits (yoki faqat requests) — o'rtacha
    BestEffort   resources YO'Q — RAM tugasa BIRINCHI o'ldiriladi 
     node RAM tugasa (OOM) K8s BestEffort  Burstable tartibida o'ldiradi

  RBAC — KIM nimaga ruxsat (Role-Based Access Control):
    Role (namespace) / ClusterRole (butun klaster) — ruxsatlar to'plami
    RoleBinding — Role'ni User/Group/ServiceAccount'ga BOG'LAYDI
     "ci-bot faqat prod namespace'da deploy qila olsin" kabi

  HELM — K8s'ning PAKET MENEJERI (npm/apt kabi):
    chart   tayyor manifest to'plami (shabon)   values.yaml  sozlamalar
    helm install postgres bitnami/postgresql      bitta buyruq bilan o'rnatish
     murakkab ilovani (ko'p YAML) qayta ishlatiladigan paketga o'raydi

QoS, RBAC va Helm. QoS (Quality of Service) sinflari — Pod'ga resources 2.10-bob qanday berilganiga qarab K8s avtomatik belgilaydi va node resursi tugaganda (OOM — RAM tugashi) qaysi Pod'ni birinchi o'chirishni shu bilan hal qiladi: Guaranteed (requests == limits, ikkalasi ko'rsatilgan va teng — eng himoyalangan, oxirida o'ldiriladi), Burstable (requests < limits, yoki faqat requests — o'rtacha), BestEffort (resources umuman yo'q — birinchi bo'lib o'ldiriladi). Production ilovaga hech bo'lmaganda Burstable (requests bilan) berish kerak. RBAC (Role-Based Access Control) — klasterda kim nimaga ruxsati borligini boshqaradi: Role (namespace ichida) yoki ClusterRole (butun klaster) — ruxsatlar to'plamini (masalan "Pod'larni o'qish, Deployment'ni yangilash") ta'riflaydi; RoleBinding / ClusterRoleBinding — bu rolni foydalanuvchi, guruh yoki ServiceAccountga (Pod ichidagi ilova nomidan) bog'laydi. Bu — CI bot yoki jamoa a'zosiga faqat kerakli ruxsatni berish (eng kam imtiyoz tamoyili — 8.x xavfsizlik g'oyasi) uchun zarur. Helm — K8s'ning paket menejeri (npm/apt ga o'xshash): chart — qayta ishlatiladigan manifest to'plami (shablon), values.yaml — o'sha shablonni sozlash qiymatlari, release — chartning klasterga o'rnatilgan nusxasi. helm install my-db bitnami/postgresql bilan murakkab ilovani (o'nlab YAML) bitta buyruq bilan o'rnatasiz. Foydasi: PostgreSQL, Redis, Prometheus kabi tayyor ilovalarni qo'lda o'nlab manifest yozmasdan, tekshirilgan chart orqali o'rnatish; o'z ilovangizni ham chart qilib, dev/staging/prod uchun turli values bilan qayta ishlatasiz.

3. Sintaksis — tez ma'lumotnoma

KO'RISH (get): kubectl get pods | get svc | get deploy | get ns | get all
       kubectl get pods -n prod           namespace bilan 2.9-bob
       kubectl get pods -o wide           qo'shimcha (node, IP)
       kubectl get pods --show-labels     label'lar bilan 2.9-bob
QO'LLASH (declarative — 2.13): kubectl apply -f file.yaml | apply -f ./dir/
       kubectl delete -f file.yaml | delete pod <nom>
BATAFSIL: kubectl describe pod <nom>      to'liq holat + EVENT (debug — 6.x)
LOG (10.4 g'oyasi): kubectl logs <pod> | logs -f <pod> | logs <pod> -c <konteyner>
ICHIGA KIRISH: kubectl exec -it <pod> -- sh     konteynerga kir (10.3 g'oyasi)
SCALE 2.10-bob: kubectl scale deployment <nom> --replicas=5
       kubectl autoscale deployment <nom> --min=2 --max=10 --cpu-percent=70
ROLLOUT 2.4-bob: kubectl rollout status deployment/<nom>
       kubectl rollout history deployment/<nom> | rollout undo deployment/<nom>
       kubectl set image deployment/<nom> app=app:2.0    rolling update boshlash
IMPERATIVE (test — 2.13): kubectl run | kubectl create deployment | expose
KONTEKST: kubectl config get-contexts | config use-context <nom> | cluster-info

YAML KALITLAR: apiVersion | kind | metadata(name,labels,namespace) | spec
  Deployment: replicas, selector.matchLabels, template.spec.containers
  Service: type, selector, ports(port,targetPort) | Ingress: rules,tls

4. Batafsil kod namunalari

Misol 1 — Eng oddiy Pod manifesti (2.3)

# pod.yaml — eng kichik birlik (odatda TO'G'RIDAN yaratilmaydi — Deployment ishlatiladi)
apiVersion: v1                  # Pod uchun "v1" (asosiy API guruhi — 2.3)
kind: Pod                       # obyekt turi: Pod
metadata:
  name: web                     # Pod nomi (DNS subdomain bo'lishi kerak)
  labels:
    app: web                    # yorliq — Service shu bilan topadi (2.9)
spec:
  containers:
    - name: web                 # konteyner nomi (Pod ichida)
      image: nginx:1.27-alpine  # aniq tag (latest EMAS — barqaror, 10.3 g'oyasi)
      ports:
        - containerPort: 80     # konteyner tinglaydigan port (hujjatlash uchun)
      resources:                #  resurs so'rovi (HPA va scheduler uchun — 2.10)
        requests: { cpu: "50m", memory: "64Mi" }   # kafolatlangan minimal
        limits:   { cpu: "200m", memory: "128Mi" } # maksimal chegara
#  kubectl apply -f pod.yaml ; lekin real ilovada Deployment ishlat (Misol 2)

Misol 2 — Deployment: replicas, image, probe (2.4, 2.11)

# deployment.yaml — ilovani ishlatishning STANDART usuli (Pod'ni o'zi boshqaradi)
apiVersion: apps/v1             # Deployment "apps/v1" guruhida (Pod'dan farqli)
kind: Deployment
metadata:
  name: api                     # Deployment nomi
  labels: { app: api }
spec:
  replicas: 3                   #  3 nusxa doim ishlasin (ReplicaSet ushlaydi — 2.4)
  selector:
    matchLabels:
      app: api                  #  qaysi Pod'larni boshqaradi (template bilan MOS — 2.9)
  template:                     # Pod SHABLONI (har nusxa shundan yaratiladi)
    metadata:
      labels:
        app: api                #  selector bilan AYNAN mos (aks holda ishlamaydi)
    spec:
      containers:
        - name: api
          image: myrepo/api:1.0          # o'z image'imiz (registry'dan — 10.5)
          ports:
            - containerPort: 3000
          resources:
            requests: { cpu: "100m", memory: "128Mi" }   #  HPA uchun majburiy (2.10)
            limits:   { cpu: "500m", memory: "512Mi" }
          livenessProbe:                 # "tirikmi?" — fail  restart (2.11)
            httpGet: { path: /healthz, port: 3000 }
            initialDelaySeconds: 15      # 15s kut (ilova ko'tarilsin), keyin tekshir
            periodSeconds: 20            # har 20s tekshir
          readinessProbe:                # "tayyormi?" — fail  trafikdan uz (2.11)
            httpGet: { path: /ready, port: 3000 }
            initialDelaySeconds: 5
            periodSeconds: 10

Misol 3 — Service (ClusterIP — ichki aloqa, 2.5)

# service-clusterip.yaml — Pod'lar oldida barqaror IP/DNS (klaster ICHIDA)
apiVersion: v1
kind: Service
metadata:
  name: api                     #  bu NOM = DNS: boshqa Pod "http://api:80" deydi (2.5)
spec:
  type: ClusterIP               # default — faqat klaster ICHIDA (appdb, ichki)
  selector:
    app: api                    #  "app=api" Pod'larga trafik yo'naltiradi (2.9)
  ports:
    - protocol: TCP
      port: 80                  # Service tinglaydigan port (boshqalar shunga ulanadi)
      targetPort: 3000          #  Pod'dagi haqiqiy port (containerPort — Misol 2)
#  app  db: "postgres://db:5432" (NOM bilan — IP kerak emas, K8s DNS hal qiladi)

Misol 4 — Service (LoadBalancer — tashqariga ochish, 2.5)

# service-lb.yaml — bulut load balancer orqali TASHQARIGA (public IP)
apiVersion: v1
kind: Service
metadata:
  name: web-public
spec:
  type: LoadBalancer           #  bulut (AWS/GCP — 10.6) LB yaratadi  tashqi IP
  selector:
    app: web                   # web Pod'lariga (2.9)
  ports:
    - protocol: TCP
      port: 80                 # tashqi port (foydalanuvchi kiradigan)
      targetPort: 80           # Pod porti
#  "kubectl get svc"  EXTERNAL-IP ustunida bulut bergan public IP chiqadi
#  Har servisga alohida LB = qimmat  ko'p servis uchun INGRESS yaxshiroq (Misol 5)

Misol 5 — Ingress (domen va yo'l bo'yicha routing + TLS, 2.6)

# ingress.yaml — BITTA darvoza, HTTP'ni domen/yo'l bo'yicha yo'naltiradi (+ HTTPS)
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: main
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt   # (ixtiyoriy) avtomatik TLS — 10.7
spec:
  ingressClassName: nginx       #  nginx-ingress controller bajaradi (10.2 K8s'da)
  tls:                          # HTTPS (TLS termination — 2.6)
    - hosts: [ "saytim.uz" ]
      secretName: saytim-tls    # sertifikat Secret'da (2.7)
  rules:
    - host: saytim.uz           #  domen bo'yicha (host-based routing)
      http:
        paths:
          - path: /api          # saytim.uz/api  api servisiga (2.5)
            pathType: Prefix    # yo'l boshini moslaydi (eng keng)
            backend:
              service:
                name: api       #  Misol 3'dagi Service nomi
                port: { number: 80 }
          - path: /             # saytim.uz/  web servisiga
            pathType: Prefix
            backend:
              service:
                name: web
                port: { number: 80 }
#  Bitta tashqi IP + TLS bilan ko'p servisni yo'naltiradi (har biriga LB shart emas)

Misol 6 — ConfigMap va Secret (2.7)

# config.yaml — oddiy sozlama (maxfiy EMAS — ochiq matn)
apiVersion: v1
kind: ConfigMap
metadata:
  name: api-config
data:                           # key-value (oddiy matn)
  NODE_ENV: "production"
  LOG_LEVEL: "info"
  DATABASE_HOST: "db"           #  Service nomi 2.5-bob — IP emas
---
# secret.yaml — MAXFIY ma'lumot (parol/kalit)
apiVersion: v1
kind: Secret
metadata:
  name: api-secret
type: Opaque
stringData:                     #  stringData — oddiy matn yozasan, K8s base64 qiladi
  DB_PASSWORD: "supersecret"    # (data: ishlatsang — o'zing base64 kodlashing kerak)
  JWT_SECRET: "my-jwt-key"
#  base64 ≠ shifrlash (oson dekodlanadi)  bu faylni GIT'GA QO'SHMA (10.11)
#  Yaxshisi: kubectl create secret generic api-secret --from-literal=... (Git'siz)

Misol 7 — Deployment env'ini ConfigMap/Secret'dan olish (2.8)

# deployment-env.yaml — ilova konfiguratsiyani ConfigMap/Secret'dan oladi
apiVersion: apps/v1
kind: Deployment
metadata: { name: api }
spec:
  replicas: 2
  selector: { matchLabels: { app: api } }
  template:
    metadata: { labels: { app: api } }
    spec:
      containers:
        - name: api
          image: myrepo/api:1.0
          envFrom:
            - configMapRef:
                name: api-config        #  ConfigMap'dagi HAMMA kalit env bo'ladi (2.8)
          env:
            - name: DB_PASSWORD         # bitta maxfiy qiymat — Secret'dan
              valueFrom:
                secretKeyRef:           #  Secret'dan bitta kalit (2.8)
                  name: api-secret
                  key: DB_PASSWORD
          resources:
            requests: { cpu: "100m", memory: "128Mi" }
#  Ilova: process.env.NODE_ENV, process.env.DB_PASSWORD 5.8-bob — koddan AJRATILGAN

Misol 8 — kubectl buyruqlar to'plami (kundalik ish oqimi)

# === QO'LLASH / KO'RISH (declarative — 2.13) ===
kubectl apply -f deployment.yaml         # manifest'ni qo'lla (yaratadi yoki yangilaydi)
kubectl apply -f ./k8s/                   # papkadagi HAMMA manifest (deploy+svc+ingress)
kubectl get pods                          # Pod'lar holati (Running? Restarts?)
kubectl get deploy,svc,ingress            # bir nechta tur birga
kubectl get pods -o wide                  # qaysi node, qaysi IP

# === DEBUG (muammo qidirish — 10.1 g'oyasi) ===
kubectl describe pod <pod-nomi>           #  to'liq holat + EVENT'lar (xato sababi shu yerda)
kubectl logs -f <pod-nomi>                # jonli log (-f = follow, 10.4 g'oyasi)
kubectl logs <pod> -c <konteyner>         # ko'p konteynerli Pod'da aniq biri (2.3)
kubectl exec -it <pod> -- sh              # konteyner ICHIGA kir (10.3 g'oyasi)

# === SCALE / ROLLOUT (2.4, 2.10) ===
kubectl scale deployment api --replicas=5            # qo'lda 5 nusxaga
kubectl rollout status deployment/api                # yangilanish holati
kubectl rollout undo deployment/api                  # OLDINGI versiyaga qayt

# === NAMESPACE / TOZALASH 2.9-bob ===
kubectl get pods -n prod                  # prod namespace'da
kubectl delete -f deployment.yaml         # manifest bo'yicha o'chir
kubectl get all -n prod                   # namespace'dagi hamma narsa

Misol 9 — Rolling update va rollback (2.4)

# === ROLLING UPDATE — image'ni UZILISHSIZ yangilash ===
kubectl set image deployment/api api=myrepo/api:2.0   #  yangi versiya (rolling boshlanadi)
# K8s: yangi ReplicaSet yaratadi, Pod'larni BITTALAB almashtiradi (eski yiqilmaguncha
#      yangi ko'tariladi)  xizmat TO'XTAMAYDI (zero-downtime — 2.4)

kubectl rollout status deployment/api     # yangilanishni kuzat (jonli)
#  "deployment "api" successfully rolled out" chiqsa — tugadi

kubectl get rs                            # eski + yangi ReplicaSet (eski 0 ga tushadi)
kubectl rollout history deployment/api    # barcha revizyalar (versiya tarixi)

# === ROLLBACK — yangi versiya XATO bo'lsa, orqaga ===
kubectl rollout undo deployment/api                  # darrov OLDINGI versiyaga (2.4)
kubectl rollout undo deployment/api --to-revision=2  # aniq revizyaga

#  Compose'da bu QO'LDA (image o'zgartir, down/up) — K8s avtomatik va uzilishsiz

Misol 10 — HPA: avtomatik masshtablash (2.10)

# hpa.yaml — yukka qarab AVTOMATIK scale (CPU 70% maqsad)
apiVersion: autoscaling/v2     #  v2 (bir nechta metrika qo'llab-quvvatlaydi)
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:              # qaysi obyektni masshtablaydi
    apiVersion: apps/v1
    kind: Deployment
    name: api                  #  Misol 2'dagi Deployment
  minReplicas: 2               # eng kam (kam yukda ham 2 ta — mavjudlik)
  maxReplicas: 10              # eng ko'p (yuk oshsa — 10 tagacha)
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70    #  o'rtacha CPU 70% dan oshsa — nusxa qo'sh

kubectl apply -f hpa.yaml                 # HPA'ni yarat
kubectl get hpa                           # holat: TARGETS (hozirgi%/maqsad%), REPLICAS
#  TALAB: metrics-server o'rnatilgan + Deployment'da resources.requests.cpu bor (2.10)
# Imperative variant (test uchun):
kubectl autoscale deployment api --min=2 --max=10 --cpu-percent=70

5. To'g'ri va noto'g'ri holatlar

1) Pod'ni qanday yaratish (2.3, 2.4)

 kubectl run / kind: Pod (to'g'ridan) — yiqilsa qaytmaydi, scale yo'q
 Deployment ishlat (ReplicaSet  Pod, self-heal + rolling update)

2) Servisga ulanish manzili (2.5)

 Pod IP'siga ulanish (10.244.1.5 — Pod o'chsa IP o'zgaradi)
 Service NOMI bilan ("http://db:5432" — K8s DNS, barqaror)

3) Image tag (10.3 g'oyasi)

 image: myapp:latest (qaysi versiya noaniq, rollback chalkash)
 image: myapp:1.4.2 (aniq tag — barqaror, rollback aniq — 2.4)

4) Maxfiy ma'lumot (2.7)

 parol Deployment YAML'da ochiq + Git'ga push (sir tarqaydi)
 Secret'da (env orqali), Secret manifest Git'da emas (10.11)

5) Resurs so'rovi (2.10)

 resources yo'q (HPA ishlamaydi, scheduler yomon joylaydi)
 requests/limits ko'rsat (cpu/memory — HPA va barqarorlik uchun)

6) Sog'liq tekshiruvi (2.11)

 probe yo'q (osilgan ilova "ishlayapti" deb sanaladi, trafik boradi)
 liveness (qayta tirilt) + readiness (tayyor bo'lmaguncha trafik yo'q)

7) Qo'llash usuli (2.13)

 kubectl run/scale qo'lda (Git'da iz yo'q, takrorlanmaydi)
 kubectl apply -f *.yaml (manifest Git'da — GitOps, takrorlanadi)

6. Keng tarqalgan xatolar va yechimlari

Xato 1 — CrashLoopBackOff (Pod doim yiqilib qayta ko'tariladi)

Sababi: konteyner ishga tushishi bilan yiqiladi (kod xatosi, yetishmayotgan env/Secret, noto'g'ri start buyrug'i, port band), K8s qayta ko'taradi — yana yiqiladi (tsikl). Yechimi: kubectl logs <pod> (xato xabari) va kubectl describe pod <pod> (Event'lar) bilan sababni toping; ko'pincha — env/ConfigMap/Secret yetishmaydi 2.7-bob yoki ilova DB'ga ulanolmaydi. Avval logni o'qing.

Xato 2 — ImagePullBackOff / ErrImagePull (image olinmadi)

Sababi: image nomi/tag noto'g'ri, registry'da yo'q, yoki private registry uchun avtorizatsiya yo'q 10.5-bob. Yechimi: kubectl describe pod <pod> Event'da aniq sabab; image nomini tekshiring (myrepo/api:1.0); private registry uchun imagePullSecrets qo'shing; tag mavjudligini tasdiqlang.

Xato 3 — Pod Pending (joylashmaydi)

Sababi: klasterda yetarli resurs yo'q (CPU/RAM — node'lar to'la), yoki PVC bog'lanmadi 2.12-bob, yoki node selector mos kelmadi. Yechimi: kubectl describe pod <pod> Event'da "Insufficient cpu/memory" yoki PVC xatosini ko'ring; requestsni kamaytiring yoki node qo'shing; PVC va StorageClass holatini tekshiring (kubectl get pvc).

Xato 4 — Service Pod'ga ulanmaydi (so'rov javob bermaydi)

Sababi: Service selector Pod labels bilan mos kelmaydi 2.9-bob — eng keng xato; yoki targetPort noto'g'ri (Pod'dagi haqiqiy portga to'g'ri kelmaydi — 2.5). Yechimi: kubectl get endpoints <svc> — bo'sh bo'lsa selector mos kelmayapti; Service selector va Pod label'larini solishtiring (kubectl get pods --show-labels); targetPort = containerPort ekanini tekshiring.

Xato 5 — Probe noto'g'ri sozlangan (Pod ishlamayapti deb sanaladi)

Sababi: livenessProbe yo'li/porti xato yoki initialDelaySeconds juda kichik — ilova ko'tarilmasdan probe fail bo'lib, K8s uni doimo qayta ko'taradi (sun'iy CrashLoop — 2.11). Yechimi: probe path/port ilovaning haqiqiy healthcheck endpoint'iga mos kelsin; sekin ishga tushadigan ilovaga initialDelaySecondsni oshiring yoki startupProbe qo'shing.

Xato 6 — YAML indentatsiya xatosi (error converting YAML)

Sababi: YAML bo'shliqqa sezgir — tab ishlatilgan (probel kerak), yoki notog'ri darajada joylashtirilgan (10.4 — Compose YAML g'oyasi). Yechimi: tab emas, probel ishlating (2 probel — standart); kubectl apply --dry-run=client -f file.yaml bilan oldindan tekshiring; redaktorda YAML linter yoqing.

Xato 7 — the server doesn't have a resource type / noto'g'ri apiVersion

Sababi: apiVersion/kind noto'g'ri (Deployment uchun v1 yozilgan — apps/v1 kerak, yoki HPA uchun eski v1). Yechimi: to'g'ri guruh: Pod/Service/ConfigMap/Secret v1; Deployment apps/v1; Ingress networking.k8s.io/v1; HPA autoscaling/v2 (3-bo'lim).

7. Integratsiya — bu mavzu stack'ning qayerida uchraydi

• Docker 10.3-bob: K8s konteynerlarni ishlatadi — image 10.3-bob Pod ichiga joylashadi; container runtime (containerd — 2.2).
• Docker Compose 10.4-bob: Compose'dan keyingi qadam — bitta xost (Compose) klaster (K8s); deklarativ YAML g'oyasi davom etadi (2.1, 10.4: 2.12).
• Nginx 10.2-bob: Ingress controller — aslida K8s ichidagi Nginx reverse proxy; TLS termination (10.2 SSL g'oyasi — 2.6).
• AWS/Cloud 10.6-bob: managed K8s — EKS (AWS), GKE (Google); LoadBalancer Service bulut LB yaratadi; PV EBS disk (2.4, 2.12).
• CI/CD 10.5-bob: pipeline image quradi, registry'ga push qiladi, kubectl apply yoki set image bilan klasterga deploy qiladi (Misol 9).
• Deploy/SSL 10.7-bob: cert-manager + Ingress avtomatik Let's Encrypt TLS; rolling update — deploy strategiyasi 2.4-bob.
• Monitoring 10.9-bob: Prometheus K8s metrikalarini yig'adi; HPA shu metrikaga tayanadi; probe'lar sog'liq holatini beradi (2.10, 2.11).
• IaC 10.10-bob: manifest'lar Git'da (declarative — 2.13); Terraform klaster (EKS) ni provayding qiladi.
• Env/secrets 10.11-bob: ConfigMap/Secret — K8s'da konfiguratsiya boshqaruvi; Secret base64 muammosi 2.7-bob.
• Mikroservis 9.5-bob: har mikroservis — alohida Deployment + Service; K8s mikroservislarni orkestrlashning standart platformasi.

8. Eng yaxshi amaliyotlar (best practices)

• Deployment ishlating, Pod to'g'ridan emas (self-heal + rolling update + scale — 2.3, 2.4).
• Service nomi bilan ulaning (Pod IP'siga emas — barqaror DNS — 2.5).
• Aniq image tag (api:1.4.2, latest emas — rollback aniq — 10.3 g'oyasi).
• resources requests/limits (HPA va scheduler uchun majburiy — 2.10).
• liveness + readiness probe (osilganni tiriltish, tayyor bo'lmaganga trafik yubormaslik — 2.11).
• ConfigMap/Secret bilan ajrating (konfiguratsiya koddan tashqarida — 2.7, 2.8).
• Secret Git'ga tushmasin (base64 ≠ shifr; --from-literal yoki tashqi menejer — 2.7, 10.11).
• Namespace bilan ajrating (dev/staging/prod alohida; defaultni production'da ishlatmang — 2.9).
• Declarative apply -f (manifest Git'da — GitOps, takrorlanadi — 2.13).
• DB uchun PVC (Pod o'chsa ma'lumot saqlansin — 2.12).
• HPA + minReplicas≥2 (avtomatik scale, lekin doim kamida 2 nusxa — mavjudlik — 2.10).
• minikube/kind'da o'rganing, managed'da ishlating (control plane'ni o'zingiz boshqarmang — 2.13).

9. Amaliy loyiha: "Lokal Klasterga To'liq Ilovani Deploy Qilish"

10.4da Compose bilan ko'targan stack'ni endi Kubernetes klasteriga ko'chiring — bu Compose'dan K8s'ga o'tishning aniq mashqi.

Maqsad

Lokal klaster (minikube yoki kind) ko'tarib, NestJS/Express ilovangizni (10.3'da Dockerlashtirilgan) PostgreSQL bilan birga manifest'lar orqali deploy qiling: Deployment + Service + Ingress + ConfigMap + Secret + PVC, probe va HPA bilan, hammasi declarative kubectl apply.

Talablar (requirements)

1. Lokal klaster: minikube yoki kind o'rnatib ishga tushiring; kubectl cluster-info ishlasin 2.13-bob.
2. Namespace: loyiha uchun alohida namespace yarating (masalan myapp), hamma narsa shunda 2.9-bob.
3. Deployment: ilova replicas: 2, aniq image tag, resources.requests bilan (Misol 2, 2.4).
4. Probe: livenessProbe va readinessProbe (ilovaga /healthz, /ready endpoint qo'shing — Misol 2, 2.11).
5. Service: ilova uchun ClusterIP, DB uchun ClusterIP — nom bilan ulanish (Misol 3, 2.5).
6. ConfigMap + Secret: NODE_ENV/DATABASE_HOST ConfigMap'da, DB_PASSWORD/JWT_SECRET Secret'da; Deployment env'iga ulansin (Misol 6, 7, 2.7).
7. PVC: PostgreSQL uchun PersistentVolumeClaim — Pod o'chsa ma'lumot saqlansin (Misol — 2.12).
8. Ingress: app.local domeni bilan ilovaga yo'naltiring; minikube'da minikube tunnel//etc/hosts (Misol 5, 2.6).
9. HPA: ilovaga CPU 70% maqsadli HPA; metrics-server yoqing (minikube addon); yuk berib sinab ko'ring (Misol 10, 2.10).
10. Rolling update: image'ni 2.0ga yangilab rollout status kuzating, keyin rollout undo bilan qaytaring (Misol 9, 2.4).

Maslahatlar (hint)

• Avval minikube start (yoki kind create cluster), kubectl get nodes bilan klaster tirikligini tekshiring 2.13-bob.
• Lokal image'ni klaster ko'rishi uchun: minikube'da minikube image load, kind'da kind load docker-image (registry'siz).
• Service Pod'ga ulanmasa — kubectl get endpoints bo'sh bo'lsa selector/label mos emas (Xato 4, 2.9).
• CrashLoopBackOff bo'lsa — kubectl logs va kubectl describe pod (Xato 1) — env/Secret yetishmaydimi.
• HPA ishlamasa — resources.requests.cpu borligini va metrics-server yoqilganini tekshiring (Xato, 2.10).
• Manifest'larni ./k8s/ papkaga yig'ib, kubectl apply -f ./k8s/ bilan birga qo'llang (declarative — 2.13).

"Tayyor" mezonlari (acceptance criteria)

• Lokal klaster ishlaydi (kubectl get nodes — Ready).
• Hamma obyekt alohida namespace'da (kubectl get all -n myapp).
• Deployment 2 Pod ishlatadi; bittasini o'chirsangiz K8s yangisini ko'taradi (self-heal — 2.4).
• App DB'ga nomi bilan ulanadi (Service DNS — 2.5).
• ConfigMap/Secret env orqali ilovaga yetadi (parol YAML'da ochiq emas — 2.7).
• PostgreSQL PVC bilan — Pod o'chib qayta ko'tarilganda ma'lumot saqlanadi 2.12-bob.
• Ingress orqali http://app.local ilovani ochadi 2.6-bob.
• probe ishlaydi (/ready 500 qaytarsa Pod trafikdan uziladi — 2.11).
• HPA yuk ostida nusxalar sonini oshiradi (kubectl get hpa — 2.10).
• Rolling update uzilishsiz; rollout undo oldingi versiyaga qaytaradi 2.4-bob.

Yechim kodi ataylab berilmagan — bu loyihani o'zingiz yozib ko'ring.

10. Xulosa va keyingi bobga ko'prik

Bu bobda konteyner orkestratsiyasini va Kubernetes asoslarini chuqur o'rgandik:

• Orchestration (Compose chegarasi klaster — 2.1); arxitektura (control plane: apiserver/etcd/scheduler/controller; node: kubelet/kube-proxy/runtime — 2.2).
• Pod (eng kichik birlik — 2.3); ReplicaSet/Deployment (deklarativ, rolling update, rollback — 2.4); Service (barqaror manzil, discovery — 2.5); Ingress (HTTP routing, domen, TLS — 2.6).
• ConfigMap/Secret (konfiguratsiya/maxfiy — 2.7, 2.8); Namespace/label/selector (izolyatsiya va bog'lash — 2.9); scaling/HPA 2.10-bob; self-healing/probe 2.11-bob; Volume/PVC (saqlash — 2.12); declarative + lokal/managed K8s 2.13-bob.
• Boshqa workload'lar — StatefulSet (DB), DaemonSet (har node), Job/CronJob (bir martalik/jadval), ExternalName 2.14-bob; QoS/RBAC/Helm (resurs kafolati, ruxsat, paket menejeri — 2.15).

Endi siz Compose'dan tashqariga chiqib, ilovani klasterga deploy qila olasiz — self-healing, avtomatik masshtablash, uzilishsiz yangilash bilan. Bu — "bitta serverga deploy qilaman" degan chegarani buzib, "katta miqyosli, yuqori mavjud tizim quraman" darajasiga o'tkazadi.

Keyingi bob — 10.9-bob: Monitoring va logging (Prometheus, Grafana, Sentry). Endi tizimimiz klasterda ishlayapti, lekin ko'rmasak — boshqara olmaymiz: qaysi Pod sekin, CPU/RAM qancha, xatolar qayerda, foydalanuvchi qanday muammoga duch keldi? Monitoring (kuzatuv — Prometheus metrikalarni yig'adi, Grafana ularni ko'rgazmali grafikka aylantiradi) va logging (loglarni markazlashtirish), va Sentry (ilova xatolarini real vaqtda tutish) — production tizimning "ko'zi va qulog'i". Bu — HPA (shu bob) tayanadigan metrikalarni ham beradi, va har bir senior DevOps'ning kundalik asbobi.

Foydalanilgan rasmiy/ishonchli manbalar

• Kubernetes Docs — "Cluster Architecture" / "Components" (kubernetes.io/docs/concepts/overview/components — control plane, node, etcd, kubelet, 2026)
• Kubernetes Docs — "Pods" va "Pod Lifecycle" (kubernetes.io/docs/concepts/workloads/pods — Pod, probe, restartPolicy, self-healing)
• Kubernetes Docs — "Deployments" (kubernetes.io/docs/concepts/workloads/controllers/deployment — ReplicaSet, rolling update, rollout undo)
• Kubernetes Docs — "Service" va "Ingress" (kubernetes.io/docs/concepts/services-networking — ClusterIP/LoadBalancer, host/path routing, TLS, Gateway API eslatmasi)
• Kubernetes Docs — "ConfigMap", "Secret", "Namespaces" (kubernetes.io/docs/concepts/configuration va overview/working-with-objects)
• Kubernetes Docs — "Horizontal Pod Autoscaling" (kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale — autoscaling/v2, metrics-server)
• Kubernetes Docs — "Persistent Volumes" (kubernetes.io/docs/concepts/storage/persistent-volumes — PV/PVC, StorageClass, accessModes)
• Kubernetes Docs — "StatefulSets", "DaemonSet", "Jobs", "CronJob" (kubernetes.io/docs/concepts/workloads/controllers — stateful ilova, har-node agenti, bir martalik/jadvalli vazifa)
• Kubernetes Docs — "Configure Quality of Service for Pods" (kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod — Guaranteed/Burstable/BestEffort, OOM tartibi)
• Kubernetes Docs — "Using RBAC Authorization" (kubernetes.io/docs/reference/access-authn-authz/rbac — Role/ClusterRole, RoleBinding, ServiceAccount)
• Helm Docs — "Charts" va "Values" (helm.sh/docs — chart, values, release; K8s paket menejeri)
• minikube (minikube.sigs.k8s.io) va kind (kind.sigs.k8s.io) rasmiy hujjatlari — lokal klaster (2026)