kubebox и другие консольные оболочки для Kubernetes

Мы уже писали о «консольных помощниках» для Kubernetes год назад, а ещё раньше делали обзор других полезных утилит. Однако с развитием K8s и его сообщества претерпевает изменения и сопутствующая экосистема. Поэтому нам снова есть о чём рассказать любителям консоли. Поехали!

kubebox

• GitHub (400+ stars)
• Язык: JavaScript (Node.js)
• Лицензия: MIT

Этот проект и послужил поводом для написания обзора. С одной стороны он является ярким представителем софта категории «гики делают для гиков», но с другой — дорос до того состояния, когда не только радует глаз, но и приносит практическую пользу…

Итак, предназначение kubebox — полноценная работа с Kubernetes в рамках удобного консольного интерфейса, представленного в стиле псевдографики:

Под работой подразумеваются такие возможности, как навигация по подам через пространства имён, просмотр логов и даже графиков потребления ключевых ресурсов (CPU, память, сеть), удалённое исполнение команд в контейнерах. Настройки для подключения к кластерам могут забираться из переменной окружения KUBECONFIG или конфигов в $HOME/.kube.

В дальнейших планах разработчиков — поддержка редактирования конфигураций и выполнения CRUD-операций, а также значительная переработка интерфейса для поддержки новых видов примитивов (Services, Deployments и др.) и удобной навигации по ним с выводом дополнительных сведений (в частности, kubectl describe pod).

Важная особенность — наличие онлайн-версии (для подключения к API-серверу Kubernetes потребуются разрешенные cors-allowed-origins). Кроме того, kubebox может запускаться как отдельный исполняемый файл, как клиент in-cluster (через kubectl), а также из сервиса, развёрнутого в кластере Kubernetes или OpenShift (для эмуляции терминала используется Xterm.js).

Разработкой kubebox уже почти 2 года занимается сотрудник Red Hat из Франции (если быть совсем точным, то ещё менее 10 % коммитов сделаны его коллегой). Достаточно широкую огласку проект получил только в прошлом месяце (на Reddit и ряде других ресурсов), так что можно ожидать, что это придаст новый импульс его развитию.

kube-shell и kube-prompt

kube-shell

• GitHub (950+ stars)
• Язык: Python
• Лицензия: Apache 2.0

(Внимание, эта GIF'ка на ~2 Мб!)

kube-prompt

• GitHub (700+ stars)
• Язык: Go
• Лицензия: MIT

Про эти проекты мы уже писали год назад, и на то время они были безоговорочными фаворитами среди полноценных консольных оболочек для работы с Kubernetes. Оба позиционируются как улучшенные (более удобные в работе) интерфейсы к kubectl. В kube-shell для этого используют библиотеку prompt-toolkit для Python, а для kube-prompt взяли и разработали схожую библиотеку на Go (go-prompt).

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

Несмотря на широкий спектр поддерживаемых возможностей (включая уже упомянутую развитую систему подсказок и автодополнений, поиск по истории команд и vi-подобный режим редактирования), история коммитов в kube-shell говорит о явном замедлении темпов развития проекта. В этом году зафиксировано всего семь коммитов, два из которых — модификации README. Хотя были и полезные — например, долгожданная поддержка переменной KUBECONFIG. Так или иначе, продолжительное отсутствие реакции разработчиков на актуальные для пользователей запросы (см. issues) не внушает должных перспектив.

Ситуация с развитием kube-prompt выглядит незначительно лучше. Хотя этот проект набрал меньше звёздочек на GitHub (если год назад он немного опережал своего Python-конкурента, то теперь заметно отстаёт), коммиты появляются более-менее регулярно, а последний релиз (1.0.5) датируется 18 октября. Однако значимых изменений за последний год не так много — отметим поддержку Kubernetes версии 1.11 и возможность автодополнения для пространства имён. Главное же в том, что сам автор признаёт невозможность уделять развитию kube-prompt достаточное время и ищет себе помощников.

Подводя итоги по этим двум проектам, можно сказать, что kube-shell сохранил лидерство в плане поддерживаемых возможностей и вышел вперёд по популярности, но вот с перспективами у обоих оболочек не всё ясно. Впрочем, если вас устраивает то, как они работают сейчас, нет причин не взять их на вооружение, т.к. иных альтернатив в аналогичном исполнении не появилось.

Click

• GitHub (750+ stars)
• Язык: Rust
• Лицензия: Apache 2.0

Click — довольно молодой проект: в виде бета-версии он был представлен в конце марта — и очень по-своему интересный. Его концепция сводится к тому, чтобы использовать kubectl в цикле REPL, который упрощает жизнь тем, что поддерживает постоянное окружение. Последнее заключается в том, что Click «помнит» текущий контекст, namespace, под и т.п., предлагая пользователю выполнить нужную команду для данного ресурса без необходимости повторно указывать весь этот «путь».

Идея проекта зародилась в компании Databricks, где активно используют Kubernetes и устали наблюдать однотипный сценарий работы с kubectl, требующий постоянного введения предшествующих данных. При этом саму утилиту kubectl — как и консоль вообще — инженеры очень любят. Так и появилась эта надстройка, не претендующая на замену kubectl, а лишь помогающая в работе с ним. Примерный сценарий использования Click таков:

pods // запросить список подов для текущего контекста и пространства имён
2 // выбрать второй под из списка
describe // вывести описание этого пода
events // посмотреть недавние события
logs -c foo > /tmp/podfoo.log // сохранить логи в файл
delete // удалить под (с запросом на подтверждение операции)

Если заинтересовались — смотрите также небольшой скринкаст, демонстрирующий работу Click с текстовыми комментариями.

Работа с логами

Как бонус — не оболочки, но консольные инструменты для работы с логами в Kubernetes. Ещё год назад в качестве таковых мы упоминали лишь k8stail, но прошедшее время показало, что проблема актуальна, и для её решения есть другие достойные внимания решения.

Stern

• GitHub (~1300 stars)
• Язык: Go
• Лицензия: Apache 2.0

Stern — безусловный фаворит категории «tail для подов в Kubernetes». Для наглядности при выводе логов используются разные цветовые обозначения:

Другой его важной особенностью является использование регулярных выражений для удобной фильтрации подов без потребности знать конкретные ID (например, отобрать все с названием web-w+). Аналогично (т.е. регэкспами) можно фильтровать и определённые контейнеры для запрашиваемых подов. Среди прочих возможностей stern:

• поддержка кастомных Go-шаблонов для выводимых логов (есть несколько предопределённых стандартно);
• поддержка label selectors;
• ограничение вывода логов заданным значением времени --since и/или заданным количеством строк;
• поддержка автодополнения для bash и zsh, а также динамической подстановки значений пространств имён и контекстов.

Kubetail

• GitHub (~950 stars)
• Язык: Shell
• Лицензия: Apache 2.0

Схожее решение, написанное на обычном Bash и чуть более активно развиваемое в последний год. Как и stern, поддерживает выделение цветом названия подов (или же всей строки, что настраивается):

Тоже позволяет фильтровать поды и контейнеры как по полным названиям, так и по регулярным выражениям, а также использовать селекторы, ограничивать вывод временем и количеством строк, поддерживает автодополнение для Bash, zsh и fish. Среди других возможностей:

• отключаемый режим --follow для обновления данных из логов в реальном времени (как в tail -f);
• --dry-run для вывода списка подходящих подов и контейнеров без выполнения каких-либо других действий;
• поддержка jq-селектора для парсинга вывода в JSON.

Kail

• GitHub (~500 stars)
• Язык: Go
• Лицензия: MIT

Ещё одна реализация, у которой за последний год наблюдается наименьшая активность в кодовой базе. Тем не менее, у неё есть интересные функциональные особенности, отличающие от своих конкурентов, а именно:

• ограничение по запросу подов названиями их Service, ReplicationController, ReplicaSet, Deployment, Node и/или Ingress (т.е. подов, принадлежащих сервисам, на которые ведёт указанный Ingress);
• возможность не только выбирать по селекторам, но и исключать по ним;
• определение уровня логирования (--log-level).

Но есть и минусы: kail не выделяет поды цветами, не поддерживает регулярные выражения для фильтров.

P.S.

Спасибо за интерес и, конечно же, будем рады информации о ваших находках в комментариях!

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

• «Консольные помощники для работы с Kubernetes через kubectl»;
• «Полезные утилиты при работе с Kubernetes»;
• «Знакомство с kube-spawn — утилитой для создания локальных Kubernetes-кластеров»;
• «Awless — мощная альтернативная CLI-утилита для работы с сервисами AWS»;
• «Обзор GUI-интерфейсов для управления Docker-контейнерами».

Автор: Дмитрий Шурупов

Источник