Последние полгода почти каждый разговор об уходе с VMware идёт по одному сценарию. Час обсуждаем виртуальные машины: куда переносить, сколько узлов, чем защищать. А в конце кто-нибудь из разработки спрашивает: «А с кубером что?» И выясняется, что у заказчика давно есть второй этаж — Kubernetes на виртуальных машинах vSphere, иногда Tanzu, иногда несколько ванильных кластеров, которые собирали разные команды в разные годы.
Первый этаж — виртуализация, второй — контейнерная платформа над ней. Про второй вспоминают последним, хотя переезжать ему приходится в любом случае. В выпуске 09 мы разбирали, куда уводить виртуальные машины. Здесь — что строить над ними, какие сочетания этажей работают и почему автоматизация, на которую ушли годы, не пропадает вместе с vSphere.
Привязки
Что уезжает вместе с vSphere
Kubernetes на виртуальных машинах переносится легко. С трудом переносятся его привязки к платформе, о которых никто не помнит.
С Tanzu всё однозначно. Отдельная линейка TKG Standalone закончилась на версии 2.5.x, VKS работает только поверх Supervisor внутри vSphere. Уходит vSphere — уходит и Tanzu, нужно выбирать замену.
С ванильным Kubernetes интереснее. Самому кластеру гипервизор безразличен, но вокруг него за годы нарастает обвязка, привязанная к vSphere намертво: драйвер vSphere CSI, облачный провайдер, балансировщик на NSX или внешнем ADC с интеграцией в vCenter, шаблоны узлов и автоматизация, которая их создаёт. А персистентные тома лежат в формате, который на другой платформе не откроется без переноса данных.
Когда просим заказчика вспомнить привязки, список почти всегда короче реального. Про CSI помнят все, про балансировщик — половина, про тома — единицы. Поэтому первый шаг миграции второго этажа — не выбор платформы, а инвентаризация привязок. Без неё сроки переезда всегда оптимистичны.
Архитектуры
Пять способов построить второй этаж
Рабочих сочетаний первого и второго этажа не меньше пяти. Ниже — те, что чаще всего встречаются в проектах.
Рабочих сочетаний не меньше пяти. Nutanix на обоих этажах: виртуальные машины на AHV, контейнеры в NKP на тех же AHV. Red Hat на обоих этажах: OpenShift прямо на физических серверах, виртуальные машины внутри него. Гибрид Nutanix и Red Hat: инфраструктура и виртуальные машины на Nutanix, контейнеры в OpenShift на виртуальных машинах AHV. SUSE на обоих этажах: SUSE Virtualization на физических серверах и Rancher над ней. И гибрид Nutanix и SUSE: кластеры RKE2 на AHV под управлением Rancher.
Сочетаний больше, чем пять: к Rancher можно подключить уже существующие кластеры других дистрибутивов, а ванильный Kubernetes собрать на любом гипервизоре. Но эти пять покрывают большинство проектов, которые мы видим в банках и телекоме, поэтому дальше разберём их по очереди.
Nutanix
Nutanix и NKP: один вендор на оба этажа
Кластер Kubernetes создаётся из той же консоли, что и виртуальные машины, а за стык этажей отвечает один вендор.
NKP построен на Cluster API и upstream Kubernetes: Cilium как сетевой слой, MetalLB для балансировки на AHV, CSI-драйвер и класс хранения по умолчанию на каждом кластере. С версии 2.17 NKP разворачивается из Marketplace в Prism Central — кластер Kubernetes создаётся из той же консоли, что и виртуальные машины. Для stateful-нагрузок в каталоге NKP есть NDK с репликацией и восстановлением на уровне приложения — та же асинхронная репликация, что в прошлом выпуске, только для подов и томов.
Главный аргумент — граница ответственности. Если под не получает том, не нужно выяснять, чья это проблема: CSI, хранилище и платформа у одного вендора. Для банка, где второй этаж сопровождают два-три человека, это весомее любого списка функций.
Ограничение тоже понятное: экосистема сертифицированных операторов у NKP меньше, чем у OpenShift. Если прикладной вендор поставляет продукт оператором под OpenShift, этот аргумент перевешивает удобство одной консоли.
Red Hat
OpenShift целиком
Виртуальная машина становится объектом Kubernetes. Для одних команд это естественно, для других — смена профессии.
Здесь меняется сама модель. В OpenShift Virtualization виртуальная машина описывается манифестом, живёт в namespace и подчиняется тем же RBAC и сетевым политикам, что и поды. Для команды, которая мыслит категориями Kubernetes, это естественно. Для администраторов с опытом vCenter — смена профессии, а не обновление инструмента.
Требование жёсткое: физические серверы, отдельный пул железа. Хранилище — OpenShift Data Foundation на дисках узлов или внешний массив через CSI его вендора. Для тех, кому сначала нужны только виртуальные машины, у Red Hat есть редакция OpenShift Virtualization Engine — без контейнерных функций, только на bare metal, с переходом на полную редакцию позже. Одна деталь, которую часто упускают: подписки на RHEL для гостевых систем в неё не входят, их покупают отдельно.
Вариант силён, когда организация стандартизуется на Kubernetes целиком и прикладные системы приходят операторами. Слаб — когда в парке сотни классических машин с Windows и Oracle, которые никто не будет переписывать.
Гибрид
Гибрид: Nutanix внизу, OpenShift сверху
Самый частый вариант в банковских планах. Работает, если правильно провести границу между этажами.
Этот вариант чаще всего встречается в банковских планах на 2–3 года вперёд. Виртуальные машины уезжают с vSphere на AHV, разрозненные ванильные кластеры собираются в OpenShift на виртуальных машинах того же Nutanix.
С поддержкой всё в порядке. AHV — сертифицированный Red Hat гипервизор, RHEL и OpenShift на нём поддерживаются полностью. С OpenShift 4.11 установка на Nutanix автоматизирована: установщик сам создаёт машины через Prism Central. Тома подам отдаёт Nutanix CSI — блочные через Volumes, общие файловые через Files.
Важно правильно провести границу. OpenShift здесь отвечает только за контейнеры, виртуальные машины живут на AHV и защищаются средствами Nutanix. Если на слайде виртуальные машины нарисованы «и в Prism, и в OpenShift», это две разные архитектуры, склеенные в одну картинку.
OpenShift здесь отвечает только за контейнеры, виртуальные машины живут на AHV и защищаются средствами Nutanix.
Плата за гибрид — два контракта поддержки и заранее разграниченные зоны ответственности. Связка Nutanix и Red Hat давно отработана, инженеры обоих вендоров хорошо знают стык. Но заявки решаются быстрее, если у заказчика есть свой специалист, который понимает оба этажа: он сразу собирает диагностику с обеих сторон и открывает обращение у того вендора, к чьей зоне относится проблема.
SUSE
SUSE: целым стеком или только Rancher
Та же развилка, что у Red Hat: строить всё на физических серверах или ставить только управление поверх чужой инфраструктуры.
Полный стек — SUSE Virtualization на bare metal, которую мы разбирали в выпуске 09: виртуальные машины через KubeVirt, распределённое хранилище Longhorn. Rancher подключает её как объект управления и создаёт на её машинах гостевые кластеры RKE2, а балансировщик и тома им отдаёт сама платформа.
Второй путь — только Rancher поверх Nutanix. У Nutanix есть драйвер узлов и расширение интерфейса для Rancher: выбираете проект Prism Central, сеть и пулы узлов, а машины под кластер RKE2 или K3s создаются на AHV автоматически. Nutanix CSI ставится из каталога Rancher партнёрским чартом, по связке есть совместное руководство Nutanix и SUSE.
От гибрида с OpenShift это отличается ролью. Rancher легче по требованиям и не навязывает свою модель приложения. Он хорош, когда кластеров много, они разного происхождения и их нужно привести к одной системе прав, мониторинга и политик, не пересобирая каждый. При зоопарке из пяти кластеров разных лет Rancher часто становится первым шагом к порядку, а дистрибутив выбирается потом.
Обвязка
Хранилище, сеть и доступ
Три вопроса, которые на vSphere были решены по умолчанию, а на новой платформе требуют ответа.
Персистентные тома между CSI-драйверами разных платформ не переезжают как есть — данные переносятся резервным копированием или репликацией приложения. Это отдельная строка плана миграции, а не деталь внедрения.
Балансировщик, который на vSphere часто давал NSX, на новой платформе — MetalLB в NKP, встроенный балансировщик SUSE Virtualization или внешний ADC. Входящий HTTP-трафик стоит сразу проверить: в марте 2026 года сообщество Kubernetes вывело из поддержки Ingress NGINX — самый распространённый ingress-контроллер, — исправлений безопасности для него больше не будет. Если вы и так перестраиваете входной контур, логично сразу смотреть на Gateway API.
С доступом проще: интеграция с AD через LDAP или OIDC есть у всех, реестр образов — Harbor в NKP, встроенный в OpenShift, Harbor отдельно для Rancher.
Защита
Защита второго этажа
Манифесты в Git — это защита конфигурации, а не данных.
Многие считают, что раз манифесты лежат в Git, кластер защищён. Git восстановит Deployment и Service, но не содержимое тома базы, которая работала в поде. Резервная копия etcd вернёт состояние кластера, а не данные приложений.
Реальная защита строится на инструментах, которые понимают и манифесты, и тома: Velero и построенный на нём OADP в OpenShift, NDK у Nutanix, корпоративные системы вроде Commvault, где Kubernetes — отдельный тип нагрузки со своим лицензированием. Дальше тот же разговор про RPO, RTO и место хранения копий, что в прошлом выпуске, только объект защиты — namespace с его томами, а не машина.
Автоматизация
Мир на VMware не заканчивается
Годы, вложенные в Terraform и Ansible, не пропадают вместе с vSphere.
Страх, который слышим почти на каждой встрече: годы ушли на модули Terraform, плейбуки Ansible и шаблоны образов, всё написано под vSphere и при переезде выбрасывается.
Не выбрасывается. Terraform описывает желаемое состояние, а с платформой работает провайдер. Он есть у vSphere и у Nutanix — официальный, от самого Nutanix. У SUSE Virtualization собственный провайдер, версии которого идут в ногу с платформой, Rancher управляется через провайдер rancher2. Виртуальные машины OpenShift Virtualization — это манифесты, и Terraform создаёт их через провайдер Kubernetes.
Модуль, который создаёт машину с ядрами, дисками, сетью и cloud-init, меняется в описании ресурса и блоке провайдера. Логика, переменные, пайплайн и согласования остаются. Это дни работы, а не переписывание. С Ansible так же — коллекции есть для каждой платформы. Argo CD и Flux вообще не замечают, на чём стоит кластер.
Логика, переменные, пайплайн и согласования остаются. Это дни работы, а не переписывание.
Одна деталь для тех, кто начинает автоматизировать Nutanix сейчас: в релизе провайдера, запланированном на четвёртый квартал 2026 года, Nutanix выводит из поддержки старые ресурсы на API v0.8–v3. Пишите сразу на ресурсы v2 поверх API v4.
Автоматизация, построенная правильно, переживает смену гипервизора. Построенная на кликах в vCenter — не переживёт, но тогда её и не было.
Чек-лист
Что спросить до выбора второго этажа
Десять вопросов, после которых выбор платформы становится расчётом, а не предпочтением.
Итог
Вместо вывода
Второй этаж редко становится причиной ухода с VMware, но почти всегда — причиной задержки. Привязки к платформе спрятаны в драйверах и томах, а не на виду.
Рабочих вариантов не меньше пяти, лучшего в общем случае среди них нет. Один вендор на оба этажа — меньше стыков. Два вендора — больше свободы выбора и чёткое разделение зон ответственности.
Если вы планируете уход с vSphere и про Kubernetes в плане пока одна строка — давайте обсудим. Начнём с инвентаризации привязок: это пара дней, которая экономит месяцы.