Послуги з роботи з російськими хмарами

Коли потрібно перенести production в російське хмаро

До нас звертаються із завданням: перенести production‑середовище з bare‑metal в російське хмаро до кінця кварталу. Ми надаємо послуги з роботи з російськими хмарами та допомагаємо обрати оптимального провайдера — Yandex Cloud, Selectel або VK Cloud. Вимоги — 152‑ФЗ, дані в РФ, SLA не нижче 99,9%. Кожен провайдер закриває ці вимоги, але архітектурні рішення всередині різні. Вибір впливає на те, як писати Terraform, налаштовувати мережу та платити за трафік.

У нас більше 7 років досвіду в хмарних технологіях та більше 50 успішних міграцій. Наші інженери сертифіковані Yandex Cloud та Selectel, ми гарантуємо мінімальний час простою при перенесенні даних. Замовте аудит поточної інфраструктури — це займе не більше дня.

Які проблеми вирішує міграція в російські хмари?

Головні болі — зниження витрат на утримання власних серверів, відповідність законодавству РФ (152‑ФЗ) та забезпечення високої доступності. При правильній архітектурі економія на ресурсах сягає 40%, а SLA піднімається до 99,95% без додаткових інвестицій в залізо. Але без досвіду легко потрапити на неочевидні обмеження managed‑сервісів.

Yandex Managed Service for Kubernetes — коли глибина важлива

Yandex Cloud — найбільш зріла платформа за кількістю managed‑сервісів. Managed Service for Kubernetes працює вже кілька років і за цей час обріс деталями, які або допомагають, або створюють неочевидні обмеження.

Node Groups та автоскейлінг

YC Kubernetes підтримує Cluster Autoscaler з прив'язкою до Instance Groups. Групи нод створюються під конкретний workload‑тип: spot‑ноди (переривані) для batch‑задач, стандартні для stateful‑компонентів. Переривані дешевші в 3 рази, але живуть не довше 24 годин — підходять для CI‑раннерів, ML‑задач, короткострокових джобів. Змішувати їх з production‑сервісами через PodDisruptionBudget та tolerations на рівні Deployment — робоча стратегія. Економія на spot‑нодах досягає 70%.

Типова грабля з автоскейлінгом: Cluster Autoscaler не скейлить, якщо pending‑поди не проходять по nodeAffinity або taints. Под висить у Pending, алерт приходить через 10 хвилин, команда дивиться на дашборд — ноди є, а под не планується. Причина — криві tolerations у Helm chart або невірно вказаний nodeSelector. Дебажимо через kubectl describe pod <name> → Events → didn't match node selector.

Yandex Container Registry

Інтегрований з кластером через Service Account. Авторизація через imagePullSecret робиться в кілька команд:

yc iam key create --service-account-id <sa-id> --output key.json kubectl create secret docker-registry yc-registry \ --docker-server=cr.yandex \ --docker-username=json_key \ --docker-password="$(cat key.json)" 

Але простіше — призначити роль container-registry.images.puller Service Account, прив'язаному до Node Group. Тоді kubelet сам отримує токени без imagePullSecret у кожному маніфесті.

Managed PostgreSQL у зв'язці з кластером

Yandex Managed PostgreSQL піднімається з відмовостійкістю з коробки: primary + replica з автоматичним failover через Patroni під капотом. Підключення з Kubernetes — через сервісне ім'я хосту кластера. Сертифікат TLS обов'язковий: у DATABASE_URL потрібен sslmode=verify-full з CA‑сертифікатом Яндекса. Без цього — підключення з production‑кластера до БД відкритим текстом, що неприйнятно.

Network Policy

Network Policy в YC Kubernetes вмикається на рівні кластера (--network-policy-provider=calico). За замовчуванням — allow all. Якщо активуєш Calico без заздалегідь написаних політик, всі поди продовжують ходити куди хочуть. Правильна послідовність: спочатку пишеш NetworkPolicy для всіх namespaces з deny‑default, потім вмикаєш провайдер. Інакше одне оновлення кластера — і у тебе працююча інфраструктура з відкритою мережевою моделлю.

Selectel: Kubernetes на managed-платформі та економіка bare-metal

Selectel пропонує дві моделі: Managed Kubernetes на базі власної платформи та оренду bare‑metal з можливістю самостійно будувати кластер. Для команд, яким важлива передбачуваність вартості, другий варіант часто вигідніший за хмарний Kubernetes при стабільному навантаженні — різниця може сягати 35% на рік.

Selectel Managed Kubernetes

Побудований на OpenStack + Magnum. API сумісний з upstream Kubernetes, ingress через nginx або Traefik, load balancer — через Octavia (OpenStack LB). Особливість: persistent volumes створюються через Cinder CSI‑драйвер. StorageClass за замовчуванням — ceph-hdd-dp1 або ceph-ssd-dp1. Для stateful‑сервісів (PostgreSQL, Kafka) обираємо SSD‑клас і прописуємо volumeBindingMode: WaitForFirstConsumer — інакше PVC створиться в зоні доступності, де не виявиться підходящої ноди.

Мережева архітектура

У Floating IP в Selectel потрібно явно асоціювати Floating IP з портом інстансу через API або Terraform. При використанні openstack_networking_floatingip_associate_v2 в Terraform важливо зберігати порядок depends_on — інакше state роз'їдеться, і terraform apply почне перестворювати ресурси, які вже існують.

Об'єктне сховище S3

Selectel S3 сумісний з AWS S3 API. У застосунках, які використовують boto3 або AWS SDK, достатньо перевизначити endpoint:

s3 = boto3.client('s3', endpoint_url='https://s3.ru-1.storage.selcloud.ru', aws_access_key_id=ACCESS_KEY, aws_secret_access_key=SECRET_KEY ) 

Версіонування об'єктів, lifecycle policies, pre‑signed URLs — все працює як в AWS S3. Мігрувати з AWS на Selectel S3 через rclone sync — завдання на кілька годин, не днів.

VK Cloud: OpenStack-історія з нюансами

VK Cloud (колишній Mail.ru Cloud Solutions) — платформа з глибокою інтеграцією OpenStack. Якщо команда вже вміє в OpenStack, освоїться швидко.

Managed Kubernetes в VK Cloud підтримує автоскейлінг, кілька node pools, інтеграцію з Cloud Load Balancer. Окремий момент — cloud-controller-manager для VK Cloud необхідний для того, щоб Services типу LoadBalancer створювали реальні балансувальники автоматично. Без правильно налаштованого CCM kubectl get svc буде показувати EXTERNAL-IP: <pending> нескінченно.

Terraform: єдиний підхід для всіх трьох

Для всіх трьох провайдерів існують Terraform‑провайдери, хоча ступінь зрілості різна.

# Yandex Cloud terraform { required_providers { yandex = { source = "yandex-cloud/yandex" version = "~> 0.84" } } backend "s3" { endpoint = "storage.yandexcloud.net" bucket = "tf-state-prod" key = "kubernetes/terraform.tfstate" region = "ru-central1" skip_region_validation = true skip_credentials_validation = true } } 

terraform { required_providers { selectel = { source = "selectel/selectel" version = "~> 3.0" } } } resource "selectel_vpc_project" "project" { name = "production" } resource "selectel_dbaas_datastore" "pg" { project_id = selectel_vpc_project.project.id name = "postgres-prod" type = "postgresql" subnet_id = var.subnet_id }