Tanzu от VMware — это набор полезных продуктов для тех, кто работает с микросервисами. В Sportmaster Lab мы тоже начали его использовать, и в этом посте расскажем, как именно. Помогут нам в этом Павел Бацев, старший администратор сервисов Спортмастера, и Алексей Гришутин, который отвечает за сети и сервисы. Поговорим про Tanzu, про общую архитектуру, отказоустойчивость, бэкапы и много другое.

Почему вы вообще решили использовать Kubernetes и как пришли к нему?

Павел

Было бы странно, если бы развитие микросервисной архитектуры прошло мимо Спортмастера, так что внедрение Kubernetes, да и других оркестраторов, мы активно рассматривали — количество сервисов увеличивается, монолит разрушается, микросервисы внедряются. В общем, современные проблемы требуют современных решений, так что мы пришли к Kubernetes именно как к достаточно популярному и зрелому решению на сегодня.

Ваши коллеги уже умели с ним работать, или приходилось дополнительно их обучать?

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

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

Алексей

Вообще, с VMware мы уже давно работаем, у нас инфраструктура развивается с версии 4.1. Сразу скажу, что я по большей части занимаюсь виртуализацией, поэтому всё, что связано с микросервисами, это для меня такая заведомо сторонняя история. Но ко мне часто приходили ребята с запросами из разных подразделений, хотели попробовать микросервисы, а какого-то единого подхода к ним у нас в то время не было. Как только появился Fling, мы его активно протестировали и стали ждать, пока выйдет коммерческая версия — удобное готовое решение, которое мы сможем нормально использовать на HA-инсталляции. В первой версии, которую мы с Павлом тестировали, был ряд подводных камней, особенно сильно нас печалило быстродействие самого HAproxy.

Дождались нового релиза на балансировщике VMware NSX Advanced Load Balancer (он же AVI Vantage), обновились и Павел сейчас переводит сервисы под управление новой версии. Площадка у нас довольно ёмкая, будем стараться привлекать еще и другие отделы из тех, кто приходил с такими запросами, но на текущий момент работает на самописных инструментах

Насчёт Tanzu. Само решение я сравнивал с опенсорсными аналогами, и для меня как для администратора огромный плюс Tanzu в том, что я могу отдать огромную площадку, на которой разработчики могут работать, имея готовую тестовую площадку тестовой среде, иногда минуя девопсов в плане подготовки сервисов. То есть все эти машины готовы, между ними настроена связанность, которая видна не только в Кубере, но и внутри виртуализации. Переход проще. Да и распределение сервисов между площадками работает полноценно и не требует от администраторов виртуализации (серверов) и девопсов большой перекрестности в знаниях, по сравнению со всеми конкурентами, что я видел.

Павел

У меня есть и более житейская причина перехода — возможность разделить именно инфраструктурные части работы с микросервисами. То есть для работы с кубером администратор может иметь более низкий порог вхождения, так как нет необходимости администрировать сам кубер, это отдано на откуп Tanzu. Есть готовый нарезанный кластер с нодами, всё это поддерживается на самой технологии Tanzu, а администратор, который будет внедрять решения микросервисной архитектуры, просто занимается написанием тех же самых чартов или подготовкой carvel-темплейтов. Написание буквально одного манифеста, и всё. Для меня такое разделение оказалось очень приятным.

Алексей

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

Расскажите про переход на Tanzu с точки зрения девопса — сложно было переходить?

Павел

На самом деле, нет. Сейчас весь процесс перехода укладывается в 3 недели максимум. Работа по переводу существующих площадок и работа в девопс-части очень схожа с ванильным Kubernetes, особых проблем не возникало. Если более детально, то 90% времени ушло на модификацию манифестов и helm-чартов под актуальную версию k8s, а остальные 10% на подбор удобного способа аутентификации в k8s и интеграцию кластеров в наши ci-инструменты.

Как у вас в целом устроена архитектура, если совсем верхнеуровнево?

Павел

Ну вот смотрите. Алексей как владелец супервайзер кластера нарезает нам неймспейсы, в терминологии Tanzu это разграничение ресурсов, которое выделяется для группы разработчиков или девопсов, как это организовано уже в самой компании. А мы в дальнейшем в этих нарезанных неймспейсах подготавливаем кластеры для различных систем. После этого, уже по классической структуре Kubernetes, идет разделение внутри кластера — когда неймспейсами все делится на dev, stage, prod и тому подобные среды. Там уже внутри можно разворачивать какие-то собственные сервисы под различные задачи. При этом, если группа разработки хочет глубже погрузиться в понимание k8s, можно выделить им свой собственный кластер и не бояться, что “я потратил три дня на согласование выделения ресурсов под этот кластер, накат k8s, отладку работы отказоустойчивости, настройку мониторинга/логирования, а кто-то неаккуратно сломал это все за час”. Как-то так.

Много времени ушло на то, чтобы научиться работать с консолью для управления Kubernetes?

Алексей

Сама консоль вопросов не вызывает, проблемы в первый раз были только с сетевой частью встроенных балансировщиков сперва HAProxy, а потом AVE. Для меня тут были еще сложности с порогом вхождения, чтобы разобраться в терминологии. Но потом понял, что подошел не с той стороны, и когда разобрался — оказалось, что все сильно проще, чем думал. Некоторые термины пересекаются, и в новой технологии они могут означать немного не то, к чему ты уже успел привыкнуть. А когда ты соотносишь терминологию, всё становится понятным.

На каком решении вы остановились в плане ingress-контроллера?

Павел

Сейчас мы используем NGINX, который из коробки идет в решении Kubernetes. А насчет решения от VMware, Contour, тоже смотрим в эту сторону — оно довольно интересное, особенно возможность выделить в отдельный манифест все настройки, не включая их в аннотации. То есть тут нет необходимости перезапускать сам ingress, если понадобится, а можно просто динамически вносить изменения в рамках тестирования, у нас как раз сейчас в одной из инсталляций Contour используется.

Используете ли persistent volume, как выстроена работа с ними?

Павел

Мы их используем для хранения дашбордов и данных систем мониторинга. Плюс для некоторых dev-площадок, если используем решения с БД, для кешей, для брокеров очередей, они тоже подразумевают хранения данных. Но это именно для dev-решений, не для прода. В прод persistent volume стараемся не заводить.

Расскажите про мониторинг

Алексей

Каждый мониторит свою сторону, я — виртуальные хосты, датасторы и виртуальные машины для этого используем стандартное решение от VMware vRealize Operation Manager, собираем логи через VMware vRelize Loginsight. Планируем в будущем попробовать и сущности Kubernetes мониторить, но пока только мониторим именно в сторону виртуализации и оборудования

Павел

А если говорить о микросервисах и сборки метрик для каждого кластера, то тут поднимаем prometheus, отправляем с него данные в центральную grafana и визуализируем дашбордами, для сбора логов — в кластере поднимаем агентов filebeat c кастомизированным конфигмапом, а далее логи аггрегируются elasticsearch и визуализируются в kibana. Задействуем всё это, получается такая централизованная система мониторинга/логирования. Я бы сказал, это такой мастхэв-джентльменский набор, чтобы понимать, что происходит с вашими сервисами.

Были сложности с prometheus?

Павел

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

Что у вас используется в качестве корпоративного registry? Что можете порекомендовать читателям?

Павел

Ну, рекомендовать что-то — это начинать холивар, тут все зависит от нужд компании и оценки каждого пользователя.

У нас — корпоративное artifactory, рассматривали и Harbor. Когда нужен быстрый доступ к какому-то хранилищу, не использовать же стандартный docker registry, хотя на нем мы тоже многое тестировали. А Harbor я оцениваю хорошо — отличные решения по инфраструктуре и внушительное количество коммитов, которое поступает в проект.

Какие именно приложения вы в первую очередь используете в Kubernetes?

Павел

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

Как дела с бэкапами и отказоустойчивостью?

Павел

Используем софт, который бэкапит именно часть приложения, которое необходимо, с конкретным контентом. Тестируем внедрение снепшотов, которые есть в Kubernetes, а также вызывает интерес Velero У нас сейчас в основном dev-стенды завязаны на использование persistent volume, так что критичной точки для использования бэкапов нет. Но мы и dev-стенды проверяем, и технологии оттачиваем параллельно.

Для отказоустойчивости и скелинга подготовлен отдельный манифест.

Какие есть основные киллерфичи Tanzu с точки зрения администратора виртуальной инфраструктуры?

Алексей

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

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

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

Павел

Для меня главный плюс в описанном выше разделении. Удобно работать. Кто-то из администраторов знает, как устроена виртуализация, кто-то — нет. Проблема на этапе планирования решается тем, что поднятие нового кластера/обновление до новой версии укладывается в один манифест. Группам администраторов не приходится тратить часы на отладку обновления/расширения dev-кластера существующими инструментами инсталляции ванильного k8s, а тем более на разработку таких инструментов, чтобы в итоге поймать при обновлении prod-кластера ошибку.

Алексей

Отдельный плюс — техподдержка. У ребят находились ответы на все наши вопросы.

Что было самым сложным при использовании Tanzu?

Алексей

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

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

Павел

Для меня вызовов стала одноранговость наименований, когда выдали доступы. Дают тебе доступ к кластеру, запрашиваешь доступные неймспейсы, а тебе говорят — нет доступа. Что произошло, почему я не могу их смотреть — сходу не понимаешь, выходит небольшой диссонанс. Все дело в немного иной парадигме работы. Нейспейсы в Tanzu — это часть решения, в котором необходимо нарезать вложенные кластера. И эти вложенные кластера уже и являются тем ванильным кубером, который все привыкли использовать. Если оперировать вложенными кластерами, проблем нет — возможность быстро нарезать кластер и получить за 10 минут работающее решение, как по мне, это хорошо. Как и то, что не надо писать дополнительный функционал в манифест.

Успели попробовать новые функции — подключение и разворачивание из YAML-файла?

Павел

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

Что бы вы могли порекомендовать читателям в плане работы с Kubernetes?

Павел

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

Алексей

А еще микросервис должен оправдывать приставку “микро”, чтобы вам не приходилось использовать контейнер, который занимает весь хост.