K9s DevOps: Pros/cons and a quick tutorial

What is K9s?

K9s is an open-source terminal-based UI for Kubernetes cluster management. Unlike the standard kubectl command-line utility, K9s provides a real-time, interactive console that displays cluster resources visually within the terminal. It allows operators and developers to navigate namespaces, examine logs, monitor workloads, and interact with various Kubernetes objects using keyboard shortcuts, reducing manual command entry and error-prone scripting.

This tool minimizes context switching, allowing users to gain visibility into their environments without leaving the command line. K9s runs directly against the kubeconfig, eliminating complex configuration steps while maintaining security. Its interface and open-source community make it suitable for organizations seeking to optimize workflows and monitor clusters more effectively.

This is part of a series of articles about Kubernetes management.

Benefits of K9s for DevOps teams

For DevOps teams working with Kubernetes, K9s addresses one of the most persistent challenges: reducing the operational complexity that comes with managing distributed systems. Traditional tools like kubectl often require extensive scripting, memorization, and context switching. K9s eliminates much of that friction by presenting a real-time, interactive view of the cluster directly in the terminal.

Its terminal-based UI lets engineers manage, monitor, and troubleshoot workloads quickly, often with just a few keystrokes. Tasks like viewing logs, describing resources, switching contexts, or executing into a pod can be done seamlessly. This improves incident response times and cuts down the likelihood of human error under pressure.

Compared to graphical tools like Lens or Rancher, K9s offers greater speed and simplicity without sacrificing control. For users comfortable with the terminal, especially those with experience in Linux or tools like Vim, K9s provides a natural interface. Custom commands and views further allow teams to tailor the experience to their workflows, boosting productivity.

Limitations and challenges of K9s

While K9s offers a fast and efficient interface for managing Kubernetes clusters, it also comes with some trade-offs that users should be aware of:

K9s is entirely terminal-based: This can be a barrier for users who prefer graphical tools like Lens or Rancher, which provide dashboards and visual context that some may find more intuitive. K9s lacks native visualization features, making it harder to get a high-level overview of cluster health at a glance.
Customization is complex: It requires familiarity with both its internal configuration and Kubernetes itself. This can introduce complexity for users who aren’t already comfortable with YAML files or Kubernetes resource definitions. Additionally, while K9s supports plugins, the ecosystem is smaller than that of some other tools, limiting extensibility.
Performance can degrade: This is especially a problem when working with large clusters, particularly on lower-end machines. K9s continuously fetches real-time data, which may introduce latency or slowdowns under heavy workloads.
Limitations for collaboration: K9s does not currently support real-time session sharing, which makes it harder for teams to troubleshoot issues together within the same interface.
Updates must be performed manually: Unlike tools that include auto-update mechanisms, this adds an extra maintenance step for users. And while K9s can simplify daily tasks, overreliance on it may lead users to lose familiarity with core kubectl commands and deeper Kubernetes concepts.

Tutorial: K9s installation

K9s can be installed on macOS, Linux, and Windows using popular package managers or by building from source. Here is a breakdown of installation methods by platform. These instructions are adapted from the K9s documentation.

macOS

The easiest way to install K9s on macOS is via Homebrew:

brew install derailed/k9s/k9s

Alternatively, MacPorts users can run:

sudo port install k9s

Linux

Linux users can install K9s using either LinuxBrew:

brew install derailed/k9s/k9s

Or, on Arch-based systems, use PacMan:

pacman -S k9s

Windows

For Windows, K9s is available via Scoop:

scoop install k9s

Or via Chocolatey:

choco install k9s

Build from source

To build K9s from source, ensure you have Go 1.14 or later installed. Then clone the repository and compile:

make build && ./execs/k9s

Preflight configuration

Before running K9s, make sure your terminal supports 256 colors. On Unix-like systems, set the TERM variable:

export TERM=xterm-256color

If you plan to edit Kubernetes resources directly from K9s, set your preferred text editor using:

export KUBE_EDITOR=my_fav_editor

Once installed and configured, K9s reads from your existing kubeconfig and is ready to use without additional setup.

Tony Kelly

Tony Kelly is a DevOps marketing leader who drives innovation and awareness of the latest trends in Continuous Delivery.

In my experience, here are tips that can help you better use K9s in DevOps workflows:

Use K9s port-forwarding as a lightweight tunnel: Instead of running kubectl port-forward, K9s provides an interactive way to set up port-forwarding directly from the resource view. Combine this with tmux or screen sessions to keep tunnels persistent during troubleshooting or debugging across multiple services.
Enable resource auto-refresh tuning for large clusters: In big clusters, the default refresh rate can strain K9s or the terminal. Set a longer refresh interval for non-critical views in k9s/config.yml to prevent lag, while keeping faster refresh for namespaces critical to operations.
Create custom plugins for non-Kubernetes workflows: Extend K9s by building plugins that invoke external tools like Argo CD, Flux, or Helm directly from the interface. This allows operators to perform common GitOps or chart upgrades without switching contexts.
Adopt K9s skins for environment awareness: Use different color themes (skins) for dev, staging, and production clusters to avoid accidental changes in sensitive environments. For example, a red-themed skin for production immediately signals caution.
Use pod log filtering shortcuts: Combine :logs -f with built-in filtering (e.g., grep) in K9s to quickly isolate errors or events in noisy logs. You can also create shortcuts in plugin.yml for common grep patterns like “CrashLoopBackOff” or “OOMKilled”.

Key K9s commands and key bindings

K9s supports both CLI arguments and in-app key bindings to streamline navigation and operations.

Common CLI arguments include:

k9s help to list all options
k9s info to view runtime details such as logs and configs
k9s -n mynamespace to start directly in a namespace
k9s -c pod to launch in pod view
k9s --context ctx-name to switch to a different kubeconfig context
k9s --readonly to run in read-only mode

Key bindings speed up navigation and resource management:

? shows help and active key mappings
ctrl-a lists resource aliases
:pod opens a pod view; supports filters like :pod /name or labels with :pod app=foo
/filter applies regex filtering, /! inverts it, and /-l filters by labels
esc cancels filters or commands
d, v, e, l describe, view, edit, and view logs for resources
:ctx switches contexts; :ns switches namespaces
ctrl-d deletes resources with confirmation, while ctrl-k deletes without prompting
:pulses and :xray open specialized cluster views
:screendump exports current resources for review

These bindings let engineers navigate quickly without repeatedly typing kubectl commands, improving both speed and accuracy.

Benchmark your applications with K9s

K9s integrates benchmarking capabilities through the Hey CLI tool, enabling quick performance checks on HTTP endpoints exposed by services or port-forwards.

To benchmark, start a port-forward from a pod using SHIFT-F. Once active, go to the PortForward view (:pf), select a forward, and run a benchmark with CTRL-B. Results appear in the Benchmarks view (:be), where pressing Enter opens detailed stats.

By default, benchmarks run with 1 concurrent connection, 200 requests, a GET method, and path /. These defaults can be adjusted in benchmarks.yaml, stored per cluster and context under $XDG_DATA_HOME/k9s/clusters/.../benchmarks.yaml. This file allows customization of concurrency, request counts, HTTP methods, paths, headers, and authentication.

Reports are saved under $XDG_STATE_HOME/k9s/clusters/..., giving teams a record of past test runs. Benchmarks work on both container ports and services, supporting NodePort and LoadBalancer setups.

This feature lets engineers validate response times and reliability directly inside K9s, without leaving the terminal or relying on separate benchmarking tools.

Best practices for K9s in DevOps workflows

Organizations should consider these practices when working with K9s in a DevOps workflow.

1. Regularly updating K9s

Keeping K9s up to date is essential to maintain compatibility with evolving Kubernetes versions and APIs. New K9s releases often include bug fixes, performance improvements, and support for new Kubernetes resources or features. Failing to update can lead to UI glitches, missing resource views, or even crashes when interacting with updated clusters.

Since K9s doesn’t include auto-update functionality, teams should incorporate update checks into regular maintenance workflows. Use brew upgrade k9s, choco upgrade k9s, or the system’s equivalent command on a monthly or biweekly schedule. Monitoring the official GitHub releases or subscribing to release notifications is also a practical way to stay informed about important changes. When updating, it’s good practice to review release notes for deprecated features or required configuration changes.

2. Using saved views for common tasks

Saved views in K9s can drastically reduce the time spent navigating cluster resources. Using views.yml and plugin.yml configuration files, teams can define scoped views or pre-filtered queries for repetitive tasks. Examples include viewing only failing pods, isolating deployments by label, or monitoring a namespace during a rollout.

By setting up these views ahead of time, teams reduce cognitive overhead during critical operations. For example, defining a saved view for ingress controllers can let developers instantly access their state during a traffic incident. These views can also be shared across teams, providing standardized entry points for common diagnostics or maintenance tasks.

Additionally, integrating hotkeys for custom views improves ergonomics. Mapping complex queries to simple shortcuts makes switching contexts seamless and improves efficiency during time-sensitive operations.

3. Integrating K9s into CI/CD pipelines

While K9s is primarily an interactive tool, it complements CI/CD pipelines by aiding in visual verification and debugging. After automated deployments, engineers can use K9s to validate pod readiness, service connectivity, or resource allocation in real-time. This is especially useful during staging or canary deployments, where visual confirmation adds an extra layer of safety.

Another approach is to use K9s views in conjunction with deployment documentation. For instance, a release guide might instruct engineers to open a predefined K9s view that filters only the new services or jobs introduced in the current release. This creates a consistent and efficient way to verify rollout health.

For teams practicing GitOps, K9s helps confirm that actual cluster state aligns with declarative manifests. Although it doesn’t run in the pipeline, its insights can validate pipeline outputs and guide incident response during failed releases.

4. Securely managing Kubernetes resources

Security best practices in K9s start with the kubeconfig context it uses. Avoid running K9s with full admin access unless necessary. Instead, create scoped service accounts or use Kubernetes RBAC roles that limit access to namespaces or resource types. This protects clusters from accidental changes and enforces least-privilege principles.

When editing resources directly in K9s, remember that changes are applied immediately. Always verify the resource scope before saving edits. For sensitive environments, consider restricting edit access altogether by removing write permissions from the context used by K9s.

Admins can also set K9s to open resources in a diff or read-only mode by default, allowing engineers to review configurations without the risk of unintended modifications. Logging and audit trails should also be configured to track changes made via K9s, especially in production clusters.

5. Collaborating effectively with shared configurations

To maintain consistency across teams, store K9s configuration files (such as plugin.yml, views.yml, and skin.yml) in a shared Git repository. Use symlinks or environment variables (e.g., K9SCONFIG) to load these settings from a central location. This ensures everyone sees the same views, shortcuts, and themes.

Document shared views and workflows in internal wikis or runbooks. For example, define which saved view to use during on-call triage or release validation. Encourage the use of descriptive names and comments in configuration files to help others understand their purpose.

Consider implementing a change review process for K9s configs just like code. Treating these settings as part of infrastructure-as-code helps prevent misconfigurations and aligns with DevOps principles of repeatability and transparency.

Help us continuously improve

Please let us know if you have any feedback about this page.

Send feedback