Развернуть кластер Kubernetes может даже неопытный администратор за пару часов. Именно это делает решение таким привлекательным, тем более, что оно условно бесплатно. А на практике? В своем твите представитель американской компании рассказал, что «подъем» Kubernetes обошелся примерно в $1 млн. Столько составила цена развертывания и настройки ПО, когда компания переложила трудозатраты своей команды в доллары. В комментариях разгорелась жаркая дискуссия на тему, как избежать космических трат при установке и управлении Kubernetes. Наше мнение радикально — обратить внимание на вендорские решения. Например, на семейство продуктов Tanzu от VMware.
VMware Tanzu — это не один продукт, а большое семейство, состоящее приблизительно из 10 разных продуктов. Оно покрывает полный жизненный цикл микросервисного приложения от создания и запуска до последующего управления.
На сегодня продукты Tanzu распространяются в трех основных редакциях:
Отдельно обращаем внимание на названия продуктов, которые, возможно, вам уже встречались. Эти продукты VMware так или иначе связаны с запуском и последующей эксплуатацией кластеров Kubernetes. Все продукты семейства Tanzu мы рассматривать не будем, сконцентрируемся исключительно на вопросах инфраструктуры.
Если для компании мир контейнеров в новинку, стоит задача быстро запустить микросервисное приложение, и при этом организация хорошо знакома с платформой виртуализации VMware vSphere, мы рекомендуем обратить внимание на VMware vSphere with Tanzu.
Основная интересная фишка в VMware vSphere with Tanzu — возможность запускать и управлять контейнерами точно так же, как и всем давно знакомыми виртуальными машинами. Эта технология называется vSphere Pods. vSphere with Tanzu включается на уровне кластера VMware через vSphere Client. В процессе подготовки разворачивается Control Plane для кластера Kubernetes (служба Workload Control Plane — WCP), в терминологии вендора — Supervisor Cluster. А на гипервизоры VMware ESXi устанавливаются агенты Spherelet, которые превращают их в worker nodes Kubernetes.
Сразу же «из коробки» для работы с контейнерами доступны такие опции:
Namespace — это логический объект, который создается на Supervisor Cluster и полностью соответствует объекту Namespace в Kubernetes. Он предназначен для разделения вычислительных и сетевых ресурсов кластера vSphere и прав доступа между разными проектами. Для предоставления доступа администратор использует стандартную ролевую модель, встроенную в платформу виртуализации VMware vSphere. Он может предоставить разработчикам URL для подключения к Supervisor Cluster, где они будут создавать контейнеры в назначенных им пространствах (Namespace).
Важно отметить, что для vSphere Pods обязательно нужно использовать дополнительный продукт VMware NSX-T, который создает программно-определяемую сеть (в терминологии Kubernetes — NSX-T выполняет роль CNI Plugin). С помощью него решаются все вопросы работы сети в контейнерных платформах и приятно, что большинство аспектов закрываются автоматически, без участия администратора. Например, это сетевое взаимодействие между vSphere Pods (East-West трафик), доступ к приложениям, запущенным в контейнерах (North-South трафик), политики безопасности, стандартные инструменты сетевой диагностики и сетевая балансировка (NSX-T обеспечивает создание объектов service с типом Load Balancer и Ingress).
Что происходит под капотом? vSphere Pods — это специальные процессы, работающие на гипервизоре параллельно с виртуальными машинами. Будет правильно назвать vSphere Pods специально подготовленной виртуальной машиной с минимально необходимыми для ее работы виртуальными устройствами и оптимизированным дистрибутивом Linux. Такой процесс запускается за несколько секунд и обеспечивает работу Kubernetes Pod, в котором работают один или несколько контейнеров.
Если по каким-то причинам vSphere Pod недостаточно и разработчику нужно управлять кластером Kubernetes, VMware vSphere with Tanzu позволяет создавать «вложенные кластеры» Tanzu Kubernetes Cluster (TKC). Для управления жизненным циклом кластеров Kubernetes в VMware vSphere with Tanzu используется проект Cluster API. Плюс в этом сценарии не обязательно использовать VMware NSX-T — можно обойтись встроенным CNI на базе проекта Antrea.
Общая схема конструкции будет выглядеть вот так:
А на нашем стенде в интерфейсе управления VMware vCenter это выглядит следующим образом:
По сравнению с бесплатными конструкторами на базе Open Source VMware vSphere with Tanzu обладает многими плюсами. Разделим их на несколько категорий.
VMware использует upstream-версию Kubernetes, а значит, можно не опасаться за совместимость приложений.
Использование VMware NSX-T в качестве CNI обеспечивает полную автоматизацию сетевого стека для Kubernetes: сетевую связность, права доступа, балансировку трафика, межсетевое экранирование и сетевой мониторинг. В качестве альтернативы во вложенных кластерах предлагается использовать проект Antrea, контрибуторами которого являются крупные вендоры, включая VMware. Это защищает проект от того, что он неожиданно прекратит свое развитие по причине нехватки внимания от сообщества.
С точки зрения хранения данных VMware vSphere with Tanzu использует механизм First Class Disk (FCD). FCD представляет собой диски VMDK, которые не принадлежат ни одной виртуальной машине. Для администратора Kubernetes каждый FCD — это Persistent Volume. В vSphere Client есть специальная вкладка, где отображаются все FCD и метки (label), которые были присвоены администратором Kubernetes при запросе Persistent Volume.
В качестве системы хранения подходят все поддерживаемые vSphere платформы (SAN, VMware vSAN, NFS). Если используется vSAN, можно также создавать файловые хранилища для контейнеров на базе NFS. Такие хранилища допустимо подключать одновременно к нескольким контейнерам.
vSphere Client — привычный для многих заказчиков графический интерфейс, в котором сочетается управление классическими виртуальными машинами, контейнерами и вложенными кластерами Kubernetes. Этого интерфейса достаточно для того, чтобы автоматизировать развертывание необходимых компонентов, упростить такие операции второго дня по работе с Kubernetes, как, например, масштабирование или обновление кластеров.
А для администраторов Kubernetes доступен привычный инструмент — kubectl.
В платформу виртуализации встроены штатные средства высокой доступности и балансировки нагрузки (vSphere HA\DRS), механизмы мониторинга и набор инструментов по обеспечению информационной безопасности.
И важно, что VMware обеспечивает техническую поддержку своего решения в режиме 24/7.
VMware vSphere with Tanzu легко встраивается и интегрируется в стэк продуктов для создания программно-определяемого дата-центра от VMware.
У VMware vSphere with Tanzu много преимуществ, но есть нюансы, которые мы, как практики, не могли не отметить.
Многие крупные компании используют сегментирование сети, чтобы обеспечить работу разных сред, например, классически разделяя производственные, тестовые среды и среды разработки. В таких ИТ-инфраструктурах потребуется создавать отдельные экземпляры супервайзер-кластера в каждом сегменте. Причина кроется в архитектуре решения: внутри NSX политикой межсетевого экранирования может управлять только он сам. Один экземпляр супервайзер-кластера может работать только с одним Т0-роутером NSX. И когда появляется задача контролировать трафик между разными Т0-роутерами, то каждому из них предоставляется отдельный комплект NSX Edge и отдельный супервайзер-кластер.
В свою очередь для работы такой связки в каждом сегменте должно быть, как минимум, 3 физических сервера. При сложной сегментации сети может потребоваться довольно много оборудования. Как рассчитать минимальное необходимое число серверов? Формула такая: число подлежащих контролю сетевых сегментов умножается на количество требуемых супервайзер-кластеров, умноженных, в свою очередь, на три.
Скажем сразу, она не поддерживается. Если ИТ-инфраструктура компании базируется на двух ЦОД, и в них реализована технология stretched-кластер — растянутые сети, репликация системы хранения данных и пр., — то нужно устанавливать независимые экземпляры VMware vSphere with Tanzu в каждом из дата-центров. Это влечет за собой новое испытание: запуск одного приложения в двух независимых экземплярах. То есть нужно обеспечить балансировку нагрузки между ЦОД или механизм переключения на резервный ЦОД при аварии основного. А еще необходимо будет наладить репликацию данных приложений между разными кластерами vSphere with Tanzu, если их архитектура подразумевает обработку одних и тех же данных (например, когда речь идет о кэшированных данных или очередях сообщений и пр.). И, наконец, потребуется настроить конвейер поставки ПО таким образом, чтобы в разных ЦОД работала одна и та же версия приложения.
Надеемся в следующих релизах этот функционал будет реализован.
При работе c «вложенными кластерами» TKGs есть одна интересная особенность. Как мы писали выше, эта функция VMware vSphere with Tanzu основана на проекте Cluster API, в основе которого лежат два подхода: декларативное описание кластеров и работа с неизменяемой инфраструктурой (immutable infrastructure). Все виртуальные машины — узлы кластера Kubernetes — создаются из одного неизменяемого шаблона. При этом они получают автоматически сгенерированные имена. При изменении шаблона узла, например, в момент обновления кластера на новую версию Kubernetes, все виртуальные машины в кластере циклически пересоздаются. Как следствие, они автоматически получают новые имена.
В целом в этом подходе нет ничего плохого, но могут быть нюансы. Например, если администратор использует механизмы «подсказок» для планировщика Kubernetes (taints, правила nodeAffinity или другие), где и как размещать компоненты приложений, кого с кем можно держать на одном узле, а кого категорически нельзя, то после обновления вложенного кластера TKG может потребоваться ручное восстановление правил с использованием новых имен узлов. Либо, как альтернативный вариант, стоит рассмотреть адаптацию приложений под изменяемое именование узлов Kubernetes.
Еще 5 лет назад казалось, что VMware нечего предложить в области контейнеризации. Но за последние годы вендор начал активно работать с Kubernetes и, как итог — в списке основных comitter’ов к системе вышел на 2-е место за 3 года.
Это стало возможным за счет того, что VMware активно поглощает команды с интересными наработками в контейнеризации. И, пропустив волну популярности Docker, вендор оказался вполне готов к массовой востребованности Kubernetes. Теперь в портфеле VMware появился готовый к работе в ИТ-ландшафте крупных компаний продукт с нужным уровнем стабильности, технической поддержкой, а главное — с полной ответственностью вендора за работоспособность контейнеров в уже созданных средах VMware.
Автор: Дмитрий Горохов, руководитель направления виртуализации «Инфосистемы Джет»
Что такое Tanzu?
VMware Tanzu — это не один продукт, а большое семейство, состоящее приблизительно из 10 разных продуктов. Оно покрывает полный жизненный цикл микросервисного приложения от создания и запуска до последующего управления.
На сегодня продукты Tanzu распространяются в трех основных редакциях:
- Tanzu Basic содержит все необходимое для запуска контейнеров и кластеров Kubernetes с фокусом на работу на стандартной платформе виртуализации VMware vSphere;
- Tanzu Standard добавляет к возможностям предыдущей редакции мониторинг и управление кластерами Kubernetes как в on-premise инсталляциях, так и на облачных платформах, поддержку резервного копирования с помощью Velero и свободой выбора ОС для узлов вложенных кластеров Kubernetes;
- Tanzu Advanced расширяет функциональность Tanzu Standart набором продуктов для управления полным жизненным циклом микросервисных приложений.
Отдельно обращаем внимание на названия продуктов, которые, возможно, вам уже встречались. Эти продукты VMware так или иначе связаны с запуском и последующей эксплуатацией кластеров Kubernetes. Все продукты семейства Tanzu мы рассматривать не будем, сконцентрируемся исключительно на вопросах инфраструктуры.
Если для компании мир контейнеров в новинку, стоит задача быстро запустить микросервисное приложение, и при этом организация хорошо знакома с платформой виртуализации VMware vSphere, мы рекомендуем обратить внимание на VMware vSphere with Tanzu.
Рассмотрим VMware vSphere with Tanzu
Основная интересная фишка в VMware vSphere with Tanzu — возможность запускать и управлять контейнерами точно так же, как и всем давно знакомыми виртуальными машинами. Эта технология называется vSphere Pods. vSphere with Tanzu включается на уровне кластера VMware через vSphere Client. В процессе подготовки разворачивается Control Plane для кластера Kubernetes (служба Workload Control Plane — WCP), в терминологии вендора — Supervisor Cluster. А на гипервизоры VMware ESXi устанавливаются агенты Spherelet, которые превращают их в worker nodes Kubernetes.
Сразу же «из коробки» для работы с контейнерами доступны такие опции:
- изоляция ресурсов (Namespaces);
- ролевая модель доступа;
- гибкое управление ресурсами (Reservations, Limits, Shares);
- постоянное хранение данных с помощью стандартных средств платформы виртуализации;
- встроенный мониторинг и диагностика;
- HA\DRS.
Namespace — это логический объект, который создается на Supervisor Cluster и полностью соответствует объекту Namespace в Kubernetes. Он предназначен для разделения вычислительных и сетевых ресурсов кластера vSphere и прав доступа между разными проектами. Для предоставления доступа администратор использует стандартную ролевую модель, встроенную в платформу виртуализации VMware vSphere. Он может предоставить разработчикам URL для подключения к Supervisor Cluster, где они будут создавать контейнеры в назначенных им пространствах (Namespace).
Важно отметить, что для vSphere Pods обязательно нужно использовать дополнительный продукт VMware NSX-T, который создает программно-определяемую сеть (в терминологии Kubernetes — NSX-T выполняет роль CNI Plugin). С помощью него решаются все вопросы работы сети в контейнерных платформах и приятно, что большинство аспектов закрываются автоматически, без участия администратора. Например, это сетевое взаимодействие между vSphere Pods (East-West трафик), доступ к приложениям, запущенным в контейнерах (North-South трафик), политики безопасности, стандартные инструменты сетевой диагностики и сетевая балансировка (NSX-T обеспечивает создание объектов service с типом Load Balancer и Ingress).
Что происходит под капотом? vSphere Pods — это специальные процессы, работающие на гипервизоре параллельно с виртуальными машинами. Будет правильно назвать vSphere Pods специально подготовленной виртуальной машиной с минимально необходимыми для ее работы виртуальными устройствами и оптимизированным дистрибутивом Linux. Такой процесс запускается за несколько секунд и обеспечивает работу Kubernetes Pod, в котором работают один или несколько контейнеров.
Если по каким-то причинам vSphere Pod недостаточно и разработчику нужно управлять кластером Kubernetes, VMware vSphere with Tanzu позволяет создавать «вложенные кластеры» Tanzu Kubernetes Cluster (TKC). Для управления жизненным циклом кластеров Kubernetes в VMware vSphere with Tanzu используется проект Cluster API. Плюс в этом сценарии не обязательно использовать VMware NSX-T — можно обойтись встроенным CNI на базе проекта Antrea.
Общая схема конструкции будет выглядеть вот так:
А на нашем стенде в интерфейсе управления VMware vCenter это выглядит следующим образом:
Какие плюсы в использовании VMware vSphere with Tanzu?
По сравнению с бесплатными конструкторами на базе Open Source VMware vSphere with Tanzu обладает многими плюсами. Разделим их на несколько категорий.
Функциональность
VMware использует upstream-версию Kubernetes, а значит, можно не опасаться за совместимость приложений.
Использование VMware NSX-T в качестве CNI обеспечивает полную автоматизацию сетевого стека для Kubernetes: сетевую связность, права доступа, балансировку трафика, межсетевое экранирование и сетевой мониторинг. В качестве альтернативы во вложенных кластерах предлагается использовать проект Antrea, контрибуторами которого являются крупные вендоры, включая VMware. Это защищает проект от того, что он неожиданно прекратит свое развитие по причине нехватки внимания от сообщества.
С точки зрения хранения данных VMware vSphere with Tanzu использует механизм First Class Disk (FCD). FCD представляет собой диски VMDK, которые не принадлежат ни одной виртуальной машине. Для администратора Kubernetes каждый FCD — это Persistent Volume. В vSphere Client есть специальная вкладка, где отображаются все FCD и метки (label), которые были присвоены администратором Kubernetes при запросе Persistent Volume.
В качестве системы хранения подходят все поддерживаемые vSphere платформы (SAN, VMware vSAN, NFS). Если используется vSAN, можно также создавать файловые хранилища для контейнеров на базе NFS. Такие хранилища допустимо подключать одновременно к нескольким контейнерам.
Управляемость и масштабируемость
vSphere Client — привычный для многих заказчиков графический интерфейс, в котором сочетается управление классическими виртуальными машинами, контейнерами и вложенными кластерами Kubernetes. Этого интерфейса достаточно для того, чтобы автоматизировать развертывание необходимых компонентов, упростить такие операции второго дня по работе с Kubernetes, как, например, масштабирование или обновление кластеров.
А для администраторов Kubernetes доступен привычный инструмент — kubectl.
Стабильность и надежность
В платформу виртуализации встроены штатные средства высокой доступности и балансировки нагрузки (vSphere HA\DRS), механизмы мониторинга и набор инструментов по обеспечению информационной безопасности.
И важно, что VMware обеспечивает техническую поддержку своего решения в режиме 24/7.
Экосистема
VMware vSphere with Tanzu легко встраивается и интегрируется в стэк продуктов для создания программно-определяемого дата-центра от VMware.
Это лучше знать заранее
У VMware vSphere with Tanzu много преимуществ, но есть нюансы, которые мы, как практики, не могли не отметить.
Особенности развертывания в сегментированных сетевых топологиях
Многие крупные компании используют сегментирование сети, чтобы обеспечить работу разных сред, например, классически разделяя производственные, тестовые среды и среды разработки. В таких ИТ-инфраструктурах потребуется создавать отдельные экземпляры супервайзер-кластера в каждом сегменте. Причина кроется в архитектуре решения: внутри NSX политикой межсетевого экранирования может управлять только он сам. Один экземпляр супервайзер-кластера может работать только с одним Т0-роутером NSX. И когда появляется задача контролировать трафик между разными Т0-роутерами, то каждому из них предоставляется отдельный комплект NSX Edge и отдельный супервайзер-кластер.
В свою очередь для работы такой связки в каждом сегменте должно быть, как минимум, 3 физических сервера. При сложной сегментации сети может потребоваться довольно много оборудования. Как рассчитать минимальное необходимое число серверов? Формула такая: число подлежащих контролю сетевых сегментов умножается на количество требуемых супервайзер-кластеров, умноженных, в свою очередь, на три.
Работа в stretched-кластерах
Скажем сразу, она не поддерживается. Если ИТ-инфраструктура компании базируется на двух ЦОД, и в них реализована технология stretched-кластер — растянутые сети, репликация системы хранения данных и пр., — то нужно устанавливать независимые экземпляры VMware vSphere with Tanzu в каждом из дата-центров. Это влечет за собой новое испытание: запуск одного приложения в двух независимых экземплярах. То есть нужно обеспечить балансировку нагрузки между ЦОД или механизм переключения на резервный ЦОД при аварии основного. А еще необходимо будет наладить репликацию данных приложений между разными кластерами vSphere with Tanzu, если их архитектура подразумевает обработку одних и тех же данных (например, когда речь идет о кэшированных данных или очередях сообщений и пр.). И, наконец, потребуется настроить конвейер поставки ПО таким образом, чтобы в разных ЦОД работала одна и та же версия приложения.
Надеемся в следующих релизах этот функционал будет реализован.
«Инфраструктура как код» поневоле
При работе c «вложенными кластерами» TKGs есть одна интересная особенность. Как мы писали выше, эта функция VMware vSphere with Tanzu основана на проекте Cluster API, в основе которого лежат два подхода: декларативное описание кластеров и работа с неизменяемой инфраструктурой (immutable infrastructure). Все виртуальные машины — узлы кластера Kubernetes — создаются из одного неизменяемого шаблона. При этом они получают автоматически сгенерированные имена. При изменении шаблона узла, например, в момент обновления кластера на новую версию Kubernetes, все виртуальные машины в кластере циклически пересоздаются. Как следствие, они автоматически получают новые имена.
В целом в этом подходе нет ничего плохого, но могут быть нюансы. Например, если администратор использует механизмы «подсказок» для планировщика Kubernetes (taints, правила nodeAffinity или другие), где и как размещать компоненты приложений, кого с кем можно держать на одном узле, а кого категорически нельзя, то после обновления вложенного кластера TKG может потребоваться ручное восстановление правил с использованием новых имен узлов. Либо, как альтернативный вариант, стоит рассмотреть адаптацию приложений под изменяемое именование узлов Kubernetes.
Теперь и VMware
Еще 5 лет назад казалось, что VMware нечего предложить в области контейнеризации. Но за последние годы вендор начал активно работать с Kubernetes и, как итог — в списке основных comitter’ов к системе вышел на 2-е место за 3 года.
Это стало возможным за счет того, что VMware активно поглощает команды с интересными наработками в контейнеризации. И, пропустив волну популярности Docker, вендор оказался вполне готов к массовой востребованности Kubernetes. Теперь в портфеле VMware появился готовый к работе в ИТ-ландшафте крупных компаний продукт с нужным уровнем стабильности, технической поддержкой, а главное — с полной ответственностью вендора за работоспособность контейнеров в уже созданных средах VMware.
Автор: Дмитрий Горохов, руководитель направления виртуализации «Инфосистемы Джет»
vp7
Как всегда, в таких статьях забыто самое главное — цена ;))
Допустим, у меня есть 5 двухпроцессорных серверов с 256Gb RAM и 8x1Tb SSD на каждом из них.
Сколько будет стоить полный набор лицензий для того, чтобы получить полнофункциональный кластер сTanzu с резервированной СХД на локальных дисках (вроде, это называется vSAN у vmware)? Есть ощущение, что ценник может очень неприятно удивить.
JetHabr Автор
Добрый день! На наш взгляд, цена — не самая главная информация о продукте. Особенно, если учитывать, что при сравнении на другой чаше весов условно бесплатное ПО и по критерию стоимости любой вендорский продукт ему априори проиграет:)
Но $ — это точно любопытный параметр. Давайте обсудим ваши задачи лично. Напишите, пожалуйста, на info@jet.su, и мы все расскажем.
inkvizitor68sl
Вы у ноготочниц в инстаграме научились, что ли? «Цена в личке».
Пример рассчитайте и в статью напишите, в чём проблема?
А Cindy работала или работает в Apple — не там ли кубер в миллион+ обошелся? Сколько сTanzu будет хотя бы на сотню хостов по 100+ ядер стоить, не говоря уже о реально крупных кластерах? Сколько хостов он вообще прожует? Кубер на 3 хоста поднять и кубер на тысячу хостов в нескольких локациях — 2 сильно разных истории.
JetHabr Автор
Информация о поддерживаемых вендором конфигурационных максимумах публична.
Ее можете найти здесь: https://configmax.vmware.com/guest?vmwareproduct=vSphere&release=vSphere%207.0&categories=70-58,71-0
А чтобы получить ценовое предложение, напишите, пожалуйста, ваш запрос на адрес info@jet.su — все посчитаем.
inkvizitor68sl
Зачем вы вообще статью тогда писали? Считайте здесь примеры, публично, мы обсудим.
И да
> Maximum number of pods per Kuberetes Cluster: 15000
Это что вообще? Это для мини-стартапов каких-то?
ProFfeSsoRr
Почему же «мини»? Набрать 15 тысяч подов в одном кластере далеко не каждая компания сможет, даже если объединить тестовые и прод в одном кластере.
inkvizitor68sl
Понятно, что далеко не каждая.
Но компании, у которых не 10к+ подов (которые быстро превратятся в 15+ из-за мусора со временем) не тратят по 1М+ долларов на внедрение кубера.
В любом случае, автор статьи стесняется приводить конкретные цены, так что мы ничего не узнаем.
JetHabr Автор
Как вы могли прочитать, этот лимит относится ко вложенным кластерам Kubernetes — vSphere Tanzu Kubernetes Grid service. Вложенных кластеров в рамках одного Supervisor Cluster (читайте одного vSphere HA Cluster) может быть 190 — смотрите параметр Maximum number of Kubernetes clusters that can be created per Supervisor Cluster. Также ничего не мешает масштабировать инфраструктуру кластерами в рамках одного сервера vCenter, так и нескольких серверов vCenter.
Гиперскейлеров в мире не так уж много и свои потребности в Kubernetes за счет инвестиций в собственные человеческие ресурсы уже реализованы. Малых и средних компаний, которым необходимо просто запускать контейнеризованные приложения, предоставляемые в таком виде разработчиками, во много раз больше. И далеко не всем по разным причинам будет комфортно и удобно работать с бесплатным Kubernetes и всей обвязкой к нему. и для них есть альтернативное решение о своими преимуществами.
Демонстрацию решения и расчет цен всегда можно запросить, пишите на info@jet.su.
На этом дискуссию вокруг стоимости комментариях будем считать закрытой.
ProFfeSsoRr
Все понимают, что если написать — цена будет со скидками. А вот без скидок прямо в статью — это было бы хорошо. Потому что без цен решение бесполезно рассматривать.