Pod в CrashLoopBackOff, а ноды загружены на 15%? Начинаем с реальной проблемы
Типичная картина: kubectl describe pod показывает OOMKilled, limits расставлены наугад, мониторинг не настроен, а автоскейлинг отсутствует. Кластер «просто запустили» — и теперь он ест бюджет, но не вывозит нагрузку. Мы за 5 лет развернули 30+ production-кластеров, сформировали команду из 10 сертифицированных инженеров и знаем, как превратить хаос в предсказуемую оркестрацию. Подбираем managed-сервис (EKS, GKE, AKS) под вашу инфраструктуру, настраиваем HPA/VPA/KEDA, внедряем GitOps через Helm и ArgoCD и даём гарантию на работу кластера.
Почему managed Kubernetes: EKS, GKE или AKS?
Три платформы решают одну задачу по‑разному. Сводная таблица поможет выбрать под ваш сценарий.
| Характеристика | EKS (AWS) | GKE (Google Cloud) | AKS (Azure) |
|---|---|---|---|
| Управление нодами | Cluster Autoscaler / Karpenter | Autopilot / Node Pools | Cluster Autoscaler / Virtual Nodes |
| Интеграция IAM | IRSA (IAM Roles for Service Accounts) | Workload Identity Federation | Azure AD pod‑managed identity |
| CSI‑драйверы | EBS, EFS, FSx | Persistent Disk, Filestore | Azure Disk, Azure Files |
| Сетевой CNI | AWS VPC CNI + Calico/Cilium | Dataplane V2 (eBPF) | Azure CNI + Cilium |
| Поддержка spot | Spot Instances с Karpenter | Preemptible / Spot VMs | Spot Scale Sets |
| Типичная стоимость за кластер ~10 нод | $0,10/час за control plane | $0,10–0,15/час за кластер | $0,10/час за control plane |
Wikipedia: Kubernetes — базовая архитектура одинакова, но выбор managed-сервиса определяет операционные расходы. EKS даёт максимальную совместимость с AWS: IRSA, ALB через AWS Load Balancer Controller, EBS CSI Driver. Под EKS оптимально ставить Karpenter вместо Cluster Autoscaler — ноды поднимаются за 30–60 секунд против 3–5 минут, и он умеет смешивать spot/on‑demand через NodePool.
GKE — самый «нативный» Kubernetes (Google его создал). GKE Autopilot снимает необходимость управлять нод‑пулами — платишь только за поды. AKS удобен в экосистеме Microsoft: Azure AD для RBAC, Key Vault через CSI, пайплайны через GitHub Actions.
Как работают HPA, VPA и KEDA? Пример с реальной экономией
Неправильный автоскейлинг либо не справляется с нагрузкой, либо сжигает деньги. Разберём три механизма.
HPA (Horizontal Pod Autoscaler) — скейлинг по CPU. Базовый манифест:
apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: api-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: api minReplicas: 2 maxReplicas: 20 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 behavior: scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 10 periodSeconds: 60 stabilizationWindowSeconds: 300 — обязательная деталь. Без неё HPA дёргает реплики при пульсирующей нагрузке. Политика Percent: 10 ограничивает скорость уменьшения. Реальный production использует custom metrics: RPS через Prometheus Adapter, глубину очереди RabbitMQ.
VPA (Vertical Pod Autoscaler) подбирает правильные requests/limits. Режим Off даёт рекомендации, Auto рестартует поды. В production чаще берут Off с еженедельным Rolling Update. VPA в режиме Auto несовместим с HPA по CPU — они конфликтуют.
KEDA (Kubernetes Event-Driven Autoscaling) масштабирует по внешним источникам: длина очереди SQS, Kafka lag, HTTP RPS. Умеет масштабировать до нуля — удобно для batch‑воркеров.
apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: worker-scaledobject spec: scaleTargetRef: name: queue-worker minReplicaCount: 0 maxReplicaCount: 50 triggers: - type: aws-sqs-queue metadata: queueURL: https://sqs.eu-west-1.amazonaws.com/123456789/jobs queueLength: "5" awsRegion: eu-west-1 authenticationRef: name: keda-aws-credentials queueLength: "5" — один воркер на каждые 5 сообщений. Пришло 100 сообщений — поднялось 20 воркеров. Очередь пуста 5 минут — воркеры ушли в ноль. Экономия на инстансах может достигать 40% от стоимости фиксированного количества подов. В деньгах это $2 000–$5 000 в месяц для среднего проекта.
Кейс: стартап из 50 микросервисов сэкономил $4 500 в месяц
У клиента были фиксированные ноды на $8 000/мес, нагрузка пульсировала (ночные batch‑задачи). Мы внедрили HPA по RPS и KEDA для очередей — без изменения кода счёт упал до $3 500/мес при той же пропускной способности. Окупаемость проекта — 3 недели.Как Helm упрощает управление релизами?
Helm — стандарт де‑факто для деплоя. Но helm upgrade --install без флагов — путь к катастрофе. Структура через overlay:
charts/api/ Chart.yaml values.yaml # base values values.prod.yaml # production overrides values.staging.yaml # staging overrides templates/ helm upgrade api ./charts/api -f values.yaml -f values.prod.yaml --atomic --timeout 5m — флаг --atomic откатит релиз, если поды не поднялись за 5 минут. Без него кластер может остаться в полу‑обновлённом состоянии.
Wikipedia: Helm (package manager) — инструмент стандартизирует деплой и управление версиями. Helm Secrets через SOPS + Age или AWS KMS хранит зашифрованные секреты в репозитории. Альтернатива — External Secrets Operator, который тянет секреты из AWS Secrets Manager или HashiCorp Vault.
Когда нужны Kubernetes Operators?
Operators — контроллеры, которые знают бизнес‑логику stateful‑приложений. Готовые решения для production:
- CloudNativePG — PostgreSQL: автоматический failover, PiTR‑бекапы в S3, управление репликами через CRD.
- Strimzi — Kafka: управляет брокерами, топиками, пользователями; TLS out of the box.
- VictoriaMetrics Operator — мониторинг: совместим с Prometheus CRD, потребляет в 5–7 раз меньше памяти.
Если готового оператора нет, пишем свой на Kubebuilder (Go). Типовой кейс — оператор для hot‑reload конфигурации: следит за изменениями в ConfigMap, вызывает /reload endpoint приложения.
Как настроить RBAC без cluster-admin?
RBAC не «поставил и забыл». Типичная ошибка: выдать команде cluster-admin «для скорости». Потом случайный kubectl delete namespace production.
Принцип минимальных привилегий через Role и RoleBinding:
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: developer namespace: production rules: - apiGroups: ["apps"] resources: ["deployments"] verbs: ["get", "list", "watch"] - apiGroups: [""] resources: ["pods", "pods/log"] verbs: ["get", "list", "watch"] Для kubectl exec нужно явно добавить pods/exec, для port‑forward — pods/portforward. CI/CD‑системам выдаём ServiceAccount с правами только на Deployment patch в конкретных namespace.
Audit log включён по умолчанию в managed‑кластерах. Политика аудита для production логирует все write‑операции и pods/exec.
Почему Network Policies критичны для безопасности?
По умолчанию в Kubernetes все поды могут общаться друг с другом — неприемлемо для production.
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: api-ingress namespace: production spec: podSelector: matchLabels: app: api policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: nginx-ingress ports: - protocol: TCP port: 8080 api принимает трафик только от ingress‑контроллера. База данных — только от api. Мониторинг — только из namespace monitoring. Реализация требует CNI с поддержкой Network Policy: Calico или Cilium (eBPF — быстрее).
Типичные сроки и объём работ
| Задача | Сроки |
|---|---|
| Настройка managed кластера (EKS/GKE/AKS) с нуля | 1–2 недели |
| Helm-чарты для существующего приложения | 3–5 дней |
| HPA + VPA + Cluster Autoscaler | 3–5 дней |
| KEDA с внешними триггерами | 3–7 дней |
| RBAC + Network Policies | 2–4 дня |
| Разработка Kubernetes Operator | 2–6 недель |
| Полная миграция приложения в K8s | 4–12 недель |
Стоимость рассчитывается индивидуально после аудита. Средняя экономия на инфраструктуре после внедрения автоскейлинга — $1 500–$4 000 в месяц, проекты окупаются за 3–6 месяцев.
Процесс работы
- Аудит — профилирование нагрузки, анализ безопасности, оценка текущих затрат.
- Проектирование — выбор managed-сервиса, схема автоскейлинга, RBAC, сетевые политики.
- Развёртывание — настройка кластера, Helm-чарты, мониторинг (Prometheus + Grafana) и алертинг.
- Тестирование — нагрузочные тесты, сценарии отказа (pod failure, node failure), canary‑деплой.
- Запуск — миграция трафика, blue‑green или canary, фиксация SLO.
- Поддержка — runbook, пост‑релизная поддержка 1 месяц с SLA 99,9%.
Что входит в работу
- Аудит текущего кластера и рекомендации по архитектуре.
- Развёртывание managed‑кластера с настроенным автоскейлингом, RBAC, Network Policies, мониторингом (Prometheus + Grafana).
- Документирование архитектуры и описание runbook.
- Обучение команды (2–4 часа воркшопа).
- Пост‑релизная поддержка на 1 месяц с SLA 99,9%.
Свяжитесь с нами для аудита вашего кластера — оценим текущее состояние и предложим план оркестрации Kubernetes с гарантией результата. Получите консультацию по выбору managed‑решения и настройке автоскейлинга под ваши нагрузки.