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

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

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

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

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

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

Поддержка

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

— Помогите, наш сервис 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.от переводчика

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

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