[Kubernetes] VMware Tanzu: как «приручить» Kubernetes
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Развернуть кластер Kubernetes может даже неопытный администратор за пару часов. Именно это делает решение таким привлекательным, тем более, что оно условно бесплатно. А на практике? В своем твите представитель американской компании рассказал, что «подъем» Kubernetes обошелся примерно в $1 млн. Столько составила цена развертывания и настройки ПО, когда компания переложила трудозатраты своей команды в доллары. В комментариях разгорелась жаркая дискуссия на тему, как избежать космических трат при установке и управлении Kubernetes. Наше мнение радикально — обратить внимание на вендорские решения. Например, на семейство продуктов Tanzu от 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.
Автор: Дмитрий Горохов, руководитель направления виртуализации «Инфосистемы Джет»
===========
Источник:
habr.com
===========
Похожие новости:
- [DevOps] Основы работы с Helm чартами и темплейтами — Часть 2 (перевод)
- [Информационная безопасность] ТОП-3 ИБ-событий недели по версии Jet CSIRT
- [Машинное обучение, DevOps, Kubernetes, Data Engineering] MLOps без боли в облаке: как развернуть Kubeflow в продакшен-кластере Kubernetes
- [Микросервисы, Kubernetes] О наблюдаемости микросервисов в Kubernetes (перевод)
- [Системное администрирование, Системное программирование, DevOps] Искусство Helm Chart: паттерны из официальных чартов Kubernetes (перевод)
- [Машинное обучение, Искусственный интеллект, Будущее здесь] Как bias может повлиять на мир вообще и людей-пользователей в частности?
- [Настройка Linux, Системное программирование, Kubernetes] Скидка на экзамены по Kubernetes и Linux
- [Системное администрирование, DevOps, Kubernetes] Как заменить container runtime в Kubernetes (перевод)
- [DevOps, Kubernetes] Подборка телеграм-каналов для DevOps инженеров
- [Информационная безопасность] ТОП-3 ИБ-событий недели по версии Jet CSIRT
Теги для поиска: #_kubernetes, #_vmware, #_kubernetes, #_blog_kompanii_infosistemy_dzhet (
Блог компании Инфосистемы Джет
), #_kubernetes
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 11:38
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Развернуть кластер Kubernetes может даже неопытный администратор за пару часов. Именно это делает решение таким привлекательным, тем более, что оно условно бесплатно. А на практике? В своем твите представитель американской компании рассказал, что «подъем» Kubernetes обошелся примерно в $1 млн. Столько составила цена развертывания и настройки ПО, когда компания переложила трудозатраты своей команды в доллары. В комментариях разгорелась жаркая дискуссия на тему, как избежать космических трат при установке и управлении Kubernetes. Наше мнение радикально — обратить внимание на вендорские решения. Например, на семейство продуктов Tanzu от VMware.  Что такое Tanzu? VMware Tanzu — это не один продукт, а большое семейство, состоящее приблизительно из 10 разных продуктов. Оно покрывает полный жизненный цикл микросервисного приложения от создания и запуска до последующего управления. На сегодня продукты Tanzu распространяются в трех основных редакциях:
Отдельно обращаем внимание на названия продуктов, которые, возможно, вам уже встречались. Эти продукты 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. Сразу же «из коробки» для работы с контейнерами доступны такие опции:
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. Автор: Дмитрий Горохов, руководитель направления виртуализации «Инфосистемы Джет» =========== Источник: habr.com =========== Похожие новости:
Блог компании Инфосистемы Джет ), #_kubernetes |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 11:38
Часовой пояс: UTC + 5