У Kubernetes проблема з репутацією: половина індустрії сприймає його як значок, інша половина - як податок. Для мене це інструмент із чіткою точкою входу. Маркетинговий сайт чи MVP чудово живе на одному сервері з менеджером процесів і CI-джобою - саме так задеплоєний цей сайт. Kubernetes починає себе виправдовувати, коли сервісів кілька, навантаження нерівне, а в ту саму інфраструктуру деплоїть більше ніж одна команда.
Усе починається з контейнера. Multi-stage Dockerfile, маленький runtime-образ, без dev-залежностей, non-root користувач, один процес на контейнер. Next.js-застосунок збирається в режимі standalone; NestJS API везе лише dist і production node_modules. Той самий образ іде з CI на стейджинг і в продакшен - змінюється лише конфіг через змінні оточення, ConfigMap і Secret, і ніколи не перезбирається під кожне середовище.
Об’єктів, якими я користуюсь щодня, небагато: Deployment на кожен сервіс, Service перед ним, Ingress з TLS для публічного трафіку і HorizontalPodAutoscaler для частин, де навантаження справді стрибає. Кожен контейнер має requests і limits - без них планувальник вгадує. Readiness і liveness проби навмисно різні: readiness каже «поки не шли мені трафік», liveness - «перезапусти мене». Якщо їх переплутати, повільна база перетворюється на шторм перезапусків. І кожен Node.js-сервіс обробляє SIGTERM і завершує поточні запити, щоб rolling update ніколи не обірвав платіж на півдорозі.
Не все - вебсервер. Воркери черг працюють як окремі Deployment і масштабуються за довжиною черги, а не за CPU. Регулярні задачі - звіти, чистки, звірка з платіжним провайдером - запускаються як CronJob з concurrencyPolicy: Forbid, щоб повільний запуск ніколи не накладався на наступний. Міграції бази йдуть окремим Job перед розгортанням, а не при старті застосунку, бо п’ять реплік, що стартують одночасно, не повинні всі пробувати мігрувати схему. Саму PostgreSQL я волію мати керованою, як RDS, а не у StatefulSet - кластер для stateless-сервісів.
Маніфести живуть у git і проходять рев’ю як код, а деплояться через CI-пайплайн з Helm чи Kustomize або через GitOps з Argo CD - тож відкат - це revert, а не нічна сесія з kubectl. kubectl apply з ноутбука - для навчання, не для продакшену. Логи йдуть у stdout і в центральне сховище, метрики - у Prometheus і Grafana, а розгортання я відстежую через kubectl rollout status, а не надію. На AWS це зазвичай EKS з керованими node group, щоб команда витрачала час на продукт, а не на control plane.
Що відмовляюсь робити: Kubernetes для сайту на дві сторінки, service mesh до того, як з’явились сервіси, секрети в git у вигляді звичайного YAML і поди без лімітів, бо «на стейджингу працювало». Якщо не впевнені, чи потрібен вам кластер - надішліть свої сервіси, трафік і розмір команди. Чесно скажу, що вам треба: Kubernetes, кілька контейнерів на одному хості чи платформа на кшталт Vercel - і приблизно скільки кожен варіант коштуватиме на місяць.
Дайте наступному продукту того, хто лишається.
Готовий стартувати зараз і лишитись. Довготермінові ретейнери, не злив за два тижні. Напишіть - обговоримо проєкт, вимоги і як рухатись далі.