Kubernetes-тің беделіне қатысты мәселе бар: саланың жартысы оны жетістік белгісіндей көреді, қалғаны артық шығын санайды. Мен үшін оның қолданылатын тұсы анық. Маркетинг сайты не MVP процесс менеджері және CI тапсырмасы бар бір серверде жақсы жұмыс істейді — осы сайт та дәл солай жарияланады. Бірнеше сервис, құбылмалы жүктеме және бір инфрақұрылымға бірнеше команда өнім шығара бастағанда Kubernetes орынды бола түседі.
Барлығы контейнерден басталады. Multi-stage Dockerfile, шағын runtime бейнесі, әзірлеу тәуелділіктерінсіз, root емес пайдаланушы, бір контейнерде бір процесс. Next.js қолданбасы standalone режимінде жиналады; NestJS API тек dist пен өндірістік node_modules қамтиды. Бір бейне CI-ден staging-ке, одан production-ға өтеді. Тек орта айнымалылары, ConfigMap пен Secret арқылы конфигурация өзгереді; әр орта үшін бейне қайта жиналмайды.
Күнделікті қолданатын нысандарым аз: әр сервиске бір Deployment, алдында бір Service, сыртқы трафикке TLS бар Ingress және жүктемесі шынымен құбылатын бөлікке HorizontalPodAutoscaler. Әр контейнерге ресурс сұранысы мен шектеуі беріледі — оларсыз scheduler болжай салады. Readiness және liveness probe-тары әдейі бөлек: readiness «әзірше трафик жіберме», liveness «қайта іске қос» дейді. Екеуін шатастыру баяу дерекқорды тоқтаусыз қайта іске қосу дауылына айналдырады. Node.js сервисі SIGTERM сигналын өңдеп, жүріп жатқан сұрауларды аяқтайды, сонда rolling update төлемді орта жолда үзбейді.
Барлығы веб-сервер емес. Кезек worker-лері бөлек Deployment-та жұмыс істеп, CPU-ға емес, кезектегі жиналған жұмысқа қарай ауқымын өзгертеді. Есеп, тазалау, төлем провайдерімен салыстыру сияқты кестелі жұмыстар concurrencyPolicy: Forbid параметрі бар CronJob арқылы орындалады, баяу іске қосылу келесімен қабаттаспайды. Дерекқор миграциясы қолданба іске қосылғанда емес, rollout алдында Job болып жүреді: қатар қосылған бес replica схеманы бес рет көшірмеуі керек. PostgreSQL-ді StatefulSet орнына RDS сияқты басқарылатын қызметте ұстағанды жөн көремін — кластер күй сақтамайтын сервистерге арналған.
Манифесттер Git ішінде сақталып, код секілді тексеріледі. Helm не Kustomize бар CI pipeline-ы немесе Argo CD арқылы GitOps пайдаланылады; кері қайту түнгі kubectl сессиясы емес, revert болады. Ноутбуктан kubectl apply іске қосу — үйренуге арналған, production-ға емес. Логтар stdout-қа, одан орталық қоймаға; метрикалар Prometheus пен Grafana-ға түседі. Бәрі дұрыс шығар деп күтпей, rollout күйін kubectl rollout status арқылы бақылаймын. AWS-та бұл көбіне басқарылатын node group-тары бар EKS болады, сонда команда control plane-ге емес, өнімге көңіл бөледі.
Екі беттік сайтқа Kubernetes орнатудан, сервистер пайда болмай тұрып service mesh қосудан, репозиторийде құпияларды ашық YAML түрінде сақтаудан және «staging-те істеді» деп pod лимиттерін алып тастаудан бас тартамын. Кластер керек пе деп күмәндансаңыз, сервистерді, трафикті және команда көлемін жіберіңіз. Kubernetes, бір хосттағы бірнеше контейнер немесе Vercel секілді платформа қайсысы керегін және әрқайсысының айлық шамамен құнын ашық айтамын.
Келесі өнімге онымен бірге қалатын адамды беріңіз.
Бастауға дайынсыз ба? Маған жазыңыз — қазір бастап, әрі қарай қалуға дайынмын. Екі апталық тапсыру емес, ұзақ мерзімді келісімдер. Жобаңызды, талаптарды және алға жылжудың ең тиімді жолын талқылайық.