Налаштування 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 } 

Процес роботи: від аналітики до деплою

1. Аналітика — вивчаємо архітектуру додатку, вимоги до SLA, поточні проблеми.
2. Проектування — проектуємо кластер: кількість нод, storage class, мережа, ingress-контролер.
3. Реалізація — пишемо маніфести, налаштовуємо CI/CD (GitLab CI, GitHub Actions), підключаємо моніторинг (Prometheus + Grafana).
4. Тестування — навантажувальне тестування, перевірка відмовостійкості (chaos engineering).
5. Деплой — розгортання на staging та production, навчання команди.

Що входить в результат

• Маніфести Kubernetes: Deployment, Service, Ingress, HPA, CronJob, ConfigMap, Secret.
• CI/CD пайплайн: автоматична збірка образів, деплой через Helm або Kustomize.
• Моніторинг та алерти: дашборди Grafana, алерти в Telegram/Slack.
• Документація: архітектурна схема, інструкції для розробників.
• Навчання команди: 2-3 сесії з роботи з кластером.
• Підтримка 2 тижні після запуску — фіксимо баги, відповідаємо на питання.

Терміни

Вартість розраховується індивідуально в залежності від складності проекту. Замовте консультацію — оцінимо ваш проект безкоштовно.

Порівняння з Docker Compose