Прим. перев.: Автор оригинального материала — 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.от переводчика
Читайте также в нашем блоге:
- «kubebox и другие консольные оболочки для Kubernetes»;
- «Инструменты для разработчиков приложений, запускаемых в Kubernetes»;
- «Появилась консольная утилита kubelive для интерактивной работы с Kubernetes»;
- «Полезные утилиты при работе с Kubernetes».
Автор: Wimbo
