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

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

vzqwtrl-t4rsh_6f0bqmavl3mb4.png

В этой публикации я рассматриваю различные веб-интерфейсы 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:

1no26-hxe8ds1vs4tyaxnv4ahu8.png

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

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

K8Dash


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

6ycuds12js0hy3408w_megxkw5u.png

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

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


Kubernator


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

_zmjn_qxcqukooo4vtksjhczkk8.png

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

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


Kubernetes Dashboard


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

d902pktzec6--iruodkki6m3sbw.png

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

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


Kubernetes Operational View (kube-ops-view)


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

4i9rtap-4fzd7l2pjzwvbc7uw20.png

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

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

Kubernetes Resource Report (kube-resource-report)


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

j6yvuy-tcogm5018a47yvdvpfiu.png

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

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

Octant


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

f7rl3ozckrncndrzioikzvstkk0.png

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

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


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

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


«kubectl для веба».

q8elanjd3fijcjdpcxium-wzzn0.png

Проанализировав доступные варианты интерфейсов для 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-файле объекта, указывая на потенциальные проблемы в спецификации объекта.

dx9nn6qwnbhf3dzf0rp-s5nredc.png
Поиск по кластерам в Kubernetes Web View

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


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

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

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

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

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

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


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

Habrahabr.ru прочитано 18766 раз