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

Cloud Bursting — это история про то, как жить на своём железе, но уметь временно «выплёскивать» лишнюю нагрузку в облако. То есть основная часть системы работает on-prem, а когда ресурсов внезапно не хватает, часть трафика или вычислений уезжает в публичный клауд — без закупки ещё одной стойки серверов.

Отсюда и метафора: локальный «резервуар» мощности переполняется, и избыток проливается в облако.

Где это реально используют #

• Пики нагрузки: чёрная пятница, рекламные кампании, релиз нового функционала, когда не хочется держать под это постоянный парк железа.
• Нагрузочное тестирование: надо кратковременно раздуть инфраструктуру, чтобы покрутить стресс‑тесты.
• Пакетная обработка данных: периодический тяжёлый расчёт, рендеринг, отчёты — проще выкинуть это в клауд на пару часов.
• Dev/Test среды: временные стенды, которых не жалко, и которые не должны постоянно жить в on-prem.

Что в этом хорошего #

• Экономия — не надо держать в дата-центре резерв на самые худшие сценарии, которые бывают пару дней в году.
• Гибкость — ресурсы в облаке включаются по необходимости и так же быстро выключаются.
• Быстрое масштабирование — вместо долгих закупок всё решается API-запросом и настройками автоскейлера.
• Гибридная модель — on-prem плюс public cloud в одной картине мира.
• Бонус к отказоустойчивости — облако может сыграть роль резерва по мощности, когда локальный кластер лежит под нагрузкой.

Что нужно, чтобы это вообще работало #

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

Какие тут подводные камни #

• Латентность — каждое лишнее перепрыгивание через интернет может стоить миллисекунд, а иногда — и секунд.
• Сложность схемы — особенно если в игре несколько облаков и гибридных решений, инфраструктура становится нетривиальной.
• Безопасность — нужно чётко контролировать, какие данные и куда текут, шифрование, IAM, всё как обычно, но сложнее.
• Лицензии — часть софта до сих пор живёт в модели «один сервер — одна лицензия в конкретном месте», и гибридные сценарии там неочевидны.
• Vendor lock-in — сильная завязка на API конкретного провайдера может аукнуться позже.

Примеры платформ, где cloud bursting «из коробки» более-менее поддержан #

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

Cloud Bursting — это не серебряная пуля. Он имеет смысл там, где нагрузка действительно «волатильная», но — и вы готовы в это инвестировать архитектурно и организационно.

Пример: bursting на Kubernetes через HPA и облачные node pools #

1. Horizontal Pod Autoscaler #

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

Как только средняя загрузка CPU по подам превышает 65%, 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"
}
}

Пул стартует с нуля нод: пока нагрузки нет, вы за него не платите. Когда HPA создаёт поды, которым нужны эти ноды, Cluster Autoscaler подтягивает виртуалки.

Схема гибридной архитектуры Cloud Bursting #

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

Что обязательно настроить #

• Taints/Tolerations — чтобы bursting-поды специально шли на облачные ноды, а не путались с локальными.
• PriorityClasses — чтобы случайно не вытеснить критичные сервисы чем‑нибудь второстепенным.
• VPN / туннели — нормальный канал между кластерами, иначе вся идея теряет смысл.
• Сбор логов и метрик — общая система наблюдаемости, а не два разрозненных мира.
• Контроль стоимости — лимиты, алерты, отчётность, чтобы внезапный пик не превратился в внезапный счёт.

Helm-чарт «bursting-ready» #

Идея чарта простая:

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

Структура чарта 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

Что в итоге делает этот чарт #

• При обычной нагрузке крутятся те самые 3 реплики, в основном локальном пуле.
• Когда CPU поднимается выше 65%, HPA добавляет поды.
• nodeAffinity направляет дополнительные поды на облачные ноды с нужными лейблами.
• Cluster Autoscaler запускает новые ноды в облаке по факту необходимости.

Аренда VPS/VDS — от ₽219/месяц

Почему выбирают VPS от AdminVPS:

✓ Дешевле физического сервера

✓ Более гибкий и мощный, чем обычный хостинг

✓ Бесплатная защита от DDoS и техподдержка 24/7

✓ Масштабируется под любые задачи

Виртуальный сервер VPS/VDS — ваш личный сервер для сайтов, магазинов, ботов и других проектов.

Арендовать VPS