Новости Статьи VMware Veeam StarWind vStack Microsoft Nakivo Citrix Symantec События Релизы Видео Контакты Авторы RSS
Виртуализация и виртуальные машины

Все самое нужное о виртуализации и облаках

Более 6300 заметок о VMware, AWS, Azure, Veeam, Kubernetes и других

VM Guru / Articles / VMware Project Pacific - подход VMware к объединению миров виртуальных машин и контейнеризованных приложений.

VMware Project Pacific - подход VMware к объединению миров виртуальных машин и контейнеризованных приложений.

VMware Project Pacific - подход VMware к объединению миров виртуальных машин и контейнеризованных приложений.

Автор: Александр Самойленко
Дата: 31/10/2019

Поддержите VM Guru!

USDT / TRC20, адрес: TCDP7d9hBM4dhU2mBt5oX2x5REPtq9QdU1




Статья:

Некоторое время назад мы рассказывали о продукте VMware Project Pacific, который был анонсирован на конференции VMworld 2019. Он представляет собой набор средств для преобразования среды VMware vSphere в нативную платформу для кластеров Kubernetes, который будет доступен в следующих релизах vSphere (сейчас находится в статусе технологического превью).

На самом деле, это часть семейства продуктов VMware Tanzu, которое объединяет в себе само средство Project Pacific для создания единой интегрированной среды контейнеров и виртуальных машин, а также Tanzu Mission Control - единую операционную консоль для кластеров Kubernetes, которая позволит контролировать все аспекты жизненного цикла приложений.

Project Pacific был одним из главных анонсов конференции VMworld в этом году, и VMware обращала на него особенное внимание. Это неудивительно - ведь VMware делает поддержку Kubernetes не для галочки. Тут дело в том, что многие пользователи планируют развертывание инфраструктуры контейнеризованных приложений на физической инфраструктуре - в этом случае не надо нести издержки на гипервизор и лицензии, а сами приложения в контейнерах работают быстро и имеют встроенные средства обеспечения доступности.

Но таким приложениям все равно приходится взаимодействовать с корпоративными сервисами, такими как базы данных, службы каталога и прочее. В этом случае получается такой микс из физической и виртуальной среды, который тяжело обслуживать (этим занимаются разные команды):

Поэтому у Project Pacific две основных цели:

  • Пересадить пользователей Kubernetes на платформу vSphere, которая дает функции отказоустойчивости, балансировки нагрузки и прочие полезности для виртуальных машин, где работают контейнеризованные приложения. Самое интересное, что в этом случае VMware заявляет поддержку таких сервисов, как NSX, vSAN и VVols для контейнеров приложений.
  • Объединить команды разработки, DevOps и администраторов vSphere единым рабочим процессом и техническими средствами по развертыванию и обслуживанию контейнеризованных приложений на платформе vSphere:

Причем основная концепция платформы Pacific - это предоставление всем этим пользователям средств (как в UI, так и через API), которые позволят выполнять задачи в декларативной форме, то есть формулировать потребность и через единую платформу оркестрации приложений получать результат. Сами же разработчики могут продолжить использовать нативный Kubernetes API для выполнения своих задач, используя декларативный синтаксис для управления облачными ресурсами, такими как виртуальные машины, хранилища и сети. При этом администратор vSphere видит инфраструктуру контейнеризованного приложения в vCenter (Kubernetes pods) как единый блок из нескольких виртуальных машин.

Если говорить об API, то Project Pacific расширяет существующую структуру API Kubernetes через механизм Custom Resource Definitions (CRD), предоставляя командам DevOps дополнительно доступ к vSphere API из инфраструктуры Kubernetes.

После внедрения Pacific в существующую инфраструктуру vSphere в объединенной среде появляются следующие компоненты:

  • Supervisor Cluster - это такой кластер из хостов ESXi, которые выступают как worker nodes. Чтобы сделать это возможным, VMware создала свою версию Kubelet, которая работает на уровне ядра ESXi и называется "Spherelet".

Supervisor Cluster в целом является Kubernetes-кластером, но с расширенными возможностями, которые предоставляет платформа vSphere через свой API.

В этом случае получается, что vSphere как бы работает на базе общего движка Kubernetes. Это еще означает и то, что администраторы приложений, когда хотят развернуть виртуальную машину, контейнер или другой ресурс, они просто создают соответствующий YAML-файл и применяют его через kubectl, как это обычно делается на платформе Kubernetes.

Пользователи Kubernetes выполняют операции с виртуальными машинами через Virtual Machine operator. Этот оператор поддерживает такие функции, как настройки RLS, Storage Policy и Compute policy. Также он предоставляет доступ к таким функциями Machine Class и Machine Image (он же элемент Content Library для администратора vSphere).

  • CRX Runtime - как некоторые из вас знают, виртуальная машина реализуется 2 процессами - VMM (virtual machine manager) и VMX (virtual machine executive). Специально для среды Kubernetes VMware сделала третью абстракцию - CRX (container runtime executive), которая и исполняет контейнеризованное приложение. Это такая мини-виртуальная машина с ядром Linux внутри (на базе ответвления Photon OS) и минимальными компонентами для исполнения контейнера внутри гостевой ОС. Из этой ВМ убрано все что только можно - особенно поддержка большинства внешних устройств, за счет чего такая машина работает очень быстро - VMware заявляет, что ее можно развернуть меньше, чем за секунду.

Такие виртуальные машины VMware называет "native pods", хост-серверы ESXi могут поддерживать до 1000 таких сред на одном физическом сервере. Надо сказать, что такие ВМ еще очень сильно паравиртуализованы, то есть внутри гостевой ОС на уровне ядра есть множество средств для прямой интеграции с гипервизором хоста в целях ускорения операций с такой машиной.

Для объектов CRX Runtime компания VMware сделала специальную процедуру Direct Boot. Если обычная виртуальная машина, когда загружается, проверяет наличие новых и существующих устройств, строит в памяти различные структуры и проводит другие сложные процессы, то для CRX создается статическая неизменяемая конфигурация с предсозданием структур в оперативной памяти, что позволяет ускорить загрузку такой ВМ в разы.

Интересная штука заключается в том, что VMware заявляет, что Kubernetes в среде Project Pacific работают на 30% быстрее, чем на обычных виртуальных машинах и на 8% быстрее, чем на физических серверах.

Объясняется это тем, что ESXi лучше работает с NUMA-архитектурой в плане производительности, чем традиционный Linux. Выглядит это как маркетинговый ход, но было бы интересно посмотреть потом на реальные результаты тестирования производительности.

Проблемы виртуальных машин с контейнерами и решение VMware

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

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

Для решения этой проблемы компания VMware использует концепцию пространств имен (namespaces) кластеров Kubernetes, которые включают в себя объекты различной природы - как CRX-виртуальные машины, так и обычные VMX-машины. Для такой сущности Project Pacific позволяет обеспечивать исполнение различных политик, таких как QoS, Security, Availability и прочее:

Для пространств имен можно, например, задавать лимиты потребления ресурсов:

Посмотреть, как работает концепция пространств имен, можно в видео ниже:

Guest clusters

В то время, как Supervisor Cluster - это платформа VMware vSphere, работающая на "платформе платформ" Kubernetes, гостевые кластеры - это уже кластеры Kubernetes, работающие на платформе vSphere. Сам Supervisor кластер не является, строго говоря, полностью совместимым кластером Kubernetes (ввиду измененных компонентов Kubelet), поэтому там теоретически могут возникуть проблемы с некоторыми контейнеризованными приложениями.

Чтобы минимизировать такие проблемы, VMware придумала подход Guest Kubernetes Cluster. В этом случае кластер Kubernetes работает в виртуальных машинах, работающих в рамках Supervisor Cluster. Guest Cluster - это самый обычный кластер Kubernetes в его неизменном виде, только работающий на виртуальных, а не физических машинах.

Чтобы понять, в чем отличие данных подходов, можно взглянуть на картинку ниже (гостевой кластер работает в рамках Namespace D):

Управление виртуальными машинами в таких кластерах происходит через open source компонент Cluster API, который позволяет контролировать жизненный цикл составляющих кластера. Со стороны разработчика такой кластер выглядит на 100% так же, как и обычный кластер. Оператор же имеет доступ к такому кластеру через плагины к vCenter:

Заключение

Некоторые из вас знают, что Project Pacific - это далеко не первый подход VMware к обслуживанию инфраструктуры Kubernetes на своей платформе (можно вспомнить Project Bonneville). Но впервые VMware делает не костыль, а полноценную, комплиментарную Kubernetes платформу, которая ориентирована на команды разработчиков и DevOps, отвечающие за инфраструктуру контейнеризованных приложений. В то же время, управлять инфраструктурой Project Pacific сможет и обычный администратор vSphere, поняв лишь основные моменты концепции пространств имен и способов организации Supervisor Cluster.

Между тем, у предложенной VMware архитектуры есть и не вполне очевидные минусы. Например, если обычных виртуальных машин в датацентре, как правило, десятки и сотни, то счет для native pods может пойти на тысячи - и тут администраторы vSphere могут утонуть в таком количестве управляемых разнородных объектов, несмотря на то, что они объединены в такие сущности, как пространства имен. Ведь управлять ими надо на разных уровнях - элементы кластеров vSphere, виртуальные сети, размещения на хранилищах и т.п.

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

Интересное:





Зал Славы Рекламодателя
Ближайшие события в области виртуализации:

Быстрый переход:
VMware Broadcom Offtopic Microsoft Veeam Cloud StarWind VMachines NAKIVO vStack Gartner Vinchin Nakivo IT-Grad Teradici VeeamON VMworld PowerCLI Citrix VSAN GDPR 5nine Hardware Nutanix vSphere RVTools Enterprise Security Code Cisco vGate SDRS Parallels IaaS HP VMFS VM Guru Oracle Red Hat Azure KVM VeeamOn 1cloud DevOps Docker Storage NVIDIA Partnership Dell Virtual SAN Virtualization VMTurbo vRealize VirtualBox Symantec Softline EMC Login VSI Xen Amazon NetApp VDI Linux Hyper-V IBM Google VSI Security Windows vCenter Webinar View VKernel Events Windows 7 Caravan Apple TPS Hyper9 Nicira Blogs IDC Sun VMC Xtravirt Novell IntelVT Сравнение VirtualIron XenServer CitrixXen ESXi ESX ThinApp Books P2V VMUG Private AI HCX vSAN VCPP VCF Workstation Labs Backup Explore vDefend Data Protection ONE Tanzu AI Intel Live Recovery VCP V2V Aria NSX DPU Update EUC Avi Community Skyline Host Client GenAI Chargeback Horizon SASE Workspace ONE Networking Ransomware Tools Performance Lifecycle Network AWS API USB SDDC Fusion Whitepaper SD-WAN Mobile SRM ARM HCI Converter Photon OS Operations VEBA App Volumes Certification VMConAWS Workspace Imager SplinterDB DRS SAN vMotion Open Source iSCSI Partners HA Monterey Kubernetes vForum Learning vRNI UAG Support Log Insight AMD vCSA NSX-T Graphics NVMe HCIBench SureBackup Docs Carbon Black vCloud Обучение Web Client vExpert OpenStack UEM CPU PKS vROPs Stencils Bug VTL Forum Video Update Manager VVols DR Cache Storage DRS Visio Manager Virtual Appliance PowerShell LSFS Client Datacenter Agent esxtop Book Photon Cloud Computing SSD Comparison Blast Encryption Nested XenDesktop VSA vNetwork SSO VMDK Appliance VUM HoL Automation Replication Desktop Fault Tolerance Vanguard SaaS Connector Event Free SQL Sponsorship Finance FT Containers XenApp Snapshots vGPU Auto Deploy SMB RDM Mirage XenClient MP iOS SC VMM VDP PCoIP RHEV vMA Award Licensing Logs Server Demo vCHS Calculator Бесплатно Beta Exchange MAP DaaS Hybrid Monitoring VPLEX UCS GPU SDK Poster VSPP Receiver VDI-in-a-Box Deduplication Reporter vShield ACE Go nworks iPad XCP Data Recovery Documentation Sizing Pricing VMotion Snapshot FlexPod VMsafe Enteprise Monitor vStorage Essentials Live Migration SCVMM TCO Studio AMD-V KB VirtualCenter NFS ThinPrint Director Memory SIOC Troubleshooting Stretched Bugs ESA Android Python Upgrade ML Hub Guardrails CLI Driver Foundation HPC Orchestrator Optimization SVMotion Diagram Ports Plugin Helpdesk VIC VDS Migration Air DPM Flex Mac SSH VAAI Heartbeat MSCS Composer
Полезные постеры:

Постер VMware vSphere PowerCLI 10

Постер VMware Cloud Foundation 4 Architecture

Постер VMware vCloud Networking

Постер VMware Cloud on AWS Logical Design Poster for Workload Mobility

Постер Azure VMware Solution Logical Design

Постер Google Cloud VMware Engine Logical Design

Постер Multi-Cloud Application Mobility

Постер VMware NSX (референсный):

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):

 

Популярные статьи:
Как установить VMware ESXi. Инструкция по установке сервера ESXi 4 из состава vSphere.

Включение поддержки технологии Intel VT на ноутбуках Sony VAIO, Toshiba, Lenovo и других.

Типы виртуальных дисков vmdk виртуальных машин на VMware vSphere / ESX 4.

Как работают виртуальные сети VLAN на хостах VMware ESX / ESXi.

Как настроить запуск виртуальных машин VMware Workstation и Server при старте Windows

Сравнение Oracle VirtualBox и VMware Workstation.

Что такое и как работает виртуальная машина Windows XP Mode в Windows 7.

Диски RDM (Raw Device Mapping) для виртуальных машин VMware vSphere и серверов ESX.

Работа с дисками виртуальных машин VMware.

Где скачать последнюю версию VMware Tools для виртуальных машин на VMware ESXi.

Подключение локальных SATA-дисков сервера VMware ESXi в качестве хранилищ RDM для виртуальных машин.

Как перенести виртуальную машину VirtualBox в VMware Workstation и обратно

Инфраструктура виртуальных десктопов VMware View 3 (VDI)

Как использовать возможности VMware vSphere Management Assistant (vMA).

Бесплатные утилиты для виртуальных машин на базе VMware ESX / ESXi.

Интервью:

Alessandro Perilli
virtualization.info
Основатель

Ратмир Тимашев
Veeam Software
Президент


Полезные ресурсы:

Последние 100 утилит VMware Labs

Новые возможности VMware vSphere 8.0 Update 1

Новые возможности VMware vSAN 8.0 Update 1

Новые документы от VMware

Новые технологии и продукты на VMware Explore 2022

Анонсы VMware весной 2021 года

Новые технологии и продукты на VMware VMworld 2021

Новые технологии и продукты на VMware VMworld 2020

Новые технологии и продукты на VMware VMworld Europe 2019

Новые технологии и продукты на VMware VMworld US 2019

Новые технологии и продукты на VMware VMworld 2019

Новые технологии и продукты на VMware VMworld 2018

Новые технологии и продукты на VMware VMworld 2017



Copyright VM Guru 2006 - 2025, Александр Самойленко. Правила перепечатки материалов.
vExpert Badge