Поскольку организации уделяют приоритетное внимание цифровой трансформации, они запускают смешанный набор приложений, используя как виртуальные машины, так и контейнеры для удовлетворения своих развивающихся инфраструктурных потребностей. Однако управление как традиционными, так и контейнерными приложениями создаёт сложность, операционную неэффективность и риски безопасности. Организациям необходима единая, упрощённая и безопасная платформа, которая соединит устаревшие и современные ИТ-среды.

VMware Cloud Foundation (VCF) предлагает решение — VCF предоставляет единую платформу со встроенной средой выполнения Kubernetes, которая оркестрирует управление Kubernetes, позволяя предприятиям запускать современные приложения наряду с традиционными рабочими нагрузками, а также включает сертифицированный дистрибутив Kubernetes, соответствующий upstream-стандартам. С помощью vSphere Supervisor VCF предоставляет пользователям доступ к самообслуживанию для полного набора облачных сервисов «из коробки». Это работает в составе VMware vSphere Kubernetes Service (VKS), который используется для развертывания кластеров Kubernetes и включает совместимый выпуск Kubernetes, а также стандартный пакет ключевых компонентов OSS. VCF предоставляет облачным администраторам и платформенным инженерам выбор интерфейсов, включая GUI, CLI и API, что позволяет командам работать эффективно и продуктивно, вместо того чтобы тратить время на изучение новых наборов инструментов.

VMware недавно представила ключевые улучшения в работе Kubernetes на VCF 9.0. Независимо от того, модернизируете ли вы устаревшие приложения или масштабируете современные рабочие нагрузки, VCF 9.0 предлагает единую платформу для создания и эксплуатации всех ваших рабочих нагрузок в большом масштабе — безопасно и эффективно.

Единая платформа для виртуальных машин и контейнеров

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

• Единый API для развёртывания и управления виртуальными машинами и контейнерами: единый API позволяет пользователям создавать, развёртывать и управлять как виртуальными машинами, так и кластерами Kubernetes. Это упрощает автоматизацию, снижает сложности интеграции и обеспечивает единые политики и средства безопасности для всех рабочих нагрузок. Благодаря единому API платформенные инженеры могут взаимодействовать с вычислительными ресурсами единообразно, устраняя необходимость в отдельных инструментах и снижая затраты на обучение.
• Сертифицированный релиз Kubernetes, соответствующий upstream, с независимой возможностью обновления: VCF использует полностью соответствующий upstream-дистрибутив Kubernetes, сертифицированный Cloud Native Computing Foundation (CNCF). Эта сертификация подтверждает, что реализация Kubernetes в vSphere соответствует программе Kubernetes Conformance Program, которая проверяет upstream API Kubernetes, рабочие нагрузки и инструменты экосистемы. Например, после обновления до VKS 3.4 вы сможете создавать и управлять кластерами Kubernetes с использованием последнего релиза vSphere Kubernetes 1.33, синхронизированного с последним релизом сообщества.

• Поддержка N-2 версий Kubernetes для гибкого развертывания: VKS поддерживает текущий релиз Kubernetes и две предыдущие основные версии. Это означает, что VKS обеспечивает совместимость сразу с тремя версиями Kubernetes в любой момент времени, что позволяет различным корпоративным командам использовать ту версию, которая необходима их приложениям, а также иметь контроль и гибкость для обновления в собственном темпе.

Упрощённые и эффективные операции

VCF снижает операционную сложность, повышает гибкость управления и позволяет командам оптимизировать распределение ресурсов между различными средами.

• Самообслуживание для доступа к облачным сервисам с управлением и контролем: благодаря модели доступа на основе ролей платформенные инженеры могут использовать возможности самообслуживания для выделения инфраструктурных ресурсов (вычислительные, хранилища и сети) и набора расширенных облачных сервисов в vSphere Supervisor, таких как VM Service, Network Services и Image Registry, по требованию, в то время как облачные администраторы сохраняют управление и контроль с помощью политик и квот ресурсов. Доступ по модели самообслуживания также поддерживает multi-tenancy с изолированными средами для разных команд и проектов.

• Независимое обновление vSphere Supervisor: VMware Cloud Foundation 9.0 предоставляет облачным администраторам дополнительную гибкость, позволяя обновлять vSphere Supervisor независимо от обновления vCenter. Благодаря асинхронным обновлениям снижается операционная сложность и обеспечивается большая гибкость для ИТ-команд в поддержании актуальности сред Kubernetes при сохранении стабильности всей инфраструктуры.
• Автомасштабирование кластеров Kubernetes: улучшения автомасштабирования позволяют динамически изменять количество рабочих узлов на основе метрик в реальном времени, обеспечивая как производительность, так и эффективность. Благодаря поддержке возможностей scale-down-to-zero и scale-up-from-zero кластеры могут автоматически уменьшаться до нуля рабочих узлов в периоды простоя и бесшовно масштабироваться вверх при возобновлении нагрузки. Такая масштабируемость по требованию оптимизирует использование инфраструктуры, снижает операционные затраты и обеспечивает выделение ресурсов только тогда, когда это необходимо.
• Workload zones для оптимизации распределения ресурсов: VCF 9.0 вводит повышенную гибкость благодаря зонам рабочих нагрузок (workload zones), позволяя облачным администраторам определять и управлять ими независимо, чтобы лучше согласовывать инфраструктурные ресурсы с требованиями рабочих нагрузок. vSphere Namespaces поддерживают как однозонные, так и многозонные конфигурации, что упрощает удовлетворение различных требований высокой доступности и сценариев аварийного восстановления. Облачные администраторы также могут расширять инфраструктуру частного облака, добавляя специализированные зоны, например выделяя ресурсы для нагрузок с интенсивным использованием GPU, что обеспечивает больший контроль, оптимизированное использование ресурсов и повышенную гибкость для различных развертываний.
• Интеграция управления кластерами VKS: управление кластерами VKS позволяет облачным администраторам эффективно управлять кластерами и группами кластеров в различных средах. Благодаря встроенным возможностям, таким как управление несколькими кластерами на уровне всей инфраструктуры (fleet-wide multicluster management) и детализированный контроль доступа, команды могут ускорить развертывание, снизить операционную сложность и обеспечить единообразную конфигурацию. Такой унифицированный подход упрощает операции Day 2 и усиливает управление и контроль всей инфраструктуры Kubernetes.

Повышенная безопасность

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

• Встроенная высокая доступность и надежность: VCF обеспечивает встроенную высокую доступность и надежность не только для виртуальных машин, но и для современных рабочих нагрузок. Благодаря интеграции VKS, VCF гарантирует, что контейнеризированные приложения получают те же возможности корпоративного уровня по обеспечению отказоустойчивости, такие как vSphere HA. vSAN предоставляет политики постоянного хранения, адаптированные для stateful-нагрузок Kubernetes, а NSX обеспечивает сетевую доступность и безопасное соединение между кластерами. Благодаря унифицированному управлению жизненным циклом VCF поддерживает стабильное время безотказной работы и операционную устойчивость как для виртуальных машин, так и для контейнеров, работающих на надежной инфраструктуре.
• Интеграция Istio Service Mesh: предоставляет расширенные возможности, такие как обнаружение сервисов, безопасное взаимодействие сервисов друг с другом, маршрутизация трафика и балансировка нагрузки, а также применение политик через интегрированные инструменты наблюдаемости. Благодаря таким функциям, как ingress и egress шлюзы, внедрение сбоев (fault injection), ограничение скорости запросов (rate limiting) и поддержка архитектуры нулевого доверия (zero-trust), Istio Service Mesh позволяет платформенным командам управлять сложными средами микросервисов с прозрачностью, отказоустойчивостью и соответствием требованиям, одновременно упрощая операционные процессы между кластерами Kubernetes.

• Режим OS FIPS для соответствия требованиям: новая опция конфигурации добавляет поддержку включения режима FIPS на уровне операционной системы, обеспечивая использование только криптографических модулей, прошедших валидацию FIPS, для соответствия строгим требованиям безопасности и комплаенса. Это улучшение даёт облачным администраторам гибкость в применении режима FIPS как для Linux, так и для Windows кластеров рабочих нагрузок, приводя среды Kubernetes в соответствие с федеральными и отраслевыми стандартами безопасности при сохранении операционного контроля над уровнем безопасности.
• Расширенная поддержка: в дальнейшем VMware планирует предоставлять Extended Support для определённых версий релизов vSphere Kubernetes (VKr), делая поддержку доступной в течение 24 месяцев с момента GA. Это позволит клиентам VCF оставаться на одной минорной версии Kubernetes значительно дольше, если это необходимо. Первым релизом с расширенной поддержкой станет VKr 1.33.

Кроме этого, что еще делает VCF таким особенным для запуска контейнеризированных рабочих нагрузок? VCF делает контейнеры полноценными участниками инфраструктуры наравне с виртуальными машинами, глубоко интегрируя Kubernetes в основной стек инфраструктуры с единым управлением жизненным циклом и рассматривая контейнеризированные рабочие нагрузки с тем же операционным приоритетом, управляемостью и функциональностью, что и виртуальные машины. В VCF контейнеры запускаются внутри виртуальных машин. Такая архитектура повышает безопасность за счёт дополнительного сильного уровня изоляции между рабочими нагрузками, при этом позволяя предприятиям применять существующие инструменты безопасности, политики соответствия требованиям и контроль доступа ко всем рабочим нагрузкам.

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

В последнем выпуске VMware vSphere Kubernetes Service (VKS) 3.6 в команде VMware сосредоточились именно на этих аспектах. Вместо того чтобы представлять длинный список несвязанных функций, этот релиз развивает платформу по нескольким ключевым операционным направлениям, которые действительно важны для платформенных инженеров и администраторов, запускающих Kubernetes в промышленной эксплуатации в крупном масштабе.

Кратко: что нового в VKS 3.6

VKS 3.6 включает улучшения в области корпоративной эксплуатации, производительности и гибкости экосистемы:

• Открытая и расширяемая сетевая экосистема – поддерживаемый путь для партнерских сетевых дополнений позволяет плагинам Container Network Interface (CNI) нативно интегрироваться с VKS, оставаясь в рамках жизненного цикла и поддержки.
• Настройка производительности для ресурсоемких по данным и чувствительных к задержкам нагрузок – декларативные профили TuneD позволяют безопасно настраивать параметры ядра и sysctl для баз данных и высокопроизводительных приложений без неподдерживаемых изменений на хостах.
• Выбор корпоративной ОС с поддержкой RHEL – узлы на базе Red Hat Enterprise Linux (RHEL), включая кластеры со смешанными операционными системами.

Kubernetes 1.35, созданный для корпоративной эксплуатации

VKS 3.6 добавляет поддержку Kubernetes версии 1.35, продолжая обязательство Broadcom по предоставлению Kubernetes с сертификацией CNCF, предназначенного для корпоративного использования. Как и в предыдущих релизах, Broadcom предоставляет расширенную поддержку на 24 месяца для каждой версии Kubernetes с перекрывающейся поддержкой версий. Это позволяет крупным организациям переводить команды на новые версии в собственном темпе, не вынуждая выполнять массовые обновления всего парка или проводить сжатые окна обслуживания.

Некоторые заметные нововведения в выпуске Kubernetes 1.35 включают:

• Настраиваемая параллельность для поэтапных обновлений StatefulSet с параметром maxUnavailable – теперь платформенные команды могут одновременно выводить из работы несколько Pod’ов во время обновлений StatefulSet, контролируя уровень нарушения работы для stateful-нагрузок и сокращая время развертывания.
• Улучшенная осведомленность о топологии для нагрузок – приложения могут безопасно использовать информацию о топологии узлов, повышая понимание своего расположения в инфраструктуре, что полезно для чувствительных к задержкам и ресурсоемких по данным приложений.
• Модернизированные основы хранения данных – такие усовершенствования, как тома на основе OCI, делают потребление хранилища в Kubernetes более согласованным с контейнерно-ориентированными моделями поставки.

В то же время Kubernetes продолжает удалять или объявлять устаревшими некоторые функции. VKS следует срокам устаревания upstream-версии, при этом предоставляя расширенную поддержку и четкие пути миграции, давая платформенным командам время на адаптацию без внезапных сбоев. Такой баланс сохраняет соответствие upstream-версии, избегая при этом разрушительных и массовых неожиданностей.

Более плавные обновления и более безопасные операции второго дня

Именно в процессе обновлений платформы Kubernetes чаще всего испытывают наибольшую нагрузку. На практике сбои при обновлении редко вызваны самим Kubernetes, а чаще конфигурацией и интеграциями. Политики, admission webhooks, а также инструменты безопасности или управления могут непреднамеренно блокировать операции жизненного цикла.

Развивая ранее внедренные предварительные проверки PodDisruptionBudget, VKS 3.6 расширяет проверки готовности к обновлению, чтобы выявлять распространенные конфликты конфигурации до начала обновления. Вместо обнаружения блокирующих факторов в середине процесса обновления платформенные команды могут заранее выявить и устранить проблемы до окна обслуживания, снижая количество неудачных обновлений и незапланированных сбоев. Эти проверки выполняются непрерывно, выявляя риски обновления через условие SystemCheckSucceeded, а не только во время выполнения обновления.

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

Производительность и ресурсоемкие по данным нагрузки

Запуск баз данных и других stateful-платформ в Kubernetes часто требует настройки ядра и параметров узлов, выходящих за пределы стандартных значений. Во многих средах команды полагались на ручные изменения узлов или специально собранные образы для удовлетворения этих требований. В моделях управляемого Kubernetes такие изменения, как правило, должны быть выражены декларативно (например, через утвержденные механизмы конфигурации, привилегированные DaemonSet’ы или стандартизированные образы), чтобы сохраняться при обновлениях и замене узлов.

VKS 3.6 вводит поддерживаемые профили TuneD, позволяя разработчикам декларативно настраивать ядро Linux (включая параметры sysctl и sysfs) через ресурсы Kubernetes. Профили могут быть привязаны к определенным пулам узлов, обеспечивая оптимизацию под конкретные нагрузки в рамках одного кластера.

Это делает распространенные сценарии простыми и поддерживаемыми, например:

• Оптимизация узлов для высокопроизводительных сетевых нагрузок
• Настройка поведения памяти для баз данных и систем кэширования
• Корректировка параметров ядра для нагрузок, чувствительных к задержкам

Встроенный профиль обеспечивает безопасную отправную точку конфигурации, готовую для корпоративного использования, а пользовательские профили позволяют при необходимости сделать более глубокую специализацию. Результат — согласованная, безопасная при обновлениях настройка производительности, применяемая через стандартные рабочие процессы Kubernetes, без ручной конфигурации узлов и без дрейфа конфигурации.

Безопасность, соответствие требованиям и управление

VKS 3.6 упрощает поддержку нормативных и требований безопасности без жесткой фиксации кластеров в универсальных схемах усиленной защиты. Расширенная конфигурация компонентов Kubernetes позволяет платформенным командам настраивать уровень соответствия требованиям для каждой нагрузки и среды. Команды могут применять более строгие меры там, где это требуется, ослаблять их при необходимости и постепенно развивать конфигурации вместо пересоздания кластеров для изменения политики.

В этом выпуске также упрощено управление профилями AppArmor. Администраторы теперь могут определять профили AppArmor как Custom Resources и автоматически загружать их и поддерживать синхронизацию на всех рабочих узлах кластера или в отдельных пулах узлов. Это позволяет настраивать каждый workload с требуемым профилем AppArmor без сложности конфигурации на уровне узлов.

VKS 3.6 также повышает операционную автономность. Владельцы workload-кластеров теперь могут генерировать пакеты поддержки VKS без учетных данных vCenter, устраняя необходимость повышенного инфраструктурного доступа при устранении неполадок. Это снижает трения между командами Kubernetes и инфраструктуры, сохраняя принцип наименьших привилегий.

Пользовательский опыт платформы и развитие экосистемы

Корпоративные платформы Kubernetes требуют как сильных настроек по умолчанию, так и реального выбора в экосистеме. Чрезмерная жесткость замедляет внедрение; избыточная свобода создает операционные риски. Этот релиз продвигает баланс вперед, открывая платформу для партнерских инноваций и поддерживая возможность использования собственных инструментов заказчика.

Ваша сеть — ваш выбор

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

Команды могут сохранить сетевой стек, которому уже доверяют, а партнеры получают стабильную и поддерживаемую основу для разработки. Это снижает трения при миграции существующих сред Kubernetes на VKS и со временем расширяет набор доступных сетевых возможностей.

Ваш фаервол — ваш выбор

VKS 3.6 вводит централизованное управление правилами сетевого экрана на уровне узлов через API для всех поддерживаемых операционных систем. Теперь платформенные команды могут открывать необходимые порты для HostPorts и сервисов NodePort через конфигурацию кластера, вместо использования привилегированных init-контейнеров или DaemonSet’ов на каждом узле.

Перенос управления файрволом с отдельных нагрузок на уровень кластера упрощает конфигурацию, повышает аудируемость и снижает риски безопасности, связанные с привилегированными компонентами. Для Linux-узлов VKS 3.6 также добавляет поддержку backend nftables для kube-proxy, обеспечивая лучшую производительность и масштабируемость по сравнению с реализацией по умолчанию на основе iptables.

Ваша ОС — ваш выбор

Red Hat Enterprise Linux (RHEL) 9 присоединяется к Photon OS 5, Ubuntu 22.04 и 24.04, а также Windows Server 2022 в качестве поддерживаемых операционных систем для узлов кластера VKS. RHEL может использоваться как для узлов control plane, так и для рабочих узлов.

Для поддержки разнообразных требований приложений в рамках одного кластера VKS продолжает позволять различным пулам узлов работать на разных операционных системах. Пулы узлов RHEL могут существовать наряду с узлами Windows, Ubuntu и Photon, обеспечивая гетерогенные кластеры и постепенную миграцию ОС со временем.

VKS 3.6 также включает улучшенные инструменты для сборки пользовательских образов узлов для всех поддерживаемых операционных систем. Image Baker предназначен для сред с ограниченной сетевой связностью, работает независимо от vCenter для снижения инфраструктурных зависимостей и поставляется как плагин CLI VMware Cloud Foundation (VCF). Broadcom продолжает предоставлять готовые образы для Photon и Ubuntu.

Kubernetes — с меньшим количеством неожиданностей

Этот релиз сосредоточен на тех аспектах Kubernetes, которые наиболее важны после первого дня. Обновления становятся более предсказуемыми, настройка производительности для ресурсоемких нагрузок упрощается, среды на базе RHEL получают четкий путь миграции, а сетевая подсистема открывается для растущей экосистемы проверенных партнеров.

В совокупности эти изменения приводят Kubernetes в соответствие с тем, как заказчики реально используют его в промышленной эксплуатации: стандартизированно, с управлением на базе политик и с интеграцией с существующими инструментами и платформами.

Для платформенных команд, работающих в масштабе, результат прост: меньше неожиданностей, ниже операционные риски и более надежная основа для дальнейшего развития.

Более подробно о VMware vSphere Kubernetes Service 3.6 можно узнать на странице продукта.

Службы VMware vSphere Kubernetes Service (VKS) версии 3.5 появились в общем доступе. Этот новый выпуск обеспечивает 24-месячную поддержку для каждой минорной версии Kubernetes, начиная с vSphere Kubernetes release (VKr) 1.34. Ранее, в июне 2025 года, VMware объявила о 24-месячной поддержке выпуска vSphere Kubernetes (VKr) 1.33. Это изменение обеспечивает командам, управляющим платформой, большую стабильность и гибкость при планировании обновлений.

VKS 3.5 также включает ряд улучшений, направленных на повышение операционной согласованности и улучшение управления жизненным циклом, включая детализированные средства конфигурации основных компонентов Kubernetes, декларативную модель управления надстройками и встроенную генерацию пакетов поддержки напрямую из интерфейса командной строки VCF CLI. Кроме того, новые защитные механизмы при обновлениях — такие как проверка PodDisruptionBudget и проверки совместимости — помогают обеспечить более безопасные и предсказуемые обновления кластеров.

В совокупности эти усовершенствования повышают надежность, операционную эффективность и качество управления Kubernetes-средами на этапе эксплуатации (Day-2) в масштабах предприятия.

Выпуск vSphere Kubernetes (VKr) 1.34

VKS 3.5 добавляет поддержку VKr 1.34. Каждая минорная версия vSphere Kubernetes теперь поддерживается в течение 24 месяцев с момента выпуска. Это снижает давление, связанное с обновлениями, стабилизирует рабочие среды и позволяет командам сосредоточиться на создании ценности, а не на постоянном планировании апгрейдов. Команды, которым нужен быстрый доступ к последним возможностям Kubernetes, могут оперативно переходить на новые версии. Те, кто предпочитает стабильную среду на длительный срок, теперь могут работать в этом режиме с уверенностью. VKS 3.5 поддерживает оба подхода к эксплуатации.

Динамическое распределение ресурсов (Dynamic Resource Allocation, DRA)

Функция DRA получила статус «стабильной» в основной ветке Kubernetes 1.34. Эта возможность позволяет администраторам централизованно классифицировать аппаратные ресурсы, такие как GPU, с помощью объекта DeviceClass. Это обеспечивает надежное и предсказуемое размещение Pod'ов на узлах с требуемым классом оборудования.

DRA повышает эффективность использования устройств, позволяя делить ресурсы между приложениями по декларативному принципу, аналогично динамическому выделению томов (Dynamic Volume Provisioning). Механизм DRA решает проблемы случайного распределения и неполного использования ресурсов. Пользователи могут выполнять точную фильтрацию, запрашивая конкретные устройства с помощью ResourceClaimsTemplates и ResourceClaims при развертывании рабочих нагрузок.

DRA также позволяет совместно использовать GPU между несколькими Pod'ами или контейнерами. Рабочие нагрузки можно настроить так, чтобы выбирать GPU-устройство с помощью Common Expression Language (CEL) и запросов ResourceSlice, что обеспечивает более эффективное использование по сравнению с count-based запросами.

Расширенные возможности конфигурации компонентов кластера Kubernetes

VKS 3.5 предоставляет гибкость для управления более чем 35 параметрами конфигурации компонентов Kubernetes, таких как kubelet, apiserver и etcd. Эти настройки позволяют командам платформ оптимизировать различные аспекты работы кластеров в соответствии с требованиями их рабочих нагрузок. Полный список доступных параметров конфигурации приведён в документации к продукту. Ниже приведён краткий обзор областей конфигурации, которые предлагает VKS 3.5:

Cluster API v1beta2 для улучшенного управления кластерами Kubernetes

VKS 3.5 включает Cluster API v1beta2 (CAPI v1.11.1), который вносит ряд изменений и улучшений в версии API для ресурсов по сравнению с v1beta1. Полный список улучшений можно найти в Release Notes для CAPI.

Для обеспечения плавного перехода все новые и существующие кластеры, созданные с использованием прежнего API v1beta1, будут автоматически преобразованы в API v1beta2 обновлёнными контроллерами Cluster API. В дальнейшем рекомендуется использовать API v1beta2 для управления жизненным циклом (LCM) кластеров Kubernetes.

Версия API v1beta2 является важным шагом на пути к выпуску стабильной версии v1. Основные улучшения включают:

• Расширенные возможности отслеживания состояния ресурсов, обеспечивающие лучшую наблюдаемость.
• Исправления на основе отзывов клиентов и инженеров с реальных внедрений.

Предотвращение сбоев обновлений из-за неверно настроенного PodDisruptionBudget

Pod Disruption Budget (PDB) — это объект Kubernetes, который помогает поддерживать доступность приложения во время плановых операций (например, обслуживания узлов, обновлений или масштабирования). Он гарантирует, что минимальное количество Pod’ов останется активным во время таких событий. Однако неправильно настроенные PDB могут блокировать обновления кластера.

VKS 3.5 вводит механизмы защиты (guardrails) для выявления ошибок конфигурации PDB, которые могут привести к зависанию обновлений или других операций жизненного цикла. Система блокирует обновление кластера, если обнаруживает, что PDB не допускает никаких прерываний.

Для повышения надёжности и успешности обновлений введено новое условие SystemChecksSucceeded в объект Cluster. Оно позволяет пользователям видеть готовность кластера к обновлению, в частности относительно конфигураций PDB.

Ключевые преимущества новой проверки:

• Проактивная блокировка обновлений — система обнаруживает PDB, препятствующие выселению Pod’ов, и останавливает обновление до его начала.
• Более чёткая диагностика проблем — параметр SystemChecksSucceeded устанавливается в false, если у любого PDB значение allowedDisruptions меньше или равно 0, что указывает на риск простоев.
• Планирование обновлений — позволяет заранее устранить ошибки конфигурации PDB до начала обновления.

Примечание: любой PDB, не связанный с Pod’ами (например, из-за неправильного селектора), также будет иметь allowedDisruptions = 0 и, следовательно, заблокирует обновление.

Упрощённые операции: CLI, управление надстройками и инструменты поддержки

Управление надстройками (Add-On Management)

VKS 3.5 упрощает эксплуатационные операции, включая управление жизненным циклом надстроек (add-ons) и создание пакетов поддержки. Новая функция VKS Add-On Management объединяет установку, обновление и настройку стандартных пакетов, предлагая:

• Единый метод для всех операций с пакетами, декларативный API и предварительные проверки совместимости.
• Возможность управления стандартными пакетами VKS через Supervisor Namespace (установка, обновления, конфигурации) — доступно через VKS-M 9.0.1 или новый плагин ‘addon’ в VCF CLI.
• Упрощённую установку Cluster Autoscaler с возможностью автоматического обновления при апгрейде кластера.
• Управление установками и обновлениями через декларативные API (AddonInstall, AddonConfig) с помощью Argo CD или других GitOps-контроллеров. Это обеспечивает версионируемое и повторяемое развертывание надстроек с улучшенной трассируемостью и согласованностью.
• Возможность настройки Addon Repository во всех кластерах VKS с помощью API AddonRepository / AddonRepositoryInstall, включая случаи с приватными регистрами.
  По умолчанию встроенный репозиторий VKS Standard Package устанавливается из пакета VKS (версия v2025.10.22 для релиза VKS 3.5.0).
• Во время обновлений кластеров VKS выполняет предварительные проверки совместимости надстроек и обновляет их до последних поддерживаемых версий. Если проверка не пройдена — обновление блокируется. При установке или обновлении надстроек выполняются дополнительные проверки, включая проверку на дублирование пакетов и анализ зависимостей.
• Упрощённое обнаружение новых версий и метаданных совместимости для Add-on Releases.

Интегрированный сборщик пакетов поддержки (Support Bundler) в VCF CLI

VKS 3.5 включает VKS Cluster Support Bundler непосредственно в VCF CLI, что значительно упрощает процесс сбора диагностической информации о кластерах. Теперь пользователи могут собирать всю необходимую информацию с помощью команды vcf cluster support-bundle, без необходимости загружать отдельный инструмент.

Основные улучшения здесь:

• Существенное уменьшение размера выходного файла.
• Селективный сбор логов — только с узлов control plane, для более быстрой и точной диагностики.
• Интегрированный сбор сетевых логов, что помогает анализировать сетевые проблемы и получить целостную картину состояния кластера.

Полезные ссылки:

• VKS 3.5 Release Notes
• VKS 3.5 Documentation
• Kubernetes 1.34 Upstream Release Notes
• Support Bundler Documentation
• Cluster API Upstream Release Notes

Возможно, вас смутило выражение «ВМ на голом железе» в заголовке. Но это не опечатка: в этом посте мы расскажем о двух ключевых вещах, а основная тема, которую мы рассмотрим — это запуск виртуальных машин (ВМ) как контейнеров в среде Kubernetes. Поэтому в этой статье будет две основные цели:

1. Раскрыть преимущества запуска ВМ и контейнеров на единой платформе. Да, этой единой платформой является служба vSphere Kubernetes Service в VMware Cloud Foundation.

2. Объяснить, почему запуск ВМ и контейнеров на «голом железе» имеет реальные недостатки для предприятий, чтобы вы могли сделать собственные выводы. Мы приведем факты, которые вы сможете проверить независимо от каких-либо поставщиков.

Начнём с того, что разберёмся, что такое служба vSphere Kubernetes Service (далее — VKS) и что она предлагает.

Что такое VKS?

VKS — это промышленный Kubernetes-рантайм от VMware, сертифицированный и совместимый с CNCF (Cloud Native Computing Foundation). Он включён в состав VMware Cloud Foundation (то есть доплачивать за него не нужно), поддерживается и уже доступен.

Если вы сейчас используете Kubernetes у одного из крупных облачных провайдеров или раньше пробовали запускать Kubernetes на vSphere, VKS стоит вашего внимания. Он изначально разрабатывался с учётом потребностей крупных предприятий — включая более простой процесс установки, возможности самообслуживания и наличие всех привычных компонентов, которые ожидают пользователи Kubernetes.

Это даёт клиентам беспрецедентные возможности запускать промышленный Kubernetes у себя на площадке — в более удобной и масштабируемой форме.

Кроме того, для приверженцев философии FOSS (свободного и открытого ПО) есть над чем задуматься:

• За последнее десятилетие VMware входила в тройку крупнейших участников по объёму вклада в исходный код Kubernetes.
• Соответствие стандарту CNCF означает, что VMware придерживается открытых стандартов. Это важно, поскольку вы получаете гибкость и можете рассчитывать на определённый набор компонентов в платформе, не попадая в ловушку специфических для конкретного вендора решений и ограничений.
• VKS развивался с тех пор, как VMware приобрела компанию Pivotal в 2019 году, так что это далеко не «версия 1.0».

Несколько слов о vSphere Supervisor

Чтобы начать использовать VKS, вам нужно установить vSphere Supervisor. Он предоставляет, помимо прочего, возможность использовать все преимущества VMware, а также предлагает компоненты, совместимые с Kubernetes.

Один из примеров: как только vSphere Supervisor будет запущен, вы создаёте пространство имен Kubernetes Namespace, которое будет сопоставлено с пулом ресурсов vSphere. Внутри кластера Kubernetes Namespace будет вести себя так, как и положено, но при этом его ресурсами можно также управлять через интерфейс vSphere для пулов ресурсов.

Другой пример: управляющие и рабочие узлы Kubernetes в буквальном смысле являются виртуальными машинами (ВМ). Это важно для следующего момента, который будет раскрыт далее.

Обратите внимание: «традиционные» виртуальные машины продолжают работать бок о бок с вашими кластерами Kubernetes. Именно такую возможность даёт VKS в составе VMware Cloud Foundation (VCF).

Если вы запомните только одну вещь из этого поста, пусть это будет следующее:

Вашим текущим инженерам VMware не нужно обладать специальными знаниями о Kubernetes, чтобы управлять как виртуальными машинами, так и потребляемыми компонентами Kubernetes или самими кластерами. Инженеры платформ или разработчики могут получать доступ через инструменты самообслуживания, а инженеры по виртуализации продолжают управлять инфраструктурой так же, как и раньше.

Развенчиваем миф о запуске ВМ и контейнеров на «голом железе»

Интересный факт: когда вы разворачиваете кластер Kubernetes у гиперскейлера (большой публичный облачный провайдер), этот кластер на самом деле работает на наборе виртуальных машин под управлением гипервизора. Это справедливо для всех гиперскейлеров на момент написания статьи. Контейнеры, в итоге, не работают напрямую на голом железе — такого просто не существует. VMware подчеркивает это, потому что они видели, как и C-level руководители, и разработчики, и даже инженеры платформ (которые вроде бы должны это знать) были поражены этим фактом.

Более того, не упомянуть ещё один момент было бы упущением: когда вы создаёте виртуальную машину у гиперскейлера, она тоже работает на гипервизоре. То, что вы его не видите — не значит, что его нет.

В результате организации начинают задумываться о:

• запуске контейнеров напрямую на голом железе;
• запуске традиционных ВМ в виде контейнеров на голом железе.

Начнём с первого: запуск контейнеров на голом железе мог бы быть темой горячих споров… если бы сейчас был 2017 год. Эта дискуссия в индустрии уже была, и виртуализированная платформа с Kubernetes одержала убедительную победу.

Почему? В числе причин: более простое управление, масштабируемость, гибкость, меньшая стоимость и практически полное отсутствие потерь в производительности. Не сказать, что у контейнеров на железе совсем нет применения, но для 98% организаций запуск контейнеров на гипервизоре оказался более выгодным решением.

Простой пример: вспомните, какие возможности даёт вам архитектура отказоустойчивости vSphere HA — ваши контейнеры в виде ВМ отлично вписываются в эту архитектуру уже на этом одном примере.

Или другими словами: запуск контейнеров рядом с ВМ на VMware обходится дешевле, при этом вы сохраняете тот же уровень отказоустойчивости, надёжности и высокой производительности, к которому вы привыкли для технологий VMware.

А как насчёт запуска ВМ как контейнеров? Во-первых, у VMware есть доказательства того, что их платформа обеспечивает лучшую производительность и масштабируемость. Например, при создании ВМ через VM Service, инженеру не нужно разбираться в деталях и компонентах Kubernetes. Обычно это лучшее решение, потому что командам не нужно проходить дорогостоящее переобучение или нанимать более дорогих специалистов, чтобы запускать ВМ внутри кластера Kubernetes.

Когда вы увидите, насколько просто получить низкую совокупную стоимость владения (TCO) с промышленной виртуализацией, которую легко внедрить (и снова напомним про vSphere HA, которая настраивается буквально двумя кликами), становится очевидно: запуск VKS в составе VCF — разумное и эффективное решение.

Источник.

Недавно было объявлено о доступности VMware vSphere Kubernetes Service (VKS) 3.3 (ранее известного как решение VMware Tanzu Kubernetes Grid (TKG) Service), а также о выпуске vSphere Kubernetes release (VKr) 1.32, ранее называвшегося Tanzu Kubernetes release. В этом выпуске представлены важные функции и улучшения, направленные на повышение безопасности, масштабируемости и управления кластерами.

Поддержка актуального релиза Kubernetes 1.32

С выпуском VKS 3.3 теперь возможно развертывание рабочих кластеров на базе VKr 1.32, основанного на последнем минорном выпуске Kubernetes 1.32. Использование последних версий Kubernetes обеспечивает безопасность, высокую производительность и совместимость с современными приложениями. vSphere Kubernetes release 1.32 обеспечивает повышение эффективности, безопасности и гибкости рабочих нагрузок.

Гибкость активации режима FIPS на уровне ОС

Данный выпуск вводит новую возможность настройки режима FIPS на уровне операционной системы, гарантируя использование только одобренных FIPS криптографических модулей. Администраторы могут самостоятельно решить, активировать ли режим FIPS для кластеров на Linux и Windows. Для активации функции необходимо настроить переменную класса кластера 'osConfiguration'. Для включения данной функции в Ubuntu-версии vSphere Kubernetes может потребоваться подписка Ubuntu Pro. Подробная информация представлена в документации.

Если ваша организация работает в регулируемой отрасли (государственные учреждения, финансы, здравоохранение и др.), соответствие стандартам FIPS необходимо для соблюдения требований безопасности и снижения рисков несоответствия.

Переход на Cluster API

Как было объявлено в документации к выпуску VKS 3.2, API TanzuKubernetesCluster будет удалён не ранее июня 2025 года. VKS 3.3 вводит упрощённый механизм миграции кластеров с TKC на Cluster API для развертывания и настройки рабочих кластеров. Переход на Cluster API обеспечивает лучшую автоматизацию и будущую совместимость. Рекомендуется заранее планировать переход на Cluster API, чтобы избежать сбоев после удаления TKC API.

Другие важные улучшения

• Интеграция узлов Windows с Active Directory (поддержка gMSA) – начиная с VKS 3.3, вы можете подключать узлы Windows к локальной службе Active Directory с использованием учётных записей группового управления (Group Managed Service Accounts, gMSA) для безопасной аутентификации. Можно автоматизировать подключение узлов Windows к домену Active Directory в организационных подразделениях и добавлять их в группу безопасности, управляющую доступом к gMSA. Это упрощает интеграцию рабочих нагрузок Kubernetes на базе Windows в предприятиях, использующих Active Directory, повышая безопасность и операционную эффективность. Подробности можно найти в документации.

• Автомасштабирование кластеров в обе стороны – VKS 3.3 позволяет масштабировать кластеры от нуля до любого количества рабочих узлов при использовании VKr версии 1.31.4 и новее. Ранее эта функция была недоступна со времен появления Cluster Autoscaler в vSphere 8.0 U3. Также это способствует экономии средств и оптимизации ресурсов, позволяя динамически масштабировать рабочие нагрузки до нуля в неиспользуемый период и эффективно справляться с сезонными всплесками активности.
• Механизмы для упрощения обновления (Guard Rails) - обновления через несколько версий могут быть затруднены, особенно с устаревшими ресурсами. В версии VKr 1.31.1 в Antrea 2.1 некоторые CRD были объявлены устаревшими и должны быть заменены на новые версии.
  • Обновление до VKr 1.31.1 – перед обновлением обязательно выполнить минимальные ручные инструкции, указанные в Release Notes 1.31.1, иначе обновление может завершиться неудачно.
  • Обновление до VKr 1.31.4 – При обновлении до версии VKr 1.31.4 устаревшие CRD Antrea автоматически заменяются новыми версиями, поэтому ручные действия не требуются.
• В VKS 3.3 встроены механизмы защиты от потенциальных ошибок при обновлении. Если рабочий кластер использует Kubernetes версии 1.30.x и обновлен до VKS 3.3, обновление до Kubernetes версии 1.31.1 заблокировано. Вместо этого рекомендуется сразу перейти на версию 1.31.4, которая не требует ручных действий. Если рабочий кластер уже на версии VKr 1.31.1, то обновление до VKS 3.3 заблокировано до предварительного обновления до VKr 1.31.4.

Заключение

vSphere Kubernetes Service 3.3 предлагает повышенную безопасность, улучшенную масштабируемость, оптимизацию расходов и усовершенствованное управление жизненным циклом кластеров для оптимизации Kubernetes-сред клиентов. О работе продукта также можно почитать вот эту полезную статью.