Заменять сам Kubernetes чаще всего не требуется — он остаётся открытым проектом с лицензией Apache 2.0, и запрета на его использование нет. Меняют другое: коммерческую поддержку, управляемые сервисы зарубежных облаков и проприетарные надстройки вроде OpenShift или Tanzu. Их место в России занимают отечественные дистрибутивы на базе upstream-Kubernetes — Deckhouse, «Штурвал», Nova Container Platform, Platform V DropApp, а также управляемые кластеры в российских облаках. Все они сохраняют совместимость с kubectl, Helm-чартами и стандартными манифестами, поэтому речь идёт о смене вендора, а не о переписывании приложений.
Содержимое обзора:
Что именно перестало работать и что нужно замещать
Первым уходит подписка: без неё нет обновлений, патчей безопасности и SLA на инциденты. Второе — доступ к публичным реестрам образов. Docker Hub, quay.io и gcr.io периодически ограничивают трафик из российских сетей, поэтому организации разворачивают собственный registry (Harbor, Nexus) и зеркалируют базовые образы. Третье — управляемые сервисы AWS EKS, GKE и AKS: аналог здесь только один — Managed Kubernetes у российских провайдеров.
Отдельная история — требования регуляторов. Для госструктур и субъектов КИИ нужен продукт из реестра российского ПО, совместимый с сертифицированной ОС. Чистый upstream-Kubernetes это требование не закрывает, каким бы стабильным он ни был.
Какие варианты замены существуют
Коробочные дистрибутивы устанавливаются на своё железо или в частное облако, включают предсобранный control plane, CNI-плагин, ingress-контроллер, мониторинг и систему логирования. Обычно поддерживают air-gapped-установку — контур без выхода в интернет. Отечественные разработчики решают и задачу мультикластерного управления: платформа оркестрации контейнеров на базе Kubernetes, созданная в Группе Астра, даёт единый интерфейс для настройки, развёртывания, обновления и масштабирования множества кластеров сразу, включая гибридные и облачные инфраструктуры и сценарии виртуального частного облака — платформа контейнеризации в россии интегрирована с ОС Astra Linux, GitFlic, Tantor и Astra Automation, а среди её партнёров указаны РЕАК СОФТ, Luntry, Positive Technologies Container Security, VK Cloud и «Контур Налоговый Мониторинг». Подробнее можно узнать на сайте.
Второй путь — облачный Managed Kubernetes у российских провайдеров: control plane и etcd обслуживает провайдер, вы платите за узлы. Быстрее в запуске, но привязывает к API конкретного облака (балансировщики, storage-классы, IAM).
Третий вариант — самостоятельная сборка через kubeadm или k3s. Дешевле по лицензиям, дороже по людям: нужен инженер, который умеет чинить etcd в три часа ночи. Для команды меньше пяти человек это обычно невыгодно, хотя для стендов разработки — вполне рабочий подход.
На что смотреть при выборе
Проверяйте сертификацию соответствия версий: дистрибутив должен проходить тесты CNCF Conformance, иначе часть операторов и чартов может не завестись. Дальше — жизненный цикл: какие версии Kubernetes поддерживаются, как часто выходят обновления, есть ли автоматизированный переход между минорными релизами. Оцените встроенные средства эксплуатации: обнаружение, диагностика и исправление инцидентов, механизмы оптимизации ресурсов, в том числе под нагрузки машинного обучения и ИИ, где важно распределение GPU между подами.
Безопасность контейнеров редко входит в базовую поставку — её закрывают отдельными продуктами класса container security: сканирование образов, контроль runtime, политики RBAC и сетевые политики. Уточняйте, с какими из них дистрибутив интегрирован «из коробки».
Что делать, если поддержка зарубежной платформы уже прекращена
Практические шаги:
- Зафиксируйте текущее состояние: версия Kubernetes, список CRD, операторы, CNI, storage-драйверы, точки интеграции с CI/CD. Без этой инвентаризации миграция превращается в угадывание.
- Поднимите локальное зеркало реестра образов и перенесите туда все базовые образы. Это снимает риск того, что кластер не поднимется после перезапуска узла.
- Разверните пилотный кластер на выбранной платформе и перенесите одно некритичное приложение целиком — вместе с конфигами, секретами и мониторингом.
- Сравните манифесты: чаще всего правки касаются storage-классов, аннотаций ingress и способа выдачи сертификатов, реже — самих контейнеров.
- Переводите продуктивную нагрузку по частям, через переключение трафика на уровне балансировщика, а не «в одну ночь». Старый кластер держите живым до окончания тестового периода.
- Заранее договоритесь о формате поддержки: время реакции, доступ к инженерам, порядок разбора инцидентов в закрытом контуре.
Если миграция откладывается из-за нехватки людей, минимальный уровень выживания — собственный registry, регулярные бэкапы etcd и ручное обновление до безопасной версии. Это не заменяет вендорскую поддержку, но снимает большую часть рисков на переходный период.