Сам Kubernetes заменять не нужно — это открытый проект под лицензией Apache 2.0, и запретить его использование технически невозможно. Заменять приходится коммерческие дистрибутивы и управляемые сервисы: OpenShift, Rancher, VMware Tanzu, EKS и GKE, у которых в России пропала подписка, поддержка и доступ к репозиториям образов. Практическая замена — российские платформы контейнеризации на базе upstream Kubernetes: Deckhouse от «Фланта», «Штурвал» от «Лаборатории Числитель», Nova Container Platform, Bootsman от «Платформы Боцман», а также managed-сервисы у Yandex Cloud, VK Cloud и Cloud.ru.
Что именно ломается при уходе зарубежных вендоров
Проблема редко в самом оркестраторе. Отваливается обвязка: реестры контейнеров (Docker Hub с лимитами, Red Hat Quay), операторы для баз данных, лицензии на CNI-плагины, сканеры уязвимостей с актуальными базами CVE, коммерческий саппорт с SLA. Отдельная боль — сертификация: без записи в реестре отечественного ПО и без совместимости с сертифицированными ОС платформу не пропустят в госсектор, КИИ и в проекты с обработкой персональных данных.
Второй момент — операционная система под узлами. Ванильный Kubernetes прекрасно живёт на Ubuntu, но если инфраструктура переезжает на Astra Linux или РЕД ОС, набор проверенных связок «ядро — контейнерный рантайм — CNI» резко сужается. Чаще всего, но не всегда, вендор российского дистрибутива сам гарантирует эту совместимость; в самосборных вариантах отладку ядра, cgroup v2 и containerd придётся вести своими силами.
Какие варианты замены существуют
Условно решения делятся на три группы.
Собственная сборка на upstream. Kubeadm, containerd, Calico или Cilium, Ingress NGINX, Prometheus и Grafana, свой Harbor как реестр образов. Дёшево по лицензиям, дорого по людям: нужны минимум двое инженеров, которые умеют чинить etcd и обновлять control plane без простоя. Для стенда и внутренних сервисов подходит, для продакшена с требованиями по доступности — рискованно.
Российские дистрибутивы Kubernetes. Это тот же upstream, но с преднастроенными модулями, единой панелью управления, собственным зеркалом образов, поддержкой и записью в реестре Минцифры. Здесь же живут решения для мультикластерных инсталляций — когда кластеров десятки, в разных ЦОДах и облаках, и их нужно администрировать из одного места. Один из примеров такого класса — российская система контейнеризации от компании «Платформа Боцман», входящей в «Группу Астра»: это гибридная облачная система для управления мультикластерами Kubernetes с единым интерфейсом для настройки, развёртывания, обновления и масштабирования множества кластеров.
Managed Kubernetes в российских облаках. Control plane обслуживает провайдер, вы платите за узлы и трафик. Быстрый старт, но привязка к площадке и ограничения по кастомизации: не всякий admission-контроллер или своя версия CRI-O туда встанет.
На что смотреть при выборе
Ориентируйтесь на проверяемые вещи, а не на маркетинговые описания:
- реестр российского ПО — есть ли запись и на какое юрлицо;
- отставание от upstream: насколько быстро вендор подтягивает новые минорные версии Kubernetes и патчи безопасности;
- сценарий обновления control plane и узлов — в идеале с rolling-стратегией и без остановки нагрузок;
- интеграции внутри экосистемы: у зрелых платформ они уже собраны — например, связка с ОС Astra Linux, репозиторием GitFlic, СУБД Tantor и Astra Automation избавляет от ручной стыковки компонентов;
- партнёрские решения по безопасности контейнеров: Luntry, Positive Technologies Container Security, РЕАК СОФТ, а также поддержка сценариев VK Cloud и Контур Налоговый Мониторинг — важно, что вендор не закрывает всё собой, а даёт совместимость со специализированными продуктами;
- поддержка задач машинного обучения и искусственного интеллекта с оптимизацией использования ресурсов — если планируете обучать модели, проверьте работу с GPU-узлами, шедулингом и квотами;
- формат поддержки: круглосуточная линия, время реакции, доступ к инженерам разработчика, а не только к партнёру-интегратору.
Отдельно стоит проверить миграцию. Манифесты, Helm-чарты и оператор-паттерны переносятся между дистрибутивами почти без правок, поскольку API Kubernetes стандартный. Переписывать приходится то, что завязано на проприетарные объекты: у OpenShift это Route, DeploymentConfig, SecurityContextConstraints и собственные ImageStream — их меняют на Ingress, Deployment и Pod Security Admission.
Начните не с выбора вендора, а с инвентаризации: сколько кластеров, какие проприетарные объекты используются, какая ОС на узлах и есть ли требования по сертификации. После этого разверните пилот на двух-трёх кандидатах и прогоните на нём реальное обновление версии — именно на этом шаге разница между дистрибутивами становится заметной. Подробнее о конкретных платформах обычно можно узнать на сайтах разработчиков и в их документации.
