Анонс веб-интерфейса Kubernetes Web View (и краткий обзор других web UI для Kubernetes)

Прим. перев.: Автор оригинального материала — Henning Jacobs из компании Zalando. Он создал новый веб-интерфейс для работы с Kubernetes, который позиционируется как «kubectl для веба». Почему новый Open Source-проект появился и каким критериям не удовлетворили уже существующие решения — читайте в его статье.

В этой публикации я рассматриваю различные веб-интерфейсы Kubernetes с открытым исходным кодом, предъявляю свои требования к универсальному UI и рассказываю, почему разработал Kubernetes Web View — интерфейс, призванный облегчить поддержку и устранение неполадок сразу во множестве кластеров.

Сценарии использования

В Zalando мы обслуживаем большое количество пользователей Kubernetes (900+) и кластеров (100+). Есть пара типичных случаев использования, в которых бы очень пригодилась помощь специализированного веб-инструмента:

1. общение с коллегами в рамках поддержки;
2. реагирование на инциденты и расследование их причин.

Поддержка

По моему опыту, общение в рамках поддержки часто выглядит следующим образом:

— Помогите, наш сервис XYZ недоступен!
— Что вы видите, когда выполняете kubectl describe ingress ...?

Или нечто похожее для CRD:

— У меня какая-то проблема с сервисом идентификации…
— А что выдает команда kubectl describe platformcredentialsset ...?

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

Поэтому хочется, чтобы веб-фронтенд к Kubernetes позволял следующее:

• пользователи могли бы обмениваться ссылками и наблюдать одно и то же;
• помогал бы избегать человеческих ошибок в поддержке: например, входа не в тот кластер в командной строке, опечаток в командах CLI и т. п.;
• позволял бы генерировать собственные представления для отправки коллегам, то есть добавлять столбцы меток, отображать множество типов ресурсов на одной странице;
• в идеале этот веб-инструмент должен позволять ставить «глубокие» ссылки на конкретные разделы YAML (например, указывать на неправильный параметр, вызывающий сбои).

Реагирование на инциденты и анализ

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

• у критически важного production-сервиса возникают проблемы и вам необходимо найти все ресурсы Kubernetes по имени во всех кластерах, чтобы устранить неполадки;
• узлы начинают падать при масштабировании, и вам необходимо найти все pod’ы со статусом «Pending» во всех кластерах, чтобы оценить размах проблемы;
• отдельные пользователи сообщают о проблеме с DaemonSet, развернутым во всех кластерах, и необходимо выяснить, имеет ли проблема тотальный характер.

Мое стандартное решение в таких случаях — нечто вроде for i in $clusters; do kubectl ...; done. Очевидно, можно разработать инструмент, предоставляющий аналогичные возможности.

Существующие веб-интерфейсы Kubernetes

Open Source-мир веб-интерфейсов к Kubernetes не слишком велик*, так что я попробовал собрать дополнительную информацию с помощью Twitter:

* Мое объяснение ограниченного числа веб-интерфейсов для Kubernetes: облачные сервисы и вендоры Kubernetes обычно предлагают собственные фронтенды, поэтому рынок для «хороших» свободных Kubernetes UI сравнительно невелик.

С помощью твита я узнал о K8Dash, Kubernator и Octant. Посмотрим на них и другие существующие Open Source-решения, попробуем понять, что они собой представляют.

K8Dash

«K8Dash — это простейший способ управлять кластером Kubernetes».

K8Dash неплохо выглядит и по ощущениям быстро работает, но обладает рядом недостатков для перечисленных выше сценариев использования:

• Работает только в границах одного кластера.
• Сортировка и фильтрация возможны, но не имеют постоянных ссылок.
• Отсутствует поддержка Custom Resource Definitions (CRDs).

Kubernator

«Kubernator — это альтернативный UI для Kubernetes. В отличие от высокоуровневой панели Kubernetes Dashboard, он обеспечивает низкоуровневый контроль и отличный обзор всех объектов в кластере с возможностью создавать новые, редактировать их и разрешать конфликты. Будучи целиком клиентским приложением (как kubectl), он не требует какого-либо бэкенда за исключением самого API-сервера Kubernetes, а также учитывает правила доступа к кластеру».

Это довольно точное описание Kubernator’а. Увы, ему не хватает некоторых возможностей:

• Обслуживает только один кластер.
• Нет режима просмотра в виде списка (т. е. нельзя вывести все pod’ы со статусом «Pending»).

Kubernetes Dashboard

«Kubernetes Dashboard — это универсальный веб-интерфейс для кластеров Kubernetes. Он позволяет пользователям управлять приложениями, работающими в кластере, и устранять их неполадки, а также управлять самим кластером».

К сожалению, Kubernetes Dashboard не особо помогает в моих мероприятиях по поддержке и реагированию на инциденты, потому что в нём:

• нет постоянных ссылок, например, когда я фильтрую ресурсы или меняю порядок сортировки;
• нет простого способа фильтровать по статусу — например, увидеть все pod’ы со статусом «Pending»;
• поддерживается только один кластер;
• не поддерживаются CRD (эта функция в процессе разработки);
• нет пользовательских столбцов (например, столбцов с метками по типу kubectl -L).

Kubernetes Operational View (kube-ops-view)

«Системная панель-наблюдатель за пространством кластеров K8s».

У Kubernetes Operational View совершенно другой подход: этот инструмент только показывает узлы кластера и pod’ы с помощью WebGL, без каких-либо текстовых подробностей объектов. Он отлично подходит для оперативного обзора состояния кластера («pod’ы падают?»)*, но не подходит для описанных выше случаев использования в поддержке и реагировании на инциденты.

* Прим. перев.: В этом смысле вас также может заинтересовать наш плагин grafana-statusmap, о котором мы рассказывали подробнее в этой статье.

Kubernetes Resource Report (kube-resource-report)

«Собирайте сведения о запросах на ресурсы pod’ов и кластера Kubernetes, сравнивайте их с потреблением ресурсов и генерируйте статичный HTML».

Kubernetes Resource Report генерирует статичные HTML-отчеты об использовании ресурсов и распределении затрат по командам/приложениям в кластерах. Отчет в некоторой степени полезен для поддержки и реагирования на инциденты, поскольку позволяет быстрее найти кластер, в котором развернуто приложение.

Прим. перев.: В просмотре сведений о распределении ресурсов и их стоимости у облачных провайдеров может также оказаться полезным сервис и инструмент Kubecost, обзор которого мы недавно публиковали.

Octant

«Расширяемая веб-платформа для разработчиков, призванная обеспечить лучшее понимание сложности кластеров Kubernetes».

Octant, созданный в VMware, — новый продукт, о котором я узнал сравнительно недавно. С его помощью удобно исследовать кластер на локальной машине (есть даже визуализации), однако он затрагивает проблематику поддержки и реагирования на инциденты лишь в ограниченной степени. Недостатки Octant:

• Нет поиска по кластерам.
• Работает только на локальной машине (не развертывается в кластере).
• Невозможно сортировать/фильтровать объекты (поддерживается только селектор меток).
• Нельзя задавать пользовательские столбцы.
• Нельзя выводить список объектов по пространствам имен.

Также у меня был проблемы с устойчивостью работы Octant с кластерами Zalando: на некоторых CRD он падал.

Представляю Kubernetes Web View

«kubectl для веба».

Проанализировав доступные варианты интерфейсов для Kubernetes, я решил создать новый: Kubernetes Web View. Ведь по сути мне всего лишь нужна вся мощь kubectl в вебе, а именно:

• доступность всех (read-only) операций, в которых пользователи предпочитают использовать kubectl;
• все URL должны быть постоянными и представлять страницу в оригинальном виде, чтобы коллеги могли обмениваться ими и использовать в других инструментах;
• поддержка всех объектов Kubernetes, что позволит решать проблему любого типа;
• списки ресурсов должны быть скачиваемыми для дальнейшей работы (в электронных таблицах, CLI-инструментах вроде grep) и хранения (например, для postmortem’ов);
• поддержка отбора ресурсов по лейблам (по аналогии с kubectl get .. -l);
• возможность создавать объединенные списки различных типов ресурсов (по аналогии с kubectl get all) для получения общей операционной картины среди коллег (например, в процессе реакции на инцидент);
• возможность добавлять настраиваемые «умные» глубокие ссылки к другим инструментам, таким как панели мониторинга, логгеры, реестры приложений и т.п. для облегчения поиска/устранения ошибок и реагирования на инциденты;
• фронтенд должен быть максимально простым (чистый HTML), чтобы избежать случайных проблем, например, зависшего JavaScript;
• поддержка множества кластеров для упрощения взаимодействия при удаленном консультировании (например, чтобы запоминать лишь один URL);
• при возможности должен упрощаться ситуативный анализ (например, с ссылками на скачивание ресурсов по всем кластерам/пространствам имен);
• дополнительные возможности по формированию гибких ссылок и выделению текстовой информации, например, чтобы можно было указать коллегам на определенный раздел в описании ресурса (строку в YAML);
• возможность подстройки под требования конкретного клиента, например, позволяя создавать специальные шаблоны отображения для CRD, свои табличные представления, изменять CSS-стили;
• средства для дальнейшего изучения в командной строке (например, показывая полноценные команды kubectl, готовые для копирования);

Вне решаемых в Kubernetes Web View задач (non-goals) остались:

• абстрагирование объектов Kubernetes;
• управление приложениями (например, управление deployment’ами, Helm-чартами и т.п.);
• операции записи (должны осуществляться через безопасный инструментарий CI/CD и/или GitOps);
• красивый интерфейс (JavaScript, темы и т.п.);
• визуализации (см. kube-ops-view);
• анализ затрат (см. kube-resource-report).

Как Kubernetes Web View помогает в поддержке и реагировании на инциденты?

Поддержка

• Все ссылки — постоянные, что облегчает обмен информацией с коллегами.
• Можно создавать свои представления, например, вывести все Deployment’ы и Pod’ы с определенной меткой в двух конкретных кластерах (несколько имен кластеров и типов ресурсов можно задавать в ссылке, разделяя их запятыми).
• Можно ссылаться на определенные строки в YAML-файле объекта, указывая на потенциальные проблемы в спецификации объекта.

Поиск по кластерам в Kubernetes Web View

Реагирование на инциденты

• Глобальный поиск (global search) позволяет искать объекты во всех кластерах.
• Представления в виде списков могут отображать все объекты с определенным состоянием/столбцом во всех кластерах (например, нам нужно найти все pod’ы со статусом «Pending»).
• Списки объектов можно скачивать в формате значений, разделенных табуляцией (TSV), для последующего анализа.
• Настраиваемые внешние ссылки позволяют переключаться на соответствующие панели мониторинга и другие инструменты.

Kubernetes Web View: список pod’ов со статусом «Pending» во всех кластерах

Если желаете попробовать Kubernetes Web View, рекомендую ознакомиться с документацией или посмотреть на живую демо-версию.

Конечно, интерфейс мог бы быть и получше, а пока Kubernetes Web View является инструментом для «продвинутых пользователей», которые не чураются манипулирования с URL-путями вручную, если это необходимо. Если у вас есть замечания/дополнения/пожелания, пожалуйста, свяжитесь со мной в Twitter!

Эта статья является кратким рассказом о предпосылках, которые привели к созданию Kubernetes Web View. За ней последуют другие! (Прим. перев.: Их следует ожидать в блоге автора.)

P.S.от переводчика

Читайте также в нашем блоге:

• «kubebox и другие консольные оболочки для Kubernetes»;
• «Инструменты для разработчиков приложений, запускаемых в Kubernetes»;
• «Появилась консольная утилита kubelive для интерактивной работы с Kubernetes»;
• «Полезные утилиты при работе с Kubernetes».

Источник: habr.com