В октябре 2025 года сообщество KubeVirt выпустило сразу две технические публикации: 13 октября про растянутый L2 между кластерами, 31 октября про выделенную сеть для live migration. Из этого складывается неприятный, но полезный вывод для тех, кто переносит виртуалки в Kubernetes: межкластерная миграция в KubeVirt без дополнительной сетевой прослойки не взлетает, а связка KubeVirt и EVPN как раз закрывает этот пробел.
Как пишет The New Stack, автор этих материалов Miguel Duarte Barroso разбирает типичный сценарий, который слишком хорошо знаком платформенным командам: часть VM уже переехала в KubeVirt, сервисы работают, уверенность растет, а потом появляется вполне взрослый вопрос про disaster recovery, обслуживание площадок, перенос нагрузки в другой регион или банальную нехватку ресурсов в одном кластере. И тут выясняется, что KubeVirt хорошо решает запуск и жизнь VM внутри одного Kubernetes-кластера, но не раздает по умолчанию магию vMotion между разными кластерами. Причина прозаична: текущая модель сети остается cluster-local и не умеет тянуть L2-домен за границы кластера, а значит переезд VM быстро упирается не в гипервизор, а в сетевую топологию.
Для старых приложений это не академический спор сетевиков, а очень прикладная проблема. Если VM при переезде меняет сетевой контекст, приходится трогать IP-адреса, DNS, маршруты, ACL, firewall rules и иногда сам код или конфигурацию приложения. Особенно больно тем системам, которые до сих пор живут с предположением, что соседние узлы должны видеть друг друга на втором уровне: кластеры баз данных с heartbeat-механикой, приложения с broadcast- или multicast-обнаружением, отдельные storage-сценарии. Внутри одного кластера live migration у KubeVirt давно существует, но при переходе на второй кластер исчезает главное удобство классической виртуализации: возможность двигать нагрузку, не переписывая половину сетевого ландшафта. Kubernetes умеет многое, но притворяться растянутой сетевой фабрикой из коробки он не обязан.
Решение, на которое указывает разбор, строится вокруг EVPN, Ethernet VPN с control plane на BGP, который умеет объявлять MAC- и IP-адреса и тем самым растягивать L2-домен между разными площадками или кластерами. В практическом примере сообщества KubeVirt использовались два кластера Kind, KubeVirt 1.5.2, внешние BGP/EVPN-спикеры на FRR и open source-проект OpenPERouter. Поверх underlay-сети авторы подняли L2VNI с VNI 110 и VRF red, выдали ему шлюз 192.170.1.1/24 и подключили VM через NetworkAttachmentDefinition evpn. В демо одна виртуальная машина получила адрес 192.170.1.3 в кластере A, вторая 192.170.1.30 в кластере B, но для приложений они выглядели как соседи в одном логическом сегменте. Это и есть ключевой эффект EVPN: сохранить сетевую идентичность и убрать обязательную перенастройку на каждом переезде.
Но на одной только L2-связности история не заканчивается. Живая межкластерная миграция сама по себе создает заметный сетевой трафик, и если гнать его по той же сети, что и пользовательский трафик, можно быстро заработать ровно те проблемы, которые потом будет долго объяснять бизнесу: просадки производительности, конкуренцию за полосу, сложную диагностику и лишние риски с точки зрения изоляции данных. Поэтому во втором материале авторы добавили отдельную overlay-сеть именно под migration traffic, второй L2VNI с VNI 666 и VRF rouge. Важный нюанс: эта сеть не пробрасывается внутрь гостевой ОС, ею пользуются компоненты KubeVirt на узлах, которые координируют перенос работающей VM между кластерами. То есть речь не о «еще одном интерфейсе в виртуалке», а о выделенном служебном канале для самой операции миграции.
Сама процедура выглядит уже не как магия, а как честная инженерия с понятными шагами. В исходном кластере VM стартует с `runStrategy: Always`, в целевом заранее готовится приемник с `runStrategy: WaitAsReceiver`, после чего создаются объекты `VirtualMachineInstanceMigration` на прием и отправку. Источник получает адрес синхронизации целевого агента и подключается к нему по `connectURL` на порту 9185. В демонстрации даже образы у машин одинаковые: контейнерный диск Fedora `v1.6.2`, одна и та же конфигурация сети, одна и та же адресация, меняется только роль VM в сценарии миграции. Это не тот случай, когда можно нажать одну большую кнопку и уйти на кофе. Зато важен сам факт: KubeVirt и EVPN уже позволяют показать сценарий, в котором виртуальная машина остается в рабочем состоянии при переезде между кластерами, а сеть вокруг нее не разваливается на набор ручных исключений.
Для платформенных команд и ИТ-руководителей здесь две новости, и обе без маркетинговой глазури. Хорошая: с момента выхода KubeVirt 1.0 в июле 2023 года разговор в экосистеме явно сместился от вопроса «можно ли вообще запускать VM в Kubernetes» к вопросу day-2-операций, где важны отказоустойчивость, обслуживание площадок и контролируемая мобильность нагрузок. Плохая: сам перенос VM в Kubernetes не решает сетевую часть автоматически и не отменяет старых зависимостей приложений. Если компания рассчитывает на мягкий выход из классической виртуализации, ей придется закладывать в проект экспертизу по BGP, EVPN, secondary networks, Multus и операционную модель, где сеть больше не живет отдельно от платформенной команды. Для разработчиков это тоже сигнал: обещание «ничего не меняем, просто переезжаем» работает только до первого разговора о межкластерной миграции.
Именно здесь проходит граница между красивой демонстрацией и зрелой инфраструктурой. Если связка KubeVirt и EVPN со временем упростится до предсказуемого платформенного паттерна, у enterprise-команд появится реалистичный способ переносить VM в Kubernetes без насильственного переписывания наследия. Если нет, рынок получит еще один сильный open source-конструктор, который отлично смотрится на стенде и заметно дороже обходится в продакшене.