Geekly Articles each Day
📜 ⬆️ ⬇️

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



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 kubebox is to fully work with Kubernetes within the framework of a convenient console interface, presented in the style of pseudographics:

image

Work implies such opportunities as navigation through files through namespaces, viewing logs and even graphs of consumption of key resources (CPU, memory, network), remote execution of commands in containers. Settings for connecting to clusters can be taken from the KUBECONFIG environment KUBECONFIG or 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 the output of additional information (in particular, kubectl describe pod ).

An important feature is the availability of an online version (to connect to the Kubernetes API server, you will need to allow 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 we can expect that this will give a new impetus to its development.

kube-shell and kube-prompt


kube-shell




(Attention, this GIF is ~ 2 MB!)

kube-prompt





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 of the 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



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 for using Click is:

pods //
2 //
describe //
events //
logs -c foo > /tmp/podfoo.log //
delete // ( )

If you are interested - see also a small screencast demonstrating the work of Click with text comments.

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



Stern is the undisputed favorite of the category “tail for pods in Kubernetes”. For clarity, the output of logs uses different color notation:



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


Kubetail



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



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 auto-completion for Bash, zsh and fish. Among other features:


Kail



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:




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:

Source: https://habr.com/ru/post/426985/

More articles:


All Articles