В стремительно меняющемся ИТ-ландшафте корпоративные ИТ-подразделения сталкиваются с фундаментальной операционной дилеммой. С одной стороны, администраторам VMware vSphere и инфраструктуры необходимы жёсткий контроль, соответствие требованиям, безопасность и мультиарендное управление ресурсами. С другой стороны, разработчикам и DevOps-инженерам нужны гибкость, быстрое самостоятельное выделение ресурсов и нативная инфраструктура, управляемая через API, чтобы ускорить выпуск приложений.
Когда эти два приоритета сталкиваются, операционные проблемы неизбежны. Инфраструктурные команды тонут в бесконечных очередях заявок на развёртывание кластеров и изменение сетевых настроек, а команды разработки, раздражённые задержками, уходят в теневые ИТ или разворачивают изолированные внешние управляющие кластеры. Такая фрагментация не только замедляет инновации, но и порождает серьёзные уязвимости в безопасности, дополнительные операционные издержки и неэффективные расходы.
В недавнем вебинаре Activating VKS Supervisor to Support Kubernetes было показано, как активация управляющего уровня, называемого vSphere Supervisor, в VMware Cloud Foundation (VCF) 9.1 напрямую решает эту дилемму современных приложений.
VMware vSphere Kubernetes Service (VKS) — это среда исполнения Kubernetes, встроенная непосредственно в VCF. Благодаря сертифицированному CNCF дистрибутиву Kubernetes служба VKS позволяет платформенным инженерам разворачивать кластеры Kubernetes, управлять ими и масштабировать их, задействуя при этом весь набор облачных сервисов VCF, а также любые совместимые сторонние сервисы.
Преодоление разрыва: что такое vSphere Supervisor
Корпоративные платформенные команды постоянно испытывают операционное напряжение: разработчикам нужны быстрые API Kubernetes в режиме самообслуживания, тогда как инфраструктурные команды обязаны обеспечивать централизованное управление, безопасность и соблюдение политик по ресурсам.
vSphere Supervisor снимает эти трения, предоставляя настоящее самообслуживание для разработчиков, подкреплённое административным контролем корпоративного уровня, — и всё это работает прямо на существующей инфраструктуре vSphere. Вместо того чтобы строить и обслуживать сложные изолированные управляющие кластеры поверх vSphere, Supervisor встраивает нативный управляющий уровень Kubernetes непосредственно в VMware ESXi и vSphere, превращая гипервизоры в нативные эндпоинты Kubernetes.
Такая архитектура создаёт общую мультиарендную платформу, на которой гармонично работают и инфраструктурные администраторы, и разработчики:
Для администраторов vSphere: контроль и соответствие требованиям сохраняются за счёт пространств имён vSphere Namespaces. Администраторы задают границы ресурсов (квоты на CPU, память и хранилище), назначают ролевую модель доступа (RBAC) и сохраняют полную операционную видимость через vSphere Client и VMware Cloud Foundation Operations.
Для DevOps-инженеров: платформа предоставляет стандартную конечную точку API Kubernetes. Инженеры могут применять декларативные YAML-манифесты через kubectl и Helm, чтобы разворачивать кластеры рабочих нагрузок (кластеры VKS), виртуальные машины (через VM Service) и контейнеризованные нагрузки прямо внутри выделенных им пространств имён vSphere.
В VCF 9.1 развязанное управление жизненным циклом позволяет платформенным командам обновлять и патчить версии Kubernetes независимо от обновлений самой платформы. В сочетании с серьёзной оптимизацией движка VKS платформа обеспечивает развёртывание кластеров до 70% быстрее, обновления до 75% быстрее и масштабирование до 500 кластеров на один экземпляр управляющего уровня.
Архитектура vSphere Supervisor и высокая доступность
Архитектура vSphere Supervisor спроектирована так, чтобы обеспечивать отказоустойчивость корпоративного уровня за счёт встраивания нативного высокодоступного управляющего уровня Kubernetes непосредственно в слой гипервизора vSphere. Управляющий уровень vSphere Supervisor состоит из трёх активных виртуальных машин управляющего уровня Kubernetes, развёрнутых на хостах ESX или в мультизональных кластерах vSphere, что обеспечивает непрерывный кворум и отсутствие единых точек отказа. Эти виртуальные машины напрямую взаимодействуют с vCenter и ESX, управляя жизненным циклом рабочих нагрузок, распределением ресурсов и согласованием состояния во всей среде.
На низком уровне примитивы хранения и вычислений тесно связаны между собой, что помогает обеспечить высокую доступность. Алгоритм размещения управляющего уровня динамически распределяет виртуальные машины по доменам отказа, а временные данные обслуживаются через эфемерные диски (Ephemeral Disks), которые автоматически очищаются при завершении работы пода. Кроме того, диски с образами контейнеров кэшируются непосредственно на отдельных хостах ESX, что позволяет обойти задержки загрузки из реестра и обеспечить практически мгновенное создание подов и их восстановление при отказе хоста.
Топологии хранения и управление политиками
Приложениям с сохранением состояния, построенным по облачно-нативным принципам, требуется надёжная работа с постоянным хранилищем. vSphere Supervisor связывает запросы Kubernetes на постоянные тома с примитивами хранения vSphere через Cloud Native Storage (CNS) и нативный драйвер vSphere Container Storage Interface (CSI).
Когда разработчик отправляет запрос PersistentVolumeClaim (PVC), драйвер CNS-CSI напрямую обращается к vCenter и транслирует этот запрос в диск First Class Disk (FCD) на нижележащем хранилище. Администраторы обеспечивают управляемость, назначая политики хранения (например, Gold, Silver) и лимиты ёмкости непосредственно пространствам имён vSphere.
vSphere Supervisor поддерживает три различные топологии хранения, рассчитанные на конкретные требования рабочих нагрузок:
Хотя чаще всего в качестве примера приводится гиперконвергентный vSAN, традиционные внешние массивы хранения (Fibre Channel, iSCSI и NFS) отображаются на те же самые топологии. Стандартные внешние хранилища SAN/NAS, подключённые к одному кластеру vSphere, работают как зональные хранилища (Zonal Datastores). В мультизональных развёртываниях заказчики, использующие репликацию на уровне сторонних массивов — например, метрокластеры хранения на базе FC/iSCSI, — могут добиться доступности межзональных хранилищ (Cross-Zone Datastore) без применения нативного растянутого кластера vSAN.
Помимо постоянного хранилища vSphere Supervisor управляет дисками управляющего уровня, эфемерными дисками (автоматически уничтожаются при удалении пода) и кэшированием образов контейнеров непосредственно на хостах ESX, что обеспечивает практически мгновенный запуск подов.
Сеть и балансировка нагрузки в vSphere Supervisor
Сетевая подсистема и балансировка нагрузки в vSphere Supervisor построены вокруг развязанной, хорошо масштабируемой модели виртуального частного облака (VPC), реализованной через системные проекты VMware NSX и централизованные транзитные шлюзы. Каждое пространство имён vSphere работает внутри собственного выделенного NSX VPC с приватными подсетями и шлюзами VPC, которые изолируют нагрузки арендаторов и устраняют конфликты IP-адресов, даже если разные команды используют пересекающиеся блоки CIDR.
Маршрутизация трафика между пространствами имён, управляющими сетями и внешними сервисами обеспечивается транзитными шлюзами Tier-0 и Tier-1, что помогает организовать безопасную и высокопроизводительную транзитную передачу по сетевой фабрике. Для балансировки нагрузки и входящего трафика vSphere Supervisor интегрируется с VMware Avi Load Balancer. Эта интеграция автоматизирует выделение и управление жизненным циклом виртуальных IP-адресов (VIP), балансировщиков для конечной точки API Kubernetes и контроллеров ingress уровней L4/L7, обеспечивая точное управление трафиком, полностью автоматическую настройку сети и глубокую изоляцию по безопасности без ручного вмешательства в сетевую конфигурацию.
Современная сеть: NSX VPC и транзитные шлюзы
Организация сети в мультиарендных контейнерных платформах традиционно вызывала значительные трудности, нередко приводя к исчерпанию IP-адресов, усложнению маршрутизации на межсетевых экранах и рискам безопасности.
vSphere Supervisor решает эту задачу, сочетая виртуальные частные облака NSX (VPC) с гибкими схемами транзитных шлюзов в системных проектах NSX. Хотя в демонстрации на вебинаре был показан вариант с централизованным транзитным шлюзом, vSphere Supervisor в полной мере поддерживает и распределённые транзитные шлюзы, что позволяет выбрать модель подключения, наиболее подходящую конкретной среде.
Ключевые возможности этой сетевой архитектуры:
Изолированные VPC для каждого пространства имён: каждое пространство имён vSphere изолировано внутри собственного NSX VPC с приватными подсетями и выделенными шлюзами VPC.
Отсутствие конфликтов IP и развязанная маршрутизация: развязанная маршрутизация между VPC позволяет разным командам разработки использовать пересекающиеся диапазоны IP без сетевых коллизий.
Линейная масштабируемость: централизованные транзитные шлюзы безопасно обрабатывают высокоскоростную маршрутизацию между пространствами имён и во внешние сети через шлюзы Tier-0/Tier-1.
Встроенная балансировка нагрузки: Avi Load Balancer автоматизирует маршрутизацию трафика через контроллер ingress и балансировку API Kubernetes.
Пошаговая активация и сценарий демонстрации
В демонстрационной части вебинара был показан полный сквозной жизненный цикл развёртывания — как со стороны администратора, так и со стороны разработчика.
Наблюдаемость на этапе Day-2: вся телеметрия, метрики производительности и логи поступают напрямую в централизованный VCF Operations для проактивного мониторинга и операций жизненного цикла.
Предварительные требования и запуск активации: перед запуском активации Supervisor необходимо убедиться, что выполнены базовые требования: действующий домен рабочих нагрузок VCF с включёнными vSphere HA и DRS, сетевая конфигурация на базе NSX или распределённого коммутатора vSphere с назначенными пулами IP-адресов, поддерживаемый балансировщик нагрузки, выделенная политика хранения vSphere и подписная библиотека контента (Subscribed Content Library). После этого активацию можно инициировать при создании домена рабочих нагрузок в VCF Operations либо уже после развёртывания непосредственно в vCenter в разделе Supervisor Management -> Get Started, где мастер перед развёртыванием проверяет вычислительные зоны, политики хранения, библиотеки контента и настройки балансировки нагрузки.
Настройка пространства имён и RBAC: администратор виртуальной инфраструктуры создаёт пространство имён vSphere, назначает политики хранения и квоты ресурсов, а также выдаёт права доступа разработчикам.
Декларативное развёртывание: DevOps-инженер аутентифицируется на управляющем уровне vSphere Supervisor через kubectl и применяет YAML-манифест с запросом на новый кластер VKS. vSphere Supervisor автоматически разворачивает узлы управляющего уровня и рабочие узлы.
Двойная перспектива наблюдения: администратор виртуальной инфраструктуры отслеживает состояние инфраструктуры и объекты виртуальных машин в vSphere и VCF Operations, тогда как разработчик управляет подами, сервисами и развёртываниями через kubectl.
Развёртывание гибридного приложения: команды разворачивают многоуровневые приложения, объединяющие виртуальные машины (через API службы VM Service) и контейнеризованные нагрузки на базе Helm-чартов.
Заключение и что дальше
Активация vSphere Supervisor превращает традиционную корпоративную виртуализацию в мощную мультиарендную облачную платформу. Предоставляя разработчикам нативное самообслуживание Kubernetes и одновременно оставляя ИТ-администраторам полный контроль над ресурсами и политиками, VKS ускоряет выпуск современных приложений без роста операционных рисков.
Учебные курсы: войдите в Learning@Broadcom через портал поддержки Broadcom, раздел «Education Portal», чтобы получить доступ к следующим курсам по VKS:
Если по проектам VKS нужна помощь, обратитесь к своему аккаунт-менеджеру Broadcom, чтобы узнать, чем могут помочь профессиональные сервисы VCF и партнёры, такие как TeraSky.
RSS
