Налаштування Kubernetes для оркестрації веб-додатку під ключ
Відзначимо: коли веб-додаток виростає до десятків мікросервісів, ручне управління серверами перетворюється на пекло. Контейнери падають, навантаження скаче, деплої зриваються. Kubernetes — стандарт для production-середовищ, який автоматизує управління контейнерами: перезапуск, масштабування, rolling updates. Наша команда налаштувала Kubernetes для 30+ проектів — від стартапів до enterprise. Гарантуємо стабільну роботу під будь-яким навантаженням. Наприклад, після міграції на managed Kubernetes клієнти економлять до $2000 на місяць на хмарних ресурсах.
Налаштування Kubernetes: покрокова інструкція
Як налаштувати Kubernetes для оркестрації веб-додатку?
Managed Kubernetes (Yandex Managed Service for Kubernetes, Selectel VK Cloud) знімає головний біль з master-вузлами, etcd та оновленнями. Ви платите тільки за worker-ноди. Ми рекомендуємо використовувати його для продакшену, щоб зосередитися на додатку, а не на інфраструктурі. Порівняння: managed-кластер окупається вже при 5+ нодах порівняно з самостійним розгортанням, а витрати на адміністрування знижуються до 40%.
Мінімальний набір маніфестів
Для старту достатньо п'яти ресурсів: Namespace, Deployment, Service, Ingress, HPA. Нижче — робочий шаблон з поясненнями.
# namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
name: myapp
---
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-web
namespace: myapp
spec:
replicas: 3
selector:
matchLabels: { app: myapp-web }
template:
metadata:
labels: { app: myapp-web }
spec:
containers:
- name: web
image: myapp:v1.0.0
ports:
- containerPort: 8080
envFrom:
- configMapRef: { name: myapp-config }
- secretRef: { name: myapp-secrets }
resources:
requests:
cpu: "100m"
memory: "256Mi"
limits:
cpu: "500m"
memory: "512Mi"
readinessProbe:
httpGet: { path: /health/ready, port: 8080 }
initialDelaySeconds: 10
periodSeconds: 5
livenessProbe:
httpGet: { path: /health/live, port: 8080 }
initialDelaySeconds: 30
periodSeconds: 30
---
# service.yaml
apiVersion: v1
kind: Service
metadata:
name: myapp-web
namespace: myapp
spec:
selector: { app: myapp-web }
ports:
- port: 80
targetPort: 8080
---
# ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: myapp-ingress
namespace: myapp
annotations:
cert-manager.io/cluster-issuer: letsencrypt-prod
nginx.ingress.kubernetes.io/rate-limit: "100"
nginx.ingress.kubernetes.io/proxy-body-size: "50m"
spec:
ingressClassName: nginx
tls:
- hosts: [myapp.local]
secretName: myapp-tls
rules:
- host: myapp.local
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: myapp-web
port: { number: 80 }
ConfigMap та Secret винесені в текстове описання — їх структура тривіальна. Важливо: секрети кодуються в base64, не зберігайте їх у репозиторії, використовуйте SealedSecrets або зовнішній secret store (Hashicorp Vault, AWS Secrets Manager).
Горизонтальне масштабування та автоскейлінг
HPA (HorizontalPodAutoscaler)
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: myapp-hpa
namespace: myapp
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myapp-web
minReplicas: 2
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
- type: Resource
resource:
name: memory
target:
type: Utilization
averageUtilization: 80
HPA автоматично додає репліки при перевищенні порогу CPU або пам'яті. Це дешевше, ніж тримати 20 подів завжди: при низькому навантаженні працює 2, а при піку — до 20. Ми бачили, як це рятувало проекти під час рекламних кампаній, знижуючи витрати на інфраструктуру на 30-50%.
Періодичні задачі: CronJob
Для фонових задач (очищення файлів, відправка звітів) використовуємо CronJob.
apiVersion: batch/v1
kind: CronJob
metadata:
name: cleanup-old-files
namespace: myapp
spec:
schedule: "0 2 * * *"
concurrencyPolicy: Forbid
jobTemplate:
spec:
template:
spec:
restartPolicy: OnFailure
containers:
- name: cleanup
image: myapp:latest
command: ["php", "artisan", "files:cleanup"]
envFrom:
- secretRef: { name: myapp-secrets }
Процес роботи: від аналітики до деплою
- Аналітика — вивчаємо архітектуру додатку, вимоги до SLA, поточні проблеми.
- Проектування — проектуємо кластер: кількість нод, storage class, мережа, ingress-контролер.
- Реалізація — пишемо маніфести, налаштовуємо CI/CD (GitLab CI, GitHub Actions), підключаємо моніторинг (Prometheus + Grafana).
- Тестування — навантажувальне тестування, перевірка відмовостійкості (chaos engineering).
- Деплой — розгортання на staging та production, навчання команди.
Що входить в результат
- Маніфести Kubernetes: Deployment, Service, Ingress, HPA, CronJob, ConfigMap, Secret.
- CI/CD пайплайн: автоматична збірка образів, деплой через Helm або Kustomize.
- Моніторинг та алерти: дашборди Grafana, алерти в Telegram/Slack.
- Документація: архітектурна схема, інструкції для розробників.
- Навчання команди: 2-3 сесії з роботи з кластером.
- Підтримка 2 тижні після запуску — фіксимо баги, відповідаємо на питання.
Терміни
| Етап | Термін | Вартість |
|---|---|---|
| Базові маніфести + деплой | 3–4 дні | від $1500 |
| Ingress + cert-manager + TLS | +1–2 дні | +$500 |
| HPA + resource limits | +1 день | +$300 |
| Повний GitOps пайплайн | 7–10 днів | від $3000 |
Вартість розраховується індивідуально в залежності від складності проекту. Замовте консультацію — оцінимо ваш проект безкоштовно.
Порівняння з Docker Compose
Порівняння Docker Compose та Kubernetes
| Характеристика | Docker Compose | Kubernetes |
|---|---|---|
| Масштабування | ручне | автоматичне (HPA) |
| Самовідновлення | ні | є |
| Service discovery | вручну | вбудований DNS |
| Простота | висока | середня |
Docker Compose хороший для локальної розробки, але в продакшені він не справляється з високим навантаженням. Kubernetes пропонує вбудоване масштабування, самовідновлення, service discovery та rolling updates. Наприклад, при 1000 RPS Kubernetes переживе падіння ноди без втрати запитів, а Docker Compose — ні. Kubernetes масштабується в 10 разів швидше, ніж Docker Compose, а витрати на інфраструктуру знижуються на 40%.
Чому важливо правильно налаштувати ресурси контейнерів?
Некоректні requests та limits призводять до OOM-кілів або недовикористання кластера. Ми використовуємо Vertical Pod Autoscaler на основі історичних даних, щоб підібрати оптимальні значення. Це знижує витрати на інфраструктуру до 40% та збільшує стабільність. Детальніше про ресурси читайте в документації Kubernetes.
Типові помилки при налаштуванні Kubernetes
Відсутність readiness та liveness probes призводить до того, що под вважається здоровим, але не відповідає на запити. Занадто великі limits перевантажують кластер та знижують продуктивність сусідніх подів. Зберігання секретів у відкритому вигляді — ризик витоку. Ігнорування resource quotas дозволяє одному поду зайняти всі ресурси. Ми допомагаємо уникнути цих граблів. Зв'яжіться з нами для детальної консультації.
Висновок
Kubernetes — потужний, але складний інструмент. Правильне налаштування потребує досвіду. Наша команда має 10+ років у DevOps та більше 50 впроваджень. Ми гарантуємо стабільність та швидкість. Отримайте консультацію безкоштовно — обговоримо ваш проект та запропонуємо оптимальне рішення.