01

ПривязкиПрив’язкиThe ties

Что уезжает вместе с vSphere

Що їде разом із vSphere

What leaves together with vSphere

Kubernetes на виртуальных машинах переносится легко. С трудом переносятся его привязки к платформе, о которых никто не помнит.

Kubernetes на віртуальних машинах переноситься легко. Важко переносяться його прив’язки до платформи, про які ніхто не пам’ятає.

Kubernetes on virtual machines moves easily. What moves badly are its ties to the platform, which nobody remembers.

С Tanzu всё однозначно. Отдельная линейка TKG Standalone закончилась на версии 2.5.x, VKS работает только поверх Supervisor внутри vSphere. Уходит vSphere — уходит и Tanzu, нужно выбирать замену.

З Tanzu все однозначно. Окрема лінійка TKG Standalone закінчилася на версії 2.5.x, VKS працює лише поверх Supervisor усередині vSphere. Іде vSphere — іде і Tanzu, потрібно обирати заміну.

With Tanzu the picture is unambiguous. The standalone TKG line ended at version 2.5.x, and VKS runs only on top of Supervisor inside vSphere. If vSphere goes, Tanzu goes, and a replacement has to be chosen.

С ванильным Kubernetes интереснее. Самому кластеру гипервизор безразличен, но вокруг него за годы нарастает обвязка, привязанная к vSphere намертво: драйвер хранения vSphere CSI, облачный провайдер, балансировщик на NSX или внешнем ADC с интеграцией в vCenter, шаблоны узлов и автоматизация, которая их создаёт. А персистентные тома лежат в формате, который на другой платформе не откроется без переноса данных.

З ванільним Kubernetes цікавіше. Самому кластеру гіпервізор байдужий, але навколо нього за роки наростає обв’язка, прив’язана до vSphere намертво: драйвер зберігання vSphere CSI, хмарний провайдер, балансувальник на NSX або зовнішньому ADC з інтеграцією у vCenter, шаблони вузлів і автоматизація, яка їх створює. А персистентні томи лежать у форматі, який на іншій платформі не відкриється без перенесення даних.

With vanilla Kubernetes it is more interesting. The cluster itself is indifferent to the hypervisor, but over the years plumbing accumulates around it that is welded to vSphere: the vSphere CSI storage driver, the cloud provider, a load balancer on NSX or an external ADC integrated with vCenter, node templates and the automation that creates them. And the persistent volumes sit in a format that will not open on another platform without moving the data.

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

Коли просимо замовника згадати прив’язки, список майже завжди коротший за реальний. Про драйвер зберігання пам’ятають усі, про балансувальник — половина, про томи — одиниці. Тому перший крок міграції другого поверху — не вибір платформи, а інвентаризація прив’язок. Без неї строки переїзду завжди оптимістичні.

When we ask a customer to recall the ties, the list is almost always shorter than the reality. Everyone remembers the storage driver, half remember the load balancer, and almost nobody remembers the volumes. Which is why the first step in migrating the second floor is not choosing a platform but inventorying the ties. Without that, the timeline is always optimistic.

02

АрхитектурыАрхітектуриArchitectures

Пять способов построить второй этаж

П’ять способів побудувати другий поверх

Five ways to build the second floor

Рабочих сочетаний первого и второго этажа не меньше пяти. Ниже — те, что чаще всего встречаются в проектах.

Робочих поєднань першого і другого поверху не менше п’яти. Нижче — ті, що найчастіше трапляються в проєктах.

There are at least five workable combinations of first and second floor. Below are the ones that come up most often in projects.

Рабочих сочетаний не меньше пяти. Nutanix на обоих этажах: виртуальные машины на AHV, контейнеры в NKP на тех же узлах. Red Hat на обоих этажах: OpenShift прямо на физических серверах, виртуальные машины внутри него. Гибрид Nutanix и Red Hat: инфраструктура и виртуальные машины на Nutanix, контейнеры в OpenShift на виртуальных машинах AHV. SUSE на обоих этажах: SUSE Virtualization на физических серверах и Rancher над ней. И гибрид Nutanix и SUSE: кластеры RKE2 на AHV под управлением Rancher.

Робочих поєднань не менше п’яти. Nutanix на обох поверхах: віртуальні машини на AHV, контейнери в NKP на тих самих вузлах. Red Hat на обох поверхах: OpenShift прямо на фізичних серверах, віртуальні машини всередині нього. Гібрид Nutanix і Red Hat: інфраструктура і віртуальні машини на Nutanix, контейнери в OpenShift на віртуальних машинах AHV. SUSE на обох поверхах: SUSE Virtualization на фізичних серверах і Rancher над нею. І гібрид Nutanix і SUSE: кластери RKE2 на AHV під управлінням Rancher.

There are at least five workable combinations. Nutanix on both floors: virtual machines on AHV, containers in NKP on the same nodes. Red Hat on both floors: OpenShift straight on physical servers with virtual machines inside it. A Nutanix and Red Hat hybrid: infrastructure and virtual machines on Nutanix, containers in OpenShift on AHV virtual machines. SUSE on both floors: SUSE Virtualization on physical servers with Rancher above it. And a Nutanix and SUSE hybrid: RKE2 clusters on AHV managed by Rancher.

Сочетаний больше, чем пять: к Rancher можно подключить уже существующие кластеры других дистрибутивов, а ванильный Kubernetes собрать на любом гипервизоре. Но эти пять покрывают большинство проектов, которые мы видим в банках и телекоме, поэтому дальше разберу их по очереди.

Поєднань більше, ніж п’ять: до Rancher можна підключити вже наявні кластери інших дистрибутивів, а ванільний Kubernetes зібрати на будь-якому гіпервізорі. Але ці п’ять покривають більшість проєктів, які ми бачимо в банках і телекомі, тому далі розберу їх по черзі.

There are more than five combinations: Rancher can adopt existing clusters of other distributions, and vanilla Kubernetes can be built on any hypervisor. But these five cover most of the projects we see in banking and telecom, so I will take them in turn.

03

Один вендор: NutanixОдин вендор: NutanixOne vendor: Nutanix

Кластер Kubernetes из той же консоли

Кластер Kubernetes із тієї самої консолі

A Kubernetes cluster from the same console

За стык этажей отвечает один вендор. Для команды из двух-трёх человек это весомее любого списка функций.

За стик поверхів відповідає один вендор. Для команди з двох-трьох осіб це вагоміше за будь-який список функцій.

One vendor owns the seam between the floors. For a team of two or three people that outweighs any feature list.

NKP построен на Cluster API и upstream Kubernetes: Cilium как сетевой слой, MetalLB для балансировки на AHV, драйвер хранения и класс хранения по умолчанию на каждом кластере. С версии 2.17 NKP разворачивается из каталога в Prism Central — кластер Kubernetes создаётся из той же консоли, что и виртуальные машины. Для нагрузок с состоянием в каталоге NKP есть NDK с репликацией и восстановлением на уровне приложения — та же асинхронная репликация, что в прошлом выпуске, только для подов и томов.

NKP побудований на Cluster API та upstream Kubernetes: Cilium як мережевий шар, MetalLB для балансування на AHV, драйвер зберігання і клас зберігання за замовчуванням на кожному кластері. З версії 2.17 NKP розгортається з каталогу в Prism Central — кластер Kubernetes створюється з тієї самої консолі, що й віртуальні машини. Для навантажень зі станом у каталозі NKP є NDK з реплікацією і відновленням на рівні застосунку — та сама асинхронна реплікація, що в минулому випуску, тільки для подів і томів.

NKP is built on Cluster API and upstream Kubernetes: Cilium for networking, MetalLB for load balancing on AHV, and a storage driver with a default storage class on every cluster. From version 2.17 NKP deploys from the marketplace in Prism Central — a Kubernetes cluster is created from the same console as the virtual machines. For stateful workloads the NKP catalogue includes NDK, with application-level replication and recovery — the same asynchronous replication as in the previous issue, only for pods and volumes.

Главный аргумент — граница ответственности. Если под не получает том, не нужно выяснять, чья это проблема: драйвер хранения, хранилище и платформа у одного вендора. Для банка, где второй этаж сопровождают два-три человека, это весомее любого списка функций.

Головний аргумент — межа відповідальності. Якщо под не отримує том, не потрібно з’ясовувати, чия це проблема: драйвер зберігання, сховище і платформа в одного вендора. Для банку, де другий поверх супроводжують дві-три особи, це вагоміше за будь-який список функцій.

The main argument is the boundary of responsibility. If a pod does not get its volume, there is no need to work out whose problem it is: the storage driver, the storage and the platform come from one vendor. For a bank where two or three people look after the second floor, that outweighs any feature list.

Ограничение тоже понятное: экосистема сертифицированных операторов у NKP меньше, чем у OpenShift. Если прикладной вендор поставляет продукт оператором под OpenShift, этот аргумент перевешивает удобство одной консоли.

Обмеження теж зрозуміле: екосистема сертифікованих операторів у NKP менша, ніж у OpenShift. Якщо прикладний вендор постачає продукт оператором під OpenShift, цей аргумент переважує зручність однієї консолі.

The limitation is equally clear: NKP’s ecosystem of certified operators is smaller than OpenShift’s. If an application vendor ships its product as an operator for OpenShift, that argument outweighs the convenience of a single console.

04

Один вендор: Red HatОдин вендор: Red HatOne vendor: Red Hat

OpenShift целиком

OpenShift цілком

OpenShift throughout

Виртуальная машина становится объектом Kubernetes. Для одних команд это естественно, для других — смена профессии.

Віртуальна машина стає об’єктом Kubernetes. Для одних команд це природно, для інших — зміна професії.

A virtual machine becomes a Kubernetes object. For some teams that is natural; for others it is a change of profession.

Здесь меняется сама модель. В OpenShift Virtualization виртуальная машина описывается манифестом, живёт в пространстве имён и подчиняется тем же правам доступа и сетевым политикам, что и поды. Для команды, которая мыслит категориями Kubernetes, это естественно. Для администраторов с опытом vCenter — смена профессии, а не обновление инструмента.

Тут змінюється сама модель. У OpenShift Virtualization віртуальна машина описується маніфестом, живе у просторі імен і підпорядковується тим самим правам доступу і мережевим політикам, що й поди. Для команди, яка мислить категоріями Kubernetes, це природно. Для адміністраторів із досвідом vCenter — зміна професії, а не оновлення інструмента.

Here the model itself changes. In OpenShift Virtualization a virtual machine is described by a manifest, lives in a namespace and obeys the same access rights and network policies as pods. For a team that thinks in Kubernetes terms this is natural. For administrators with vCenter experience it is a change of profession, not a tool upgrade.

Требование жёсткое: физические серверы, отдельный пул железа. Хранилище — OpenShift Data Foundation на дисках узлов или внешний массив через драйвер его вендора. Для тех, кому сначала нужны только виртуальные машины, у Red Hat есть редакция OpenShift Virtualization Engine — без контейнерных функций, только на физических серверах, с переходом на полную редакцию позже. Одна деталь, которую часто упускают: подписки на RHEL для гостевых систем в неё не входят, их покупают отдельно.

Вимога жорстка: фізичні сервери, окремий пул заліза. Сховище — OpenShift Data Foundation на дисках вузлів або зовнішній масив через драйвер його вендора. Для тих, кому спочатку потрібні лише віртуальні машини, у Red Hat є редакція OpenShift Virtualization Engine — без контейнерних функцій, лише на фізичних серверах, із переходом на повну редакцію пізніше. Одна деталь, яку часто пропускають: підписки на RHEL для гостьових систем до неї не входять, їх купують окремо.

The requirement is strict: physical servers, a separate pool of hardware. Storage is OpenShift Data Foundation on the nodes’ disks or an external array through its vendor’s driver. For those who need only virtual machines at first, Red Hat offers the OpenShift Virtualization Engine edition — no container features, bare metal only, with a path to the full edition later. One detail often missed: RHEL subscriptions for the guest systems are not included and are bought separately.

Вариант силён, когда организация стандартизуется на Kubernetes целиком и прикладные системы приходят операторами. Слаб — когда в парке сотни классических машин с Windows и Oracle, которые никто не будет переписывать.

Варіант сильний, коли організація стандартизується на Kubernetes цілком і прикладні системи приходять операторами. Слабкий — коли в парку сотні класичних машин із Windows і Oracle, які ніхто не переписуватиме.

This option is strong where an organisation is standardising on Kubernetes wholesale and the application systems arrive as operators. It is weak where the estate holds hundreds of classic Windows and Oracle machines that nobody is going to rewrite.

05

ГибридГібридThe hybrid

Nutanix внизу, OpenShift сверху

Nutanix внизу, OpenShift згори

Nutanix below, OpenShift above

Самый частый вариант в банковских планах. Работает, если правильно провести границу между этажами.

Найчастіший варіант у банківських планах. Працює, якщо правильно провести межу між поверхами.

The most common option in banks’ plans. It works if the boundary between the floors is drawn correctly.

Этот вариант чаще всего встречается в банковских планах на 2–3 года вперёд. Виртуальные машины уезжают с vSphere на AHV, разрозненные ванильные кластеры собираются в OpenShift на виртуальных машинах того же Nutanix.

Цей варіант найчастіше трапляється в банківських планах на 2–3 роки вперед. Віртуальні машини їдуть із vSphere на AHV, розрізнені ванільні кластери збираються в OpenShift на віртуальних машинах того самого Nutanix.

This option appears most often in banks’ two- and three-year plans. The virtual machines move off vSphere to AHV, and the scattered vanilla clusters are consolidated into OpenShift on virtual machines of that same Nutanix.

С поддержкой всё в порядке. AHV — сертифицированный Red Hat гипервизор, RHEL и OpenShift на нём поддерживаются полностью. С OpenShift 4.11 установка на Nutanix автоматизирована: установщик сам создаёт машины через Prism Central. Тома подам отдаёт драйвер Nutanix — блочные через Volumes, общие файловые через Files.

Із підтримкою все гаразд. AHV — сертифікований Red Hat гіпервізор, RHEL і OpenShift на ньому підтримуються повністю. З OpenShift 4.11 встановлення на Nutanix автоматизоване: інсталятор сам створює машини через Prism Central. Томи подам віддає драйвер Nutanix — блокові через Volumes, спільні файлові через Files.

Support is in order. AHV is a Red Hat certified hypervisor, and RHEL and OpenShift are fully supported on it. Since OpenShift 4.11 the installation on Nutanix is automated: the installer creates the machines itself through Prism Central. Volumes are presented to pods by the Nutanix driver — block through Volumes, shared file through Files.

Важно правильно провести границу. OpenShift здесь отвечает только за контейнеры, виртуальные машины живут на AHV и защищаются средствами Nutanix. Если на слайде виртуальные машины нарисованы «и в Prism, и в OpenShift», это две разные архитектуры, склеенные в одну картинку.

Важливо правильно провести межу. OpenShift тут відповідає лише за контейнери, віртуальні машини живуть на AHV і захищаються засобами Nutanix. Якщо на слайді віртуальні машини намальовані «і в Prism, і в OpenShift», це дві різні архітектури, склеєні в одну картинку.

Drawing the boundary correctly matters. OpenShift here is responsible only for containers; the virtual machines live on AHV and are protected by Nutanix’s own means. If a slide shows virtual machines “both in Prism and in OpenShift”, that is two different architectures glued into one picture.

OpenShift здесь отвечает только за контейнеры, виртуальные машины живут на AHV и защищаются средствами Nutanix.

OpenShift тут відповідає лише за контейнери, віртуальні машини живуть на AHV і захищаються засобами Nutanix.

OpenShift here is responsible only for containers; the virtual machines live on AHV and are protected by Nutanix’s own means.

Плата за гибрид — два контракта поддержки и заранее разграниченные зоны ответственности. Связка Nutanix и Red Hat давно отработана, инженеры обоих вендоров хорошо знают стык. Но заявки решаются быстрее, если у заказчика есть свой специалист, который понимает оба этажа: он сразу собирает диагностику с обеих сторон и открывает обращение у того вендора, к чьей зоне относится проблема.

Плата за гібрид — два контракти підтримки і заздалегідь розмежовані зони відповідальності. Зв’язка Nutanix і Red Hat давно відпрацьована, інженери обох вендорів добре знають стик. Але заявки вирішуються швидше, якщо в замовника є свій спеціаліст, який розуміє обидва поверхи: він одразу збирає діагностику з обох боків і відкриває звернення в того вендора, до чиєї зони належить проблема.

The price of the hybrid is two support contracts and zones of responsibility agreed in advance. The Nutanix and Red Hat pairing has long been proven, and engineers from both vendors know the seam well. But cases are resolved faster when the customer has someone of their own who understands both floors: they collect diagnostics from both sides at once and open the case with whichever vendor owns the problem.

06

Один вендор: SUSEОдин вендор: SUSEOne vendor: SUSE

Целым стеком или только управлением

Цілим стеком або лише управлінням

The whole stack, or just the management layer

Та же развилка, что у Red Hat: строить всё на физических серверах или ставить только управление поверх чужой инфраструктуры.

Та сама розвилка, що в Red Hat: будувати все на фізичних серверах чи ставити лише управління поверх чужої інфраструктури.

The same fork as with Red Hat: build everything on bare metal, or put only the management layer on top of somebody else’s infrastructure.

Полный стек — SUSE Virtualization на физических серверах, которую я разбирал в выпуске 09: виртуальные машины через KubeVirt, распределённое хранилище Longhorn. Rancher подключает её как объект управления и создаёт на её машинах гостевые кластеры RKE2, а балансировщик и тома им отдаёт сама платформа.

Повний стек — SUSE Virtualization на фізичних серверах, яку я розбирав у випуску 09: віртуальні машини через KubeVirt, розподілене сховище Longhorn. Rancher підключає її як об’єкт управління і створює на її машинах гостьові кластери RKE2, а балансувальник і томи їм віддає сама платформа.

The full stack is SUSE Virtualization on bare metal, which I covered in issue 09: virtual machines through KubeVirt and Longhorn distributed storage. Rancher adopts it as a managed object and creates guest RKE2 clusters on its machines, with the load balancer and volumes provided by the platform itself.

Второй путь — только Rancher поверх Nutanix. У Nutanix есть драйвер узлов и расширение интерфейса для Rancher: выбираете проект Prism Central, сеть и пулы узлов, а машины под кластер RKE2 или K3s создаются на AHV автоматически. Драйвер хранения Nutanix ставится из каталога Rancher партнёрским чартом, по связке есть совместное руководство обоих вендоров.

Другий шлях — лише Rancher поверх Nutanix. У Nutanix є драйвер вузлів і розширення інтерфейсу для Rancher: обираєте проєкт Prism Central, мережу і пули вузлів, а машини під кластер RKE2 або K3s створюються на AHV автоматично. Драйвер зберігання Nutanix ставиться з каталогу Rancher партнерським чартом, по зв’язці є спільне керівництво обох вендорів.

The second path is Rancher alone on top of Nutanix. Nutanix provides a node driver and a UI extension for Rancher: you pick the Prism Central project, the network and the node pools, and the machines for an RKE2 or K3s cluster are created on AHV automatically. The Nutanix storage driver is installed from the Rancher catalogue as a partner chart, and the two vendors publish a joint guide for the combination.

От гибрида с OpenShift это отличается ролью. Rancher легче по требованиям и не навязывает свою модель приложения. Он хорош, когда кластеров много, они разного происхождения и их нужно привести к одной системе прав, мониторинга и политик, не пересобирая каждый. При зоопарке из пяти кластеров разных лет Rancher часто становится первым шагом к порядку, а дистрибутив выбирается потом.

Від гібрида з OpenShift це відрізняється роллю. Rancher легший за вимогами і не нав’язує свою модель застосунку. Він хороший, коли кластерів багато, вони різного походження і їх треба привести до однієї системи прав, моніторингу і політик, не перезбираючи кожен. За зоопарку з п’яти кластерів різних років Rancher часто стає першим кроком до порядку, а дистрибутив обирається потім.

What distinguishes this from the OpenShift hybrid is the role. Rancher is lighter in its requirements and does not impose its own application model. It is good where there are many clusters of different origins that need to be brought under one system of rights, monitoring and policies without rebuilding each of them. With a zoo of five clusters from different years, Rancher is often the first step towards order, and the distribution is chosen later.

07

ОбвязкаОбв’язкаThe plumbing

Хранилище, сеть и доступ

Сховище, мережа і доступ

Storage, networking and access

Три вопроса, которые на vSphere были решены по умолчанию, а на новой платформе требуют ответа.

Три питання, які на vSphere були вирішені за замовчуванням, а на новій платформі потребують відповіді.

Three questions that vSphere answered by default and the new platform makes you answer yourself.

Персистентные тома между драйверами хранения разных платформ не переезжают как есть — данные переносятся резервным копированием или репликацией приложения. Это отдельная строка плана миграции, а не деталь внедрения.

Персистентні томи між драйверами зберігання різних платформ не переїжджають як є — дані переносяться резервним копіюванням або реплікацією застосунку. Це окремий рядок плану міграції, а не деталь впровадження.

Persistent volumes do not move as is between the storage drivers of different platforms — the data is moved by backup or by application-level replication. That is a separate line in the migration plan, not an implementation detail.

Балансировщик, который на vSphere часто давал NSX, на новой платформе — MetalLB в NKP, встроенный балансировщик SUSE Virtualization или внешний ADC. Входящий HTTP-трафик стоит сразу проверить: в марте 2026 года сообщество Kubernetes вывело из поддержки Ingress NGINX — самый распространённый контроллер входящего трафика, — исправлений безопасности для него больше не будет. Если вы и так перестраиваете входной контур, логично сразу смотреть на Gateway API.

Балансувальник, який на vSphere часто давав NSX, на новій платформі — MetalLB у NKP, вбудований балансувальник SUSE Virtualization або зовнішній ADC. Вхідний HTTP-трафік варто одразу перевірити: у березні 2026 року спільнота Kubernetes вивела з підтримки Ingress NGINX — найпоширеніший контролер вхідного трафіку, — виправлень безпеки для нього більше не буде. Якщо ви і так перебудовуєте вхідний контур, логічно одразу дивитися на Gateway API.

The load balancer that NSX often provided on vSphere becomes MetalLB in NKP, SUSE Virtualization’s built-in balancer, or an external ADC. Inbound HTTP traffic is worth checking straight away: in March 2026 the Kubernetes community retired Ingress NGINX — the most widely used ingress controller — and there will be no further security fixes for it. If you are rebuilding the inbound path anyway, it makes sense to look at the Gateway API now.

С доступом проще: интеграция с каталогом через LDAP или OIDC есть у всех, реестр образов — Harbor в NKP, встроенный в OpenShift, Harbor отдельно для Rancher.

Із доступом простіше: інтеграція з каталогом через LDAP або OIDC є у всіх, реєстр образів — Harbor у NKP, вбудований в OpenShift, Harbor окремо для Rancher.

Access is simpler: directory integration through LDAP or OIDC exists everywhere, and for the image registry it is Harbor in NKP, the built-in one in OpenShift, and a separate Harbor for Rancher.

08

ЗащитаЗахистProtection

Защита второго этажа

Захист другого поверху

Protecting the second floor

Манифесты в системе контроля версий — это защита конфигурации, а не данных.

Маніфести в системі контролю версій — це захист конфігурації, а не даних.

Manifests in version control protect the configuration, not the data.

Многие считают, что раз манифесты лежат в системе контроля версий, кластер защищён. Она восстановит описание развёртывания и сервиса, но не содержимое тома базы, которая работала в поде. Резервная копия хранилища состояния кластера вернёт состояние кластера, а не данные приложений.

Багато хто вважає, що раз маніфести лежать у системі контролю версій, кластер захищений. Вона відновить опис розгортання і сервісу, але не вміст тому бази, яка працювала в поді. Резервна копія сховища стану кластера поверне стан кластера, а не дані застосунків.

Many people assume that because the manifests are in version control, the cluster is protected. It will restore the deployment and service definitions, but not the contents of the volume of a database that was running in a pod. A backup of the cluster state store returns the state of the cluster, not the applications’ data.

Реальная защита строится на инструментах, которые понимают и манифесты, и тома: Velero и построенный на нём OADP в OpenShift, NDK у Nutanix, корпоративные системы вроде Commvault, где Kubernetes — отдельный тип нагрузки со своим лицензированием. Дальше тот же разговор про точку восстановления, время восстановления и место хранения копий, что в прошлом выпуске, только объект защиты — пространство имён с его томами, а не машина.

Реальний захист будується на інструментах, які розуміють і маніфести, і томи: Velero і побудований на ньому OADP в OpenShift, NDK у Nutanix, корпоративні системи на кшталт Commvault, де Kubernetes — окремий тип навантаження зі своїм ліцензуванням. Далі та сама розмова про точку відновлення, час відновлення і місце зберігання копій, що в минулому випуску, тільки об’єкт захисту — простір імен із його томами, а не машина.

Real protection is built on tools that understand both manifests and volumes: Velero and the OADP built on it in OpenShift, NDK in Nutanix, and enterprise systems such as Commvault, where Kubernetes is a workload type of its own with its own licensing. After that it is the same conversation about recovery point, recovery time and where the copies live as in the previous issue — only the object being protected is a namespace with its volumes rather than a machine.

09

АвтоматизацияАвтоматизаціяAutomation

Мир на VMware не заканчивается

Світ на VMware не закінчується

The world does not end with VMware

Годы, вложенные в описание инфраструктуры кодом, не пропадают вместе с vSphere.

Роки, вкладені в опис інфраструктури кодом, не пропадають разом із vSphere.

The years invested in infrastructure as code do not vanish along with vSphere.

Страх, который слышу почти на каждой встрече: годы ушли на модули Terraform, плейбуки Ansible и шаблоны образов, всё написано под vSphere и при переезде выбрасывается.

Страх, який чую майже на кожній зустрічі: роки пішли на модулі Terraform, плейбуки Ansible і шаблони образів, усе написано під vSphere і при переїзді викидається.

A fear I hear at almost every meeting: years went into Terraform modules, Ansible playbooks and image templates, all written for vSphere, and the move throws it all away.

Не выбрасывается. Terraform описывает желаемое состояние, а с платформой работает провайдер. Он есть у vSphere и у Nutanix — официальный, от самого вендора. У SUSE Virtualization собственный провайдер, версии которого идут в ногу с платформой, Rancher управляется через провайдер rancher2. Виртуальные машины OpenShift Virtualization — это манифесты, и Terraform создаёт их через провайдер Kubernetes.

Не викидається. Terraform описує бажаний стан, а з платформою працює провайдер. Він є у vSphere і в Nutanix — офіційний, від самого вендора. У SUSE Virtualization власний провайдер, версії якого йдуть у ногу з платформою, Rancher керується через провайдер rancher2. Віртуальні машини OpenShift Virtualization — це маніфести, і Terraform створює їх через провайдер Kubernetes.

It does not. Terraform describes the desired state, and it is the provider that talks to the platform. There is one for vSphere and one for Nutanix — official, from the vendor itself. SUSE Virtualization has its own provider whose versions track the platform, and Rancher is managed through the rancher2 provider. OpenShift Virtualization’s virtual machines are manifests, and Terraform creates them through the Kubernetes provider.

Модуль, который создаёт машину с ядрами, дисками, сетью и начальной конфигурацией, меняется в описании ресурса и блоке провайдера. Логика, переменные, пайплайн и согласования остаются. Это дни работы, а не переписывание. С Ansible так же — коллекции есть для каждой платформы. Argo CD и Flux вообще не замечают, на чём стоит кластер.

Модуль, який створює машину з ядрами, дисками, мережею і початковою конфігурацією, змінюється в описі ресурсу і блоці провайдера. Логіка, змінні, пайплайн і погодження залишаються. Це дні роботи, а не переписування. З Ansible так само — колекції є для кожної платформи. Argo CD і Flux узагалі не помічають, на чому стоїть кластер.

A module that creates a machine with its cores, disks, network and initial configuration changes in the resource block and the provider block. The logic, the variables, the pipeline and the approvals stay. That is days of work, not a rewrite. The same goes for Ansible — collections exist for every platform. Argo CD and Flux do not notice what the cluster runs on at all.

Логика, переменные, пайплайн и согласования остаются. Это дни работы, а не переписывание.

Логіка, змінні, пайплайн і погодження залишаються. Це дні роботи, а не переписування.

The logic, the variables, the pipeline and the approvals stay. That is days of work, not a rewrite.

Одна деталь для тех, кто начинает автоматизировать Nutanix сейчас: в релизе провайдера, запланированном на четвёртый квартал 2026 года, вендор выводит из поддержки старые ресурсы на интерфейсах версий 0.8–3. Пишите сразу на ресурсы второй версии поверх интерфейса v4.

Одна деталь для тих, хто починає автоматизувати Nutanix зараз: у релізі провайдера, запланованому на четвертий квартал 2026 року, вендор виводить із підтримки старі ресурси на інтерфейсах версій 0.8–3. Пишіть одразу на ресурси другої версії поверх інтерфейсу v4.

One detail for anyone starting to automate Nutanix now: in the provider release planned for the fourth quarter of 2026 the vendor retires the old resources built on the v0.8–v3 interfaces. Write against the v2 resources on the v4 interface from the start.

Автоматизация, построенная правильно, переживает смену гипервизора. Построенная на кликах в консоли — не переживёт, но тогда её и не было.

Автоматизація, побудована правильно, переживає зміну гіпервізора. Побудована на кліках у консолі — не переживе, але тоді її й не було.

Automation built properly survives a change of hypervisor. Automation built on clicks in a console will not — but then there was none to begin with.

10

Чек-листЧек-листChecklist

Что спросить до выбора второго этажа

Що запитати до вибору другого поверху

What to ask before choosing the second floor

Десять вопросов, после которых выбор платформы становится расчётом, а не предпочтением.

Десять питань, після яких вибір платформи стає розрахунком, а не вподобанням.

Ten questions that turn the platform choice into a calculation rather than a preference.

1. Какие кластеры Kubernetes есть сейчас, кто их собирал и какие версии на них работают?
2. Что во втором этаже завязано на vSphere: драйвер хранения, облачный провайдер, балансировщик, шаблоны, автоматизация?
3. Сколько данных лежит в персистентных томах и чем их переносить?
4. Поставляют ли прикладные вендоры продукты операторами под конкретную платформу?
5. Нужны ли виртуальные машины и контейнеры в одной консоли, или их сопровождают разные команды?
6. Готов ли отдельный пул физических серверов, если выбор — OpenShift Virtualization или SUSE Virtualization?
7. Кто разбирает инциденты на стыке этажей, если вендоров два?
8. Чем защищаются данные подов, а не только манифесты и состояние кластера?
9. Какой контроллер входящего трафика стоит сейчас и не пора ли его менять?
10. На каком провайдере и версии интерфейса написана автоматизация и сколько в ней платформенно-зависимых ресурсов?

1. Які кластери Kubernetes є зараз, хто їх збирав і які версії на них працюють?
2. Що в другому поверсі зав’язане на vSphere: драйвер зберігання, хмарний провайдер, балансувальник, шаблони, автоматизація?
3. Скільки даних лежить у персистентних томах і чим їх переносити?
4. Чи постачають прикладні вендори продукти операторами під конкретну платформу?
5. Чи потрібні віртуальні машини і контейнери в одній консолі, чи їх супроводжують різні команди?
6. Чи готовий окремий пул фізичних серверів, якщо вибір — OpenShift Virtualization або SUSE Virtualization?
7. Хто розбирає інциденти на стику поверхів, якщо вендорів два?
8. Чим захищаються дані подів, а не лише маніфести і стан кластера?
9. Який контролер вхідного трафіку стоїть зараз і чи не час його міняти?
10. На якому провайдері та версії інтерфейсу написана автоматизація і скільки в ній платформозалежних ресурсів?

1. Which Kubernetes clusters exist today, who built them, and what versions do they run?
2. What on the second floor is tied to vSphere: the storage driver, the cloud provider, the load balancer, the templates, the automation?
3. How much data sits in persistent volumes, and what will move it?
4. Do your application vendors ship their products as operators for a particular platform?
5. Do you need virtual machines and containers in one console, or are they looked after by different teams?
6. Is a separate pool of physical servers ready, if the choice is OpenShift Virtualization or SUSE Virtualization?
7. Who handles incidents at the seam between the floors when there are two vendors?
8. What protects the pods’ data, rather than just the manifests and the cluster state?
9. Which ingress controller is in place now, and is it time to replace it?
10. Which provider and API version is the automation written against, and how many platform-specific resources does it contain?

11

ИтогПідсумокWrap-up

Вместо вывода

Замість висновку

In place of a conclusion

Второй этаж редко становится причиной ухода с VMware, но почти всегда — причиной задержки. Привязки к платформе спрятаны в драйверах и томах, а не на виду.

Другий поверх рідко стає причиною відходу від VMware, але майже завжди — причиною затримки. Прив’язки до платформи сховані в драйверах і томах, а не на виду.

The second floor is rarely the reason for leaving VMware, but it is almost always the reason for the delay. The ties to the platform are hidden in drivers and volumes, not out in the open.

Рабочих вариантов не меньше пяти, лучшего в общем случае среди них нет. Один вендор на оба этажа — меньше стыков. Два вендора — больше свободы выбора и чёткое разделение зон ответственности.

Робочих варіантів не менше п’яти, найкращого в загальному випадку серед них немає. Один вендор на обидва поверхи — менше стиків. Два вендори — більше свободи вибору і чіткий поділ зон відповідальності.

There are at least five workable options, and none of them is best in the general case. One vendor across both floors means fewer seams. Two vendors mean more freedom of choice and a clear split of responsibility.