Kubernetes obro‘sida muammo bor: sohaning yarmi uni nishondek taqadi, qolgan yarmi ortiqcha soliq deb biladi. Men uchun u qo‘llash nuqtasi aniq bo‘lgan vosita. Marketing sayti yoki MVP jarayon boshqaruvchisi va CI vazifasi bor bitta serverda yaxshi ishlaydi — ushbu sayt ham shu tarzda joylangan. Bir nechta xizmat, o‘zgaruvchan yuklama va bir infratuzilmaga bir nechta jamoa mahsulot chiqarishi boshlanganda Kubernetes o‘zini oqlaydi.
Hammasi konteynerdan boshlanadi. Multi-stage Dockerfile, kichik runtime obrazi, ishlab chiqish bog‘liqliklarisiz, root bo‘lmagan foydalanuvchi va har konteynerda bitta jarayon. Next.js ilovasi standalone rejimida yig‘iladi; NestJS API’siga faqat dist va production node_modules kiradi. Bir xil obraz CI’dan staging’ga, keyin production’ga o‘tadi. Faqat muhit o‘zgaruvchilari, ConfigMap va Secret orqali konfiguratsiya almashadi; har muhit uchun qayta yig‘ilmaydi.
Har kuni ishlatadigan obyektlarim kam: har bir xizmat uchun Deployment, uning oldida Service, ommaviy trafik uchun TLS’li Ingress va yuklamasi chindan ham keskin o‘zgaradigan qismlar uchun HorizontalPodAutoscaler. Har konteynerga resurs requests va limits beriladi — ularsiz scheduler taxmin qiladi. Readiness va liveness probe’lari ataylab ajratilgan: readiness «hali trafik yuborma», liveness esa «meni qayta ishga tushir» deydi. Ularni chalkashtirish sekin bazani qayta ishga tushish bo‘roniga aylantiradi. Har Node.js xizmati SIGTERM’ni qayta ishlab, davom etayotgan so‘rovlarni tugatadi, shunda rolling update to‘lovni o‘rtasida uzmaydi.
Hamma narsa veb-server emas. Navbat worker’lari o‘z Deployment’larida yuradi va CPU’ga emas, navbatdagi ortib qolgan ishga qarab masshtablanadi. Hisobot, tozalash va to‘lov provayderi bilan solishtirish kabi rejalangan vazifalar concurrencyPolicy: Forbid sozlamali CronJob sifatida ishlaydi; sekin jarayon keyingisi bilan ustma-ust tushmaydi. Ma’lumotlar bazasi migratsiyasi ilova ishga tushganda emas, rollout oldidan Job orqali bajariladi: bir vaqtda ochilgan besh replica sxemani baravar ko‘chirishga urinmasligi kerak. PostgreSQL’ni StatefulSet’da saqlagandan ko‘ra RDS kabi boshqariladigan xizmatni afzal ko‘raman — klaster stateless xizmatlar uchun.
Manifestlar Git’da saqlanadi va kod kabi ko‘rib chiqiladi. Helm yoki Kustomize’li CI pipeline yoxud Argo CD bilan GitOps orqali chiqariladi; demak, orqaga qaytish yarim tunda kubectl seansi emas, revert bo‘ladi. Noutbukdan kubectl apply — o‘rganish uchun, production uchun emas. Loglar stdout va markaziy omborga, metrikalar Prometheus va Grafana’ga boradi; umid qilish o‘rniga rollout’ni kubectl rollout status’da kuzataman. AWS’da bu odatda boshqariladigan node group’li EKS bo‘ladi, shunda jamoa control plane’ga emas, mahsulotga vaqt ajratadi.
Ikki sahifali saytga Kubernetes qo‘llashni, xizmatlar paydo bo‘lishidan oldin service mesh joriy etishni, repozitoriyda maxfiy qiymatlarni oddiy YAML’da saqlashni va «staging’da ishladi» deb pod limitlarini olib tashlashni rad etaman. Klaster kerakmi, bilmasangiz, xizmatlar, trafik va jamoa hajmini yuboring. Kubernetes, bitta xostdagi bir nechta konteyner yoki Vercel kabi platforma qaysi biri ma’qul ekanini va har birining taxminiy oylik xarajatini ochiq aytaman.
Keyingi mahsulotingizga qoladigan insonni bering.
Boshlashga tayyormisiz? Yozing — hozir boshlayman va qolaman. Ikki haftalik topshirish emas, uzoq hamkorlik. Loyiha, talab va eng yaxshi yo‘lni muhokama qilaylik.