company_banner

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



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

    kubebox


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

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

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

    image

    Под работой подразумеваются такие возможности, как навигация по подам через пространства имён, просмотр логов и даже графиков потребления ключевых ресурсов (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.


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

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

    • +15
    • 6.2k
    • 6
    Флант
    485.30
    Специалисты по DevOps и Kubernetes
    Support the author
    Share post

    Comments 6

      0
      Расскажите, пожалуйста, как вы сделали векторную гифку.
        0
        Рассказал бы, но все анимации взяты с сайтов/github'ов проектов…
          0
          Как вы поняли, что она векторная?
            +1
            Откройте её в новой вкладке (https://habrastorage.org/getpro/habr/post_images/b25/799/ddd/b25799ddd6a4aa7c0a4b8d3d106d2c9e.svg).
            Во-первых, svg, а во-вторых, текст селектится мышкой.
        +1
        Много полезных утилит, спасибо.
        Из утилит для чтения логов больше всего понравился Stern. Регулярки очень помогают.
        Еще порадовали kubectx и kubens (упоминались как раз тут).

        Only users with full accounts can post comments. Log in, please.