开源软件名称（OpenSource Name）：

开源软件地址(OpenSource Url)：

开源编程语言(OpenSource Language)：

开源软件介绍(OpenSource Introduction)：

K9s - Kubernetes CLI To Manage Your Clusters In Style!

K9s provides a terminal UI to interact with your Kubernetes clusters. The aim of this project is to make it easier to navigate, observe and manage your applications in the wild. K9s continually watches Kubernetes for changes and offers subsequent commands to interact with your observed resources.

Note...

As you may know k9s is not pimped out by a big corporation with deep pockets. It is a complex OSS project that demands a lot of my time to maintain and support. K9s will always remain OSS and therefore free! That said if you feel, k9s makes your day to day Kubernetes journey a tad brighter, please consider sponsoring us or purchase a K9sAlpha license. Your donations will go a long way in keeping our servers lights on and beers in our fridge!

Thank you!

Documentation

Please refer to our K9s documentation site for installation, usage, customization and tips.

Slack Channel

Wanna discuss K9s features with your fellow K9sers or simply show your support for this tool?

• Channel: K9ersSlack
• Invite: K9slackers Invite

Installation

K9s is available on Linux, macOS and Windows platforms.

• Binaries for Linux, Windows and Mac are available as tarballs in the release page.

• Via Homebrew for macOS or LinuxBrew for Linux

  brew install k9s

• Via MacPorts

  sudo port install k9s

• On Arch Linux

  pacman -S k9s

• On OpenSUSE Linux distribution

  zypper install k9s

• Via Scoop for Windows

  scoop install k9s

• Via Chocolatey for Windows

  choco install k9s

• Via a GO install

  # NOTE: The dev version will be in effect!
  go get -u github.com/derailed/k9s

• Via Webi for Linux and macOS

  curl -sS https://webinstall.dev/k9s | bash

• Via Webi for Windows

  curl.exe -A MS https://webinstall.dev/k9s | powershell

Building From Source

K9s is currently using go v1.14 or above. In order to build K9s from source you must:

1. Clone the repo

2. Build and run the executable

   make build && ./execs/k9s

Running with Docker

Running the official Docker image

You can run k9s as a Docker container by mounting your KUBECONFIG:

docker run --rm -it -v $KUBECONFIG:/root/.kube/config quay.io/derailed/k9s

For default path it would be:

docker run --rm -it -v ~/.kube/config:/root/.kube/config quay.io/derailed/k9s

Building your own Docker image

You can build your own Docker image of k9s from the Dockerfile with the following:

docker build -t k9s-docker:0.1 .

You can get the latest stable kubectl version and pass it to the docker build command with the --build-arg option. You can use the --build-arg option to pass any valid kubectl version (like v1.18.0 or v1.19.1).

KUBECTL_VERSION=$(make kubectl-stable-version 2>/dev/null)
docker build --build-arg KUBECTL_VERSION=${KUBECTL_VERSION} -t k9s-docker:0.1 .

Run your container:

docker run --rm -it -v ~/.kube/config:/root/.kube/config k9s-docker:0.1

PreFlight Checks

• K9s uses 256 colors terminal mode. On `Nix system make sure TERM is set accordingly.

  export TERM=xterm-256color

• In order to issue manifest edit commands make sure your EDITOR env is set.

  # Kubectl edit command will use this env var.
  export EDITOR=my_fav_editor
  # Should your editor deal with streamed vs on disk files differently, also set...
  export K9S_EDITOR=my_fav_editor

• K9s prefers recent kubernetes versions ie 1.16+

The Command Line

# List all available CLI options
k9s help
# To get info about K9s runtime (logs, configs, etc..)
k9s info
# To run K9s in a given namespace
k9s -n mycoolns
# Start K9s in an existing KubeConfig context
k9s --context coolCtx
# Start K9s in readonly mode - with all cluster modification commands disabled
k9s --readonly

Logs

Given the nature of the ui k9s does produce logs to a specific location. To view the logs and turn on debug mode, use the following commands:

k9s info
# Will produces something like this
#  ____  __.________
# |    |/ _/   __   \______
# |      < \____    /  ___/
# |    |  \   /    /\___ \
# |____|__ \ /____//____  >
#         \/            \/
#
# Configuration:   ~/Library/Preferences/k9s/config.yml
# Logs:            /var/folders/8c/hh6rqbgs5nx_c_8k9_17ghfh0000gn/T/k9s-fernand.log
# Screen Dumps:    /var/folders/8c/hh6rqbgs5nx_c_8k9_17ghfh0000gn/T/k9s-screens-fernand

# To view k9s logs
tail -f /var/folders/8c/hh6rqbgs5nx_c_8k9_17ghfh0000gn/T/k9s-fernand.log

# Start K9s in debug mode
k9s -l debug

Key Bindings

K9s uses aliases to navigate most K8s resources.

Screenshots

1. Pods
2. Logs
3. Deployments

Demo Videos/Recordings

• k9s Kubernetes UI - A Terminal-Based Vim-Like Kubernetes Dashboard
• K9s v0.21.3
• K9s v0.19.X
• K9s v0.18.0
• K9s v0.17.0
• K9s Pulses
• K9s v0.15.1
• K9s v0.13.0
• K9s v0.9.0
• K9s v0.7.0 Features
• K9s v0 Demo

K9s Configuration

K9s keeps its configurations inside of a k9s directory and the location depends on your operating system. K9s leverages XDG to load its various configurations files. For information on the default locations for your OS please see this link. If you are still confused a quick k9s info will reveal where k9s is loading its configurations from. Alternatively, you can set K9SCONFIG to tell K9s the directory location to pull its configurations from.

NOTE: This is still in flux and will change while in pre-release stage!

# $XDG_CONFIG_HOME/k9s/config.yml
k9s:
  # Represents ui poll intervals. Default 2secs
  refreshRate: 2
  # Number of retries once the connection to the api-server is lost. Default 15.
  maxConnRetry: 5
  # Enable mouse support. Default false
  enableMouse: true
  # Set to true to hide K9s header. Default false
  headless: false
  # Set to true to hide K9s crumbs. Default false
  crumbsless: false
  # Indicates whether modification commands like delete/kill/edit are disabled. Default is false
  readOnly: false
  # Toggles icons display as not all terminal support these chars.
  noIcons: false
  # Logs configuration
  logger:
    # Defines the number of lines to return. Default 100
    tail: 200
    # Defines the total number of log lines to allow in the view. Default 1000
    buffer: 500
    # Represents how far to go back in the log timeline in seconds. Setting to -1 will show all available logs. Default is 5min.
    sinceSeconds: 300
    # Go full screen while displaying logs. Default false
    fullScreenLogs: false
    # Toggles log line wrap. Default false
    textWrap: false
    # Toggles log line timestamp info. Default false
    showTime: false
  # Indicates the current kube context. Defaults to current context
  currentContext: minikube
  # Indicates the current kube cluster. Defaults to current context cluster
  currentCluster: minikube
  # Persists per cluster preferences for favorite namespaces and view.
  clusters:
    coolio:
      namespace:
        active: coolio
        # With this set, the favorites list won't be updated as you switch namespaces
        lockFavorites: false
        favorites:
        - cassandra
        - default
      view:
        active: po
      featureGates:
        # Toggles NodeShell support. Allow K9s to shell into nodes if needed. Default false.
        nodeShell: false
      # Provide shell pod customization of feature gate is enabled
      shellPod:
        # The shell pod image to use.
        image: killerAdmin
        # The namespace to launch to shell pod into.
        namespace: fred
        # The resource limit to set on the shell pod.
        limits:
          cpu: 100m
          memory: 100Mi
      # The IP Address to use when launching a port-forward.
      portForwardAddress: 1.2.3.4
    kind:
      namespace:
        active: all
        favorites:
        - all
        - kube-system
        - default
      view:
        active: dp
  # The path to screen dump. Default: '%temp_dir%/k9s-screens-%username%' (k9s info) 
  screenDumpDir: /tmp

Popeye Configuration

K9s has integration with Popeye, which is a Kubernetes cluster sanitizer. Popeye itself uses a configuration called spinach.yml, but when integrating with K9s the cluster-specific file should be name $XDG_CONFIG_HOME/k9s/<context>_spinach.yml. This allows you to have a different spinach config per cluster.

Node Shell

By enabling the nodeShell feature gate on a given cluster, K9s allows you to shell into your cluster nodes. Once enabled, you will have a new s for shell menu option while in node view. K9s will launch a pod on the selected node using a special k9s_shell pod. Furthermore, you can refine your shell pod by using a custom docker image preloaded with the shell tools you love. By default k9s uses a BusyBox image, but you can configure it as follows:

# $XDG_CONFIG_HOME/k9s/config.yml
k9s:
  clusters:
    # Configures node shell on cluster blee
    blee:
      featureGates:
        # You must enable the nodeShell feature gate to enable shelling into nodes
        nodeShell: true
      # You can also further tune the shell pod specification
      shellPod:
        image: cool_kid_admin:42
        namespace: blee
        limits:
          cpu: 100m
          memory: 100Mi

Command Aliases

In K9s, you can define your very own command aliases (shortnames) to access your resources. In your $HOME/.config/k9s define a file called alias.yml. A K9s alias defines pairs of alias:gvr. A gvr (Group/Version/Resource) represents a fully qualified Kubernetes resource identifier. Here is an example of an alias file:

# $XDG_CONFIG_HOME/k9s/alias.yml
alias:
  pp: v1/pods
  crb: rbac.authorization.k8s.io/v1/clusterrolebindings

Using this alias file, you can now type pp/crb to list pods or ClusterRoleBindings respectively.

HotKey Support

Entering the command mode and typing a resource name or alias, could be cumbersome for navigating thru often used resources. We're introducing hotkeys that allows a user to define their own hotkeys to activate their favorite resource views. In order to enable hotkeys please follow these steps:

1. Create a file named $XDG_CONFIG_HOME/k9s/hotkey.yml

2. Add the following to your hotkey.yml. You can use resource name/short name to specify a command ie same as typing it while in command mode.

   # $XDG_CONFIG_HOME/k9s/hotkey.yml
   hotKey:
     # Hitting Shift-0 navigates to your pod view
     shift-0:
       shortCut:    Shift-0
       description: Viewing pods
       command:     pods
     # Hitting Shift-1 navigates to your deployments
     shift-1:
       shortCut:    Shift-1
       description: View deployments
       command:     dp
     # Hitting Shift-2 navigates to your xray deployments
     shift-2:
       shortCut:    Shift-2
       description: Xray Deployments
       command:     xray deploy

Not feeling so hot? Your custom hotkeys will be listed in the help view ?. Also your hotkey file will be automatically reloaded so you can readily use your hotkeys as you define them.

You can choose any keyboard shortcuts that make sense to you, provided they are not part of the standard K9s shortcuts list.

NOTE: This feature/configuration might change in future releases!

FastForwards

As of v0.25.0, you can leverage the FastForwards feature to tell K9s how to default port-forwards. In situations where you are dealing with multiple containers or containers exposing multiple ports, it can be cumbersome to specify the desired port-forward from the dialog as in most cases, you already know which container/port tuple you desire. For these use cases, you can now annotate your manifests with the following annotations:

1. k9scli.io/auto-port-forwards -> activates one or more port-forwards directly bypassing the port-forward dialog all together.
2. k9scli.io/portforwards -> pre-selects one or more port-forwards when launching the port-forward dialog.

The annotation value takes on the shape container-name::[local-port:]container-port

NOTE: for either cases above you can specify the container port by name or number in your annotation!

Example

# Pod fred
apiVersion: v1
kind: Pod
metadata:
  name: fred
  annotations:
    k9scli.io/auto-portforwards: zorg::5556        # => will default to container zorg port 5556 and local port 5566. No port-forward dialog will be shown.
    # Or...
    k9scli.io/portforward: bozo::9090:p1           # => launches the port-forward dialog selecting default port-forward on container bozo port named p1(8081)
                                                   # mapping to local port 9090.
    ...
spec:
  containers:
  - name: zorg
    ports:
    - name: p1
      containerPort: 5556
    ...
  - name: bozo
    ports:
    - name: p1
      containerPort: 8081
    - name: p2
      containerPort: 5555
    ...

The annotation value must specify a container to forward to as well as a local port and container port. The container port may be specified as either a port number or port name. If the local port is omitted then the local port will default to the container port number. Here are a few examples:

1. bozo::http - creates a pf on container bozo with port name http. If http specifies port number 8080 then the local port will be 8080 as well.
2. bozo::9090:http - creates a pf on container bozo mapping local port 9090->http(8080)
3. bozo::9090:8080 - creates a pf on container bozo mapping local port 9090->8080

Resource Custom Columns

SneakCast v0.17.0 on The Beach! - Yup! sound is sucking but what a setting!

You can change which columns shows up for a given resource via custom views. To surface this feature, you will need to create a new configuration file, namely $XDG_CONFIG_HOME/k9s/views.yml. This file leverages GVR (Group/Version/Resource) to configure the associated table view columns. If no GVR is found for a view the default rendering will take over (ie what we have now). Going wide will add all the remaining columns that are available on the given resource after your custom columns. To boot, you can edit your views config file and tune your resources views live!

NOTE: This is experimental and will most likely change as we iron this out!

Here is a sample views configuration that customize a pods and services views.

# $XDG_CONFIG_HOME/k9s/views.yml
k9s:
  views:
    v1/pods:
      columns:
        - AGE
        - NAMESPACE
        - NAME
        - IP
        - NODE
        - STATUS
        - READY
    v1/services:
      columns:
        - AGE
        - NAMESPACE
        - NAME
        - TYPE
        - CLUSTER-IP

Plugins

K9s allows you to extend your command line and tooling by defining your very own cluster commands via plugins. K9s will look at $XDG_CONFIG_HOME/k9s/plugin.yml to locate all available plugins. A plugin is defined as follows:

• Shortcut option represents the key combination a user would type to activate the plugin
• Confirm option (when enabled) lets you see the command that is going to be executed and gives you an option to confirm or prevent execution
• Description will be printed next to the shortcut in the k9s menu
• Scopes defines a collection of resources names/short-names for the views associated with the plugin. You can specify all to provide this shortcut for all views.
• Command represents ad-hoc commands the plugin runs upon activation
• Background specifies whether or not the command runs in the background
• Args specifies the various arguments that should apply to the command above

K9s does provide additional environment variables for you to customize your plugins arguments. Currently, the available environment variables are as follows:

• $RESOURCE_GROUP -- the selected resource group
• $RESOURCE_VERSION -- the selected resource api version
• $RESOURCE_NAME -- the selected resource name
• $NAMESPACE -- the selected resource namespace
• $NAME -- the selected resource name
• $CONTAINER -- the current container if applicable
• $FILTER -- the current filter if any
• $KUBECONFIG -- the KubeConfig location.
• $CLUSTER the active cluster name
• $CONTEXT the active context name
• $USER the active user
• $GROUPS the active groups
• $POD while in a container view
• $COL-<RESOURCE_COLUMN_NAME> use a given column name for a viewed resource. Must be prefixed by COL-!

Example

This defines a plugin for viewing logs on a selected pod using ctrl-l for shortcut.

# $XDG_CONFIG_HOME/k9s/plugin.yml
plugin:
  # Defines a plugin to provide a `ctrl-l` shortcut to tail the logs while in pod view.
  fred:
    shortCut: Ctrl-L
    confirm: false
    description: Pod logs
    scopes:
    - pods
    command: kubectl
    background: false
    args:
    - logs
    - -f
    - $NAME
    - -n
    - $NAMESPACE
    - --context
    - $CONTEXT

NOTE: This is an experimental feature! Options and layout may change in future K9s releases as this feature solidifies.

Benchmark Your Applications

K9s integrates Hey from the brilliant and super talented Jaana Dogan. Hey is a CLI tool to benchmark HTTP endpoints similar to AB bench. This preliminary feature currently supports benchmarking port-forwards and services (Read the paint on this is way fresh!).

To setup a port-forward, you will need to navigate to the PodView, select a pod and a container that exposes a given port. Using SHIFT-F a dialog comes up to allow you to specify a local port to forward. Once acknowledged, you can navigate to the PortForward view (alias pf) listing out your active port-forwards. Selecting a port-forward and using CTRL-B will run a benchmark on that HTTP endpoint. To view the results of your benchmark runs, go to the Benchmarks view (alias be). You should now be able to select a benchmark and view the run stats details by pressing <ENTER>. NOTE: Port-forwards only last for the duration of the K9s session and will be terminated upon exit.

Initially, the benchmarks will run with the following defaults:

• Concurrency Level: 1
• Number of Requests: 200
• HTTP Verb: GET
• Path: /

The PortForward view is backed by a new K9s config file namely: