Maximizing productivity with Kubernetes: the benefits of using K9s

Kubernetes is a robust and powerful orchestrator for containerized applications, but it is also complex and sometimes difficult to get to grips with. Memorizing kubectl flags, jumping between resources, and chaining commands together just to see what is happening in a cluster gets old fast. In this guide we'll walk through K9s, a terminal tool that turns all of that into a fast, visual workflow you can drive entirely from the keyboard.

Prerequisites

To follow along, you'll need:

• A Civo account
• A Kubernetes cluster created and configured on Civo
• The cluster's kubeconfig file saved locally so kubectl can reach the cluster

If you do not have a cluster yet, you can create one from the Civo dashboard and download the kubeconfig in a couple of minutes.

What is K9s?

K9s is a command-line based utility for managing and monitoring Kubernetes clusters. It provides a visual interface allowing users to view and manage their Kubernetes resources, such as pods, deployments, and services, in a more intuitive and user-friendly way than using the kubectl command-line tool.

Everything K9s does is something you could do with kubectl, but the visual layout means you do not have to remember command syntax or type out long resource names. A few things make it pleasant to live in day to day:

• Resource filtering so you can narrow down to exactly what you need
• Inline editing of resource definitions
• A full set of resource management actions a keystroke away
• A lightweight design that runs comfortably in any terminal
• A user-friendly interface that reads cluster state at a glance

Installation

K9s is available through most popular package managers. Pick the one for your platform:

On macOS with Homebrew:

1brew install k9s

On Windows with scoop:

1scoop install k9s

On Windows with Chocolatey:

1choco install k9s

On Linux, you may find your package manager already contains K9s. If not, you can always grab the latest binaries from the K9s releases page.

Using K9s

With K9s installed and your kubeconfig in place, start it by running:

1K9s

K9s opens against your current context and drops you straight into a live view of your cluster. A couple of keys to know right away:

• Press ? on any screen to see the available shortcuts for that view.
• Press Ctrl-c to exit K9s.

To jump to a resource type, type a colon followed by its name. For example:

1:pods

The same pattern works for :node, :svc, :deploy, and any other resource. K9s offers tab-completion, so :na and Tab will complete to namespaces. To move around a list, use the arrow keys or vim-style navigation with j to go down and k to go up.

To see the full definition of whatever you have highlighted, press d to describe it.

Searching and filtering

Long lists get unwieldy, so K9s gives you a filter. Press / and start typing to narrow the current view. For example, on the namespaces view, typing /kube filters down to namespaces whose names contain "kube".

Searching narrows the current view to matching resources.

Viewing logs

Logs are usually the first place we look when something misbehaves. Highlight a pod and press:

• l to view its logs
• p to view the previous container's logs, which is handy after a crash and restart
• t to toggle timestamps on each line

Logs of Kubernetes resources viewed directly in K9s.

Operating on resources

K9s is not just for looking. Most common operations are a single keystroke on the highlighted resource.

• Press e to edit a resource's configuration. K9s opens it in your default editor, and your changes are applied on save.
• Press Ctrl-d to delete the highlighted resource. K9s shows a confirmation prompt first.
• Press s to open a shell inside a pod. This is the equivalent of kubectl exec --stdin --tty <podname> -- /bin/bash. Type exit when you are done to return to K9s.
• Press Shift-f to set up a port-forward. Choose a local port, for example 3000, and then reach the pod at localhost:3000.

For node maintenance, K9s exposes cordon and drain directly from the nodes view, so you can mark a node unschedulable and evict its pods without leaving the UI.

Monitoring with Pulses

To get a live, color-coded overview of cluster activity, run:

1:pulses

Pulses shows updating graphs of cluster metrics such as pods, events, and deployments. Move between the panels with Tab or by selecting a numbered tile.

Live, color-coded cluster metrics in the Pulses view.

Plugins

K9s is extensible through plugins, which bind a shortcut to a command. Two useful examples:

• get-all: with krew and ketall installed, this lets you press g to display every resource in a namespace, including the ones kubectl get all leaves out.
• log-full: bound to Shift-l, this pulls comprehensive logs for a resource in one keystroke.

Plugins are defined in a plugins.yaml file, where each entry maps a key to the command you want to run.

Power-user commands

Once you are comfortable with the basics, a handful of command-mode features will speed you up considerably. Each one below works against any cluster, including a Civo Kubernetes cluster.

Resource dependency trees with :xray

When we want to see how a workload hangs together, rather than scrolling separate views, we can open an XRay tree:

1:xray deploy

That gives us a collapsible tree of each Deployment down through its ReplicaSets, Pods, and the Services and ConfigMaps they touch. XRay accepts po, svc, dp (deploy), rs, sts, and ds, with an optional namespace, for example :xray dp my-namespace. Why you'd use it: fast visual dependency tracing when something downstream is unhealthy and we want to find the parent.

The :xray deploy tree showing a Deployment, its ReplicaSet, and Pods in one collapsible view.

Safe production browsing with read-only mode

Before we hand K9s to someone for a look around production, we can disable every mutating action by launching in read-only mode:

1k9s --readonly

With this flag, edit, delete, kill, scale, and other modification commands are turned off, so browsing is safe by default. We can also set readOnly: true in the K9s config to make it permanent for a given setup. Why you'd use it: poke around a sensitive cluster, or screen-share it, with zero risk of an accidental delete.

K9s launched with --readonly; mutating shortcuts are disabled.

Jumping between clusters and namespaces

Managing more than one cluster is the common case, and K9s switches context without dropping back to the shell. Type:

1:ctx

to list every context in our kubeconfig and pick one, or :ctx <context-name> to jump straight there. To switch the active namespace, we use:

1:ns

Why you'd use it: hop from a dev cluster to staging, or from one namespace to another, in a couple of keystrokes instead of running kubectl config use-context.

The :ctx view listing the contexts in our kubeconfig, with the active one marked.

Quick HTTP benchmarks with the built-in benchmarker

K9s ships a built-in HTTP benchmarker (backed by hey) so we can load-test a service without leaving the UI. The flow:

1. Select a pod that serves HTTP and press Shift-f to set up a port-forward. In the dialog, set a non-privileged local port such as 8080 (binding to 80 needs root on most machines), then choose OK.
2. Open the port-forward list with :portforward.
3. Highlight the forward and press b to start the benchmark.

The default run is 200 requests at concurrency 1 against /. Open the Benchmarks view with :benchmark to see each run's status, requests per second, and 2xx/error counts, then press Enter on a run for the full report: summary, response-time histogram, and latency distribution. We can tune requests, concurrency, method, path, and headers in benchmarks.yaml under the K9s config directory. Why you'd use it: a fast sanity check on latency and throughput before tuning resource requests and limits.

The :benchmark report for a port-forwarded pod: 200 requests, all 2xx, with the response-time histogram and latency distribution.

Permission debugging with the RBAC view

When access fails, and we need to know who can do what, K9s surfaces RBAC directly. There is no :rbac command; instead, open the roles or cluster roles list and drill in:

1:role

Or, :clusterrole for cluster-scoped roles. Highlight a role and press Enter to open its permission matrix: every resource the role touches, laid out against the verbs (get, list, watch, create, patch, update, delete) with a tick or a cross for each. That turns a wall of YAML into a grid you can read at a glance. Why you'd use it: debug a "forbidden" error or audit a role's reach in seconds, instead of stitching together kubectl auth can-i calls.

Drilling into a Role shows its permission matrix: resources down the side, verbs across the top, ticks and crosses for what is allowed.

Customization

K9s stores its configuration as YAML. On current versions the config lives under ~/.config/k9s/ (or wherever $K9S_CONFIG_DIR points), with the main file at ~/.config/k9s/config.yaml. Older guides that reference ~/.k9s/ predate this move. Two kinds of customization are worth knowing:

• Skins let you restyle the interface. Drop a skin file in ~/.config/k9s/skins/ and point k9s.ui.skin at it in config.yaml, and you can even apply cluster-specific skins so production looks visibly different from dev, a small thing that prevents big mistakes. If you want a ready-made starting point rather than hand-rolling colors, solarized-k9s is a Solarized skin you can drop straight in.
• Aliases give you your own shortcuts for resource types. Add them to ~/.config/k9s/aliases.yaml using the form alias: group/version/resource. For example:

1dep: apps/v1/deployments

With that in place, typing :dep jumps straight to your deployments.

Conclusion

For getting information at-a-glance, quickly and at your fingertips in your terminal, K9s is an invaluable tool. It lets us run common cluster operations without chaining together complex commands, and its plugins, skins, aliases, and power-user commands mean it grows with us as our needs get more advanced. Spin it up against your Civo cluster and drive it from the keyboard, and you may find you rarely reach for raw kubectl again.