Услуги по работе с альтернативными облаками и мультиоблаком

Альтернативные облачные платформы: Hetzner и DigitalOcean в production

Мы работаем с альтернативными облачными платформами — DigitalOcean, Hetzner Cloud, OVH, Selectel — и строим мультиоблачные архитектуры без vendor lock-in. Когда данные не привязаны к юрисдикции РФ, выбор провайдеров расширяется. DigitalOcean и Hetzner — два облака, которые устойчиво держат аудиторию разработчиков за соотношение цены и предсказуемости. Hetzner при этом — особый случай: стоимость VDS там в 3–5 раз ниже сопоставимых конфигураций AWS или GCP, что делает его основным выбором, когда маржинальность инфраструктуры критична.

Какие альтернативные облачные платформы выбирают для production?

Мы отдаём предпочтение Hetzner и DigitalOcean — у каждого своя ниша. Hetzner — для compute-heavy задач, где важна цена гигабайта RAM и CPU-ядра. DigitalOcean — для managed-сервисов (Kubernetes, PostgreSQL, Redis), когда нет выделенного DevOps. Оба провайдера поддерживают Terraform, имеют зрелые API и стабильные SLA. Ниже — разбор ключевых решений.

Hetzner: как выжать максимум из дешёвого железа

Hetzner Cloud — немецкий провайдер с датацентрами в Нюрнберге, Фалькенштайне и Финляндии. CX21 (2 vCPU, 4 GB RAM) стоит около 4 евро в месяц. Для сравнения — выделенный сервер AX41 с Ryzen 5 3600 и 64 GB RAM обходится в 38 евро. Это меняет архитектурные решения.

Terraform-провайдер hetznercloud/hcloud зрелый и стабильный. Базовая конфигурация кластера с тремя control-plane нодами и autoscaling worker pool:

resource "hcloud_server" "control_plane" { count = 3 name = "k8s-cp-${count.index}" image = "ubuntu-22.04" server_type = "cx31" location = "nbg1" ssh_keys = [hcloud_ssh_key.default.id] network { network_id = hcloud_network.k8s.id ip = "10.0.1.${count.index + 10}" } } resource "hcloud_load_balancer" "k8s_api" { name = "k8s-api-lb" load_balancer_type = "lb11" location = "nbg1" } 

Hetzner предоставляет managed load balancer (lb11, около 5 евро) с поддержкой TCP/HTTP балансировки. Для K8s API-сервера оптимально: три control-plane ноды, Hetzner LB перед ними.

Kubernetes на Hetzner без managed-сервиса. Managed K8s (Hetzner Managed Kubernetes) пока в beta, поэтому большинство команд разворачивают через k3s или kubeadm. k3s — предпочтительный вариант: меньше памяти (control-plane живёт в 512 MB), встроенный Traefik, SQLite или external etcd.

CSI для persistent volumes — hcloud-csi-driver. Он создаёт Hetzner Volumes (сетевые диски) как PersistentVolume. StorageClass по умолчанию — hcloud-volumes. RWO, не RWX — если нужен ReadWriteMany, используем NFS или объектное хранилище.

Сеть. Private Network обязательна для production. Публичные IP у каждого сервера по умолчанию, но трафик между серверами внутри Private Network — бесплатный и без лимитов. Трафик через публичный интерфейс — с квотами и тарифами. Pod-to-pod через Flannel или Calico должен ходить через private сеть, иначе при активной межнодовой коммуникации (Kafka, Cassandra) счёт неприятно удивит.

Hetzner Object Storage — S3-совместимое хранилище (появилось относительно недавно). Endpoint: https://fsn1.your-objectstorage.com. Дешевле AWS S3 в 4–5 раз. Velero backup с Hetzner S3 как backend:

# values.yaml для Velero configuration: provider: aws backupStorageLocation: bucket: k8s-backups config: region: fsn1 s3Url: https://fsn1.your-objectstorage.com s3ForcePathStyle: "true" 

Как избежать vendor lock-in при работе с альтернативными облаками?

Мультиоблачная стратегия — не про «запускаем всё везде одновременно». Это про конкретное решение: prod в Hetzner, CDN и DNS через Cloudflare, backups в S3 другого провайдера, CI/CD на выделенных раннерах в DigitalOcean.

Terraform workspace-подход:

infrastructure/ modules/ k8s-cluster/ postgres/ object-storage/ environments/ prod-hetzner/ main.tf terraform.tfvars staging-do/ main.tf terraform.tfvars 

Один модуль k8s-cluster с абстрактным интерфейсом (input: node_count, node_size, region) и две реализации под разных провайдеров. terraform workspace select prod-hetzner && terraform apply — production, terraform workspace select staging-do && terraform apply — staging на DigitalOcean.

State locking критичен при командной работе. Без него параллельный terraform apply от двух инженеров гарантированно разваливает state:

Error: Error acquiring the state lock Error message: ConditionalCheckFailedException: The conditional request failed 

После такого — terraform force-unlock <lock-id> с ручной проверкой state на консистентность.

Crossplane — альтернатива Terraform для управления облачными ресурсами из Kubernetes. Провайдеры для Hetzner и DigitalOcean доступны. XRD описывает абстракцию «кластер» или «база данных», конкретная реализация — в Composition. Для команд, уже живущих в Kubernetes, интересный вариант: kubectl apply -f postgres-claim.yaml создаёт managed PostgreSQL у провайдера.

DigitalOcean: managed-сервисы без головной боли

DigitalOcean позиционирует себя как «облако для разработчиков» — и это не маркетинг. DOKS (DigitalOcean Kubernetes Service) поднимается за 5 минут через UI или Terraform, DigitalOcean Managed PostgreSQL и Redis — ещё 10 минут. Для небольших production-сервисов без выделенного DevOps — разумный компромисс.

doctl — CLI, который реально используется рядом с kubectl:

doctl kubernetes cluster create prod \ --region fra1 \ --node-pool "name=workers;size=s-4vcpu-8gb;count=3;auto-scale=true;min-nodes=2;max-nodes=8" \ --version 1.29 

DOKS поддерживает cluster-autoscaler из коробки. Container Registry интегрирован через doctl registry kubernetes-manifest | kubectl apply -f -.

Слабое место DigitalOcean — размер инстансов. Самый мощный Droplet без dedicated CPU — 32 vCPU, 192 GB RAM. Для GPU-задач или heavy compute нужен другой провайдер. Для типичного web+API стека — хватает с запасом.

Сравнение ключевых характеристик:

Гибридные сценарии

Гибридная инфраструктура — не редкость: часть сервисов на bare-metal (latency-critical или большие объёмы данных), часть в облаке (публичные API, frontend, CDN). Связка через VPN-туннель или Wireguard.

Wireguard между Hetzner VPS и on-premise сервером:

# /etc/wireguard/wg0.conf на облачной стороне [Interface] PrivateKey = <cloud-private-key> Address = 10.100.0.1/24 ListenPort = 51820 [Peer] PublicKey = <onprem-public-key> AllowedIPs = 10.100.0.2/32, 192.168.1.0/24 Endpoint = <onprem-ip>:51820 PersistentKeepalive = 25 

Через этот туннель Kubernetes pods в Hetzner могут обращаться к on-premise PostgreSQL или NFS. Latency туннеля — 10–30 ms в зависимости от расстояния. Для синхронных read-запросов к БД допустимо, для real-time — нет.

Процесс работы и что входит

Наш подход — аналитика → проектирование → реализация → тест → деплой.

1. Аудит текущей инфраструктуры (3–5 дней): оценка нагрузки, лицензий, зависимостей. Определяем, какой провайдер подходит под конкретные задачи.
2. Проектирование (1–2 недели): Terraform-модули, схемы сети, CI/CD пайплайны.
3. Реализация (1–4 недели в зависимости от сложности): развёртывание Kubernetes, базы данных, объектного хранилища.
4. Тестирование (3–5 дней): нагрузочное тестирование, проверка отказоустойчивости.
5. Деплой и документация: сдача инфраструктуры, runbook для эксплуатации, обучение команды.

Что входит в работу:

• Terraform-конфигурации для всех окружений
• Код Kubernetes манифестов и Helm-чартов
• Настройка observability (Prometheus + Grafana, логи в Loki)
• Документация по сети, резервному копированию, disaster recovery
• Обучение вашей команды работе с новой инфраструктурой

Ориентировочные сроки

Стоимость рассчитывается после аудита — пишите в Telegram, оценим проект за 1 день.

Мы работаем с альтернативными облаками больше 5 лет, выполнили 30+ проектов по миграции и построению мультиоблачных архитектур. Сертифицированные Kubernetes администраторы (CKA) и Terraform ассоциаты. Гарантируем документацию и поддержку после сдачи.

• Официальная документация Hetzner Cloud (https://docs.hetzner.com/cloud/)
• Wikipedia: Kubernetes (https://en.wikipedia.org/wiki/Kubernetes) — для понимания основ оркестрации.