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 |
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% від вартості фіксованої кількості подів, що становить значну суму для середнього проєкту.
Кейс: стартап з 50 мікросервісів заощадив значну суму на місяць
У клієнта були фіксовані ноди на високу суму, навантаження пульсувало (нічні batch-задачі). Ми впровадили HPA за RPS та KEDA для черг — без зміни коду рахунок значно знизився при тій самій пропускній здатності. Окупність проєкту — 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 тижнів |
Вартість розраховується індивідуально після аудиту. Середня економія на інфраструктурі після впровадження автоскейлінгу є значною, проєкти окупаються за 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-рішення та налаштування автоскейлінгу під ваші навантаження.