\n1. Logs\n

\n1. Deployments\n

\n\n---\n\n---\n\n## Demo Videos/Recordings\n\n* [k9s Kubernetes UI - A Terminal-Based Vim-Like Kubernetes Dashboard](https://youtu.be/boaW9odvRCc)\n* [K9s v0.21.3](https://youtu.be/wG8KCwDAhnw)\n* [K9s v0.19.X](https://youtu.be/kj-WverKZ24)\n* [K9s v0.18.0](https://www.youtube.com/watch?v=zMnD5e53yRw)\n* [K9s v0.17.0](https://www.youtube.com/watch?v=7S33CNLAofk&feature=youtu.be)\n* [K9s Pulses](https://asciinema.org/a/UbXKPal6IWpTaVAjBBFmizcGN)\n* [K9s v0.15.1](https://youtu.be/7Fx4XQ2ftpM)\n* [K9s v0.13.0](https://www.youtube.com/watch?v=qaeR2iK7U0o&t=15s)\n* [K9s v0.9.0](https://www.youtube.com/watch?v=bxKfqumjW4I)\n* [K9s v0.7.0 Features](https://youtu.be/83jYehwlql8)\n* [K9s v0 Demo](https://youtu.be/k7zseUhaXeU)\n\n---\n\n## K9s Configuration\n\n K9s keeps its configurations inside of a `k9s` directory and the location depends on your operating system. K9s leverages [XDG](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html) to load its various configurations files. For information on the default locations for your OS please see [this link](https://github.com/adrg/xdg/blob/master/README.md). 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.\n\n | Unix | macOS | Windows |\n |-----------------|------------------------------------|-----------------------|\n | `~/.config/k9s` | `~/Library/Application Support/k9s` | `%LOCALAPPDATA%\\k9s` |\n\n > NOTE: This is still in flux and will change while in pre-release stage!\n\n ```yaml\n # $XDG_CONFIG_HOME/k9s/config.yml\n k9s:\n # Represents ui poll intervals. Default 2secs\n refreshRate: 2\n # Number of retries once the connection to the api-server is lost. Default 15.\n maxConnRetry: 5\n # Enable mouse support. Default false\n enableMouse: true\n # Set to true to hide K9s header. Default false\n headless: false\n # Set to true to hide K9s crumbs. Default false\n crumbsless: false\n # Indicates whether modification commands like delete/kill/edit are disabled. Default is false\n readOnly: false\n # Toggles whether k9s should exit when CTRL-C is pressed. When set to true, you will need to exist k9s via the :quit command. Default is false.\n noExitOnCtrlC: false\n # Toggles icons display as not all terminal support these chars.\n noIcons: false\n # Toggles whether k9s should check for the latest revision from the Github repository releases. Default is false.\n skipLatestRevCheck: false\n # Logs configuration\n logger:\n # Defines the number of lines to return. Default 100\n tail: 200\n # Defines the total number of log lines to allow in the view. Default 1000\n buffer: 500\n # Represents how far to go back in the log timeline in seconds. Setting to -1 will show all available logs. Default is 5min.\n sinceSeconds: 300\n # Go full screen while displaying logs. Default false\n fullScreenLogs: false\n # Toggles log line wrap. Default false\n textWrap: false\n # Toggles log line timestamp info. Default false\n showTime: false\n # Toggles whether JSON log lines should be colorized. Default false\n showJSON: false\n # Indicates the current kube context. Defaults to current context\n currentContext: minikube\n # Indicates the current kube cluster. Defaults to current context cluster\n currentCluster: minikube\n # Persists per cluster preferences for favorite namespaces and view.\n clusters:\n coolio:\n namespace:\n active: coolio\n # With this set, the favorites list won't be updated as you switch namespaces\n lockFavorites: false\n favorites:\n - cassandra\n - default\n view:\n active: po\n featureGates:\n # Toggles NodeShell support. Allow K9s to shell into nodes if needed. Default false.\n nodeShell: false\n # Provide shell pod customization of feature gate is enabled\n shellPod:\n # The shell pod image to use.\n image: killerAdmin\n # The namespace to launch to shell pod into.\n namespace: fred\n # The resource limit to set on the shell pod.\n limits:\n cpu: 100m\n memory: 100Mi\n # The IP Address to use when launching a port-forward.\n portForwardAddress: 1.2.3.4\n kind:\n namespace:\n active: all\n favorites:\n - all\n - kube-system\n - default\n view:\n active: dp\n # The path to screen dump. Default: '%temp_dir%/k9s-screens-%username%' (k9s info)\n screenDumpDir: /tmp\n ```\n\n---\n\n## Popeye Configuration\n\nK9s has integration with [Popeye](https://popeyecli.io/), 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/_spinach.yml`. This allows you to have a different spinach config per cluster.\n\n---\n\n## Node Shell\n\nBy 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:\n\n```yaml\n# $XDG_CONFIG_HOME/k9s/config.yml\nk9s:\n clusters:\n # Configures node shell on cluster blee\n blee:\n featureGates:\n # You must enable the nodeShell feature gate to enable shelling into nodes\n nodeShell: true\n # You can also further tune the shell pod specification\n shellPod:\n image: cool_kid_admin:42\n namespace: blee\n limits:\n cpu: 100m\n memory: 100Mi\n```\n\n---\n\n## Command Aliases\n\nIn 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:\n\n```yaml\n# $XDG_CONFIG_HOME/k9s/alias.yml\nalias:\n pp: v1/pods\n crb: rbac.authorization.k8s.io/v1/clusterrolebindings\n```\n\nUsing this alias file, you can now type pp/crb to list pods or ClusterRoleBindings respectively.\n\n---\n\n## HotKey Support\n\nEntering 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:\n\n1. Create a file named `$XDG_CONFIG_HOME/k9s/hotkey.yml`\n2. 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.\n\n ```yaml\n # $XDG_CONFIG_HOME/k9s/hotkey.yml\n hotKey:\n # Hitting Shift-0 navigates to your pod view\n shift-0:\n shortCut: Shift-0\n description: Viewing pods\n command: pods\n # Hitting Shift-1 navigates to your deployments\n shift-1:\n shortCut: Shift-1\n description: View deployments\n command: dp\n # Hitting Shift-2 navigates to your xray deployments\n shift-2:\n shortCut: Shift-2\n description: Xray Deployments\n command: xray deploy\n ```\n\n 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.\n\n You can choose any keyboard shortcuts that make sense to you, provided they are not part of the standard K9s shortcuts list.\n\n> NOTE: This feature/configuration might change in future releases!\n\n---\n\n## FastForwards\n\nAs 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:\n\n- `k9scli.io/auto-port-forwards`\n activates one or more port-forwards directly bypassing the port-forward dialog all together.\n- `k9scli.io/port-forwards`\n pre-selects one or more port-forwards when launching the port-forward dialog.\n\nThe annotation value takes on the shape `container-name::[local-port:]container-port`\n\n> NOTE: for either cases above you can specify the container port by name or number in your annotation!\n\n### Example\n\n```yaml\n# Pod fred\napiVersion: v1\nkind: Pod\nmetadata:\n name: fred\n annotations:\n k9scli.io/auto-port-forwards: zorg::5556 # => will default to container zorg port 5556 and local port 5566. No port-forward dialog will be shown.\n # Or...\n k9scli.io/port-forwards: bozo::9090:p1 # => launches the port-forward dialog selecting default port-forward on container bozo port named p1(8081)\n # mapping to local port 9090.\n ...\nspec:\n containers:\n - name: zorg\n ports:\n - name: p1\n containerPort: 5556\n ...\n - name: bozo\n ports:\n - name: p1\n containerPort: 8081\n - name: p2\n containerPort: 5555\n ...\n```\n\nThe 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:\n\n1. 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.\n2. bozo::9090:http - creates a pf on container `bozo` mapping local port 9090->http(8080)\n3. bozo::9090:8080 - creates a pf on container `bozo` mapping local port 9090->8080\n\n---\n\n## Resource Custom Columns\n\n[SneakCast v0.17.0 on The Beach! - Yup! sound is sucking but what a setting!](https://youtu.be/7S33CNLAofk)\n\nYou 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!\n\n> NOTE: This is experimental and will most likely change as we iron this out!\n\nHere is a sample views configuration that customize a pods and services views.\n\n```yaml\n# $XDG_CONFIG_HOME/k9s/views.yml\nk9s:\n views:\n v1/pods:\n columns:\n - AGE\n - NAMESPACE\n - NAME\n - IP\n - NODE\n - STATUS\n - READY\n v1/services:\n columns:\n - AGE\n - NAMESPACE\n - NAME\n - TYPE\n - CLUSTER-IP\n```\n\n---\n\n## Plugins\n\nK9s 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:\n\n* Shortcut option represents the key combination a user would type to activate the plugin\n* 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\n* Description will be printed next to the shortcut in the k9s menu\n* 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.\n* Command represents ad-hoc commands the plugin runs upon activation\n* Background specifies whether or not the command runs in the background\n* Args specifies the various arguments that should apply to the command above\n\nK9s does provide additional environment variables for you to customize your plugins arguments. Currently, the available environment variables are as follows:\n\n* `$RESOURCE_GROUP` -- the selected resource group\n* `$RESOURCE_VERSION` -- the selected resource api version\n* `$RESOURCE_NAME` -- the selected resource name\n* `$NAMESPACE` -- the selected resource namespace\n* `$NAME` -- the selected resource name\n* `$CONTAINER` -- the current container if applicable\n* `$FILTER` -- the current filter if any\n* `$KUBECONFIG` -- the KubeConfig location.\n* `$CLUSTER` the active cluster name\n* `$CONTEXT` the active context name\n* `$USER` the active user\n* `$GROUPS` the active groups\n* `$POD` while in a container view\n* `$COL-` use a given column name for a viewed resource. Must be prefixed by `COL-`!\n\nCurly braces can be used to embed an environment variable inside another string, or if the column name contains special characters. (e.g. `${NAME}-example` or `${COL-%CPU/L}`)\n\n### Example\n\nThis defines a plugin for viewing logs on a selected pod using `ctrl-l` for shortcut.\n\n```yaml\n# $XDG_CONFIG_HOME/k9s/plugin.yml\nplugin:\n # Defines a plugin to provide a `ctrl-l` shortcut to tail the logs while in pod view.\n fred:\n shortCut: Ctrl-L\n confirm: false\n description: Pod logs\n scopes:\n - pods\n command: kubectl\n background: false\n args:\n - logs\n - -f\n - $NAME\n ","has_starred","hub_user","immutable_tags_settings",{"_138":11,"_139":140},"enabled","rules",[141],".*","is_automated","permissions",{"_145":17,"_146":11,"_147":11},"read","write","admin","user","storage_size",45013257925,"isOrg","reponame","tag","sha256:b97e0b5ccfa495e8f0bdbed6458336a4f7b890baf1cb47ed7c9eb2ed41f6616e","canDeleteTags","isHubSbxKitsEnabled","currentTab","tagAttestations","displaySecurityMetadata","routes/_layout.layers.$namespace.$reponame.$tag.(images).($imageUrlDigest)._index",{"_23":24,"_100":-7,"_98":-7,"_99":-7,"_25":162,"_31":154,"_165":-7,"_166":11},{"_27":28,"_29":30,"_31":32,"_33":34,"_35":36,"_37":163,"_56":57,"_58":30,"_59":60,"_61":62,"_63":64,"_65":66,"_67":45,"_68":57,"_69":54,"_70":17},[164],{"_40":41,"_31":32,"_42":43,"_44":45,"_46":47,"_48":49,"_50":43,"_51":-5,"_52":34,"_53":54,"_55":-5},"imageWithLayers","hasPermissionToViewRepoSettings","actionData","errors"]

derailed/k9s:latest