Cloud Bursting (Облачное масштабирование по требованию)

Cloud Bursting — это архитектурная стратегия, при которой локальная (on-premises) инфраструктура интегрирована с публичным облаком, и при превышении доступных ресурсов часть нагрузки автоматически переносится во внешний облачный сегмент. Это позволяет временно расширить вычислительные мощности без необходимости закупки дополнительного оборудования.

Концепция названа метафорически: локальный ресурсный “резервуар” как бы «переполняется», и избыточная нагрузка “выплёскивается” (bursts) в облако.

Где применяется Cloud Bursting

Пиковые нагрузки: периоды интенсивного трафика, маркетинговые кампании, запуск новых сервисов;
Тестирование под нагрузкой: стресс-тесты, моделирование предельных условий работы систем;
Обработка данных: периодическое выполнение ресурсоёмких задач (рендеринг, расчёты, отчётность);
Разработка и тестирование: временные среды, не требующие постоянного размещения в on-prem.

Преимущества Cloud Bursting

Экономичность — нет необходимости держать избыточную инфраструктуру «на случай пиков»;
Гибкость — масштабирование происходит автоматически и только при необходимости;
Скорость развертывания — ресурсы в облаке активируются по триггеру без длительной подготовки;
Поддержка гибридных моделей — сочетание on-prem и public cloud в единой архитектуре;
Повышение отказоустойчивости — облако может выступать как резервный канал обработки нагрузки.

Требования к реализации

Низкая задержка между on-prem и облаком (канал связи, VPN, Direct Connect);
Автоматизация: правила масштабирования, триггеры и политики (например, через Kubernetes HPA + Cluster Autoscaler + cloud provider);
Совместимость окружений — приложения должны быть способны работать как локально, так и в облаке;
Наблюдаемость — мониторинг, алерты и логирование должны охватывать оба сегмента инфраструктуры;
Согласованность данных — в случае передачи состояний и данных важно обеспечить синхронизацию и согласованность.

Ограничения и риски

Задержка — при передаче данных между локальной и облачной средой;
Сложность конфигурации — особенно при использовании нескольких провайдеров;
Безопасность — перенос трафика и данных требует строгой модели доступа и шифрования;
Лицензирование — не все программные продукты допускают гибридную эксплуатацию;
Зависимость от облачного API и провайдера — важно избегать vendor lock-in.

Примеры платформ с поддержкой Cloud Bursting

AWS Outposts + EC2 Auto Scaling
Azure Stack + Azure Scale Sets
Google Anthos + GKE on-prem
VMware Cloud Foundation + vSphere with Tanzu
Kubernetes с внешними облачными нодами (через node pools или federation)

Cloud Bursting — это не универсальное решение, а инструмент, уместный в сценариях с переменной или предсказуемо-волатильной нагрузкой. Успешная реализация требует точной архитектурной проработки, автоматизации масштабирования и жёсткого контроля зон ответственности между локальной и облачной инфраструктурой.

Пример реализации Cloud Bursting на Kubernetes с Horizontal Pod Autoscaler (HPA), Cluster Autoscaler и autoscaling node pools в облаке, плюс схема гибридной архитектуры.

YAML: HPA + bursting в облако (GKE, EKS, AKS)

1. Horizontal Pod Autoscaler (HPA)

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 65

📌 При превышении 65% CPU HPA масштабирует приложение.

2. Node Autoscaler (облако)

В GKE, EKS или AKS необходимо активировать Cluster Autoscaler, который будет добавлять ноды в облачную нод-группу при нехватке ресурсов.

Пример в Terraform (EKS):

resource "aws_eks_node_group" "burst_pool" {
  cluster_name = aws_eks_cluster.this.name
  node_group_name = "bursting"
  scaling_config {
    desired_size = 0
    min_size     = 0
    max_size     = 10
  }
  instance_types = ["t3.medium"]
  labels = {
    workload = "burstable"
  }
}

📌 Пул создан с min=0: он не расходует ресурсы, пока не будет нужен. HPA запускает новые поды → кластер запускает ноды.

Архитектура гибридного Cloud Bursting:

         ┌──────────────────────────────┐
         │        On-Prem Cluster       │
         │ ┌────────────┐              │
         │ │ Web App    │              │
         │ │ (3 пода)   │              │
         │ └────┬───────┘              │
         └──────┼──────────────────────┘
                │
       нагрузка > порога
                ▼
 ┌────────────────────────────────────────────┐
 │            Public Cloud (e.g., AWS)        │
 │ ┌────────────┐     ┌────────────┐         │
 │ │ Web App    │ ... │ Web App    │         │
 │ │ (autoscale)│     │ (burst)    │         │
 │ └────────────┘     └────────────┘         │
 │ Cluster Autoscaler добавляет ноды         │
 └────────────────────────────────────────────┘

Важно настроить:

Taints/Tolerations — чтобы bursting-поды шли только на облачные ноды;
Priority Classes — чтобы не вытеснять критичные сервисы;
Network tunnel/VPN — для low-latency доступа между on-prem и cloud;
Log aggregation + metrics — чтобы не терять наблюдаемость на границе кластеров;
Cost controls — чтобы bursting не стал неожиданно дорогим.

И в дополнение — полноценный bursting-ready Helm-чарт, который:

масштабирует поды с помощью HPA,
направляет их в облачный node pool через nodeAffinity,
совместим с Cluster Autoscaler,
и разделяет трафик с приоритетами.

Структура Helm-чарта (`cloud-bursting-app/`)

cloud-bursting-app/
├── templates/
│   ├── deployment.yaml
│   ├── hpa.yaml
│   └── service.yaml
├── values.yaml
└── Chart.yaml

`values.yaml`

replicaCount: 3
image:
  repository: myregistry/web-app
  tag: latest
resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 256Mi
bursting:
  enabled: true
  cloudLabelKey: workload
  cloudLabelValue: burstable

`templates/deployment.yaml`

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "cloud-bursting-app.fullname" . }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ include "cloud-bursting-app.name" . }}
  template:
    metadata:
      labels:
        app: {{ include "cloud-bursting-app.name" . }}
    spec:
      containers:
        - name: app
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          resources:
            requests:
              cpu: {{ .Values.resources.requests.cpu }}
              memory: {{ .Values.resources.requests.memory }}
            limits:
              cpu: {{ .Values.resources.limits.cpu }}
              memory: {{ .Values.resources.limits.memory }}
      {{- if .Values.bursting.enabled }}
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: {{ .Values.bursting.cloudLabelKey }}
                    operator: In
                    values:
                      - {{ .Values.bursting.cloudLabelValue }}
      {{- end }}

`templates/hpa.yaml`

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: {{ include "cloud-bursting-app.fullname" . }}
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: {{ include "cloud-bursting-app.fullname" . }}
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 65

Применение:

helm install web cloud-bursting-app/ -n default

Что делает этот чарт:

При стандартной нагрузке работает в пределах локального пула;
При росте CPU до 65% — HPA создаёт новые поды;
Через nodeAffinity bursting-поды направляются в облачные узлы;
Cluster Autoscaler в облаке добавляет ноды по мере необходимости.