Услуги по работе с российскими облаками

Работа с российскими облаками: Yandex Cloud, Selectel, VK Cloud. Миграция, настройка managed Kubernetes, баз данных, CDN и обеспечение соответствия требованиям 152-ФЗ.
Показано 27 из 27Все 1054 услуг

Наши компетенции:

Часто задаваемые вопросы

Последние работы

  • Разработка сайта компании B2B ADVANCE
    Разработка сайта компании B2B ADVANCE
    1532
  • Разработка веб-приложения для компании FEEDME
    Разработка веб-приложения для компании FEEDME
    1365
  • Разработка веб-сайта для компании БЕЛФИНГРУПП
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    1071
  • Разработка интернет магазина для компании FURNORO
    Разработка интернет магазина для компании FURNORO
    1331
  • Разработка логотипа компании B2B Advance
    Разработка логотипа компании B2B Advance
    784
  • Разработка веб-приложения для компании Enviok
    Разработка веб-приложения для компании Enviok
    1077

Когда нужно перенести production в российское облако

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

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 при стабильной нагрузке.

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 конфигурации для Selectel
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 } 

Remote state в S3‑совместимом хранилище провайдера — обязательно. terraform.tfstate локально в репозитории — это потеря контроля над инфраструктурой при работе в команде.

Инструменты экосистемы

В рамках российских облаков особо актуальны:

  • ArgoCD — GitOps‑деплой в Managed Kubernetes. Манифесты в Git, синхронизация автоматическая. Работает одинаково во всех трёх провайдерах
  • Helm + helmfile — управление чартами, окружениями. helmfile sync разворачивает все сервисы в правильном порядке
  • Velero — backup Kubernetes ресурсов и persistent volumes. В качестве backend — S3 любого из провайдеров
  • cert‑manager — автоматические TLS‑сертификаты. Let's Encrypt работает без ограничений, для внутренних доменов — self‑signed CA через Vault

Как выбрать провайдера для российского облака?

Выбор зависит от нескольких факторов одновременно. Если задача — быстро развернуть managed PostgreSQL, Kafka, Redis вместе с Kubernetes в одной сети без ручной настройки — Yandex Cloud закроет это из коробки. Если нужна предсказуемая стоимость на 1–2 года без сюрпризов от спотового ценообразования и есть навыки работы с OpenStack — Selectel и VK Cloud дают больше контроля.

Характеристика Yandex Cloud Selectel VK Cloud
Managed Kubernetes Да (с 2019) Да (OpenStack + Magnum) Да (OpenStack)
Managed PostgreSQL Да (Patroni) Да (через DBaaS) Да
Объектное хранилище S3‑совместимое (Object Storage) S3‑совместимое (S3) S3‑совместимое
Ценообразование Pay‑as‑you‑go, spot‑ноды Pay‑as‑you‑go, bare‑metal Pay‑as‑you‑go, fixed
SLA 99,95% 99,9% 99,9%

Гибридный сценарий: production в Selectel на bare‑metal, managed‑сервисы (почта, CDN, Object Storage) — через Yandex Cloud. Terraform workspace per environment, state в S3 каждого провайдера. Работает, но поддерживать нужно два провайдерных конфига.

Этапы работы

  1. Аудит текущей инфраструктуры — инвентаризация сервисов, зависимостей, объёмов данных
  2. Выбор провайдера и архитектурное проектирование — сеть, IAM, namespace‑стратегия в Kubernetes
  3. Terraform‑кодификация инфраструктуры — модули, remote state, workspace per env
  4. Настройка кластера — node pools, autoscaling, network policies, ingress
  5. Деплой приложений — Helm чарты, ArgoCD, secrets через Vault или YC Lockbox
  6. Настройка мониторинга и алертинга — Prometheus, Grafana, интеграция с managed‑метриками провайдера
  7. Документация и передача — runbook, схемы архитектуры, доступы
Задача Сроки
Аудит и проектирование 1–2 недели
Базовая инфраструктура в облаке (IaC) 1–2 недели
Kubernetes кластер + CI/CD 2–3 недели
Полная миграция с тестированием 4–8 недель

Что входит в работу по миграции в российское облако?

В результате вы получаете:

  • Документированную инфраструктуру (архитектурные схемы, описание модулей Terraform)
  • Настроенные CI/CD и observability (Prometheus + Grafana, алерты)
  • Runbook для типовых операций (rollback, масштабирование, обновление кластера)
  • Доступы и обучение команды (сессия по работе с облаком и инструментами)
  • Постмиграционную поддержку в течение месяца

Мы также готовим отчёт с экономической моделью — сколько будет стоить инфраструктура через полгода и где можно сэкономить (например, за счёт spot‑нод или reserved‑инстансов).

Закажите аудит вашей текущей инфраструктуры — это займёт не больше дня. Получите консультацию инженера, который знает нюансы каждого провайдера. Свяжитесь с нами для оценки вашего проекта.