kubebox and other console shells for Kubernetes

We already wrote about “console helpers” for Kubernetes a year ago, and even earlier we did a review of other useful utilities. However, with the development of K8s and its community, the associated ecosystem is also changing. Therefore, we again have something to tell console lovers. Go!

kubebox

GitHub (400+ stars)
Language: JavaScript (Node.js)
License: MIT

This project was the reason for writing a review. On the one hand, he is a bright representative of the software category "geeks do for geeks", but on the other hand, he has grown to a state where he is not only pleasing to the eye, but also brings practical benefits ...

So, the purpose of the kubebox is to fully work with Kubernetes as part of a convenient console interface presented in the style of pseudo-:

Under work involves features such as navigation through the file a name space, view logs, and even graphs of key resources consumption (CPU, memory, network), remote command execution in konteyne ah. Settings for connecting to clusters can be taken from the environment variable KUBECONFIGor configs in $HOME/.kube.

Future plans of developers include support for editing configurations and performing CRUD operations, as well as significant reworking of the interface to support new types of primitives (Services, Deployments, etc.) and easy navigation through them with additional information (in particular kubectl describe pod).

An important feature is the availability of an online version (to connect to the API server Kubernetes, you will need to be allowed cors-allowed-origins). In addition, kubebox can be launched as a separate executable file, as an in-cluster client (via kubectl), as well as from a service deployed in a Kubernetes or OpenShift cluster ( Xterm.js is used to emulate the terminal ).

The development of kubebox for almost 2 years has been done by a Red Hat employee from France (to be quite precise, even less than 10% of commits are made by his colleague). The project received quite wide publicity only last month (on Reddit and a number of other resources), so one can expect that this will give a new impetus to its development.

kube-shell and kube-prompt

kube-shell

GitHub (950+ stars)
Language: Python
License: Apache 2.0

(Attention, this GIF is ~ 2 MB!)

kube-prompt

GitHub (700+ stars)
Language: Go
License: MIT

We already wrote about these projects a year ago, and at that time they were unconditional favorites among full-fledged console shells for working with Kubernetes. Both are positioned as improved (more convenient to use) interfaces to kubectl. In the kube-shell, use the prompt-toolkit library for Python for this , and for the kube-prompt, they took and developed a similar Go library ( go-prompt ).

If you compare them with kubebox, here the interface is not based on pseudo graphics, but on a familiar console for entering commands (see screenshots above) , which, however, is accompanied by very interesting “special effects”: tooltips with help by commands, convenient automatic addition and etc.

Despite the wide range of supported features (including the already mentioned developed hint and autocompletion system, a search in command history and the vi-like editing mode), the kube-shell commit history indicates a clear slowdown in the development of the project. This year only seven commits were recorded, two of which are modifications README. Although there were useful - for example, the long-awaited support for the variable KUBECONFIG. One way or another, the prolonged lack of response from developers to requests that are relevant to users (see issues ) does not inspire proper prospects.

The situation with the development of kube-prompt looks slightly better. Although this project scored fewer stars on GitHub (if a year ago it was slightly ahead of its Python competitor, it is now noticeably lagging behind), commits appear more or less regularly, and the latest release ( 1.0.5 ) dates back to October 18th. However, there are not many significant changes over the past year - we note the support for Kubernetes version 1.11 and the possibility of autocompletion for the namespace. The main thing is that the author himself admits that it is impossible to devote sufficient time to the development of the kube-prompt and is looking for helpers.

Summing up on these two projects, it can be said that the kube-shell retained its leadership in terms of supported capabilities and went ahead in popularity, but with the prospects for both shells all is not clear. However, if you are satisfied with the way they work now, there is no reason not to take them into service, because other alternatives in the same performance did not appear.

Click

GitHub (750+ stars)
Language: Rust
License: Apache 2.0

Click is a rather young project: in the form of a beta version it was presented at the end of March - and very interesting in its own way. His concept is to use kubectl in the REPL loop , which simplifies life by supporting a constant environment. The last is that Click "remembers" the current context, namespace, under, etc., prompting the user to execute the necessary command for this resource without having to re-specify the whole "path".

The idea of the project originated in the company Databricks, where Kubernetes actively use and are tired of seeing the same type of work with kubectl, which requires the constant introduction of previous data. At the same time, the engineers themselves love the kubectl utility itself - just like the console in general. And so this add-in appeared, which does not claim to replace kubectl, but only helps in working with it. An example scenario of using Click is as follows: If you are interested, see also a small screencast demonstrating how Click works with text comments.

pods // запросить список подов для текущего контекста и пространства имён

2 // выбрать второй под из списка

describe // вывести описание этого пода

events // посмотреть недавние события

logs -c foo > /tmp/podfoo.log // сохранить логи в файл

delete // удалить под (с запросом на подтверждение операции)

Work with logs

As a bonus - not shells, but console tools for working with logs in Kubernetes. A year ago, we mentioned only those k8stail as such , but the past tense has shown that the problem is relevant, and there are other solutions worthy of attention to solve it.

Stern

GitHub (~ 1300 stars)
Language: Go
License: Apache 2.0

Stern is the undisputed favorite of the category “tail for pods in Kubernetes”. For clarity, when displaying logs, different color notations are used:

Another important feature is the use of regular expressions for convenient filtering of plots without the need to know specific IDs (for example, select everything with a name web-\w+). Similarly (i.e. regexpami), you can filter certain containers for the requested pods. Among other features stern:

support for custom Go templates for output logs (there are several predefined ones as standard);
label selectors support;
restriction of log output to a specified time value --sinceand / or a specified number of lines;
support for autocompletion for bash and zsh, as well as dynamic substitution of the values of namespaces and contexts.

Kubetail

GitHub (~ 950 stars)
Language: Shell
License: Apache 2.0

A similar solution, written in the usual Bash and a little more actively developed in the last year. Like stern, it supports highlighting the names of the pods (or the entire line, which is customizable):

It also allows filtering pods and containers both by full names and regular expressions, as well as using selectors, limiting output by time and number of lines, supports autocompletion for bash, zsh and fish. Among other features:

switchable mode --followfor updating data from logs in real time (as in tail -f);
--dry-run to display a list of suitable pods and containers without performing any other actions;
jq selector support for parsing output in JSON.

Kail

GitHub (~ 500 stars)
Language: Go
License: MIT

Another implementation that has the least activity in the code base over the last year. Nevertheless, it has interesting functional features that distinguish it from its competitors, namely:

restriction on the request of hearths by the names of their Service, ReplicationController, ReplicaSet, Deployment, Node, and / or Ingress (that is, those belonging to the services to which the specified Ingress leads) ;
opportunity not only to select by selectors, but also to exclude them;
determination of the logging level ( --log-level).

But there are also disadvantages: kail does not select with colors, does not support regular expressions for filters.

PS

Thank you for your interest and, of course, we will be happy to receive information about your findings in the comments!

Read also in our blog:

Tags: