Налаштування Kubernetes для оркестрації веб-додатку під ключ

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