[DevOps, Микросервисы, Kubernetes] KubeGraf — плагин для мониторинга Kubernetes в Grafana. Как создавался и почему стал востребованным
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
KubeGraf — это плагин для Grafana, который собирает данные с кластера Kubernetes и приложений внутри него, а затем показывает их на красивых и понятных графиках. В феврале этого года вышел релиз 1.5, и стало известно, что предыдущие версии скачали более 250 тысяч раз! Мы расспросили Сергея Спорышева, создателя плагина и директора направления DevOps-продуктов в ITSumma, об истории создания плагина, факапах и причинах популярности.
Сергей Спорышев участвует в создании курса по мониторингу и логированию в «Слёрме», набор на который уже начался. В конце интервью мы немного поговорим и про курс тоже.
Как-то, рассказывая о разработке KubeGraf, ты упомянул, что вы хотели сделать универсальный инструмент для мониторинга, который поставил — и ничего больше делать не надо. Что скажешь спустя полтора года: получилось ли?
Я думаю, получилось. Здесь логично рассказать, откуда возникла идея плагина. В апреле 2019 года я помогал Евгению Потапову, гендиректору ITSumma, готовить доклад для конференции HighLoad в Питере. Он планировал рассказать про мониторинг Kubernetes: какие есть инструменты, подходы… Всего этого — и методологий, и инструментов, — было очень много, но какого-то более-менее универсального решения, чтобы поставил и ничего делать не нужно, не было.
Углубляясь, мы нашли у самой Grafana плагин для мониторинга Kubernetes. Он вроде был жив, но почему-то не поддерживался. Мы его поставили и увидели, что половина функций не работает. Так возникла идея написать своё и докинуть туда багаж практик, который мы наработали внутри компании (одно из направлений ITSumma — как раз техподдержка 24/7 и, соответственно, круглосуточный мониторинг).
Была ещё одна вещь, которую мы хотели реализовать. В России раскатка на bare metal — это нормальное явление, а все прогрессивные страны пользуются managed-решениями: Kubernetes от Google, Amazon (у нас теперь ещё Яндекс и Mail.ru). В работе с облаками есть свои нюансы, и мы подумали — почему бы не сделать плагин, который будет эти нюансы учитывать?
Такой был план: написать плагин, основываясь на решении, выпущенном самой Grafana, дополнить его своими наработками и сделать так, чтобы он работал везде одинаково. Я думаю, получилось. Лично я его юзаю, и наши клиенты тоже: причём как те, кто на голом железе сидит, так и те, кто сидит в Google и Amazon. Лишних телодвижений делать не приходится никому.
А какие фичи плагина ты используешь каждый день?
Одна из основных фишек — это как раз возможность работы с облачными провайдерами. Обычно во всех этих системах используется авторизация по сертификатам. В облаке сертификаты тебе никто не даст, поэтому мы сделали возможность работы через токены. Ты применяешь кубовые манифесты, регистрируешь пользователя, выдаешь ему права, и с этим пользователем плагин работает.
Мы мониторим как приложения, которые крутятся в Kubernetes, так и ноды, на которых Kubernetes работает. В реальном времени можно смотреть нагрузку по ноде, сколько ресурсов на ней зарезервировано и какие выставлены лимиты. Например, мы индицируем, что у ноды есть всего лишь 2.5 Гб памяти, 2 Гб которых уже зарезервировано, и тогда подкрашиваем ноду жёлтым либо красным, таким образом предупреждая: «Ребят, эта нода скоро закончится». То же самое с лимитами.
В реалтайме видно, какие именно приложения, какие поды Kubernetes крутятся на ноде, их можно группировать. Видно потребление и резервирование, лимитирование ресурсов для конкретного приложения. Это позволяет заметить, например, что какие-то приложения слишком много выжирают и надо бы их расселить.
Второй режим просмотра — это так называемая Карта всех приложений. Виден список всех приложений, как они сгруппированы по неймспейсам, какие сущности за собой тянут, сколько там реплик. Все красивенько отображается.
Ну, и последний ключевой момент — в одном месте сведена информация обо всех предупреждениях, ошибках, критических ситуациях. Ты можешь просто открыть страничку Cluster Status и посмотреть, что у тебя с кластером происходит. Куда надо обратить внимание, куда не надо.
Можешь вспомнить ситуации из своей рабочей практики, когда KubeGraf реально тебе помог?
Это случилось, когда мы научились правильно индицировать лимиты, реквесты и всё остальное. На одном из проектов облачный кластер Kubernetes в момент пиковых нагрузок разрастался до 25-26 нод. Мы стали смотреть на данные из плагина и, пользуясь ими, сократили парк почти в два раза. Сейчас этот же кластер с бо̀льшим количеством приложений спокойно работает на 12-13 нодах.
При этом ресурсы кластера мы никак не разбирали. Мы просто смотрели, что такие-то приложения при таком-то трафике практически не должны ничего жрать, но потребление вырастает до колоссальных размеров. Анализировали приложение, смотрели, что где можно подтюнить, как именно построен scheduling на основе реквестов. Видели, например, что зарезервировано 1.5 Гб памяти, но за два месяца никто столько никогда не использовал и можно это сократить. Потихоньку-помаленьку сократили кластер в два раза.
В новостях о плагине вы писали, что его скачали 250 000 раз…
По не совсем официальной информации — да. Это такая информация для разработчиков, её в паблике нет, но вот я нечаянно узнал. Круто!
Это много или мало?
Много! У нас четыре с лишним сотни клиентов, у одного клиента может быть максимум кластеров 10. Если мы хотя бы 400 умножим на 10 — это 4 000. То есть если бы каждый наш клиент был с Kubernetes, мы бы каждому накатили и получили только 4 000. А тут — четверть миллиона! Это много и это круто.
Как думаешь, в чём причина такой популярности?
Один из ключевых факторов: плагин от Grafana, о котором я уже упоминал, разработчики по неизвестным причинам перестали поддерживать. И теперь в issues или в pull request на GitHub, я не помню точно, их спрашивают: ребята, вы собираетесь этот инструмент дальше развивать или нет? А они говорят: нет, вот вам ссылка на нормальное решение. И дают ссылку на нас.
Плюс сарафанное радио: мы раскидываем плагин клиентам, активно взаимодействуем с сообществом, много где его презентуем. Скорее всего, в этом причина.
А если оценивать аудиторию — англоязычную, русскоязычную — как тебе кажется, где KubeGraf больше используют?
Мне кажется, это неправильным в современном мире — разделять аудиторию на русскоговорящую и не русскоговорящую.
Недавно вышла версия 1.5. Что там нового?
Мы починили большое количество ошибок совместимости. В середине 2020 года релизнулась седьмая версия Grafana, там всё еще работало, а с 7.3 начались большие изменения в структуре, поэтому пришлось дорабатывать плагин, чтобы ничего не отваливалось. Плюс добавили поддержку последних версий Kubernetes, доработали, по каким путям мы забираем данные из API Kubernetes.
В версии 1.5 мы добавили сбор метрик по лимитам для приложений. До этого работали только с реквестами и текущим потреблением: приложение сколько-то под себя резервирует и сколько-то использует в реальном времени. Но со временем поняли, что очень важна еще и работа с лимитами.
Переработали UX, чтобы было удобно для восприятия, добавили реалтайм индикации. Раньше была сводная таблица по всем приложениям, и мы просто видели, сколько они резервируют и потребляют. В 1.5 добавили индикацию: в табличке подсвечено, где что-то не указано, где зеленая зона, где желтая, красная и так далее.
Как обычно, были небольшие фиксы: где-то слетела легенда, где-то кнопка не работала — поправили.
Последнее ключевое — в сводной таблице по состоянию кластера мы наконец-то догадались ввести сортировку по важности уведомления: жёлтое, красное и т. д.
Алертинга у вас нет?
Тут можно холиварить долго, но устоявшееся мнение такое: алерты и Grafana — это разные вещи. Алерты в Grafana делать можно, но это неправильно. Для алертинга нужен другой инструмент: Prometheus+Alert Manager, например. Grafana — это про визуализацию. Мы только планируем на графике сделать индикацию алертинга.
Ты говорил, что многие фичи появлялись, исходя из ваших потребностей. А были такие, которые вы делали по запросам?
Конечно! Здесь соотношение где-то 60/40. 60 — это наша практика. 40 — это общение с комьюнити, с клиентами. Сейчас мы работаем над версией 1.6, и одним из ключевых новшеств в ней будет обновлённый дашборд. К нам пришли клиенты, которые активно юзают плагин, и говорят: ребята, мы пользуемся, всё круто, но хотелось бы увидеть ещё такую вот панель. Мы отвечаем: ну, супер.
Запросы на разные фишки по дашбордам тоже приходили от клиентов, так что сообщество играет здесь большую роль. Большая часть, конечно, это наши клиенты, потому что они могут прямо в клиентский чатик написать — я приду, поговорю, обсудим.
Заспойлери что-нибудь ещё из версии 1.6.
Будет небольшой редизайн, потому что первый макет создавался кустарно. Сначала мы с Женей Потаповым набросали на бумажке, как может выглядеть интерфейс. Потом один из наших разработчиков разобрал тулкит Grafana с визуализационными элементами, и мы просто впихали всё, как было. Позже подключился дизайнер, и где-то в версии 1.3-1.4 мы переработали одну из страниц. Теперь перерабатываем остальные и в 1.6 затащим красоты.
Плюс к странице Cluster Status появится сводный дашборд по общему состоянию кластера. Не по отдельным нодам, а именно по всему кластеру, как если бы он был одним большим сервером. Дашборд даст понимание, как он себя чувствует.
Ну и мы хотим полностью переписать плагин. С выхода первой версии прошло два года, Grafana выпустила много вспомогательных инструментов для разработки. Поэтому мы полностью переписываем сборку, переходим на использование компонентов от Grafana и другой фреймворк: плагин написан на Angular, а где-то год назад пошёл тренд на React-плагины, поэтому я думаю, что после 1.6 будет сразу версия 2.0 на React.
С какой скоростью выпускаете новые версии?
Критичные минорные изменения вносим так быстро, как это только возможно, но вообще стараемся релизиться раз в два месяца. Только с версией 1.5 что-то пошло не так — готовили её почти полгода. Сказался и личный загруз (это все-таки наш open source проект), и эпидемия, и задержки со стороны Grafana. С релиза версии может пройти от недели до двух месяцев, когда её примут и опубликуют на сайте Grafana. Поэтому релизный цикл плавающий.
Как устроена работа над плагином: сколько человек в команде, сколько времени каждый из вас уделяет разработке?
Команда — это два разработчика: я и мой коллега Дмитрий Воронов. Когда нужно, подключаем дизайнера. Менеджерю этот процесс я сам. Если по работе у нас ничего не горит, то понедельник мы посвящаем плагину. Понедельник у нас — Grafana Day, такая разминка перед тяжёлой рабочей неделей.
То есть это не выходные, не ночь, а полноценный рабочий день?
Да. Единственное — это предрелизная штука, когда обычно я на себя всё захватываю. Там может выжирать и три дня в неделю. Но стандартно — день.
В таком режиме получается отдыхать от плагина? Когда два года делаешь какую-то штуку, она может слегка поднадоесть, нет?
Бывает такое, но можно взять на неделю перерыв. Это же pet project: поднадоело — давайте отложим.
Были за эти два года такие факапы, которые прям совсем факапы?
Конечно, они бывают в любой разработке. Как-то раз выкатили версию, которая не работала. Потестили на одной из версий Grafana, а на остальных нет. Где-то всё поехало, где-то метрики перестали приходить.
Заметили довольно быстро, потому что мы обычно, пока ждём официального релиза от Grafana, ходим и через Git и обновляем это всё у наших клиентов. Видим, где ломается.
Второй факап был прямо жёсткий. В одной из версий Kubernetes и Prometheus полностью сменился лейблинг. До этого в основных метриках было два лейбла: container name и pod name, а тут они поменялись на container и pod (я уже сейчас не вспомню точно). В какой-то момент мы заметили, что нейминг разъехался: здесь мы собираем по pod, здесь по pod name; здесь по container, здесь по container name. И у нас половина плагина работала, половина не работала. Никто сначала ничего не мог понять. Пришлось пойти, разобраться, упороться регулярками, которые все ненавидят. Ну и вроде собрали, заработало.
Но, в целом, за счет того, что time-to-market у плагина очень высокий, у нас всегда есть минимум две недели в ожидании релиза, когда можно сходить всё исправить. То есть факапы — они локальные, в паблик не могут уйти.
Если бы ты сейчас подходил к разработке плагина, что-нибудь бы сделал иначе?
Думаю, нет. Я даже не знаю, что можно было изменить, потому что оно как шло по желанию, так и шло. Какие-то фишки придумывались, какие-то дорабатывались. Что-то изменить? Не знаю.
Какую побочную, помимо технической, пользу принёс плагин тебе самому и вашей компании?
Brand awareness — узнаваемость бренда. Это самое большое, что мы получили. Когда компания выпускает open source продукты, она закрепляет свою экспертизу, повышает узнаваемость. На приток клиентов не рассчитывали. Хотели только, чтобы нас узнавали, чтобы люди понимали, что мы это умеем и в этом шарим.
Мне кажется, у нас получилось, потому что про плагин писали везде. Очень много материалов в интернете, и везде ссылочки на нас. Да, определённый процент клиентов приходили с плагина: понимали, что в теме Kubernetes и мониторинга нам можно довериться, и работали с нами дальше.
В небольшом видео с анонсом версии 1.5 ты сказал, что вы планируете сделать плагин отдельным продуктом. Что это за идеи?
У нас была мысль сделать плагин прямо такой stand-alone версией, потому что мы наработали большое количество практик в работе с Kubernetes, и хотели бы их реализовать в отдельном продукте.
Мы думаем про сервис, который будет делать не только визуализацию, но поможет проводить аудит кластера и тюнить его. Grafana здесь будет только мешать, поэтому думаем оформить его в виде stand-alone решения, которое просто так же поставил через Helm и видишь красивую картиночку, где у тебя что происходит. Но это всё пока только на уровне проработки концепции.
Еще какие-то плагины делать? Я пока не знаю. У нас было много идей, как можно что-то визуализировать. Пока руки не доходят.
Если это будет отдельный продукт, который будет шире, чем просто мониторинг и визуализация, он будет платным?
Open source продукты принято делать бесплатными. Но, например, Grafana тоже open source, но есть Grafana Enterprise. Мне кажется, этот продукт будет в двух вариациях — free и с какой-то подпиской.
Такой серьезный продукт придётся не только по понедельникам делать.
Да.
Выходит, ITSumma сейчас смотрит чуть в сторону open sourse, в направлении разработки своих продуктов?
Конечно! Нужны же какие-то артефакты работы компании. Хоть что-то после себя оставить нужно.
На этом мы закончили обсуждать плагин KubеGraf и немного поговорили о видеокурсе по мониторингу Kubernetes, который Сергей Спорышев вместе с другими спикерами разрабатывал в «Слёрме». К беседе присоединился СТО «Слёрма» Марсель Ибраев.
Что будет в новом курсе?
МАРСЕЛЬ: Мы будем говорить о том, как мониторить и собирать логи с приложений, которые запущены в кластере, и с самого кластера Kubernetes. Потому что просто поднять кластер — это полдела, и с этим справляется большинство, а вот правильно настроить сбор логов и метрик уже получается не у всех. Цель курса — рассказать и показать лучшие практики.
Стоит ли идти на курс по логированию тем, кто уже проходил курсы по Kubernetes в «Слёрме»?
МАРСЕЛЬ: Стоит, потому что в наших курсах по Kubernetes не раскрывается тема логирования и мониторинга. Мы пробовали её включить в первые базовые курсы, но получалось не очень: материала много, и дать его в рамках двух занятий внутри обзорного курса по Kubernetes невозможно. Уже тогда была идея, что надо делать что-то отдельное. Наконец-то мы к этому пришли.
Чем хорош курс? Почему вы бы сами на него пошли?
МАРСЕЛЬ: Во-первых, курс подготовили практикующие инженеры — ребята, которые каждый день работают с Kubernetes, набивают шишки. Они рассказывают именно то, что нужно знать. Это чистый опыт. Да, его можно наработать и самому, но мы конвертируем время в деньги (и наоборот) и приносим опыт на блюдечке.
Мы не обещаем, что, пройдя курс, вы сразу станете крутым специалистом. Чтобы освоить все инструменты, нужно много практиковаться. Но начать это делать можно уже во время обучения. И это вторая причина, по которой я бы сам на него пошёл: «Слёрм» даёт практические задания и стенды для их выполнения. У студента есть все возможности, чтобы закрепить знания на практике и получить навыки, которые потом можно оттачивать на реальных проектах.
Сергей, ты один из спикеров курса по мониторингу и логированию в Kubernetes. Как тебе кажется, чем этот курс хорош?
СЕРГЕЙ: Я впервые участвую в создании такой штуки, но, посмотрев на внутреннюю кухню, поучаствовав в проработке одной из тем, пообщавшись с другими спикерами, я понял, что все спикеры максимально детально разжевывают материал, но делают это не в формате старых книг вроде «PHP для чайников», а на реальных практических примерах, затрагивая современные аспекты технологии.
Сама площадка тоже топчик. Я планировал писать на локальном кластере, но потом понял, что всё есть, всё удобно, и с минимальными усилиями за минимальное количество времени ты можешь попробовать выполнять практические задания, в реальном времени видеть результат.
Всё сделано по-максимуму для студента, слушателя курса. Без воды, без лишнего материала. Всё учтено. Такая тонкая грань между вводом и хардкором.
Программа курса максимально последовательная. Когда меня только привлекли к подготовке, я прочитал план и понял, что он составлен идеально. Студента проводят по тем же этапам, которые он бы прошёл сам, настраивая мониторинг и логирование.
Кому будет полезен этот курс?
СЕРГЕЙ: Есть замечательная шутейка, что в современных реалиях Kubernetes — это операционная система, а Helm — просто пакетный менеджер для него. Всем приходится иметь дело с Kubernetes, значит всем нужно знать мониторинг и логирование — такой промышленный стандарт. То есть курс будет полезен всем.
Какие знания необходимы для учёбы?
МАРСЕЛЬ: Мы рассчитывали курс на тех, кто уже знаком с Kubernetes. Знание систем контейнеризации, Docker в первую очередь, тоже горячо приветствуется. Без них будет тяжело, потому что в рамках курса мы не рассказываем о базовых абстракциях.
Предполагается, что у человека есть кластер, он с ним уже работал, но просто не знает, как правильно настроить мониторинг.
Нужно ли идти на курс, если что-то уже настраивал сам?
МАРСЕЛЬ: Думаю, да. У всех свой взгляд, как это сделать и настроить. Иногда я узнаю, как некоторые делают очень страшные вещи, строят костыли, где не надо, и прочее. Поэтому хочется, чтобы люди просвещались в этом вопросе. В рамках обмена опытом, скажем так.
Что ещё важно сказать про курс?
МАРСЕЛЬ: Первая версия прошла тестирование. Бета-тестеры дали очень много фидбека, после которого мы изменили программу. Например, в программе был Zabbix, а потом мы поспрашивали ребят, экспертную группу, и поняли, что он там не нужен, поэтому убрали его и добавили другие темы. Кроме того, мы значительно усилили команду спикеров, подключили ребят из ITSumma.
Бонусом студенты получают видеокурс о Prometheus. Он будет полезен даже для тех, кто с Prometheus никогда не работал.
Узнать больше о курсе и записаться
===========
Источник:
habr.com
===========
Похожие новости:
- [Высокая производительность, Информационная безопасность, IT-инфраструктура, Серверное администрирование] АМА-сессия «Service mesh 2021» 17 февраля
- [Программирование, Управление разработкой, Управление продуктом, Микросервисы] Суровая правда о разработчиках и разработке
- [Amazon Web Services, Microsoft Azure, DevOps, Google Cloud Platform] Как я получил несколько сертификатов по облачным технологиям за 9 месяцев (перевод)
- [Open source, Git, Системы управления версиями, Системы сборки, DevOps] Вышел релиз GitLab 13.8 с редактором конвейеров и первой из метрик DORA (перевод)
- [Open source, Git, DevOps] GitLab oпрос — ждем Bаших предложений
- [Программирование, DevOps, Kubernetes] Круглый стол «Нужно ли разработчику знать Kubernetes» 11 февраля
- [DevOps] Бенчмарк Prometheus vs VictoriaMetrics на метриках node_exporter (перевод)
- [IT-компании, Микросервисы] Микросервисы VS монолит: баттл адептов
- [*nix, Amazon Web Services, Microsoft Azure, Google Cloud Platform, Kubernetes] Calico Enterprise: обзор (перевод)
- [INFOLUST, IT-стандарты, Социальные сети и сообщества] Почему я по-прежнему пользуюсь RSS (перевод)
Теги для поиска: #_devops, #_mikroservisy (Микросервисы), #_kubernetes, #_grafana, #_prometheus, #_kubergraf, #_slerm (слёрм), #_itsumma, #_blog_kompanii_itsumma (
Блог компании ITSumma
), #_blog_kompanii_southbridge (
Блог компании Southbridge
), #_devops, #_mikroservisy (
Микросервисы
), #_kubernetes
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 10:24
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 KubeGraf — это плагин для Grafana, который собирает данные с кластера Kubernetes и приложений внутри него, а затем показывает их на красивых и понятных графиках. В феврале этого года вышел релиз 1.5, и стало известно, что предыдущие версии скачали более 250 тысяч раз! Мы расспросили Сергея Спорышева, создателя плагина и директора направления DevOps-продуктов в ITSumma, об истории создания плагина, факапах и причинах популярности. Сергей Спорышев участвует в создании курса по мониторингу и логированию в «Слёрме», набор на который уже начался. В конце интервью мы немного поговорим и про курс тоже. Как-то, рассказывая о разработке KubeGraf, ты упомянул, что вы хотели сделать универсальный инструмент для мониторинга, который поставил — и ничего больше делать не надо. Что скажешь спустя полтора года: получилось ли? Я думаю, получилось. Здесь логично рассказать, откуда возникла идея плагина. В апреле 2019 года я помогал Евгению Потапову, гендиректору ITSumma, готовить доклад для конференции HighLoad в Питере. Он планировал рассказать про мониторинг Kubernetes: какие есть инструменты, подходы… Всего этого — и методологий, и инструментов, — было очень много, но какого-то более-менее универсального решения, чтобы поставил и ничего делать не нужно, не было. Углубляясь, мы нашли у самой Grafana плагин для мониторинга Kubernetes. Он вроде был жив, но почему-то не поддерживался. Мы его поставили и увидели, что половина функций не работает. Так возникла идея написать своё и докинуть туда багаж практик, который мы наработали внутри компании (одно из направлений ITSumma — как раз техподдержка 24/7 и, соответственно, круглосуточный мониторинг). Была ещё одна вещь, которую мы хотели реализовать. В России раскатка на bare metal — это нормальное явление, а все прогрессивные страны пользуются managed-решениями: Kubernetes от Google, Amazon (у нас теперь ещё Яндекс и Mail.ru). В работе с облаками есть свои нюансы, и мы подумали — почему бы не сделать плагин, который будет эти нюансы учитывать? Такой был план: написать плагин, основываясь на решении, выпущенном самой Grafana, дополнить его своими наработками и сделать так, чтобы он работал везде одинаково. Я думаю, получилось. Лично я его юзаю, и наши клиенты тоже: причём как те, кто на голом железе сидит, так и те, кто сидит в Google и Amazon. Лишних телодвижений делать не приходится никому. А какие фичи плагина ты используешь каждый день? Одна из основных фишек — это как раз возможность работы с облачными провайдерами. Обычно во всех этих системах используется авторизация по сертификатам. В облаке сертификаты тебе никто не даст, поэтому мы сделали возможность работы через токены. Ты применяешь кубовые манифесты, регистрируешь пользователя, выдаешь ему права, и с этим пользователем плагин работает. Мы мониторим как приложения, которые крутятся в Kubernetes, так и ноды, на которых Kubernetes работает. В реальном времени можно смотреть нагрузку по ноде, сколько ресурсов на ней зарезервировано и какие выставлены лимиты. Например, мы индицируем, что у ноды есть всего лишь 2.5 Гб памяти, 2 Гб которых уже зарезервировано, и тогда подкрашиваем ноду жёлтым либо красным, таким образом предупреждая: «Ребят, эта нода скоро закончится». То же самое с лимитами.  В реалтайме видно, какие именно приложения, какие поды Kubernetes крутятся на ноде, их можно группировать. Видно потребление и резервирование, лимитирование ресурсов для конкретного приложения. Это позволяет заметить, например, что какие-то приложения слишком много выжирают и надо бы их расселить.  Второй режим просмотра — это так называемая Карта всех приложений. Виден список всех приложений, как они сгруппированы по неймспейсам, какие сущности за собой тянут, сколько там реплик. Все красивенько отображается.  Ну, и последний ключевой момент — в одном месте сведена информация обо всех предупреждениях, ошибках, критических ситуациях. Ты можешь просто открыть страничку Cluster Status и посмотреть, что у тебя с кластером происходит. Куда надо обратить внимание, куда не надо.   Можешь вспомнить ситуации из своей рабочей практики, когда KubeGraf реально тебе помог? Это случилось, когда мы научились правильно индицировать лимиты, реквесты и всё остальное. На одном из проектов облачный кластер Kubernetes в момент пиковых нагрузок разрастался до 25-26 нод. Мы стали смотреть на данные из плагина и, пользуясь ими, сократили парк почти в два раза. Сейчас этот же кластер с бо̀льшим количеством приложений спокойно работает на 12-13 нодах. При этом ресурсы кластера мы никак не разбирали. Мы просто смотрели, что такие-то приложения при таком-то трафике практически не должны ничего жрать, но потребление вырастает до колоссальных размеров. Анализировали приложение, смотрели, что где можно подтюнить, как именно построен scheduling на основе реквестов. Видели, например, что зарезервировано 1.5 Гб памяти, но за два месяца никто столько никогда не использовал и можно это сократить. Потихоньку-помаленьку сократили кластер в два раза. В новостях о плагине вы писали, что его скачали 250 000 раз… По не совсем официальной информации — да. Это такая информация для разработчиков, её в паблике нет, но вот я нечаянно узнал. Круто! Это много или мало? Много! У нас четыре с лишним сотни клиентов, у одного клиента может быть максимум кластеров 10. Если мы хотя бы 400 умножим на 10 — это 4 000. То есть если бы каждый наш клиент был с Kubernetes, мы бы каждому накатили и получили только 4 000. А тут — четверть миллиона! Это много и это круто. Как думаешь, в чём причина такой популярности? Один из ключевых факторов: плагин от Grafana, о котором я уже упоминал, разработчики по неизвестным причинам перестали поддерживать. И теперь в issues или в pull request на GitHub, я не помню точно, их спрашивают: ребята, вы собираетесь этот инструмент дальше развивать или нет? А они говорят: нет, вот вам ссылка на нормальное решение. И дают ссылку на нас. Плюс сарафанное радио: мы раскидываем плагин клиентам, активно взаимодействуем с сообществом, много где его презентуем. Скорее всего, в этом причина. А если оценивать аудиторию — англоязычную, русскоязычную — как тебе кажется, где KubeGraf больше используют? Мне кажется, это неправильным в современном мире — разделять аудиторию на русскоговорящую и не русскоговорящую. Недавно вышла версия 1.5. Что там нового? Мы починили большое количество ошибок совместимости. В середине 2020 года релизнулась седьмая версия Grafana, там всё еще работало, а с 7.3 начались большие изменения в структуре, поэтому пришлось дорабатывать плагин, чтобы ничего не отваливалось. Плюс добавили поддержку последних версий Kubernetes, доработали, по каким путям мы забираем данные из API Kubernetes. В версии 1.5 мы добавили сбор метрик по лимитам для приложений. До этого работали только с реквестами и текущим потреблением: приложение сколько-то под себя резервирует и сколько-то использует в реальном времени. Но со временем поняли, что очень важна еще и работа с лимитами. Переработали UX, чтобы было удобно для восприятия, добавили реалтайм индикации. Раньше была сводная таблица по всем приложениям, и мы просто видели, сколько они резервируют и потребляют. В 1.5 добавили индикацию: в табличке подсвечено, где что-то не указано, где зеленая зона, где желтая, красная и так далее. Как обычно, были небольшие фиксы: где-то слетела легенда, где-то кнопка не работала — поправили. Последнее ключевое — в сводной таблице по состоянию кластера мы наконец-то догадались ввести сортировку по важности уведомления: жёлтое, красное и т. д. Алертинга у вас нет? Тут можно холиварить долго, но устоявшееся мнение такое: алерты и Grafana — это разные вещи. Алерты в Grafana делать можно, но это неправильно. Для алертинга нужен другой инструмент: Prometheus+Alert Manager, например. Grafana — это про визуализацию. Мы только планируем на графике сделать индикацию алертинга. Ты говорил, что многие фичи появлялись, исходя из ваших потребностей. А были такие, которые вы делали по запросам? Конечно! Здесь соотношение где-то 60/40. 60 — это наша практика. 40 — это общение с комьюнити, с клиентами. Сейчас мы работаем над версией 1.6, и одним из ключевых новшеств в ней будет обновлённый дашборд. К нам пришли клиенты, которые активно юзают плагин, и говорят: ребята, мы пользуемся, всё круто, но хотелось бы увидеть ещё такую вот панель. Мы отвечаем: ну, супер. Запросы на разные фишки по дашбордам тоже приходили от клиентов, так что сообщество играет здесь большую роль. Большая часть, конечно, это наши клиенты, потому что они могут прямо в клиентский чатик написать — я приду, поговорю, обсудим. Заспойлери что-нибудь ещё из версии 1.6. Будет небольшой редизайн, потому что первый макет создавался кустарно. Сначала мы с Женей Потаповым набросали на бумажке, как может выглядеть интерфейс. Потом один из наших разработчиков разобрал тулкит Grafana с визуализационными элементами, и мы просто впихали всё, как было. Позже подключился дизайнер, и где-то в версии 1.3-1.4 мы переработали одну из страниц. Теперь перерабатываем остальные и в 1.6 затащим красоты. Плюс к странице Cluster Status появится сводный дашборд по общему состоянию кластера. Не по отдельным нодам, а именно по всему кластеру, как если бы он был одним большим сервером. Дашборд даст понимание, как он себя чувствует. Ну и мы хотим полностью переписать плагин. С выхода первой версии прошло два года, Grafana выпустила много вспомогательных инструментов для разработки. Поэтому мы полностью переписываем сборку, переходим на использование компонентов от Grafana и другой фреймворк: плагин написан на Angular, а где-то год назад пошёл тренд на React-плагины, поэтому я думаю, что после 1.6 будет сразу версия 2.0 на React. С какой скоростью выпускаете новые версии? Критичные минорные изменения вносим так быстро, как это только возможно, но вообще стараемся релизиться раз в два месяца. Только с версией 1.5 что-то пошло не так — готовили её почти полгода. Сказался и личный загруз (это все-таки наш open source проект), и эпидемия, и задержки со стороны Grafana. С релиза версии может пройти от недели до двух месяцев, когда её примут и опубликуют на сайте Grafana. Поэтому релизный цикл плавающий. Как устроена работа над плагином: сколько человек в команде, сколько времени каждый из вас уделяет разработке? Команда — это два разработчика: я и мой коллега Дмитрий Воронов. Когда нужно, подключаем дизайнера. Менеджерю этот процесс я сам. Если по работе у нас ничего не горит, то понедельник мы посвящаем плагину. Понедельник у нас — Grafana Day, такая разминка перед тяжёлой рабочей неделей. То есть это не выходные, не ночь, а полноценный рабочий день? Да. Единственное — это предрелизная штука, когда обычно я на себя всё захватываю. Там может выжирать и три дня в неделю. Но стандартно — день. В таком режиме получается отдыхать от плагина? Когда два года делаешь какую-то штуку, она может слегка поднадоесть, нет? Бывает такое, но можно взять на неделю перерыв. Это же pet project: поднадоело — давайте отложим. Были за эти два года такие факапы, которые прям совсем факапы? Конечно, они бывают в любой разработке. Как-то раз выкатили версию, которая не работала. Потестили на одной из версий Grafana, а на остальных нет. Где-то всё поехало, где-то метрики перестали приходить. Заметили довольно быстро, потому что мы обычно, пока ждём официального релиза от Grafana, ходим и через Git и обновляем это всё у наших клиентов. Видим, где ломается. Второй факап был прямо жёсткий. В одной из версий Kubernetes и Prometheus полностью сменился лейблинг. До этого в основных метриках было два лейбла: container name и pod name, а тут они поменялись на container и pod (я уже сейчас не вспомню точно). В какой-то момент мы заметили, что нейминг разъехался: здесь мы собираем по pod, здесь по pod name; здесь по container, здесь по container name. И у нас половина плагина работала, половина не работала. Никто сначала ничего не мог понять. Пришлось пойти, разобраться, упороться регулярками, которые все ненавидят. Ну и вроде собрали, заработало. Но, в целом, за счет того, что time-to-market у плагина очень высокий, у нас всегда есть минимум две недели в ожидании релиза, когда можно сходить всё исправить. То есть факапы — они локальные, в паблик не могут уйти. Если бы ты сейчас подходил к разработке плагина, что-нибудь бы сделал иначе? Думаю, нет. Я даже не знаю, что можно было изменить, потому что оно как шло по желанию, так и шло. Какие-то фишки придумывались, какие-то дорабатывались. Что-то изменить? Не знаю. Какую побочную, помимо технической, пользу принёс плагин тебе самому и вашей компании? Brand awareness — узнаваемость бренда. Это самое большое, что мы получили. Когда компания выпускает open source продукты, она закрепляет свою экспертизу, повышает узнаваемость. На приток клиентов не рассчитывали. Хотели только, чтобы нас узнавали, чтобы люди понимали, что мы это умеем и в этом шарим. Мне кажется, у нас получилось, потому что про плагин писали везде. Очень много материалов в интернете, и везде ссылочки на нас. Да, определённый процент клиентов приходили с плагина: понимали, что в теме Kubernetes и мониторинга нам можно довериться, и работали с нами дальше. В небольшом видео с анонсом версии 1.5 ты сказал, что вы планируете сделать плагин отдельным продуктом. Что это за идеи? У нас была мысль сделать плагин прямо такой stand-alone версией, потому что мы наработали большое количество практик в работе с Kubernetes, и хотели бы их реализовать в отдельном продукте. Мы думаем про сервис, который будет делать не только визуализацию, но поможет проводить аудит кластера и тюнить его. Grafana здесь будет только мешать, поэтому думаем оформить его в виде stand-alone решения, которое просто так же поставил через Helm и видишь красивую картиночку, где у тебя что происходит. Но это всё пока только на уровне проработки концепции. Еще какие-то плагины делать? Я пока не знаю. У нас было много идей, как можно что-то визуализировать. Пока руки не доходят. Если это будет отдельный продукт, который будет шире, чем просто мониторинг и визуализация, он будет платным? Open source продукты принято делать бесплатными. Но, например, Grafana тоже open source, но есть Grafana Enterprise. Мне кажется, этот продукт будет в двух вариациях — free и с какой-то подпиской. Такой серьезный продукт придётся не только по понедельникам делать. Да. Выходит, ITSumma сейчас смотрит чуть в сторону open sourse, в направлении разработки своих продуктов? Конечно! Нужны же какие-то артефакты работы компании. Хоть что-то после себя оставить нужно. На этом мы закончили обсуждать плагин KubеGraf и немного поговорили о видеокурсе по мониторингу Kubernetes, который Сергей Спорышев вместе с другими спикерами разрабатывал в «Слёрме». К беседе присоединился СТО «Слёрма» Марсель Ибраев. Что будет в новом курсе? МАРСЕЛЬ: Мы будем говорить о том, как мониторить и собирать логи с приложений, которые запущены в кластере, и с самого кластера Kubernetes. Потому что просто поднять кластер — это полдела, и с этим справляется большинство, а вот правильно настроить сбор логов и метрик уже получается не у всех. Цель курса — рассказать и показать лучшие практики. Стоит ли идти на курс по логированию тем, кто уже проходил курсы по Kubernetes в «Слёрме»? МАРСЕЛЬ: Стоит, потому что в наших курсах по Kubernetes не раскрывается тема логирования и мониторинга. Мы пробовали её включить в первые базовые курсы, но получалось не очень: материала много, и дать его в рамках двух занятий внутри обзорного курса по Kubernetes невозможно. Уже тогда была идея, что надо делать что-то отдельное. Наконец-то мы к этому пришли. Чем хорош курс? Почему вы бы сами на него пошли? МАРСЕЛЬ: Во-первых, курс подготовили практикующие инженеры — ребята, которые каждый день работают с Kubernetes, набивают шишки. Они рассказывают именно то, что нужно знать. Это чистый опыт. Да, его можно наработать и самому, но мы конвертируем время в деньги (и наоборот) и приносим опыт на блюдечке. Мы не обещаем, что, пройдя курс, вы сразу станете крутым специалистом. Чтобы освоить все инструменты, нужно много практиковаться. Но начать это делать можно уже во время обучения. И это вторая причина, по которой я бы сам на него пошёл: «Слёрм» даёт практические задания и стенды для их выполнения. У студента есть все возможности, чтобы закрепить знания на практике и получить навыки, которые потом можно оттачивать на реальных проектах. Сергей, ты один из спикеров курса по мониторингу и логированию в Kubernetes. Как тебе кажется, чем этот курс хорош? СЕРГЕЙ: Я впервые участвую в создании такой штуки, но, посмотрев на внутреннюю кухню, поучаствовав в проработке одной из тем, пообщавшись с другими спикерами, я понял, что все спикеры максимально детально разжевывают материал, но делают это не в формате старых книг вроде «PHP для чайников», а на реальных практических примерах, затрагивая современные аспекты технологии. Сама площадка тоже топчик. Я планировал писать на локальном кластере, но потом понял, что всё есть, всё удобно, и с минимальными усилиями за минимальное количество времени ты можешь попробовать выполнять практические задания, в реальном времени видеть результат. Всё сделано по-максимуму для студента, слушателя курса. Без воды, без лишнего материала. Всё учтено. Такая тонкая грань между вводом и хардкором. Программа курса максимально последовательная. Когда меня только привлекли к подготовке, я прочитал план и понял, что он составлен идеально. Студента проводят по тем же этапам, которые он бы прошёл сам, настраивая мониторинг и логирование. Кому будет полезен этот курс? СЕРГЕЙ: Есть замечательная шутейка, что в современных реалиях Kubernetes — это операционная система, а Helm — просто пакетный менеджер для него. Всем приходится иметь дело с Kubernetes, значит всем нужно знать мониторинг и логирование — такой промышленный стандарт. То есть курс будет полезен всем. Какие знания необходимы для учёбы? МАРСЕЛЬ: Мы рассчитывали курс на тех, кто уже знаком с Kubernetes. Знание систем контейнеризации, Docker в первую очередь, тоже горячо приветствуется. Без них будет тяжело, потому что в рамках курса мы не рассказываем о базовых абстракциях. Предполагается, что у человека есть кластер, он с ним уже работал, но просто не знает, как правильно настроить мониторинг. Нужно ли идти на курс, если что-то уже настраивал сам? МАРСЕЛЬ: Думаю, да. У всех свой взгляд, как это сделать и настроить. Иногда я узнаю, как некоторые делают очень страшные вещи, строят костыли, где не надо, и прочее. Поэтому хочется, чтобы люди просвещались в этом вопросе. В рамках обмена опытом, скажем так. Что ещё важно сказать про курс? МАРСЕЛЬ: Первая версия прошла тестирование. Бета-тестеры дали очень много фидбека, после которого мы изменили программу. Например, в программе был Zabbix, а потом мы поспрашивали ребят, экспертную группу, и поняли, что он там не нужен, поэтому убрали его и добавили другие темы. Кроме того, мы значительно усилили команду спикеров, подключили ребят из ITSumma. Бонусом студенты получают видеокурс о Prometheus. Он будет полезен даже для тех, кто с Prometheus никогда не работал. Узнать больше о курсе и записаться =========== Источник: habr.com =========== Похожие новости:
Блог компании ITSumma ), #_blog_kompanii_southbridge ( Блог компании Southbridge ), #_devops, #_mikroservisy ( Микросервисы ), #_kubernetes |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 10:24
Часовой пояс: UTC + 5