Convert Figma logo to code with AI

astefanutti logokubebox

⎈❏ Terminal and Web console for Kubernetes

2,154
141
2,154
40

Top Related Projects

26,434

🐶 Kubernetes CLI To Manage Your Clusters In Style!

6,327

📦 Find and install kubectl plugins

6,280

Highly extensible platform for developers to better understand the complexity of Kubernetes clusters.

22,461

Lens - The way the world runs Kubernetes

4,181

A solution for implementing efficient and consistent software delivery to Kubernetes facilitating best practices.

3,207

⎈ Multi pod and container log tailing for Kubernetes -- Friendly fork of https://github.com/wercker/stern

Quick Overview

Kubebox is a terminal and web console for Kubernetes. It provides a user-friendly interface to interact with Kubernetes clusters, offering real-time monitoring, log viewing, and cluster management capabilities. Kubebox aims to simplify Kubernetes operations for both beginners and experienced users.

Pros

  • Cross-platform compatibility (works on Linux, macOS, and Windows)
  • Lightweight and fast, with minimal resource consumption
  • Offers both terminal and web-based interfaces for flexibility
  • Provides real-time updates and monitoring of cluster resources

Cons

  • Limited advanced features compared to some other Kubernetes management tools
  • May require some initial learning curve for users new to terminal-based interfaces
  • Documentation could be more comprehensive for certain features
  • Fewer integrations with third-party tools compared to some alternatives

Getting Started

To get started with Kubebox, follow these steps:

  1. Install Kubebox using npm:

    npm install -g kubebox
    
  2. Ensure you have a valid Kubernetes configuration file (~/.kube/config).

  3. Launch Kubebox:

    kubebox
    
  4. Use arrow keys to navigate, Enter to select, and Esc to go back or exit.

  5. For the web interface, run:

    kubebox --ui
    

    Then open a web browser and navigate to http://localhost:8080.

Competitor Comparisons

26,434

🐶 Kubernetes CLI To Manage Your Clusters In Style!

Pros of k9s

  • More feature-rich with extensive functionality for managing Kubernetes clusters
  • Highly customizable with support for plugins and skins
  • Active development with frequent updates and a larger community

Cons of k9s

  • Steeper learning curve due to more complex interface and features
  • Higher resource consumption, especially for larger clusters

Code Comparison

k9s uses a more structured approach with Go packages:

package views

type ClusterInfoView struct {
	*tview.TextView
}

func NewClusterInfoView() *ClusterInfoView {
	return &ClusterInfoView{tview.NewTextView()}
}

Kubebox uses a simpler JavaScript structure:

class Dashboard {
  constructor(screen, kube) {
    this.screen = screen;
    this.kube = kube;
  }
}

Both projects aim to provide terminal-based UIs for Kubernetes cluster management, but k9s offers a more comprehensive set of features and customization options. Kubebox, on the other hand, provides a simpler and more lightweight interface, which may be preferable for users who prioritize ease of use and lower resource consumption. The choice between the two depends on the user's specific needs and preferences in managing Kubernetes clusters.

6,327

📦 Find and install kubectl plugins

Pros of krew

  • Official Kubernetes SIG project, ensuring better long-term support and community involvement
  • Provides a plugin management system for kubectl, allowing easy installation and updates of multiple tools
  • Supports cross-platform compatibility (Linux, macOS, Windows)

Cons of krew

  • Requires separate installation and setup process before using kubectl plugins
  • Limited to kubectl plugins, while Kubebox offers a standalone terminal UI for Kubernetes cluster management
  • May have a steeper learning curve for users new to kubectl plugin ecosystems

Code comparison

Kubebox (Terminal UI interaction):

screen.key(['C-c', 'q', 'escape'], (ch, key) => process.exit(0));
screen.key(['C-l'], (ch, key) => screen.alloc());
screen.key(['tab'], (ch, key) => dashboard.focus());

krew (Plugin installation):

kubectl krew install ns
kubectl krew upgrade
kubectl krew list

While Kubebox focuses on providing a direct terminal UI for Kubernetes cluster management, krew serves as a plugin manager for kubectl, extending its functionality through various plugins. Kubebox offers a more visual and interactive experience, while krew enhances kubectl's capabilities through a modular approach.

6,280

Highly extensible platform for developers to better understand the complexity of Kubernetes clusters.

Pros of Octant

  • More feature-rich UI with a comprehensive dashboard for Kubernetes cluster management
  • Extensible plugin system allowing for custom views and functionality
  • Actively maintained by VMware (until archival) with regular updates and community support

Cons of Octant

  • Heavier resource usage due to its more complex UI and features
  • Steeper learning curve for users new to Kubernetes dashboards
  • Requires installation and setup, unlike Kubebox which can run directly in the terminal

Code Comparison

Kubebox (Terminal-based UI):

const blessed = require('blessed');
const contrib = require('blessed-contrib');
const screen = blessed.screen();

Octant (Web-based UI):

import (
    "github.com/vmware-tanzu/octant/pkg/plugin/service"
    "github.com/vmware-tanzu/octant/pkg/view/component"
)

While Kubebox uses JavaScript and focuses on terminal-based rendering, Octant is built with Go and provides a web-based interface. This fundamental difference in approach affects the overall user experience and deployment complexity of each tool.

22,461

Lens - The way the world runs Kubernetes

Pros of Lens

  • Rich graphical user interface with a more comprehensive feature set
  • Cross-platform support (Windows, macOS, Linux)
  • Integrated terminal and resource editor

Cons of Lens

  • Larger resource footprint and slower startup time
  • Requires installation and updates
  • Less suitable for quick, lightweight interactions

Code Comparison

Kubebox (Terminal-based):

kubebox

Lens (GUI-based):

lens

Summary

Kubebox is a lightweight, terminal-based Kubernetes cluster management tool, while Lens is a feature-rich, graphical Kubernetes IDE. Kubebox excels in simplicity and low resource usage, making it ideal for quick interactions and resource-constrained environments. Lens offers a more comprehensive set of features and a user-friendly interface, but at the cost of increased resource usage and complexity.

Kubebox is better suited for users who prefer command-line interfaces and need a fast, lightweight tool for basic cluster management. Lens is more appropriate for users who require a full-featured Kubernetes IDE with advanced capabilities and a graphical interface, especially for complex cluster management tasks and extended development work.

4,181

A solution for implementing efficient and consistent software delivery to Kubernetes facilitating best practices.

Pros of werf

  • More comprehensive CI/CD solution for Kubernetes
  • Supports multiple container registries and deployment strategies
  • Actively maintained with frequent updates and releases

Cons of werf

  • Steeper learning curve due to more complex features
  • Requires more configuration and setup compared to Kubebox
  • Larger codebase and dependencies

Code comparison

Kubebox (Terminal-based UI):

const blessed = require('blessed');
const contrib = require('blessed-contrib');
const screen = blessed.screen();

werf (YAML configuration):

project: myapp
configVersion: 1
deploy:
  namespace: myapp
  kubectl:
    context: production

Key differences

  • Kubebox is a lightweight, terminal-based UI for Kubernetes cluster management
  • werf is a full-featured CI/CD tool for building and deploying applications to Kubernetes
  • Kubebox focuses on monitoring and interaction, while werf emphasizes the entire deployment pipeline
  • Kubebox is written in JavaScript, while werf is primarily written in Go
  • werf has a larger community and more frequent updates compared to Kubebox

Both tools serve different purposes within the Kubernetes ecosystem, with Kubebox being more suitable for quick cluster interactions and werf for managing complex deployment workflows.

3,207

⎈ Multi pod and container log tailing for Kubernetes -- Friendly fork of https://github.com/wercker/stern

Pros of stern

  • Focused specifically on tailing multiple pod logs simultaneously
  • Supports regular expressions for pod/container selection
  • Lightweight and easy to install as a single binary

Cons of stern

  • Limited to log viewing functionality only
  • Lacks interactive UI for broader cluster management
  • No built-in container shell access

Code Comparison

stern:

stern pod-query [flags]

kubebox:

kubebox

Summary

stern is a specialized tool for tailing Kubernetes pod logs, offering powerful filtering capabilities and multi-pod support. It's ideal for developers who primarily need log viewing functionality.

kubebox, on the other hand, is a more comprehensive terminal-based Kubernetes dashboard. It provides a broader range of cluster management features, including an interactive UI for navigating resources, viewing logs, and accessing container shells.

While stern excels in its focused log tailing capabilities, kubebox offers a more holistic approach to cluster interaction. The choice between the two depends on whether you need a dedicated log viewing tool or a more versatile cluster management interface.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

= Kubebox [small]#^⎈❏^# Antonin Stefanutti https://github.com/astefanutti[@astefanutti] // Meta :description: Terminal and Web console for Kubernetes // Settings :idprefix: :idseparator: - :experimental: // Aliases ifdef::env-github[] :note-caption: :information_source: :icon-check: :heavy_check_mark: :icon-edit: :pencil2: endif::[] ifndef::env-github[] :icons: font :icon-check: icon:check[] :icon-edit: icon:pencil[fw] endif::[] // URIs :uri-kubebox-download: https://github.com/astefanutti/kubebox/releases/download/v0.10.0 :uri-kubebox-twitter: https://twitter.com/kubebox :uri-kube-apiserver: https://kubernetes.io/docs/admin/kube-apiserver/ :uri-ingress-controllers: https://kubernetes.io/docs/concepts/services-networking/ingress/#ingress-controllers :uri-service-account: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/ :uri-xterm-js: https://github.com/xtermjs/xterm.js :uri-cadvisor: https://github.com/google/cadvisor

{description}

// image::./docs/kubebox.png[kubebox, align="center"] ++++

++++

=== Features

  • Configuration from kubeconfig files (KUBECONFIG environment variable or $HOME/.kube)
  • Switch contexts interactively
  • <<authentication,Authentication support>> (bearer token, basic auth, private key / cert, OAuth, OpenID Connect, Amazon EKS, Google Kubernetes Engine, Digital Ocean)
  • Namespace selection and pods list watching
  • Container log scrolling / watching
  • Container resources usage (memory, CPU, network, file system charts) footnote:[Requires {uri-cadvisor}[cAdvisor] to be deployed as a DaemonSet. See the <> section for more details.]
  • Container remote exec terminal
  • Cluster, namespace, pod events
  • Object configuration editor and CRUD operations
  • Cluster and nodes views / monitoring

See the <> section for some examples, and follow image:https://img.shields.io/badge/%40kubebox-00ACEE.svg?&logo=twitter&colorA=555&logoColor=fff[link={uri-kubebox-twitter}] for some updates.

== Run

The following alternatives are available for you to use Kubebox, depending on your preferences and constraints:

=== Executable

Download the Kubebox standalone executable for your OS:

[source,shell,subs=attributes+]

Linux (x86_64)

$ curl -Lo kubebox {uri-kubebox-download}/kubebox-linux && chmod +x kubebox

Linux (ARMv7)

$ curl -Lo kubebox {uri-kubebox-download}/kubebox-linux-arm && chmod +x kubebox

OSX

$ curl -Lo kubebox {uri-kubebox-download}/kubebox-macos && chmod +x kubebox

Windows

$ curl -Lo kubebox.exe {uri-kubebox-download}/kubebox-windows.exe

Then run:

$ ./kubebox

=== Server

Kubebox can be served from a service hosted in your Kubernetes cluster. Terminal emulation is provided by {uri-xterm-js}[Xterm.js] and the communication with the Kubernetes master API is proxied by the server.

To deploy the server in your Kubernetes cluster, run:

$ kubectl apply -f https://raw.github.com/astefanutti/kubebox/master/kubernetes.yaml

To shut down the server and clean-up resources, run:

$ kubectl delete namespace kubebox

For the Ingress resource to work, the cluster must have an Ingress controller running. See {uri-ingress-controllers}[Ingress controllers] for more information.

Alternatively, to deploy the server in your OpenShift cluster, run:

$ oc new-app -f https://raw.github.com/astefanutti/kubebox/master/openshift.yaml

=== Kubectl

You can run Kubebox as an in-cluster client with kubectl, e.g.:

$ kubectl run kubebox -it --rm --env="TERM=xterm" --image=astefanutti/kubebox --restart=Never

If RBAC is enabled, you'll have to use the --serviceaccount option and reference a service account with sufficient permissions.

=== Docker

You can run Kubebox using Docker, e.g.:

$ docker run -it --rm astefanutti/kubebox

You may want to mount your home directory so that Kubebox can rely on the ~/.kube/config file, e.g.:

$ docker run -it --rm -v ~/.kube/:/home/node/.kube/:ro astefanutti/kubebox

=== Online

Kubebox is available online at https://astefanutti.github.com/kubebox. Note that it requires this address to match the allowed origins for CORS by the API server. This can be achived with the {uri-kube-apiserver}[Kubernetes API server CLI], e.g.:

$ kube-apiserver --cors-allowed-origins .*

== Authentication

We try to support the various authentication strategies supported by kubectl, in order to provide seamless integration with your local setup. Here are the different authentication strategies we support, depending on how you're using Kubebox:

[cols="<,^,^,^",options="header"] |=== ||Executable|Docker|Online

|OpenID Connect |{icon-check} |{icon-check} |{icon-check}footnote:[Custom IDP certificate authority files are not supported in Web versions.]

|Amazon EKS| {icon-check} | |

|Digital Ocean |{icon-check} | |

|Google Kubernetes Engine| {icon-check} | | |===

If the mode you're using isn't supported, you can refresh the authentication token/certs manually and update your kubeconfig file accordingly.

== cAdvisor

Kubebox relies on {uri-cadvisor}[cAdvisor] to retrieve the resource usage metrics. Before version 0.8.0, Kubebox used to access the cAdvisor endpoints, that are embedded in the Kubelet. However, these endpoints are being deprecated, and will eventually be removed, as discussed in https://github.com/kubernetes/kubernetes/issues/68522[kubernetes#68522].

Starting version 0.8.0, Kubebox expects cAdvisor to be deployed as a https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/[DaemonSet]. This can be achieved with:

$ kubectl apply -f https://raw.githubusercontent.com/astefanutti/kubebox/master/cadvisor.yaml

It's recommended to use the provided cadvisor.yaml file, that's tested to work with Kubebox. However, the DaemonSet example, from the {uri-cadvisor}[cAdvisor] project, should also work just fine. Note that the cAdvisor containers must run with a privileged security context, so that they can access the container runtime on each node.

You can change the default --storage_duration and --housekeeping_interval options, added to the cAdvisor container arguments declared in the cadvisor.yaml file, to adjust the duration of the storage moving window (default to 5m0s), and the sampling period (default to 10s) respectively. You may also have to provide the path of your cluster container runtime socket, in case it's not following the usual convention.

== Hotkeys

[cols="1v,2v"] |=== |Keybinding |Description

2+^.e|General

|kbd:[l], kbd:[Ctrl+l] |Login

|kbd:[n] |Change current namespace

|[kbd:[Shift]+]kbd:[←], kbd:[→] + [kbd:[Alt]+]kbd:[1], ..., kbd:[9] |Navigate screens + (use kbd:[Shift] or kbd:[Alt] inside exec terminal)

|kbd:[Tab], kbd:[Shift+Tab] |Change focus within the active screen

|kbd:[↑], kbd:[↓] |Navigate list / form / log

|kbd:[PgUp], kbd:[PgDn] |Move one page up / down

|kbd:[Enter] |Select item / submit form

|kbd:[Esc] |Close modal window / cancel form

|kbd:[Ctrl+z] |Close current screen

|kbd:[q], kbd:[Ctrl+q] |Exit footnote:[Not available in Web versions.]

2+^.e|Login

|kbd:[←], kbd:[→] |Navigate Kube configurations

2+^.e|Pods

|kbd:[Enter] |Select pod / cycle containers

|kbd:[r] |Remote shell into container

|kbd:[m] |Memory usage

|kbd:[c] |CPU usage

|kbd:[t] |Network usage

|kbd:[f] |File system usage

|kbd:[e] |Pod events

|kbd:[Shift+e] |Namespace events

|kbd:[Ctrl+e] |Cluster events

|===

== FAQ

  • Resources usage metrics are unavailable!

** Starting version 0.8.0, Kubebox expects {uri-cadvisor}[cAdvisor] to be deployed as a DaemonSet. See the <> section for more details;

** The metrics are retrieved from the REST API, of the cAdvisor pod running on the same node as the container for which the metrics are being requested. That REST API is accessed via the API server proxy, which requires proper RBAC permission, e.g.: + [source,shell]

Permission to list the cAdvisor pods (selected using the spec.nodeName field selector)

$ kubectl auth can-i list pods -n cadvisor yes

Permission to proxy the selected cAdvisor pod, to call its REST API

$ kubectl auth can-i get pod --subresource proxy -n cadvisor yes

== Development

$ git clone https://github.com/astefanutti/kubebox.git
$ cd kubebox
$ npm install
$ node index.js

== Screenshots

Cluster events: ++++

++++

Shell into a container: ++++

++++

Terminal theme support: ++++

++++

Web browser version: ++++

++++

NPM DownloadsLast 30 Days